This is hard to let go. Once started, the cogs of the mind continue turning, even when doing other things.
So I added glitch suppression to the schematic in the same way as on the main board with the /WE signal: mute the signal during the first phase of the Gigatron cycle. You need an OR gate for that, but we can construct one from the unused gates. The input and output logic looks symmetrical now, but that is accidental.
- Inline image
- Expansion2.png (837.43 KiB) Viewed 9916 times
Component wise it could be arranged like this.
- Mockup component layout
- photo_2019-02-24_15-11-28.jpg (45 KiB) Viewed 9916 times
I like that the logic chips are all 14-pins here. There are plenty of other arrangements of course.
Indeed, breakouts have to be on, as well as (room for) more blinking fun.
~~~ Some new and random thoughts below ~~~
When pondering on the glitch suppression, it occurred to me that the /WE signal also carries some phase information. This can help and prevent us from having to connect a patch wire to the CLK1 breakout. Furthermore, there may be an alternative method to trigger expansion bus operations (other than decoding address lines): using the combined /OE and /WE signals. For regular instructions, at most one of /OE and /WE will be active. After all, you can't read from RAM and write to it at the same time. In the instruction table the opcodes that attempt a read/write combination have their data undefined (operand "$??").
These instructions are valid in the sense that they don't break anything. The data sheet tells what happens to the RAM:
- Data sheet 62256 RAM
- Screenshot 2019-02-24 at 15.51.35.png (32.84 KiB) Viewed 9916 times
The RAM simply gives precedence to /WE over /OE: it won't try to put data on the bus while also reading from it. This is a protection mechanism of course, but we can use it to our advantage. In a standard Gigatron it just means that it is writing uninitialised data into RAM.
So here's a new idea:
Code: Select all
/IOSEL = /OE | /WE
_ _ _
CLK | |_| |_| |_
____ ___
/OE |___|
______ ___
/WE |_|
______ ___
/IOSEL |_|
First observe that, now that we have data bus in tristate with the RAM reading, we could just as well pass external data lines through a buffer (74'244) to the bus. This gives us 8 lines of input in the same instruction.
Now we have to figure out where the data for the output flip-flops is coming from. I haven't thought that through yet.
One idea is to use address lines again, for example A8:A15. Except that this doesn't quite fly (yet), because those are also addressing the RAM, to which we're now writing. We could add two 74'157s in the same way as in the MAU, and force the RAM to address the zero-page during this cycle. However, that's 2 chips, and they get inserted on the critical path of the Gigatron cycle.
Another idea is to take these bits from the data bus one cycle before, using another 74'273 register. But that chip needs to be clocked by something.
Also, accidental I/O can still happen, especially during boot time(*). If several slave enable lines come from individual flip-flops, we can't just wait until the software initialises them: there is the 350 ms delay by the MCP.
Food for thought....
(*) I see now that this is the point of both the inverters behind the /CSn flip-flops and the hardware triggered reset. That answers my older note 12. So my schematic above is still not right anyway.