Close
0%
0%

Sugarplum

A homebrew computer that is implemented using the Digilent CMOD A7-T35 FPGA board.

Public Chat
Similar projects worth following
This is my first attempt at a homebrew computer. I will be using at least 1 Digilent CMOD A7-T35 FPGA board. Due to there possibly not being enough GPIO lines, I may have to divide that across two FPGAs.

Proposed features:

* 16-bit homebrew processor, may do some 24-bit ops.
* 16-bit I/O port to ease doing a homebrew GPU.
* 20 - 24 bits memory addressing.
* 3+ channel sound, perhaps 3 square-wave channels and a noise channel. 4+ channels would be nice.
* PS/2 keyboard support.

Wishlist:

* Hardware sprites.
* 4 or more sound channels, preferably in tune when used for music.
* Perhaps an alternate 434 Hz middle-A frequency tuning set if music notes are sent.

Caveats:

* This project may exceed the ability of the CMOD A7-T35 in terms of available pins. It is possible that it may need to be split between two of them, perhaps one for the CPU and one for a multi-I/O controller.

  • 1 × Digilent CMOD A7-T35 FPGA board

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

    Courtney05/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

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates