Modified Gigatron Design Ideas

General project related announcements and discussions. Events, other retro systems, the forum itself...
Post Reply
PurpleGirl
Posts: 8
Joined: 09 Sep 2019, 08:19

Modified Gigatron Design Ideas

Post by PurpleGirl » 06 Oct 2019, 13:07

[Note: Thread moved to Escape Meta Alt Control Shift by moderator ("..., other retro systems, ...")]

I have not built a Gigatron yet. It seems very interesting. What I'd like to see is a way to get the video out of software and have dedicated circuitry for it. Now, generating sync pulses is the easiest. But I can't figure out where the pixels come from. If they were in memory, then some sort of multiplexer could be used to read the memory. But I don't understand how the firmware draws the pixels. And so, if the Gigatron still has to send the data to the dedicated hardware and babysit it, then I don't see how that would be any better.

And I wonder if the firmware could be simpler, even with the programmed video, if the syncs and pixel-counting were done in hardware. A binary counter could be added to the clock (or through a clock divider if you double the frequency). Other logic would be needed. The porches would be more accurate. But would that screw up the keyboard I/O?

Now on sound, I see that as easier to do. Maybe the X-I/O port could be repurposed to send sound-specific opcodes and data, and some way to differentiate commands from data. The sound circuitry could be a reduced Gigatron. It would not need video, lights, or keyboard/joystick port. It could be written completely in native code with no emulator except to add new opcodes for the sound. And it could have an expanded library in ROM filled with more waveforms and samples. Not sure where it would get its data, but I guess the main I/O could be used for that since it would not handle user input.

And with the idea of joining 2 Gigatrons, an idea came to mind. What if both used dual-ported ram and used the high address bit to control a multiplexer? So you could put 32K on each and use the multiplexer to address the memory of the other board. So the high bit would change the memory lines to the memory on the other machine. Maybe do it in a criss-cross formation so each machine would have its own memory on the bottom and the other machine's memory on top.

And I wonder how a hardware halt instruction could be done, such as in the Sally 6502 as used by the Atari computers. Could it be as simple as freezing the PC register? Like maybe a way to use a wire to disconnect the clock line from the PC?

While at it, could there be a way to merge two Gigatrons in parallel and creating a 16-bit machine? Use one for even addresses and the other for odd, and each using their own bank of memory for its role.

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

Re: Modified Gigatron Design Ideas

Post by marcelk » 06 Oct 2019, 14:23

PurpleGirl wrote: I have not built a Gigatron yet. It seems very interesting. What I'd like to see is a way to get the video out of software and have dedicated circuitry for it. Now, generating sync pulses is the easiest. But I can't figure out where the pixels come from.
The pixel burst is this snippet in ROM:

Code: Select all

              address
              |    encoding
              |    |     instruction
              |    |     |    operands
              |    |     |    |
              V    V     V    V
              020b 00c0  ld   $c0
              020c 5d00  ora  [y,x++],out ;Pixel burst
              020d 5d00  ora  [y,x++],out
              020e 5d00  ora  [y,x++],out
              * 160 times
              02ac 18c0  ld   $c0,out
The OR'ing with $c0 forces the /vSync and /hSync signals to stay high, regardless of what's in RAM.
If they were in memory, then some sort of multiplexer could be used to read the memory. But I don't understand how the firmware draws the pixels. And so, if the Gigatron still has to send the data to the dedicated hardware and babysit it, then I don't see how that would be any better.
My last project before embarking on the Gigatron was just that: https://hackaday.io/project/20334-bread ... l-and-sram
It displays a frame from it's own RAM. Once every scanline it takes a memory address and data byte from the shift registers and performs a write operation in that RAM. The computer side has 3 control lines to put data into those shift registers.

For the Gigatron we deliberately steered away from having a separate video circuit. Just out of curiosity, to see how far we could push that concept: we wanted something small and unique. It was a leap of faith if it was going to work out. vCPU, XOUT and the serial input arrived much later to the party.
And I wonder if the firmware could be simpler, even with the programmed video, if the syncs and pixel-counting were done in hardware. A binary counter could be added to the clock (or through a clock divider if you double the frequency). Other logic would be needed.
Indeed, an independent counter will simplify multitasking a lot. But programming cycle exact 8-bit code with a branch delay slot has it's own charm. It's like solving puzzles, you get good at it, and somewhat addicted. Applications should be done in vCPU or v6502, and that's more mundane.

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

