Page 4 of 6

Re: Modified Gigatron Design Ideas

Posted: 23 Nov 2019, 23:06
by PurpleGirl
It seems like that could be remedied in other ways. The X-Out could be given some opcodes. The low-hanging fruit is 11 of the 12 NOPs. I could create an instruction like LD XOout, AC by piggybacking off of a NOP like I've been mentioning. So since they are not used and do nothing, it would then be a simple matter of using those in new code.

Now, what is the H signal feeding the X-out chip? And what does the Mr signal do?

Re: Modified Gigatron Design Ideas

Posted: 24 Nov 2019, 00:35
by marcelk
I believe my proposal is sound. The data sheet for the XOUT chip is here here. I'll leave it at that.

Re: Modified Gigatron Design Ideas

Posted: 24 Nov 2019, 01:39
by PurpleGirl
Thanks. I'll read that. But I see the opcode thing as not too hard. Make X-out closer to another register.

I see, so Mr is the reset, and holding the clock low causes it to act more like a register. If I were going to mod it and make it more like a register, I'd probably be more interested in a 244 there.

I think I'll like the Sweet-16 better. While the original intent is a co-processor, I think I'd like working with it better as a main CPU. So far, it looks like he will make it with a single bidirectional port, and make it port-mapped. Since the bottom half of his instructions are for byte immediates and his port instructions always work with the accumulator, it won't be hard to address specific devices via opcodes. Any devices can listen for their address and communicate when addressed. And yeah, I can see bit-banging working around that processor.

Still, the jury is out on what to send to the 2nd Gigatron, let alone me building such an arrangement. I might want to study the ANTIC chip some more for ideas. That was the display list coprocessor in the Atari 8-bit computers. And yes, it signaled back to the 6502 via a VBlank interrupt, though it sent no real data back (so the ANTIC was not Turing complete as a CPU). So what I proposed and you helped with was using a 2nd Gigatron sort of like ANTIC, POKEY, and GTIA, while the first one functions as SALLY and PIA. And like the newer homebuilt Atari computer clones, we'd have no FREDDIE equivalent due to using SRAM.

Re: Modified Gigatron Design Ideas

Posted: 24 Nov 2019, 04:35
by marcelk
The '244 is just a tri-state buffer, not a register, not even a latch. You can find a really good explanation here. This video is part of the Ben Eater youtube series that goes through all steps of building an 8-bit breadboard computer. It is a very good resource for you as well. There are 44 videos where he explains the details of every TTL chip and how it is used. Many of his part numbers, or their cousins, come back in the Gigatron in a similar role. For under $300 he also sells everything you need to build his computer yourself. It can calculate Fibonacci numbers and you can see every step.

Re: Modified Gigatron Design Ideas

Posted: 25 Nov 2019, 06:04
by PurpleGirl
So a 377 or 2 161's might be better for what I have in mind, though a tristate buffer might work if the data is streamed. So it depends on the application. But adding opcodes, I think I'd want an X-Out rather than a load.

Thinking of creating a custom CPU

Posted: 05 Dec 2019, 15:50
by PurpleGirl
I am not committed yet, but I've been considering a custom CPU. I am only in the crude planning stages about the architecture I'd want.

I'd likely need to learn how to do FPGA, especially if I were to do 32 or more bits. So I'd need to get accustomed to using FPGA design software and Verilog/HDL.

Now, it would be nice to keep Gigatron compatibility. Now, with 16 bits, you could keep the entire Gigatron opcode set as is. Maybe add one more access mode bit, so the 3-8 decoder could be swapped with a 4-16, thus not worrying about losing opcodes. There could be a bit to override the entire Gigatron instruction set thus allowing all the other bits to be used for a new decoder. So if that bit is set, you have space for 32k (32768) opcodes in a totally new instruction mode. Otherwise, you'd have the 256 original set and 128 new ones (1 bit is used as an escape sequence for the new set).

