Page 1 of 1

Some ideas for an enhanced Gigatron

Posted: 14 Apr 2019, 14:12
by gesari
Long post...

Here I'm presenting some ideas about how to improve the Gigatron. I know there is work being done about this, mainly about I/O (SPI, namely), and I think these changes deserve some discussion before ending with dozens of different Gigatrons. In particular I found the Gigatron is lacking two features I would like to have in a new revision:

ADD and SUB with carry.

An “standard” I/O expansion bus.

The first modification would simplify a lot extended precision arithmetic and, for instance, can enable the Gigatron to beat any CISC 8-bit machine in floating point calculations (Even the performance of an 80286 can be withing reach) The main problem here how to map these instructions into the existing op-codes.

The second modification is more urgent because the current I/O capabilities of the Gigatron are very limited and people want to attach lots of commonly available peripherals to it.

CARRY register

The addition and subtraction with carry requires a flip-flop to store the carry and new instructions. But definitely there is no room for ADC and SBC with all the possible addressing modes, so a different approach is needed. My idea is to use a control bit to modify the behavior of the existing ADD and SUB instructions (in a similar way to the BCD arithmetic of the 6502). If this bit is zero the carry FF is not used at all and ADD and SUB behaves the same as before, but if the control bit is one the carry input to the ALU is taken from the carry FF instead. This is only done if the instruction being executed is ADD or SUB because some other instructions need Cin to be fixed at zero or one (Bcc).

The circuit for Carry, and also for the control register, would be like the following:
carry.gif (15.44 KiB) Viewed 1708 times
I hope no purist is offended for including a 'CMOS' multiplexer in a 'TTL' computer. Of course other circuits are possible, this is just for showing the idea.

Here I want to remark some peculiarities:

The carry FF is keep in a reset state as long as the control bit is zero. This means the Carry value is known when extended precision is first enabled.

The carry FF is written for ADD and SUB instructions only.

If enabled, the carry FF can be set to one with a single instruction. This is not so important but it can ease subtractions and comes at no cost with the following decoder expansion.

New instructions

The Gigatron seems tho have all the op-codes already used, but many of them are currently NOPs. The idea for the expansion of the instruction set is to turn some of these NOPs into useful instructions. First, these are the unconditional NOPs we have now:
carry.gif (15.44 KiB) Viewed 1708 times
The first one (LD AC,AC) is the more attractive because it does not use any bit of the D register, so we can modify this instruction by decoding the two unused bits of IR into:
carry.gif (15.44 KiB) Viewed 1708 times
Where the first instruction is keep as a NOP for compatibility with the existing software (The ROM includes lots of $0200 opcodes).

The second is used as a write into the I/O bus. Here the AC register is already in the Data bus, so it is easy to implement a bidirectional I/O bus using just a bus transceiver to the data bus. And the previously unused D operand is now an I/O address.

The last two instructions are related to the Carry FF and its control bit. The circuit for the additional decoding can be built with just one HC138:
carry.gif (15.44 KiB) Viewed 1708 times
IO bus

The IO bus is going to use the the new I/O op-code (BOUT for instance) for output (AC is copied to I/O bus), while maintaining the OUT register with all its addressing modes for video generation. The XOUT register can be maintained as well for compatibility, although I would prefer to move it to the I/O bus. For input nothing extra is needed, all we have to do is to replace the HC595 register with a bus transceiver and we get a bidirectional I/O bus:
new_io.gif (7.98 KiB) Viewed 1708 times
Now, the instructions using the IN register as ALU source will have to specify an address in their previously unused D bits, as the new BOUT instruction also does.

One advantage of this approach is that no memory mapped I/O is needed at all. All the memory space is left for memory.

SPI peripheral

Probably the first peripheral we want to attach to the new I/O bus is an SPI controller. This will allow the interfacing of lots of interesting things, like SD cards / Flash memories, ADCs, ..., and the already used game controller (well, it requires a tristate gate). One possible schematic, including the XOUT register, could be:
SPI.gif (21.56 KiB) Viewed 1708 times
Here the IO address space is reduced to only 4 addresses for output and input. The SCK clock is generated by toggling a FF with each write to IO address 1. Therefore an SPI transfer would require 16 BOUTs with dummy data to this address in order to generate the 8 clock pulses. This is done this way because some SPI devices (like SD cards) need a slow clock that can be generated by inserting the appropriate delays between writes (If not for this, an inverter at the /STROBE output could have been enough to obtain the SCK signal at 6.25MHz).

That's all. I home the images are attached... If any of these ideas is found to be useful it will worth the work of drawing them :)
Best Regards

Re: Some ideas for an enhanced Gigatron

