Gigatron OS - Some progress and a (solved) hardware mystery.

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
lb3361
Posts: 107
Joined: 17 Feb 2021, 23:07

Gigatron OS - Some progress and a (solved) hardware mystery.

Post by lb3361 »

I am working on using the SD card attached to my Gigatron RAM & IO expansion (https://github.com/lb3361/gigatron-lb/t ... sion-retro). This should also work with Marcel's design or Hans61's design. At this point I have a nice read-only browser that relocates itself in bank3, browses the SD card, and can load any GT1 intended for a 32k or 64k Gigatron. This relies on a SYS function that is only available in the dev rom to copy data across banks. But as a result, the loader runs from bank3, using no memory at all from bank 0 or 1, except for a six bytes trampoline located in the stack space when transferring control to the loaded program. See the cellphone video at https://www.youtube.com/watch?v=NVz7u3ZNf54 .

Right now this is still hacky. I had to fix many aspects of Marcel's CardBoot program, and because I am out of AT27C1024 write-once ROMs, I am using a SD card that is bizarrely formatted to work around the limitations of the CardBoot burnt in my last ROM. Also CardBoot is very slow (it takes about 20 seconds. I cut the video). But this is on a good track. The browser code (https://github.com/lb3361/gigatron-os/tree/master/sys1, to be documented) needs to be computed with the very last version of GLCC (to be documented as well) and you need the latest v5a DEVROM to have the proper SYS_CopyMemoryExt and CardBoot.gt1.

The reason for my early post is in fact a hardware mystery. See how my VGA screen flickers and woobles around 0:30 when I am loading at67's Boing demo. This happens whenever I am quickly switching banks or maybe merely accessing different banks in quick succession. It is worse when accessing the SD, but also happens to a lesser extent when copying things across banks. Yet everything seems to work fine. I would be grateful if people more experienced in hardware could help me prune the list of possible culprits. These are much harder to debug than software (for me at least.)
  1. Timing error in SYS_CopyMemoryExt. Running them in at67's emulator doesnt show timing issues.
  2. Power issues. I tried a stronger power supply to no effect.
  3. Decoupling issues. My expansion card has 33nF capacitors near each chip. I noticed Hans61's card has 100nf capacitors. Could that be the problem?
  4. GAL glitches or excessive power requirements?
  5. Interferences with the VGA cable. The Gigatron is not exactly RF friendly ?
  6. Something else?
Last edited by lb3361 on 21 Oct 2021, 17:47, edited 1 time in total.
lb3361
Posts: 107
Joined: 17 Feb 2021, 23:07

Re: Gigatron OS - Some progress and a hardware mystery.

Post by lb3361 »

I tried all my collection of expansion boards. All of them do the same snow, including the very first one (viewtopic.php?f=3&t=282) which is a very different design using SSOP 74xxx files instead of GALs. The only common point is the RAM chip and the 33nf decoupling capacitors. Could it be that the RAM eats too much current when using all the banks?

I think this eliminates (4). It reduces the likelihood of (5) because my first two boards are four layer designs with two internal power planes, which in theory are much more RF friendly. I also checked (1) again with a version of at67's emulator that prints lots of video synchronization diagnosis messages, but did not find anything wrong...

The most amusing thing is that apart for the snow and wobbling screen, all works find. I can load anything....
bmwtcu
Posts: 63
Joined: 01 Nov 2018, 12:02

Re: Gigatron OS - Some progress and a hardware mystery.

Post by bmwtcu »

Is the OSD message popping up at 36s indicative of loss of vsync? I don't suppose you have an oscilloscope you can monitor vsync with? Have you also tried different monitor and different VGA cable? You don't want to know how many times a flaky cable has been the root cause of my woes.
lb3361
Posts: 107
Joined: 17 Feb 2021, 23:07

Re: Gigatron OS - Some progress and a hardware mystery.

Post by lb3361 »

bmwtcu wrote: 18 Oct 2021, 23:47 Is the OSD message popping up at 36s indicative of loss of vsync? I don't suppose you have an oscilloscope you can monitor vsync with? Have you also tried different monitor and different VGA cable? You don't want to know how many times a flaky cable has been the root cause of my woes.
Yes there is a loss of vsync. But the question is why it occurs always in this place and not in normal usage.
at67
Posts: 431
Joined: 14 May 2018, 08:29

Re: Gigatron OS - Some progress and a hardware mystery.

Post by at67 »

Firstly that looks great, well done. I don't have much of an idea of how the expansion card works, but the first thing to do as bmwtcu said is to put HSync and VSync on a CRO.

The snow is indicative of noise and/or race/timing conditions, once again like bmwtcu suggested, try different monitor cables and monitors, (even if they worked fine before, something may be marginal about the current circuit/software and may react differently with different cables/monitors.

Does the hardware/software interact with HSync/VSync in anyway at all? For example the BabelFish save mechanism modulates the length of VSync to output one bit per vertical sync which some monitors don't appreciate at all.
bmwtcu
Posts: 63
Joined: 01 Nov 2018, 12:02

Re: Gigatron OS - Some progress and a hardware mystery.

Post by bmwtcu »

at67 wrote: 19 Oct 2021, 06:57 For example the BabelFish save mechanism modulates the length of VSync to output one bit per vertical sync which some monitors don't appreciate at all.
That was exactly what I was thinking of when I saw it.
lb3361
Posts: 107
Joined: 17 Feb 2021, 23:07

Re: Gigatron OS - Some progress and a hardware mystery.

Post by lb3361 »

at67 wrote: 19 Oct 2021, 06:57 For example the BabelFish save mechanism modulates the length of VSync to output
one bit per vertical sync which some monitors don't appreciate at all.
Problem is that the expansion board does none of this. It only plugs through the RAM socket and the A15 pin. The only signals it touches are A[0..15], /OE, /WE, and BUS[0-8]. Noise on any of these signals would prevent the Gigatron from executing anything! Instead I get some amount of noise on HSYNC during the video blanks, that is, when vCPU instructions are running...

It turns out the HSYNC resistor is located immediately below the SD-Card. EMI? Nope. Displacing the SD-Card elsewhere didn't change anything. I also noticed that the noise does not occur when one accesses the SD, but when SYS_CopyMemoryExt copies data across banks in a tight loop that exercises the RAM very densely. Next I am planning to try using a fatter decoupling capacitor (1uF) near the RAM chip. But my expectations are low...

- L.
at67
Posts: 431
Joined: 14 May 2018, 08:29

Re: Gigatron OS - Some progress and a hardware mystery.

Post by at67 »

lb3361 wrote: 19 Oct 2021, 19:02 It turns out the HSYNC resistor is located immediately below the SD-Card. EMI? Nope. Displacing the SD-Card elsewhere didn't change anything. I also noticed that the noise does not occur when one accesses the SD, but when SYS_CopyMemoryExt copies data across banks in a tight loop that exercises the RAM very densely. Next I am planning to try using a fatter decoupling capacitor (1uF) near the RAM chip. But my expectations are low...
Capacitive coupling, ground bounce or dirty VCC is much more likely than EMI. Is there a schematic somewhere of the expansion board? I mean your modified one.

The fact that the noise manifests when you switch banks suggests a race/timing condition either in the circuit or the software, can the bank switching occur while the Gigatron is scanning out pixels from memory, or is it all under native control?
lb3361
Posts: 107
Joined: 17 Feb 2021, 23:07

Re: Gigatron OS - Some progress and a hardware mystery.

Post by lb3361 »

The schematic is at https://github.com/lb3361/gigatron-lb/b ... ematic.pdf

You also want to see the GAL equations in the PLD files under https://github.com/lb3361/gigatron-lb/t ... retro/cupl. I just changed them to make sure the BUS[0..7] lines are not left floating during a CTRL instructions, to no avail.

The bank switching is entirely under native control. It happens during the execution of the CTRL instruction, when bits 6 and 7 of the address bus are latched into the GAL flip-flops attached to pins B0 and B1 of GAL1. (https://github.com/lb3361/gigatron-lb/b ... L1.pld#L51) These output pins are not connected because their value is used via a feedback path to generate outputs A15R and A16R (https://github.com/lb3361/gigatron-lb/b ... L1.pld#L73) which go directly into the SRAM. There are two minor subtleties in the design. Because all GAL flip-flops are latched when pin1 (CTRLCLK in my files) goes high, GAL1 computes a signal CTRLCLKOUT which is externally looped to pin1 of both GALs. The second one is that GAL1 receives two address decoding signals GTG1 and GTG2 which are computed by GAL2. The remaining cells of GAL2 are using to latch the rest of the CTRL instruction argument (the SPI clock and the SPI chip select).

All this produces the correct results. I haven't seen an instance where the loss of vga sync was associated with incorrect gigatron operation. What seems to happen is that the HSYNC signal gets noisy in a manner that the monitor interprets as a timing change. And this happens while native code is executing tight loops that involve the CTRL instruction while exercising all banks of the RAM (e.g. SYS_CopyMemoryExt). Of course I triple-checked the timings of SYS_CopyMemoryExt by adding extra printfs into gtemuAT67.

To bad that fixing the floating bus didn't do it. I am now waiting for my beefed up capacitors. I ordered a couple 1uF ones but maybe I was too shy...

- L.



p.s. -
An example of code that really messes up the vga sync is the stress test in https://github.com/lb3361/gigatron-lcc/ ... ext.c#L227 which copies memory from bank to bank repeatedly. I am going to check the timings of SYS_CopyMemoryExt again. Maybe the red border test in gtemuAT67 does not capture all potential problems...
lb3361
Posts: 107
Joined: 17 Feb 2021, 23:07

Re: Gigatron OS - Some progress and a hardware mystery.

Post by lb3361 »

The mystery thickens but in a good way.

I made several observations.
  1. A test program that heavily uses the SYS_CopyMemoryExt ROM function and nothing else triggers the problem in a big way.
  2. The same program using instead the SYS_CopyMemory function does not trigger the problem. The main difference is that the former uses instruction CTRL(X) to swap banks before reading or writing, whereas this one does not. So the culprit is the CTRL instruction.
  3. Program that heavily use SYS_ExpanderControl or SYS_SpiExchangeBytes would not trigger the problem despite the fact that these two functions use CTRL. In fact SYS_SpiExchangeBytes is an heavier user than SYS_CopyMemoryExt
  4. However these other SYS function use the forms CTRL(Y,X) or CTRL(Y,X++). SYS_CopyMemoryExt is the only one using CTRL(X).
Therefore I changed all CTRL(X) into CTRL(Y,X) in SYS_CopyMemoryExt and burned new ROM. Result: everything works fine now.

Now I would really like to understand why this is so. It is useful to recall that the CTRL instruction is simply a non-sensical ST instruction that selects the RAM as input. Basically it tries to both read and write the RAM at the same time, which amounts to writing a random value at the specified address. Marcel's expansion board design interpose itself between the Gigatron and the RAM. When this condition occurs, it overrides the write enable signal /WE and latches certain bits of the address into useful output signals: A15 becomes MOSI, A7-A6 become the selected bank, A5-A2 become the SPI selects, A0 become the SPI clock, etc. In principle, CTRL(X) and CTRL(Y,X) only differ in what they put on the A15-A8 lines. But what does this is the decoding logic of the ST instruction on the Gigatron main board. My expansion board does a fair amount of address decoding using A8-A15. Maybe a bunch of zeroes make the GAL power hungry? This is questionable because all this address decoding works very well when one does not try to change the bank bits. But the main fact that disproves this hypothesis is that the problem also occurs when I use my first expansion board design which is much closer to Marcel's initial design and only latches address bits when both /WE and /OE are asserted. In other words, whatever happens when one uses CTRL(X) instead of CTRL(Y,X) happens on the Gigatron board! Which does not make things any simpler of course...
Post Reply