Reworking the original Gigatron instructions
In addition, unused or unusable opcodes of the original set could be subject to a secondary decoder to make them usable -- so long as this doesn't introduce too many delays or any race conditions (like if an instruction ends up taking 2 cycles and its output is used before it's ready). We pretty much know that any instructions with the top 3 bits high will be unique if my studying and math are right, but not sure if it is any of those pins or all of them (AND vs OR). I'd have to study that more. Seeing the instruction set in binary would be helpful. But I think it is anything that's 224 or higher that should certainly not be touched. Then I need to find the rules for the rest of them.

Another idea I had here with the original Gigatron would be to have a crude piggybacked decoder to look for specific NOPs and use those to change the instruction context, where the same binary code would take on different functions once a specific NOP is used, with a NOP in the new context to restore the original opcode meanings. That would mean that anything needed for video processing would need to function the same regardless of context.

8/16-bit register bonding modes
Maybe there could be 1-2 bits in the upper 8 bits to determine the register bonding mode. That mainly involves whether the carries are joined in the ALU, and if not joined, the upper registers have their own ALU. If 16-bit, I'd like to see a way to have the new half-registers to operate both in bonded mode with the existing ones with all calculations being able to use 16-bits, while also being able to split them and use them differently and simultaneously in more of an MMX fashion. What this would enable would be the freedom to do 8-bit operations at any time, and to do 16-bit (or 2 simultaneous 8-bit) operations during porches and vblank. Thus the 16-bit instructions would allow for emulated code to run better while doing the instructions in MMX fashion would allow for full speed 8-bit native code with the occasional 16-bit instructions. If there's not enough room to do different addressing modes simultaneously in augmented control logic mode, then those things can be done in the new instruction set mode and new control logic.

Architecture Change
Currently, the Gigatron uses Harvard architecture. It meets the goals of the Gigatron. But I'd like to see the ability to use native mode all the time., even when running software out of RAM. The vCPU emulator can still exist for compatibility. So expanding the Harvard architecture to include the RAM and giving some instructions that make it seem more Von Neumann might be a goal. Right now, only the ROM is connected to the Instruction Register, and thus that's the major reason why vCPU is necessary if you want to run programs out of RAM. Since IR cannot see the RAM and execute instructions from there, then there has to be software to read the RAM into registers and interpret it. So now, you'd have to find a way for the IR to access the RAM. The first thought there is to use multiplexers. But that poses a challenge. The current ROM is 16-bit while the memory is currently 8-bit. The ROM uses 8-bit instructions in the low byte and an 8-bit operand in the high byte. That would not run on a 16-bit machine since all 16-bits would be an opcode. So a 32-bit ROM would be one way to work around this. But I have difficulty finding any 32-bit EPROM or EEPROM that is not serial. Serial ROM would take an extensive memory controller that would need to be clocked at least 8 times faster. Or you could have 2 16-bit ROMs, with one being code and the other being data. Or a compromise would be to keep the ROM as-is, but only connect it to the low IR and the low DR, with possible overrides (when ROM is active) on the upper registers such as tristate buffers, tying the upper lines low, and being careful to not introduce skew when in 16-bit mode due to such complexity. But that would cripple the point of it being 16-bit, since then, only RAM programs would be able to use any of the new architecture, and how would you get to any addresses past the ones the ROM occupies without using paging, let alone getting to use RAM at all, or getting back into ROM from a RAM access? So 32-bit ROM would make more sense.

Now let's suppose we have 32-bit ROM. You'd still only have 64k of addresses, addressing it as 16-bit in 8-bit mode. But addressing it the usual way would mean the low word goes to the IR and the high word to the DR. The current ROM uses all 64k, and the current RAM can only go just as far if upgraded. But the registers would be twice as wide, meaning you could address up to 4 Gb. So the ROM could sit below the RAM. Or alternatively, you could page out the ROM. So if the program in RAM exited, it would need to page the ROM back and jmp to it, since that's where the "shell" is.

But that leaves another challenge. Would the operands in RAM require 32-bit wide RAM, or would the instruction have to increment it and read from the next address? That could mean 2 cycles. And I see the shortcomings of both approaches. I'd prefer to not get into needing to use thunking.

Speaking of thunking what if blocks of memory are used only for data? So how would you access or calculate (ALU) all 4 bytes of an address? I know a way but that introduces feature creep and increases HW complexity.