Posted: 14 Apr 2019, 14:16
by gesari
As I feared all the images were scrambled... Sorry about that.

Re: Some ideas for an enhanced Gigatron

Posted: 14 Apr 2019, 14:18
by gesari
And also the SPI schematic is incomplete. It should be this:
SPI.gif (26.74 KiB) Viewed 1707 times

Re: Some ideas for an enhanced Gigatron

Posted: 14 Apr 2019, 16:34
by marcelk
gesari wrote:
14 Apr 2019, 14:12
Here I'm presenting some ideas about how to improve the Gigatron. I know there is work being done about this, mainly about I/O (SPI, namely), and I think these changes deserve some discussion before ending with dozens of different Gigatrons. In particular I found the Gigatron is lacking two features I would like to have in a new revision:
Thanks for sharing! The images don't look scrambled to me.

Please don't worry too much about variations or compatibility too much, or about adding 4000-series chips from the same era. In home-brew CPU computing everyone just builds whatever suits their own need...

There are other variations already:
Justin Davis': ... h-keyboard
HGM's: viewtopic.php?f=4&t=6&p=92

The reason the Gigatron has no status register, and no carry flag, is because software can handle its function. (It's mentioned in the FAQ). So it saved a lot of chips in the control unit. The ADDW and SUBW routines must jump through some hoops to provide 16-bit arithmetic, but you wouldn't do all of that when you need speed. For example, the sound code is more critical and uses 7+8 bit arithmetic that is faster and simpler. I guess you can do rather efficient longer word arithmetic by treating bytes as 7-bit units and use the MSB as a carry to the next byte. But we haven't tried: a floating point library is not on our priority list now because it is very hard in general. Maybe after retirement... (Even Bill Gates and Paul Allen didn't write the floating point code for Micro-Soft BASIC after all).

Our slogan "If software can do it, you don't need it in hardware" is only half-serious though... We were not 100% consistent in our minimalism to the very end, and you can see that in some places if you know where to look. (For example, that's why there is still a fairly complex '595 shift register for the input. It was a simple '244 octal buffer chip in the original design. The only reason the '595 is there now is because we were too lazy to decode the kit's game controller signal fully in software, so we cheated. Also it has fewer pins, and that helped with the PCB layout, but that was not the main reason. If we had more time back then, the '595 may not have made its way in.)

The idea for a dual-direction buffer is quite interesting. I didn't think of that before.

I wouldn't care too much about preserving XOUT's function either. It's a single-chip hack on top of the core design, just to make the kit edition slightly more interesting with sound and at least some blinking LEDs. It's perfectly valid to use it for other purposes.

More SPI designs are seriously interesting! Nothing is truly settled in that area (yet). We have a 3-chip option already, and a 4-chip option that also adds banking. The vast majority of the work will be FAT library support anyway, not hardware. Actually, I start to fear that the fastest route involves writing a C cross-compiler first, so we can use this:

Re: Some ideas for an enhanced Gigatron

Posted: 15 Apr 2019, 10:11
by gesari
Excuse my poor english. The images were in random order, not scrambled...
And the 4053 CMOS 'intruder' was just a sort of joke. In fact all chips are CMOS. This chip would end up being a 74HC4053, with a '74' in its name :)
And yes, I understand simplicity here is the main goal. The upgraded carry only needs two more ICs, (three counting also the decoder). In fact it is a negligible amount of logic when compared with the rest of the computer, but the bad thing about TTLs is that you have to live with the standard parts and you end up using lots of chips even for quite trivial things. Anyway, in this case the software developers can judge better than I if a carry reg. is worth the effort at all. I should try to understand how you are doing 16bit adds and subs in the vCPU...

A read only FAT16/FAT32 is not too difficult. I did it a couple of times, one for 6502 assembly. Writing is more problematic. Porting GCC to a vCPU-none-gcc is going to be much more complicated than the filesystem itself.

And, by the way. Gigatron programs aren't very long. Have you considered using an SPI Flash for storage instead of an SD card? A chip like the 25Q064 gives you 8MB of storage and is simpler to use than any SD card (also pages are 256 bytes long, not 512)

Re: Some ideas for an enhanced Gigatron

Posted: 27 Apr 2019, 13:32
by monsonite

Some very interesting ideas.

I have also followed your thread for an in-circuit EPROM emulator and this would be another way to make the ROM more accessible for modification.

If you use fast access time RAMs (10nS) for the Romulator - then there is the option to increase the clock frequency even more - perhaps 16MHz?

I recently read about a TTL cpu on the forum that used large EPROMS for instruction decoding. An AT27C1024 ROM could potentially replace much of the control unit circuitry and have additional address lines available for decoding the ALU status - such as zero, carry etc.