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 general purpose I/O. You can toy with the 4 blinkenlights, but we want MUCH more. Our goal is to expand to four SPI interfaces, so 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 a row 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 and BASIC. That turned it into a home computer. Now we want a PC...

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 »

Expansion 1906.zip

CAD files

Zip Archive - 545.76 kB - 12/28/2019 at 00:57

Download

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

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

  • Untethered!

    Marcel van Kervinck12/15/2019 at 14:57 0 comments

    As of yesterday, DEVROM itself can detect a memory card during reset. When detected it will continue to boot from there instead of jumping to the built-in main menu. This means you don't need the Arduino route anymore when playing with the expander.


    Naturally everything still needs refinements. But from here we can theoretically bootstrap an entire new system without ever updating the EPROM again, and without being tethered to a laptop/PC.

    Some unrelated but noteworthy recent updates:

    • Preliminary interrupt support is now available (vIRQ)
    • We have the ROM files discoverable with a new function: SYS_ReadRomDir. With this we can iterate over the built-in files and get their ROM address for reading. I can see this become useful in a simple command line shell. Or for making libraries.
    • TinyBASIC now accepts hexadecimal numbers ($....) in expressions. This could be squeezed in without sacrificing free bytes.

  • First conversation with SDCard

    Marcel van Kervinck09/01/2019 at 13:04 0 comments

    First messages exchanged with a physical memory card. "Reset" (aka CMD0) puts the card in SPI mode. "Version" (aka CMD8) is the canonical method to check if the card is ok. The reply bytes come from the card and are the expected value (0x01).

    A few hours later we can correctly initialise the card and detect the card type:

    Update: And here's the root directory. It takes a bit of 32-bit arithmetic to locate it correctly. You can see the volume label in the first slot. It reads "GIGATRON".

    Update 2: and here is a proper listing:

  • Roadmap for Gigatron expander

    Marcel van Kervinck05/19/2019 at 21:02 0 comments

    As usual, the hardware turns out to be easier than the software. So where can we take this now that we've covered the hardware support for SPI, memory cards and 128K of banked memory? It's clear to me that this subproject must aim for proper FAT filesystem R/W compatibility. Not some halfway solution with image files. But I really don't feel like coding it from scratch in vCPU. @roelh has suggested FatFs. But that needs a C compiler...

    But I don't feel like porting FAT support from C either. Are we stuck?

    In Seattle I briefly met with [Pat Gavlin]. A month later he surprised the world by announcing that he's retargeted LCC to the Gigatron vCPU. Just wow.... HaD covered it recently. This is a proper ANSI C compiler (C89) with fancy stuff such as strength reduction and common subexpression elimination. One of the great things about Pat's backend is not just that it targets vCPU, but moreover that it overcomes the Gigatron's non-linear memory address space: C programs "see" a fairly standard environment. Currently we're still ironing out the bugs that you inevitably bump into when compiling larger programs. And we're working on the C library. For example, printf is working already.

    Now a roadmap starts to sketch itself:

    1. Bring the compiler to an acceptable maturity level
    2. Do memory card block reading and writing over SPI using C
    3. Add file system support using FatFs
    4. Expand the C library
    5. Add a DOS or some other operating system! Maybe an early version of MINIX? Alan Cox' FUZIX? Joerg's MXE11? (Any other suggestions?)

  • Full recovery & mission accomplished

    Marcel van Kervinck03/31/2019 at 14:34 6 comments

    After returning from the VCF, three things needed recovery: 1. the jetlag, 2. a stomach bug and 3. the little brittle breadboard with dummy peripherals. Today it all worked again. And even better: the SPI test routines now load from my laptop into the Gigatron (through an Arduino Uno that acts as a bridge). Now I don't have to type in hex codes anymore, and that should help with our follow-up project: talking to the MicroSD card.

    A glimpse of the mountain that is now ahead of us:

    And that's just for initialising the card, so you know you can talk to it. The best thing of this? This reassuring quote:

    "This is just one example of such an initialization sequence. [...] It’s possible that it may work or not depending on the type of card you use and on its manufacturer. Other similar such flowcharts exist. [...]  Most of the times, you will have to try to implement several of them until you will get it to work"

    Now imagine deciphering the FAT file system on top of that. This can easily take the remainder of the year to get right.

    Down the rabbit hole we go...

    Source: http://www.mayumitokuda.com/2d-illustration/art-stuff/7246032

  • VCF inspiration

    Marcel van Kervinck03/26/2019 at 18:55 2 comments

    I needed some inspiration before resuming with the I/O expander, so this weekend I visited the Vintage Computer Festival in Seattle. 

    It's only a 10 hour flight. There are ways to deal with that, such as watching 3.5 movies per leg.

    Seattle is a friendly place and great for playing tourist.

    The Aquarium is nice too. But why does its restaurant serve fish?

    The festival was held at the late Paul Allen's Living Computers Museum + Labs.

    Every computer museum must have an Enigma machine of course.

    But how many PDP-10's does your museum have in its basement?

    PDP units everywhere... Here some PDP-12, PDP-11 and PDP-8 processors and front panels.

    When you have a Cray-1 on the main floor just as a visitor's bench, the Cray-2 can sit in storage.

    An original Apple 1 that needed some reprogramming. They have three such ultra rare machines on display, but none are even mentioned on the website...

    I found Richard Greenblatt and a couple of CADR aka LISP machines in the attic. It's part of what makes it a Living Museum I guess.

    How the LISP machine is wired.

    And how the Cray-1 is wired.

    Richard and a PDP-6 front end, with his Mac Hack Six chess program running in the background.

    Part of the VCF show just before opening. You can see my exhibit of two Gigatrons in the center. I only brought one: the Gigatron that I'm using for the I/O expander project. The other I borrowed... believe it or not.... from the museum itself. How bizarre is that.

    Driving simulator shootout. All right, we'll call it a draw.

    I almost bought this laser videodisc, but it was bundled with the player and I didn't want that.

    The result of all of this is a slightly improved version of the LED blinking program. 

    It controls 16 LEDs using the following SPI commands to the MCP23S17:

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

    Blinking lights are essential for vintage computer shows, especially when your table is next to Oscar Vermeulen's fabulous mini PDP-replicas.

  • 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 8 project logs

Enjoy this project?

Share

Discussions

aldolo wrote 04/18/2021 at 18:08 point

wow... just realized you passed away... rip and thanks for your knowledge.

  Are you sure? yes | no

aldolo wrote 04/18/2021 at 18:05 point

great. are you one of the original gigatron developers? i have not been able to understand the opcode decoding.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

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