GTXL Gigatron clone computer with keyboard

Microcomputer that runs without a CPU

Similar projects worth following
This project is a clone of the Gigatron computer project called the GTXL in honor of the second generation Atari XL computers. The Gigatron is designed to be a full 8-bit computer which does not require a CPU. Only simple 7400 series in-production chips are used.

My goal is this clone is 100% reverse compatible while adding some new functionality.

1.  Built-in 63-key keyboard
2. 128kB RAM
3. Cartridge slot for new PROMs
4. New instructions ST AC -> [X,D] and ST AC -> [X++,D]
5. Audio input
6. 4 Parallel inputs from DB9 connector
7. Hi-resolution mode (double screen width)

Much like the Apple 1 computer which did not come with a keyboard, the second generation did.  This made the computer much more approachable to novices.  I borrowed heavily from the mechanical keyboard culture to create a custom key layout using the Cherry MX key footprint.

The cartridge slot makes it possible to create cartridges much like the old Commodore 64 and Atari 400/800 style of computers.  It also aids in development of new ROM code.

The new instructions make block memory copying easier.  This is helpful for things like sprites or arrays of data.

The audio input can be used for old-school style program storage.  With the advent of BASIC built-in on the ROM, support can be added for audio-out and audio-in data storage.  Store your programs on your smartphone!