Re: Modified Gigatron Design Ideas

Post by PurpleGirl » 07 Oct 2019, 06:03

Yes, as you can see, I'm more interested in using the Gigatron plans as a base for another project. I tend to be more after performance than nostalgia. So figuring out how to do the mods I mentioned and modify the ROM to remain operational.

Maybe you can explain more how that code sends the data to the video port. I mean, how much is that? Just one pixel? Or a line of 160? And what does encoding do? I am not familiar with the instructions. I know some x86 assembly, but not your instructions.

---
For the last week or so, I've been studying the Atari architecture. Atari modded the 6502 CPU to add a /halt line in place of an N/C pin. They called their modded 6502 a Sally. Atari literature refers to the Sally chip as a 6502C but it is a modified 6502B. That was unofficial since the MOS 6502C does not have a /halt pin. The earliest Ataris added 4 chips to disable the 6502 during memory writes by Antic. So the Sally 6502 reduced the chip count.

In addition to running user code, Sally writes a display list, Antic takes over to process the display list, and Antic sends its output to the GTIA (or CTIA, or FGTIA, depending on model). Antic will use interrupts to get Sally to run display list handlers. The GTIA makes things displayable and sends its data to the RF modulator. Antic is also part of the DRAM refresh circuitry, and that is another reason it halts Sally. "Freddie" and the MMU chips handle the refresh. Pokey handles the sound, and along with PIA, it also handles the ports.

The 1088 XEL is an interesting project. That uses 5 of the original Atari chips (Sally 6502, Antic, GTIA, Pokey, and PIA). It adds a 2nd Pokey so it can have true stereo. It uses SRAM, so the Freddie and MMU chips are avoided. That improves performance since those chips aren't there to tell Antic to pause Sally during refresh. I imagine that if they used dual-ported SRAM that they could get more performance since Sally could be attached to 1 channel and Antic and the others could connect to the other. Then maybe the /halt line could be disconnected since memory accesses would be safe. It does not include a ROM since it is made from the ground up to include the Ultra 1 meg daughterboard, and the Ultra 1M replaces the ROM in Atari machines. Other modifications from the original design include using a PS2 keyboard and mouse.

The 1088 XEL It only provides S-video and maybe composite, but if you add the VBXE mod, you can get enhanced RGB/CGA. With the Sophia mod, you can get DVI. The VBXE mod replaces the Antic chip, and the Sophia mod intercepts the GTIA. If I had one, I'd add the Rapidus mod which sits between Sally and its socket. The Rapidus adds a W65C816 CPU, which is a 16-bit version of the 6502, and it is clocked at 20 Mhz.
===

The Atari architecture gives me ideas for improvements, like a new machine built from Gigatron ideas.

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

Re: Modified Gigatron Design Ideas

Post by marcelk » 07 Oct 2019, 06:50

Encoding is the binary form. It's code that bursts 160 pixels, and then turns to black. Walter's Gigatron talks explain practically everything about the native instruction set and video generation. I'm not familiar with Atari architectures (other than the 2600 :-)).

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

Re: Modified Gigatron Design Ideas

Post by PurpleGirl » 07 Oct 2019, 10:44

Oh, so encoding is the opcode, I see.

Where can I find such talks? So if that is just a line of pixels, then I could find a way to get them from memory and output them? And could I use an external clock, or would I have to derive the clock from the system clock to ensure compatibility? I am not sure how the Gigatron handles the last refresh.

As for Atari architecture, the 2600 is simpler than the computer ones. It has a 6507 (a 28-pin version of the 6502 with 13 instead of 16 memory address pins, though they only used 12, no /halt line, and no interrupt lines), the TIA chip (like GTIA, but not as complex), and the RIOT chip (RAM, I/O. Timer). Other than that is has mostly discrete resistors and a few pots, inductors, capacitors, and crystals. The cartridges were the ROM and software. One company did make a keyboard and a homebrewer made a BASIC for it.

