Could the Propeller 2 be used as an I/O controller for a Gigatron TTL computer?
The Gigatron TTL computer has no ASIC CPU and uses 74xx series ICs to make a Harvard RISC CPU. All native instructions are single-cycle. A stock one operates at 6.25 Mhz. Because it is a Harvard machine and cannot execute out of data RAM, it uses the vCPU interpreter to run user code. It is a minimalist machine in that the CPU handles everything via bit-banging. The Gigatron has no interrupts and no easy, obvious way to do DMA, though I have ideas in mind for that. The native code uses time-slices and everything there is cycle-exact.
For video production, there are specialized instructions. The most used instructions there have the ability to read RAM, perform a logical operation, send the data to the Out port, and increment the memory index, all in a single cycle. Since the VGA pixel clock is around 25 Mhz, the Gigatron uses 6.25 Mhz to produce 1/16 VGA. To keep the aspect ratio, the lines are sent 4 times each. So the result is 160x120 pixels. There are only 64 colors because the upper two bits of the port are the sync bits. So the video output logic ignores the upper 2 bits of memory. So coders can use those 2 bits per frame buffer byte as they see fit. As an optimization, there is an indirection table for the frame buffer. That is just a list of 120 pages and offset addresses. That makes it easy to do scrolling, screen flipping, line substitution, etc. It's easier to virtualize lines than to blit them. So each line gets its own page, and the remaining 96 bytes can be used for either program code or for additional graphics data. This makes it easy to do a Pole Position sort of game, and changing the offset in the indirection table lets you use the other additional data past the lines. Since the video uses the Out++ instructions, and they only increment the X register, the lines can wrap around.
Sound is produced from the horizontal frequency. For each actual line (1/4 of a virtual line), 1 sound channel is handled. The channels are added and shifted to create the final output. Due to this mechanism, sounds above 3900 Hz are not possible. That makes sense if you think about it. The Nyquist frequency is 1/2 the horizontal sync, and since you have 4 channels, the maximum range is no more than 1/4 that. Now, while there are 6-bit sound samples in the sample table, the code reduces this to 4 bits and sends that to half of the X-Out register.
Blinkenlights is done using the other half of the X-Out register and is handled independently of the sound.
The game controller (and keyboard port) goes to a shift register, so the In port is a serial port. To make a keyboard work, an Arduino of the PluggyMcPlugface adapter handles that, and I assume it does ASCII conversion too. Pluggy also adds some limited storage I/O abilities, and at least a version 3 ROM is needed to handle that. This is polled every vertical pulse, and I assume written to a memory location.
What I want the Propeller 2 to do and questions
I need the Propeller to snoop the SRAM bus asynchronously and shadow what is on the Gigatron into the hub RAM, at least at specific locations, though it may be easier to just shadow the first 32K. Then I would need the cogs to read from the hub RAM to support video output, sound, Blinkenlights output, keyboard/game input, and maybe an SD card.
Will I be able to send to and from the hub memory fast enough? I imagine I can. If that is a challenge, I guess I could use 2 cogs for that. Use one cog to copy from the hub to LUT memory and one to copy from the LUT to the hub.
Now, how would I produce VGA on the P2 in assembly? Does the P2 have the same VGA abilities and character table as the P1? Or would I need to manually bit-bang it from a cog?
As for transferring from the Gigatron, that would mostly be via SRAM bus snooping. For the keyboard/game input, I could probably do lazy writes to the Gigatron's RAM. Being a Harvard machine, the RAM won't be in use all the time, so writes should be able to occur during those times.
On the snooping, I am not sure what the best way to cross clock domains would be. There probably needs to be spinlocks or something so the I/O lines would be read long enough. I figure that maybe I'd need the Gigatron's clock (probably the Clock 2 line) as an input. And I'd probably need to read the /OE and /WE lines. The /WE would be the main line to pay attention to, but /OE can't also be low. For other add-on boards, both control lines being low would be used to pass commands directly from the CPU, and maybe separate hub memory could be used in that case, but it shouldn't be allowed to overwrite existing memory.