The Hi-resolution mode doubles the width resolution of the screen.  This drops the color resolution to 3 bits, but could help significantly in BASIC program development.

  • All but keyboard soldered

    Justin Davis11/28/2018 at 20:30 4 comments

    I have everything but the keys and diodes are soldered on.  The board should be able to run the ROM code.  Except it doesn't.  I burned the ROM and it doesn't seem to be running the code.  It does appear to be running SOME code, but not the correct code.  I'm wondering if I perhaps burned the ROM incorrectly.  I need more time to investigate, but it does not execute the first few instructions which can easily be probed on the board.  I can read the code back off the ROM, so I know it's burned.  I'll need to decode each instruction to verify it's correct, but more time is needed which I have very little of lately.  I need to retire so I can have more fun with hobbies.  Unfortunately I have at least another 20 years to go...

  • Building

    Justin Davis11/14/2018 at 13:01 4 comments

    Still building - not quite to blinking lights yet.  Lots of soldering.  I ran out of 20-pin sockets, so I had to put some on order.  I also didn't realize I had no 750 Ohm resistors.  I've also been seeing if there's a drop-in ZIF socket for the ROM, but I haven't found one yet.  I probably should have thought of that during layout.  It may help if I do lots of ROM updates.  More likely I will just build the cartridge with reprogrammable memory.  

    While I'm waiting I can start loading chips and testing starting with the ALU and then the X/Y registers.  I'll wait for the Cherry MX keys until I have everything else checked out since they are fairly expensive (at 63 of them are).

  • Build update

    Justin Davis11/01/2018 at 16:04 3 comments

    I've been building the GTXL one step at a time and checking as I go.  So far, the power system, clock, program counter, IR/D registers, and control system is working. 

    I made one mistake with the diodes.  The artwork is reversed, so I installed all the diode backwards.  Installing (and removing) those diodes is pretty time-intensive, so it set me back quite a bit.  But everything else is ok so far.  

    I'll probably do the ALU next followed by the X/Y registers.  I want to build up and test all of the existing functionality before I move on to the added functions.

  • PCBs are in

    Justin Davis10/19/2018 at 12:37 0 comments

    I received my PCBs today from PCBWay.  The Gigatron guys gave me a coupon to use for the board which made them FREE (thanks guys!).  I've ordered maybe a dozen designs from PCBWay before, and I've never had any problems.  Hopefully the tariffs don't make the price go up too much because they have always had great prices and great quality.  

    They look good on first inspection.  They feel larger than I was expecting.  It's probably the largest board I've ever made, but I wasn't exactly trying to minimize the space.  The width of the keyboard set that dimension, but I could squeeze the length.  I wanted to keep the same component layout so it looks the same as the original Gigatron.  I don't expect there to be a big demand for this, so these might be the only 5 boards that I get made.

    Now I just need some time to assemble.  I think I have all the parts for it.  I was planning on using sockets for everything since this is a prototype just in case I have rewire things.

  • Cartridge design

    Justin Davis09/28/2018 at 17:12 0 comments

    I've made a cartridge which matches the slot to verify the pinout.  It has two flash chips.  It's a little bigger than I expected, but that's because of the DIP through-hole packages.  I could probably make a much smaller one with surface mount memories.  But it's cool.  I may have to make a programmer board for it.

  • Cartridge port

    Justin Davis09/24/2018 at 14:48 0 comments

    I wanted to have a cartridge port to make it easier to load new programs into ROM.  It also makes it more like old Commodore 64 or Atari 400/800 computers.  I don't think there will be many cartridges made, but I like to think that it's possible.  I also want to be able to pop out the cart and reprogram it easily without modifying the computer itself.  When the cart is inserted, the /ROMEN line is forced high by the cart which disables the internal ROM.  I also included the data bus, clocks, and an /EXPAN input which is enabled with /IE just in case someone comes up with a good idea.

    I chose an edge connector that is keyed so that it's not possible to plug the cart in backwards.

  • Keyboard interface

    Justin Davis09/24/2018 at 14:20 0 comments

    With the control register, I can change the functionality of the input select line.  Previously /IE would select the serial input chip for the gamepad controller.  That's still the default behavior, but it can be changed to select a different input peripheral.  My main goal was to add a built-in keyboard, so I started with a simple keyboard matrix.  The AC line selects the column, and then a ST IN -> [X,Y] stores the row information to RAM.  AC should only set one bit low at a time while the others will be high.  This will take 8 reads from the keyboard to see which keys are pressed.  This is relatively software intensive, but only costs one CMOS chip (a bus buffer).  This style allows many more possibilities for functionality.  It should also be immune to ghosting from multiple key presses due to each key having its own diode.

    This limits us to 64 keys, but that's ok.  I came up with a layout of 63-keys that includes arrow keys.

    I prefer a good mechanical keyboard to simulate a good old 70s/80s computer.  It's more expensive than other options, but it has a great feel to it.  I used the GH60 open-source keyboard layout design as a reference and is compatible with the Cherry MX keys.  The arrow keys are not on the GH60, so it's not exactly the same.  And I didn't put in the options for alternate key mounting.

  • Control register

    Justin Davis09/24/2018 at 14:00 0 comments

    I need to have another control register to control the new functions.  This register controls the hi-resolution mode, the keyboard access, the cartridge access, the bank switching of the RAM, etc.   I don't want it to get modified unintentionally, so I need it to be tied to the new instruction calls.  This is not too difficult, because I can use the /OVerride signal to drive it.  But I don't want all the /OVerride instructions to call it, so I chose to use one of the instructions ST AC->[0,D] and /OVerride to load the control register /LC.  Much like XOUT, the CTRL register loads from the AC register.  And at the same time, AC is stored to RAM at [0,D], so the programmer needs to be a little careful.

    /LC = /OV or [0,D],AC 

    likewise, /LC = /OV or (/IR2 and /IR3 and /IR4)

  • Instruction set expansion - STORE AC -> [X++,D]

    Justin Davis09/24/2018 at 13:44 0 comments

    Making the previous changes to the instruction also gives a few extra instructions: ST AC->[X,X] and ST AC->[X++,X++].  These are not super useful, so I decided to make a change to give me ST AC->[X++,D] instead.  I can do this by forcing the lower byte to be D when the /OVERRIDE is active.

    Current the lower byte MAU select line EL selects X when 0 and D when 1.  I want to reverse this behavior by removing the wired-ROM diodes that are there, and putting in diodes for the instructions not currently selected.  Then I swap the X and D inputs to the lower byte MAU chips.  This results in the same behavior as before, but now EL selects D when 0 and X when 1.

    Now I can add one more diode from the EL line to the /OVERRIDE line. So when the /OVERRIDE is low (active), it forces EL to be low as well selecting D.  And BAM I have my ST AC->[X++,D] function for only 3 extra diodes.

  • Instruction set expansion - STORE AC-> [X,D]

    Justin Davis09/24/2018 at 13:30 0 comments

    One improvement I'm making to the Gigatron is to increase the instruction set.  I wanted this to be 100% compatible with the original, so that means I can't really replace any instructions that anyone may use; however, there are some instructions that no-one will use.  The STORE instruction has some possibilities to store to memory and read from memory at the same time.  This is an undefined mode for the RAM.  So nobody would be using these instructions.  So I'm assuming these are up for grabs.

    I decided that I wanted to have a store instruction with X as the high byte.  Then it is easy to do a LOAD Y,D and then STORE X,D to move data around.  The upper byte in the MAU is currently only connected to Y, so it isn't too hard to connect up the other side to X.  Then I just need an enable wire to select X. 

    I can identify when these undefined instructions are called by looking for both the STore instruction and the /OE is enabled.  This gives me the new enable for X which I call /OVerride.  However, I still need to fix the undefined problem, so instead of selecting /OE, I will now select the ACcumulator register /AE instead.  So this leads to three new equations:

    /OV = /OE or ST

    /OE = /oldOE or /ST

    /AE = /oldAE and /OV

    I can accomplish this with one more quad OR chip and a wired-AND.

View all 10 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

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