Close
0%
0%

Gigatron I/O and RAM expander

Adding four SPI ports and up to 128K of banked RAM using nothing more than 4 TTL chips and some wizardry.

Similar projects worth following
The Gigatron is a single board 8-bit TTL computer without microprocessor. It can run video games and BASIC. See https://hackaday.io/project/20781-gigatron-ttl-microcomputer

What's still lacking, is more I/O. We want MUCH more I/O. Our goal is to expand the system with four SPI interfaces, so that it can access MicroSD cards, IoT gadgets or up to 64 GPIO pins using standard MCP23S17 port expander chips. The challenge is to stop thinking about this and to start building a working prototype. Including proof-of-concept software for at least controlling an array of LEDs. Of course all while preserving the Gigatron's minimalistic style!

When the Gigatron was born 1 year ago, it was like an early microcomputer. Last summer we added a keyboard interface and BASIC. That turned it into a home computer. Now we want a personal computer...

The idea is to transform the RAM socket into an expansion bus in which we plug a small daughterboard. This little board will have a socket to reseat the original RAM, as well as some glue logic for the new I/O capabilities.

Expanding the RAM

Expanding the memory is an easy by-catch: the original RAM socket is 28-pins for the 32K RAM chip (62256). It has just 15 address lines (A0:14). The sixteenth line (A15) is only available as a breakout on the mainboard. You don't need it for working with 32K, but you need it when you have more memory. If we bring that A15 signal to the daughterboard with an extra wire, we can increase the addressing space. 32-pins memory chips exist in 64K and 128K sizes (62512 and 628128). Their pin layout is compatible: you can put the smaller chip in the larger socket, and it will work!

(Actually, if you just want 64K, you don't even need a daughterboard, as shown on the photo above.)

Access to output

It's a lot less obvious how to expand the I/O: there simply aren't enough user controllable signals going to the RAM socket. Next to the address and data bus, there are only a READ signal (/OE, for Output Enable) and a WRITE signal (/WE, for Write Enable). RAM doesn't need more... One idea is to map the I/O actions into the address space. But this runs into practical issues we won't delve into here.

The solution is to abuse the Gigatron's orthogonal instruction set. In the Gigatron, writing is controlled by the upper 3 bits in the opcode. Those bits select the operation. Reading is controlled by the lower 2 bits that determine who accesses the bus.

The magic trick is that we can activate a simultaneous READ+WRITE to give access to our new I/O capabilities... No smoke will escape, but normally this combination results in writing undefined data into the RAM. With a little bit of glue logic, we will repurpose this combination to give access to the I/O port:

/WE_PORT = /OE | /WE

We just hacked and extended the native instruction set with a single OR gate! Problem solved. Well, except that the data bus is not accessible when /OE is low, so where does our data go? That will have go on the address bus when we invoke this new mode.

The I/O logic will have one 8-bit register (74x273) for the output lines. We assign each bit a meaning: MOSI, SCLK, /SS0, /SS1, /SS2, /SS3. These signals branch out to four SPI ports (Serial Peripheral Interface).

With SPI you can interface with MicroSD cards, sensors and IoT gadgets. There's also the popular MCP23S17 chip that turns a SPI channel into 16 GPIO pins. Imagine the possibilities: a RAID with SD cards? 64 GPIO pins?

Access to input

The returning four SPI data lines are fed into a 4-bit buffer chip (74x125) which connects back to the Gigatron data bus. This chip will be allowed to write onto the bus during an I/O action (meaning: when SCLK is HIGH). From a machine code point of view, this looks like a well-timed memory read.

... Read more »

ROMv3x.rom

Experimental ROM image based on ROM v3 release

rom - 128.00 kB - 03/09/2019 at 08:25

Download

Expander-schematic.pdf

Circuit diagram

Adobe Portable Document Format - 186.85 kB - 03/02/2019 at 13:42

Preview
Download

  • 1 × 74LS00 Quad NAND
  • 1 × 74LS32 Quad OR
  • 1 × 74LS125 Quad Non-Inverting Buffer
  • 1 × 74LS273 Octal Flip-Flop

  • Success! Now we can have 512 GPIO pins

    Marcel van Kervinck03/11/2019 at 23:51 0 comments

    In this video I control some GPIO pins over SPI from a Gigatron TTL computer with the expander prototype. The chip on the breadboard is an MCP23S17 16-bit I/O chip with SPI interface. Because this is the retro challenge RC2019/03, I wrote the test program on paper and toggled it in using the WozMon. Then I started filming:

    It works the first time! The test program first configures 8 pins as outputs, and then continuously copies over the Gigatron's 60 Hz frame counter. There are two SPI commands involved:

    40 00 00 ; Set PORTA to all-output
    
    40 14 xx ; Send byte value xx to PORTA

    It turns out this chip is addressable and can share select lines without causing contention on the MISO line: it keeps its SPI output in high-impedance unless addressed for reading. There are 3 pins for setting its hardware address, giving 8 addresses. We have 4 ports, so we can effortlessly hookup 4x8x16 = 512 GPIO pins...

    The next step would be talking to an MicroSD card using the AdaFruit breakout board. (SparkFun has a similar one.) You can see it's already installed on the breadboard. These breakouts come with voltage level shifters, so they should work just like that.

  • Driving SPI with the WozMon

    Marcel van Kervinck03/09/2019 at 13:34 0 comments

    The board is now integrated. Regular pin headers won't fit in the machined RAM socket: a square peg doesn't fit a round hole, literally. You need machine pin headers. Luckily the local electronics shop had a couple. After fixing a cycle counting bug in the driver code, I decided on using the WozMon for testing the board. With an LED I could easily determine that I can drive the enable lines of each SPI port. The next step is to send data. Here is what it looks like:

    It looks promising on the scope. We are sending out the expected data while the Gigatron maintains its video signal. The longer gap is caused by a VGA pixel burst, during which the application is stalled. However, the input comes in as all-ones where we expect all-zeroes. The input lines looks noisy as well. As if the pull-down resistors don't do anything. [Edit: And that was exactly the case: bending over the resistors had broken off some of them.]

    To be continued...

  • Will it work?

    Marcel van Kervinck03/08/2019 at 16:08 0 comments

    While waiting for the prototype board, it became clear that some small changes are desirable for much easier programming. Today the board came in and it's already obsoleted. To test our ideas, we add two patch wires and change the resistors from pull-up to pull-down. The pins for banking will also change, but I didn't bother to patch those as I put in the original 32K chip anyway. Nothing is socketed, so it fits inside the existing enclosure. Will it work?

View all 3 project logs

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