dual core Gigatron CPU

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice.
PurpleGirl
Posts: 47
Joined: 09 Sep 2019, 08:19

Re: Modified Gigatron Design Ideas

Post by PurpleGirl » 23 Nov 2019, 23:06

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?

User avatar
marcelk
Posts: 453
Joined: 13 May 2018, 08:26

Re: Modified Gigatron Design Ideas

Post by marcelk » 24 Nov 2019, 00:35

I believe my proposal is sound. The data sheet for the XOUT chip is here here. I'll leave it at that.

PurpleGirl
Posts: 47
Joined: 09 Sep 2019, 08:19

Re: Modified Gigatron Design Ideas

Post by PurpleGirl » 24 Nov 2019, 01:39

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.

User avatar
marcelk
Posts: 453
Joined: 13 May 2018, 08:26

Re: Modified Gigatron Design Ideas

Post by marcelk » 24 Nov 2019, 04:35

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.

PurpleGirl
Posts: 47
Joined: 09 Sep 2019, 08:19

Re: Modified Gigatron Design Ideas

Post by PurpleGirl » 25 Nov 2019, 06:04

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.

PurpleGirl
Posts: 47
Joined: 09 Sep 2019, 08:19

Re: Opcode mods

Post by PurpleGirl » 19 Dec 2019, 08:41

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.

monsonite
Posts: 64
Joined: 17 May 2018, 07:17

Re: Opcode mods

Post by monsonite » 28 Dec 2019, 12:09

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


Ken

PurpleGirl
Posts: 47
Joined: 09 Sep 2019, 08:19

Re: Opcode mods

Post by PurpleGirl » 18 Jan 2020, 18:22

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.

PurpleGirl
Posts: 47
Joined: 09 Sep 2019, 08:19

Re: Modified Gigatron Design Ideas

Post by PurpleGirl » 18 Jan 2020, 18:24

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.

User avatar
marcelk
Posts: 453
Joined: 13 May 2018, 08:26

Re: Opcode mods

Post by marcelk » 18 Jan 2020, 20:36

Thanks for clarifying. The only point I tried to make is that if you want to create extra output signals, every flip-flop's output on the board is exposed (as "bare metal you can solder to") and available for tapping into. None are hidden behind a buffer for example, as in many other designs. Therefore you don't need to restrict yourself to the IR flip-flop outputs. That's all.

Maybe I misunderstand, but if you reset a video controller while it is active, most screens will black out for a couple of seconds. Screens don't like discontinuities in the sync signals they receive. The more modern ones even less so than older ones. Just a caution.

Post Reply