Another problem with expanding the Harvard architecture to RAM comes to mind. You might only be able to take advantage of the split registers being made autonomous (effectively 2 8-bit cores) when staying in the first 64k addresses. Paging out the ROM might be helpful here, and I think you could take advantage of the branching quirk (jump and then change pages while jumping, but the added paging instruction could take too long, and not sure the other would work, so there might be a need for nops at the beginning of the ROM or a loaded program). But what if you need to use ROM routines on the same page?

Beyond that would require full 16-bit mode and tying up 2 registers or a word register (or a byte register for 24-bits) and an immediate. So for the video, if you still want to bit-sling, you' might as well send a doubleword to the Out with circuitry there to serialize the bytes. That could buy 3 clock cycles. That would require bonding 2 16-bit registers, and the Out would likely need to be a register.

Re: Opcode mods

Posted: 19 Dec 2019, 08:41
by PurpleGirl
Another mod that came to mind, though likely not attractive to use, would be replacing most of the instruction decoder with a ROM. The instruction register can drive the address lines and the data lines drive the control lines. So this replaces the logic with an instruction map. There would be no speed advantage, but you'd need a fast dedicated ROM (or two if 16-bits isn't wide enough, though they don't need to be deep) for this if you want to overclock.

The only advantage of this approach would be the ability to arbitrarily assign opcodes. Of course, if I were to do this, I'd leave all the used ones as they are for compatibility and only replace duplicated (about 62 if I remember right from the last time I counted) or nonsense opcodes. That would give room for things like more access modes, ability to copy between more registers, additional ALU instructions, or even additional registers. There would be no reason to add instructions to clear registers or set them to arbitrary values due to the Harvard architecture. In fact, the opcodes for assigning 0 could be fair game to change since they are no faster than assigning from immediates.

The above is the simplest implementation. However, this can be more complex. For instance, the map could be copied to fast SRAM and shadowed there. And perhaps better yet, there may be hybrid ROM/SRAM.

Re: Opcode mods

Posted: 28 Dec 2019, 12:09
by monsonite
Hi PurpleGirl,

Using a ROM as the instruction decoder is an often used approach, but the problem is with the speed an instruction can be decoded.

Fast ROMs are not very common these days and the AT27C1024 from Microchip/Atmel has an access time of 45nS. You might find that you could sample a batch of them and find some that are faster, you might even get down to 30nS.

It would be a great way of obtaining 16 hardware control lines from either an 8-bit or 16-bit instruction field.

I have had similar thoughts for a TTL machine I am currently working on - and will experiment with the 27C1024.

This will be future work for 2020

Happy New Year to Everyone in the Gigatron Community


Re: Opcode mods

Posted: 18 Jan 2020, 18:22
by PurpleGirl
A clarification. I've never said that the CPU has any hidden states. My idea to piggyback onto a NOP instruction is only for external devices. For instance, if an external video controller is used and there is the chance of losing the syncs or not knowing where the raster is, one of the spare NOPs could be used as a signal to reset the video controller.

Re: Modified Gigatron Design Ideas

Posted: 18 Jan 2020, 18:24
by PurpleGirl
I've been thinking about Ben Eater's "video card" design. I was pondering how to modify it to where the syncs could be modified by software. I think I've discovered a way to do that. Instead of using hardwired logic gates, a register and a digital comparator would be better. So the pixel counter setpoints for the porches could be placed into the registers. Then the comparators would trigger the latches to toggle the syncs for the porches based on the values in the registers. While that would ideally take a microprocessor, jumpers could work.

Now, I've been pondering on how to make a video board. I know the basics about how to do a pixel counter and do the latches and syncs. I could put RAM on the board. The pixel counter would not only control the latches but would also do the addressing of the video memory. A shift register could be used to buffer the output, thus the buffer could hold the memory. However, even then, the same problem would present itself, and that is how to get the data out of the memory.

So using 2 memory banks that flip could work, but that introduces another problem. The banks could get considerably out of sync. If you add other mods such as adding the ability to update single lines or pixels, then the entire page won't be overwritten on the memory that's being used for output. So that could cause artifacts, flicker or display corruption. So one workaround would be to write to the current output bank if/when the input address is the same as the output address. Another workaround would be to write to the current output bank during the porches.