List of possible Gigatron mods

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
qwertyface
Posts: 68
Joined: 16 Jul 2019, 09:19
Location: UK

Re: List of possible Gigatron mods

Post by qwertyface »

alastair wrote: 01 Dec 2020, 20:06 This got me thinking. Who else has written (native) code for the Gigatron? Obviously Marcel and there is one other project I'm aware of - https://hackaday.io/project/168293-gigatron-forth

Working directly with the op-codes is a significant undertaking and it looks like the Gigatron Forth project might have stalled because of this. I'm assuming that adding or changing op-codes would be of limited use. Does anyone have plans to work directly with these op-codes?
I'd imagine that after Marcel, I'm the person who's written the most native code (I'm the author of the project you linked). I'd say that a lot of the challenge of working with the native instruction set isn't the programming itself - that's just time (and space) consuming. It's coming up with the systems, encodings and protocols that make things work. For example, how can you encode the pointers you need in a Forth thread in the ROM? How can you structure routines so that they never overrun your time slice? But actually these challenges are the fun part - and while doing a great job would be hard, finding something bad that works is not. And while you do need to invent quite a bit, a lot more can be copied from the tried and tested approaches in Marcel's code. Once you put yourself in the native world, and appreciate the problems he's faced, his code is very clear and well commented! I have no earthly idea how he achieved it though! I wish I'd asked him about it.

What's caused the project to stall is actually not getting bored of writing native code - in fact I'm trying to go back to writing native code to re-kindle the enjoyment - it's getting bogged down in decisions about how to implement things, and vacillating over what the next thing to do is, and what is worth doing - particularly when it comes to how to deal with memory. I have about 5 different git branches, all with started approaches to different things, all given up because I was making things too complicated, or they felt like they were dependent on solving other problems, or they were just getting too messy too fast, with no end in sight. Good programmers are good at breaking things down into chunks that are manageable for them - and that's what I've failed to do.

I would definitely recommend trying to write native code for the Gigatron to anyone. As I've said before, I've learned an awful lot, not least about what is easy and what is hard! I'd be happy to give tips on how to get started (and one thing I've started but not finished is cleaning up some of my supporting tooling, because I think it might be useful to others).
alastair
Posts: 68
Joined: 10 Oct 2019, 14:28

Re: List of possible Gigatron mods

Post by alastair »

qwertyface wrote: 02 Dec 2020, 10:15 What's caused the project to stall is actually not getting bored of writing native code - in fact I'm trying to go back to writing native code to re-kindle the enjoyment.
Glad to hear it's still ongoing :D I've been working on a similar project to the Gigatron and spent the last year coding in my native machine code. I knew what I was getting myself in to at the start but you never appreciate the amount of work until you get to the other end.

Working with limited hardware at this low level goes against all modern iterative software development "rules". You have to figure out every tiny detail before you write a single line of code and even that can take months. It's like juggling Rubix cubes and trying to solve them at the same time :lol:
Sugarplum
Posts: 93
Joined: 30 Sep 2020, 22:19

Re: List of possible Gigatron mods

Post by Sugarplum »

Yes, as I said, this is just a unified list of possible mods and not put here with specific plans. I might use some of these in my eventual design. The goal did not specifically include a list of architectural design plans. It is just a unified place for a "wish list." Now, if others want to discuss them in more detail, that would be good too.

If I were to make mine in FPGA, I'd have my own "hardware" PSG. So once it is dispatched, it runs in the background and doesn't continue to take CPU power. And it could have a small buffer. There could also be a pass-through mode to where it can be programmed like it is now. I can see a challenge in that this would probably trade calculations for port traffic.

In my possible design, the external framebuffer would be to help with crossing clock domains. So the CPU and video core can operate at different speeds. That would isolate the CPU pipeline from the display pipeline. If I implemented HW sprites, I'd keep it simple by giving it its own memory and probably wouldn't use layered sprites.

I'd probably do the I/O as a custom, unified I/O controller. That would make the different signals available to each of the devices on it. I think implementing it more as an APU would be better since the CPU could then have direct control of the various coprocessors.

I still haven't quite figured out how to do vCPU as a coprocessor. Making the coprocessor is the easy part in comparison to figuring out how to integrate it with the Gigatron core. There likely needs to be Gigatron opcodes for start, halt/sleep, and Jump on the coprocessor. As for avoiding memory races, I'd likely need a more complex memory unit or at least clock the memory faster and use alternating cycles. On the Gigatron side, this would require rewriting the emulator code. It would probably be more of a listener in a client-listener setup.
Sugarplum
Posts: 93
Joined: 30 Sep 2020, 22:19

Re: List of possible Gigatron mods

Post by Sugarplum »

I'm still gaining ideas and working out logistics before embarking on my own creation. On the vCPU coprocessor idea, a smaller step might be just to enhance the native opcodes to have more hardware available for the vCPU, focusing on opcodes and minimal hardware that would make the current vCPU code more efficient. That would help simplify the native code used and move things a step closer to hyperthreading. I imagine that would be even more noticeable with v6502.

