Some ideas for an enhanced Gigatron
Posted: 14 Apr 2019, 14:12
Long post...
Hi,
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:
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:
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:
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:
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:
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:
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
Hi,
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:
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:
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:
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:
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:
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:
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