Project Logs

Collapse

• Starting the Project -- Deciding How to Use the GPIO Lines

  Courtney • 05/29/2020 at 19:54 • 0 comments

  Starting the Project -- Deciding How to Use the GPIO Lines

  The CMOD A7-T35 will not be as easy to work with as I first thought, due to the necessary signals. You'd think that 44 pins from a DIP socket and 8 more from the PMOD socket, for a total of 52, would be enough. If you need 16 for the peripheral bus, and 34 for the memory, that is already 50 pins. Assuming 16-bit addresses and 16-bit data, and 2 control signals, that gives 34. However, it would be nice to have 3-4 more address lines and maybe some handshake lines for the IO port.

  One idea on how to manage this is to make this closer to being an SOC. Since the A7-T35 board includes 512K of SRAM, it can use 19-20 bits addressing that stays internal. Or alternatively, you could free up 8 lines by having only 8-bit memory access like the IBM XT. However, this could be different in that internal block RAM can be 16-bits, while access to the onboard SRAM (since that is the width used on the board) or any external RAM could be 8-bits. Plus the multiple RAMs might have the advantage of simultaneous I/O. A disadvantage would be having to do address translation.
  

  If the memory addressing is only done internally, then the I/O bus port could be the only means of access to external devices. That would also mean that it would need some control lines and perhaps some port address lines.

  A thought on what to do if more memory is needed could be to make a simple SSD as a port device, but without a file-system. That would not be optimal since the port bus would be multiplexed for addresses and data, but it could have a streaming mode that works much like a block copy. Then it could be used as a swap file.

  The 16-bit I/O bus is a feature I'd like to keep since it could be used flexibly for video. For instance, for 64-256 color mode, the high byte could be used to send control signals. Or all bits but 1 can be used for 32K color mode. There could also be text mode and monochrome graphics mode.

  Sound is still undecided. It is possible to do simple PCM over a single wire. However, 4-8 bits would be better, allow for digital volume control, and allow for shaping the waveforms from a table.

  Random Number Generator

  A hardware random number function would be nice. That could be implemented wherever the sound, video, and keyboard are integrated. That would be easiest since having 2 unrelated clock signals nearby would allow for ANDing the signals and getting random bits. The pixel clock would be one good clock source. If the sound uses a different clock that is not derived from the pixel clock, it could be a random number source. Then there is the keyboard. It has around a 15.5 KHz clock, but it is only active when the keyboard is in use. It is done that way to facilitate writes to the keyboard. The computer would force the keyboard clock line high for a short duration then hold the data line low for a short duration. Then the keyboard is active as an output device so you can toggle the locks, change the typematic delay, or query it for an ID. However, when the keyboard clock is active, it is available as a random number source. Since the keyboard and sound are unreliable as RNG sources, there could be a small cache for holding random numbers when they are available. If that is insufficient, there could be a pseudorandom number generator as well. A random number generator would be good on the same chip as the video and sound to help produce white noise and "snow." For instance, depending on the boot delay, the video output and sound could be "snow" during this time to add some nostalgia from the time when home computer users used NTSC TV sets with their computers.

View project log