smaller (and not serious) nitpick, WDC is Western Design Cent
er, not Western Design Cent
re, atleast that's what it says on their site
barnacle wrote:
if (WD or WDC) were to release a version of the 6502 which could execute directly from a serial SPI memory, I'd be first in line...
man i would be so hyped if WDC were to redo the 65c265 to be more like a modern Microcontroller...
programmable flash, useful amounts of internal Memory, hardware IO controllers for things like SPI, I2C, UART (without needing to use a timer to generate the baudrate), actual 32-bit timers, internal system clock and clock divider so you can run it without an external clock (like AVR chips). and of course have the core run at >20MHz natively, with programmable wait states for external accesses (which i think already exist on the current 65c265).
anyways, sick project! i've never seen this Serial to Parallel IC before.
it's like TI extracted the receiving half of a UART, set it into free-run mode, and put it into it's own chip.
acording to the datasheet it has a maximum "data rate" of 24kbps. though i don't know how to intepret that.... is it the rate of actual data you transfer (4 bits of data for 10 bits of packet), or the raw amount of bits it can handle per second (baud rate), if it's the latter then 19200 is the highest standard baud rate it would officially handle.
though i guess speed is not really that much of a concern when all they do is boot the SBC.
but why stop at just one? if you're able to reset and boot the board over UART, and the SBC itself also has a UART (or ideally a DUART), then couldn't you just daisy chain them to create a basic network of 6502's? (with the first one in the chain being connected to a PC or similar self-booting system)
but for that to fully work, the UART connection to the 8153's should go through a demux IC, so by default it points to the 8153's, and after the boot process is done and the CPU is executing code, it can write to some onboard register to manually switch the demux to point to the receiving side of the onboard (D)UART instead.
that way you only need 1 combined UART header, and after booting it turns into a regular bi-directional UART interface. or rather 2 headers, one for the combined booting/regular UART, and one for the other regular UART.
the reason i would have the CPU do the switching manually is so that you cannot accidentally put the board out of booting mode without the CPU running valid code first.
also then i would include some onboard LEDs, because everything network related needs fancy blinking lights
anyways, again interesting project, was just throwing my 2 cents into it.