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: 109
Joined: 17 Feb 2021, 23:07

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

Post by lb3361 »

Anyway for those who want to try a SD card plugged in the expansion board:
  1. Unzip the attached 'sys1.zip' file.
  2. Burn 'dev.rom' into a fresh ROM to be installed in your Gigatron

    Code: Select all

    $ minipro -p 'AT27C1024@DIP40' -w dev.rom -y -s 
  3. Copy 'sd.vhd' onto a SD card.

    Code: Select all

    dd if=sd.vhd of=/dev/YourSdCardDevice bs=1M
  4. Place the SD into a SD breakout connected to SPI0 on the expansion board, and boot the Gigatron.
The dev.rom file is the official dev.rom from the Gigatron ROM repository with the CTRL(X)->CTRL(Y,X) fix. The image sd.vhd contains a file SYSTEM.GT1 from https://github.com/lb3361/gigatron-os/tree/master/sys1 and all the GT1 files I could gather in the Gigatron ROM repository. This is all work in progress but I am quite happy to have reached that point. This was the reason for rewriting the C compiler...

Update: the attached file sys1.zip now contains the rom with the correct fix (viewtopic.php?p=2639#p2639)
Attachments
sys1.zip
(976.64 KiB) Downloaded 104 times
Last edited by lb3361 on 21 Oct 2021, 15:15, edited 2 times in total.
at67
Posts: 435
Joined: 14 May 2018, 08:29

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

Post by at67 »

Well done on solving the problem, I couple of questions:

1) Does CTRL actually write to RAM, (you mentioned something about random values being written)? If it does then that is your issue, when Y=0 you are overwriting parts of zero page.

2) What value did you make Y to get it to work, zero?

P.S. You can easily miss timing issues in my emulator when using the graphical timing bar, (i.e. timing glitches that happen once per video frame), un-comment cpu.cpp:1272 to never miss a timing error.
lb3361
Posts: 109
Joined: 17 Feb 2021, 23:07

Re: Gigatron OS - Some progress and a hardware mystery (solved at last).

Post by lb3361 »

I finally understand what is going on!

The CTRL instruction is a nonsensical ST instruction that asserts both write enable /WE and output enable /OE. Without an expansion board, this would write a random byte at the specified location. The expansion board detects that both are asserted, prevents /WE from reaching the RAM chip, and interpret the provided address as special functions such as switching banks or twiddling SPI signals. All expansion board so far (from Marcel's to Hans61's) compute /RAMWE = /WE or /OE in order to prevent writing anything during a CTRL instruction. Imagine now a CTRL instruction followed by an instruction that does not load from memory. This second instruction deasserts /OE on CLK1 via a single 74HCT139. Meanwhile /WE is de-asserted on CLK1 with a 74HCT32. Which one arrives faster is anyone's guess. Therefore the RAM can receive an asserted write enable signal during a short window after the raising clock. The RAM chip may or may not write. If it does, the write address is a mix of whatever address was presented during the CTRL instruction and whatever the following instruction causes the address bus to eventually become. For instance, for a sequence CTRL(X);LD(constant), this would write somewhere in page zero. Soon or later one is going to touch a byte that controls the video timing. In contrast, none of this happens when the CTRL instruction is followed by a memory load such as LD([vTmp]) because the latter also asserts /OE and therefore does not open a window for a spurious write enable.

To verify this theory, I returned to the initial ROM (the one with problem) and identified the only two CTRL instructions that are not followed by a memory load or another CTRL instruction. I just inserted a LD([vTmp]) after these two CTRL instruction and adjusted the timing constants to account for the additional instructions. The diff can be seen in the pull request https://github.com/kervinck/gigatron-rom/pull/212

Result: the lost sync problems are gone, which I believe validates the theory.

Conclusion: CTRL() MUST ALWAYS BE FOLLOWED BY AN INSTRUCTION THAT LOADS SOMETHING FROM MEMORY (ASSERTS /OE)

In the end, this is the way the Gigatron works.
at67
Posts: 435
Joined: 14 May 2018, 08:29

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

Post by at67 »

Congratulations, mystery solved and makes perfect sense.
bmwtcu
Posts: 65
Joined: 01 Nov 2018, 12:02

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

Post by bmwtcu »

nice work!
axelb
Posts: 18
Joined: 07 Jan 2021, 06:27

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

Post by axelb »

The new ROM works great with your GAL based Expansion & IO board ! Is it possible to modify the contents of the vhd file ?
walter
Site Admin
Posts: 129
Joined: 13 May 2018, 08:00

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

Post by walter »

Nice detective work!
lb3361
Posts: 109
Joined: 17 Feb 2021, 23:07

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

Post by lb3361 »

axelb wrote: 22 Oct 2021, 06:45 The new ROM works great with your GAL based Expansion & IO board ! Is it possible to modify the contents of the vhd file ?
The vhd file is just a FAT32 filesystem!

Any tool that handles FAT images should work. I wrote https://github.com/lb3361/dosfs to teach myself how to use the FatFS library. In fact, after imaging a SD card with sd.vhd, you can just pop the card into a SD card reader and start changing things. The only problem is that the filesystem is limited to 64MB, which is the smallest one I can do with FAT32.

In fact I have fixed CardBoot.gcl in the ROM. You should now be able to take any FAT32 formatted SD card, copy SYSTEM.GT1 into the root directory (last version attached). Cards between 2GB and 32GB come FAT32 formatted. Those about 32GB come with exFAT but can be reformatted in FAT32.
Attachments
system.gt1
(23.19 KiB) Downloaded 76 times
lb3361
Posts: 109
Joined: 17 Feb 2021, 23:07

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

Post by lb3361 »

at67 wrote: 21 Oct 2021, 18:06 Congratulations, mystery solved and makes perfect sense.
This thread was very useful in fact, with lots of good advice and good insights.

Anyway, we now have a reliable way to browse a FAT32 formatted card on SPI0 and to execute any gt1 it contains. This is comparable to the Pluggy reloaded browser, but without the Pluggy. In theory, the SPI interface can load 30KB/second (one byte per usable scan line) which can be 8 times more than the Loader (one bit per scanline). In practice, it seems hard to go past 8KB/second.

I spent some time yesterday chasing useless divisions or remainders in FatFS to it speed up a little bit. Listing long directories takes time because one needs to parse the long file name records (never been a fan of 8+3 names). On the other hand, the Loader benefits from substantial native support and from the help of the AVR chip to navigate the filesystem. In fact, Pluggy is faster than the Gigatron :-). Feels like cheating ;-)


Example: Running at67's Invaders...
Screenshot from 2021-10-23 14-05-54.png
Screenshot from 2021-10-23 14-05-54.png (7.03 KiB) Viewed 3285 times
Screenshot from 2021-10-23 14-06-25.png
Screenshot from 2021-10-23 14-06-25.png (6.93 KiB) Viewed 3285 times
Screenshot from 2021-10-23 14-06-40.png
Screenshot from 2021-10-23 14-06-40.png (8.73 KiB) Viewed 3285 times
klf
Posts: 15
Joined: 10 Jan 2019, 22:48

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

Post by klf »

Did I understand correctly -- your Gigatron OS does not use the zeropage switching, so that it also works with the classic expansion board?

I want to keep my Gigatron GAL-free as long as possible :-)
Post Reply