I was wondering if I could find a way to offload the video on the Gigatron, and it might be helpful if there was a /halt line. I am not sure how to do that. Maybe unhook the program counter from the clock using a signal line, but I wouldn't do that with software video. If hardware took over the timings, that would allow 2 more bits to be used for colors. I'm not sure which 2 colors I'd want to extend the pallete of. Maybe red and either blue or green. Adding a blue could give more purple shades, but adding green could give more orange and brown.

A software halt instruction could be good if someone wanted to add an FPU, though there would likely need to be a line to signal that the FPU is done and cancel the software halt.

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

Re: Modified Gigatron Design Ideas

Post by marcelk » 07 Oct 2019, 11:51

PurpleGirl wrote: Where can I find such talks?
They're all over the place by now :-). There's an early one on the Gigatron site's front page, and there's a recent one from Moscow in this subforum.
So if that is just a line of pixels, then I could find a way to get them from memory and output them?
Personally I have no thoughts on shared memory approaches. Hence the shift register system in the early project.

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

Re: Modified Gigatron Design Ideas

Post by PurpleGirl » 07 Oct 2019, 12:59

I hadn't thought about serializing it. If the address range is at a fixed location, chips could be arranged to be addressed by the pixel counter. So the pixel counter in the video could be used to strobe the memory.

As for how to safely access the memory externally, two ideas come to mind. One is to try dual-port SRAM, and another would be the halt line idea. Maybe freezing the instruction counter could do that.

As for how to do extra colors if syncs are in dedicated hardware, 2 strategies come to mind. One would be to leave the original shades where they are and use the two bits for the additional colors desired. The disadvantage would be that it would be harder to calculate the additional colors since bits would be out of order. The other would be to remap the pins, and the disadvantage there would be some incompatibility with existing software. The colors would be corrupted. If I were to opt for that, it would be good to write a converter program to recalculate all the color values and perhaps replace it in the source code.

The way this sounds, maybe use a 2nd Gigatron and dedicate it to video and sound. If that is a waste, maybe the 2nd Gigatron could be given an FP library. X-Out could be used to send commands while the operands and the result could be passed in memory. One of the lights on the 2nd Gigatron could signal /halt (if that ability is added to the first one). But that would only protect from memory collisions but not protect from race conditions. While an FP initiation /halt would stop things during the write, it would not protect from corruption if the program has skipped the FP instructions before they complete unless it halts while calculating. And I guess that could throw off pixels being buffered in memory.

----
Ooh, a crazy idea came to mind. Why not a modified Gigatron with 2 ROMs that switch back and forth, and maybe 2 program counters, with each counter only incrementing every other cycle or whatever? Thus video routines could be handled by one software stack and user software handled by the other. Not sure if more control circuitry would be needed. This wouldn't be faster, just more user-friendly.

Come to think of it, I think some 286 machines did something similar. They had 2 BIOS chips, one odd and one even. So you could have 2 separate machines a bit more integrated and working as one.

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

Re: Modified Gigatron Design Ideas

Post by PurpleGirl » 09 Oct 2019, 04:58

I guess if I wanted to separate the video, I probably should to it incrementally and leave the BIOS alone until it works. The horizontal pulse is likely the easiest one to get rid of. A pulse generator, probably best derived from the existing clock can generate the syncs, though for starters, since I wouldn't know which line is being sent, I'd want to rely on the existing bit to sync the rows so the display is not fragmented.

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

Re: Modified Gigatron Design Ideas

Post by PurpleGirl » Today, 00:35

Another idea came to mind. Why not piggyback an unused NOP instruction as a function to reset dedicated video HW? That way, HW can manage the syncs, but if things get out of sync or software cannot be trusted, then issuing an alternative NOP would reset the pixel counter. As for intercepting the instruction, I guess that could be done by using diodes and resistors to tie the unwanted lines into a common output (ORing them), doing a NOT of that and ANDing with the desired lines. Then the high signal from there could reset the pixel counter.

Post Reply