I might still want to experiment with a dedicated but moderately integrated vCPU core. However, it would take considerably more work to fully integrate with the native core, including new native instructions to coordinate them.

1. Having a 16-bit register could be helpful to vCPU (and native code, too). It could be used mostly as vAC.

Load/Stores to the new register could be done in a 16-bit manner. One idea could be to decouple the memory unit some (a minor CU mod) and allow it to work in the background (do half in the current cycle and the other half in the next). That could introduce races, but the workaround could be on the programming side. If the next instruction is a non-RAM op, then no considerations would be needed. However, if the next instruction is a RAM operation, then work in a NOP or rearrange the code. So memory-cycle "stealing," but inside the CPU.

The new 16-bit register could have its own bus and be just for load/store. Alternately, make AC 16-bit but leave the lower half as it is and do only load/store on the upper half. I tend to favor a whole separate register that gets past the AC clobbering issue for the original 8 bits without modding/changing that.


2. Make the memory unit autonomous. So make things closer to "DMA." This is only good for when you need to rapidly output from the memory to the port. Let the memory unit take over the port accesses and allow the PC to continue until RAM accesses are needed. Then some work can be done during display. To avoid confusion, program with the port block command only for short blocks when you have enough ops to do simultaneously. So if you need to send ten different pixels to the screen in succession and also work nine instructions that don't use the memory, you can. So the port can be the bus master without halting the CPU. When you run out of uses for non-RAM instructions, then use the typical Out instructions. So cycle counts will appear the same as before. Or if you just need to repeatedly send a single byte, there is no advantage to using the new way. Just set the byte and forget it until it is time to change it or the syncs.

This strategy will work better when there are more registers and non-RAM opcodes. That could make things more superscalar. So let the memory controller take over the port while things not using memory or the port can continue. Ideally, keeping track of this should be done in software, though a hardware safety halt/ready could be thrown in to prevent races. Still, software race prevention is better.


3. There is still the idea about what to do with the wasted operand space in ROM. It would be nice to have an instruction set that could run when "data" is not put on the bus. That would have to be mostly instructions that only modify registers. Or one could put a 4-bit CPU of sorts in that space that operates when the operand is not used. For compatibility, $h00 should be a NOP. So these instructions might be able to run while slinging pixels. Now, since these additional instructions run from operand space would not be allowed to perform jumps (only the main core can do that), conditional instructions could help. So there would be no need to jump if a true gives action A and a false gives action B or a NOP.


If I were to build something with such features or similar, I wonder about the name. While Polytron would be nice, that one is taken. I wouldn't use Multitron either. Just the above features would make a vCPU coprocessor less attractive. Doing multiple normal native instructions simultaneously with a memory unit functioning as a DMA/bus-master controller for many RAM-Out instructions would help vCPU be more efficient. Plus, if there were a way to harness the unused operand bytes, that could also boost vCPU. Or alternately, they could allow more software-driven hardware. So imagine being able to update sounds or keyboard/storage reads while bit-banging a line. So you could have more concurrent polling opportunities.

So with the primary core, the occasional operand core, some 16-bit register moves, and a bus-mastering RAM-to-Out controller, it would be like having 2.5 real cores. And all this could improve RAM and ROM usage density.
Sugarplum
Posts: 93
Joined: 30 Sep 2020, 22:19

Re: List of possible Gigatron mods

Post by Sugarplum »

I have more understanding of how the Gigatron works since I've started this thread. To be honest, the CPU portion doesn't need port opcodes at all. The 6502 didn't have them. More native opcodes, including shifts, registers, and memory modes, would have a higher priority to me. As for the ports, you can do that in memory. So add a DMA port controller.

That would be easier in an FPGA implementation. The main issue is that the Gigatron uses a single clock phase. The 6502 used a multiphase clock. So for the C64 (though it used a 6510), it used every other cycle and memory stealing could be used. The Atari 800 used a bus-mastering DMA approach and used a modified 6502 to facilitate that. Actually, the modified 6502 ("Sally") used in the Atari 800 was actually closer to the original design of the 6502. The original 6502 was simplified to remove multiplexers from the bus for the production version and the "Sally" version added them back to be able to halt the CPU. Now, halting the CPU would be a challenge in the Gigatron, since you'd need to find a way to bubble the pipeline. However, a more sophisticated clock circuit might do the trick. For instance, clock it at 12.5 Mhz and split opposing phases off of it that run at effectively 6.25 Mhz each. Then one goes to the CPU and one goes to the DMA/port controller.

However, an autonomous DMA controller would complicate other things since the Gigatron doesn't use interrupts. You'd pretty much need a coprocessor. Video would be rather easy for this. Do similar to Ben Eater's video card design and maybe add a ROM to tell it where to find the indirection table. Sound and other I/O would be harder, but possible. You could make a hardware PSG that does everything the Gigatron way.
Post Reply