12 hours ago, paulscottrobson said:
Actually the X8 is way closer. The original plan was something that was going to cost $30. I don't think that's doable, maybe as a DIY kit just, but there's a thing called the ZX-Uno which is effectively a Superspectrum, which is something like $60-$80 to produce I think. You could probably design it for less now.
The "real hardware" design came later.
Though the original plan was something that was going to under $50 and made from off the shelf ASIC chips, which was an internal contradiction.
The "phase 1" (X16p) and
"phase 3" (X16e) plan eventually emerged from that contradiction. And of course, the X8 emerged as a proof of concept of the X16e.
12 hours ago, paulscottrobson said:
It's cheap, technically feasible and nearly the same thing. I don't know if it has external RAM or uses Block RAM, but effectively what it does is move the 6502 into the FPGA rather than existing as a seperate chip.
It's already too many black boxes. Aside from obviously Vera which now does most of the sound and all the graphics, there are microcontrollers and all sorts to make it work. It's a black box already. If you want the bells and whistles do Ben Eater's course. If you want to build a kit, it could probably be a kit.
I think it's a no-brainer personally. Largely because if nothing happens soon the project will die.
It appears that it is just the same internal 128KB single port RAM in the same FPGA as the Vera was designed on. Vera has 128KB internal RAM accessible at the 50MHz dot clock because that member of that FPGA family has a 1Mb SPRAM module. Take half of it and make it 65C02 system RAM, keep the other half for the Vera routines, add some more secret sauce,
voila, X8.
This black box argument doesn't seem like it is likely to persuade many people who are not already inclined to agree with it. The Video and Audio chips being "black boxes" in that sense was normal in the 80s. If an in-stock tile and sprite video chip was still in production, then it would have been a black box too. The micro-controller is a white box. Serial is going to be bit banged on VIAs, which is very white box. The PS/2 ports are either going to be bit banged on VIAs or run on code on the micro-controller, so they are white box one way or the other.
The biggest feature creep of them all was adding bit-mapped graphics modes, but as long as the bit-maps are used as the equivalent of painted canvas backgrounds in the theater it's still in the spirit of 8bit graphics. Luckily they didn't give in to the demands for more feature creep with more built in Vera functions to support faster bitmap rendering on the fly, or else there wouldn't have been the logic resources to spare for the X8 to include the full Vera operations and the 65c02 core as well.
12 hours ago, paulscottrobson said:
Hardware's not my thing, but couldn't you just have an I2C port on the FPGA for expansion ? Then if you wanted (say) a classical user port you could get an Arduino to do it, maybe.
The issue is pins ... there appears to be at most one spare X8 pin, and that might not be truly available ... it might be stranded by logic resources used for other things. To get two free pins, you need to overload the I2C on something that already has a purpose. If the unofficial information in circulation is correct, the most obvious candidates are the two pins used for the debug serial interface, which
@Wavicle describes as being "connected to a UART driver and accessible to software via I/O registers", but since that will already be on pins, I would prefer if that could be left open as a two line serial port.
And also, there might not be sufficient logic resources to do that overlay, especially since you want the two wire debug serial access to be able to work even when the internal register has set the port to I2C.
What may be possible is to make the existing SPI interface available on a block pin header with independent selects. Two chip selects are already done, one for the SD card, one for the serial flashROM (I presume the bootloader loads from a specific location in the flashROM, since at 512bytes fitting an SD card read routine would be challenging). They are decoded internally .. %10 selected one, %01 selects the other, %00 and %11 turns off both. Taking out the internal decode and decoding them externally seems like it would allow for setting up the SPI expansion bus ... a 2>4 decoder would generate the SD select and serial flashROM select lines. A third select line could select a serial shift register, into which you could write the state of the eight "external" select lines. Then the fourth select line would enable the output of the eight external select lines. With the output high impedance when output is not enabled, pull up resisters would ensure that the external selects are only low when they are set low in the serial shift register AND the output is enable.
So you could have a block pin header with SPI MOSI, MISO, SCLK, +3.3v, GND and CS0-CS7.
Even more speculative than the above (speculative^2), if the unused pin is an actual spare pin and not just stranded, it might be given to an alert pin which shows up in the SPI control register. That would have to be polled if it was used, unless there is the spare logic to have a setting to allow it to trigger the 65C02 IRQ.
Just put an SPI GPIO extender on a hat, and you have a User Port. Or you can have an RTC, or an RS-232C interface with hardware flow control, or ... well, since what happened when SPI faded a bit relative to I2C (when the faster I2C protocols became established) was a a portion of the market accepting both SPI and I2C for serial I/O, there is quite a lot that can be done if you have an SPI bus with enough selects. And of course you can talk to modern microcontroller SBCs as well: I'm thinking an RPi nano hat would be straightforward.
12 hours ago, paulscottrobson said:
The Next and the M65 are pretty much entirely FPGA, they just have external RAM (which may be worth considering for the X8 ? Thinking of Grant Searle's work here). You can have a working M65 now, you just need a Nexys A7 board.
I have been guessing that external RAM would be the biggest cost driver ... both the RAM itself and the cost of the larger FPGA with enough pins to increase from 5 address pins to 22 or 24 ... behind David's estimate that the X16e would cost roughly twice what the X8 does ... so where the X8 might cost in the range of $35-$50, the X16e might cost in the range of $70-$100.
For me, if the X8 can be given SOME way to have expansion hats, the $35-$50 price range really sets it ahead of the X16e. The load and run compatibility with the X16p/X16c would be nice, but without the slot, it's only "compatible until I make a card to go into the slot". Without the option for a bus mastering card, the X16e is much more locked down than the X16p/X16c.
So in THAT sense, the bootloader "load BIOS code to RAM and run it" approach is actually more in line with the X16p/X16c than the X16e is, and at half the price.
Once I worked out that the video RAM can be used to store program data that has nothing to do with video functions ... the only thing I'd really want to add to the X8 is some way to put a hat on it.