Memory detection

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

Memory detection

Post by lb3361 »

Some Gigatrons with 64K keep displaying "Gigatron 128K" when they boot.

The ctrl() instruction that controls the RAM & IO expansion board is a nonsensical instruction that asserts both the output enable (OE) and write enable (WE) pins of the static ram socket. The expansion board recognizes this condition and updates its status register instead of passing them to the SRAM chip. Without an expansion board, the SRAM chip sees both OE and WE asserted. With the normal 32K SRAM, this causes some random value to be written at the address present on the address bus.

The memory detection code in https://github.com/kervinck/gigatron-ro ... /Reset.gcl first tests whether doing a ctrl(0x7c) writes random data at address 0x7c. If this is the case, there is no expansion board: address 0x1f8 is set to zero to indicate that using the ctrl instruction is unsafe. Otherwise the code assumes there is a memory expansion board and that it is safe to use the ctrl() instruction. It then uses the ctrl(0xbc) instruction to set bank2. If writing to $8024 overwrites $24, then bank2 is the same as bank0, meaning that there is only 64k. Otherwise there is 128k.

The problem is that not all SRAM chips react like the original 32K SRAM when both OE and WE are asserted. Many chips do not write random data but instead do nothing or maybe rewrite what they just read at the indicated address. If such a RAM is used for the 64K hack (https://forum.gigatron.io/viewtopic.php?f=4&t=9), the Reset.gcl code believes that there is an expansion board because ctrl(0x7c) does not write random data. Yet, nothing happens when the code sets bank2. And since writing $8024 does not overwrite $24, the code concludes that the non-existent expansion board contains a 128K chip.

Attached are a few programs that attempt to fix this code.
  • TSTmem.gt1 is a memory test program whose first part is an updated memory detection code that hopefully is able to correctly detect the presence of an expansion board and the correct (accessible) memory size from 32K to 512K.
    TSTmem.c
    (2.83 KiB) Downloaded 90 times
    TSTmem_v4.gt1
    (7.18 KiB) Downloaded 81 times
    TSTmem_v5a.gt1
    (5.81 KiB) Downloaded 90 times
    Screenshot from 2022-05-12 18-29-22.png
    Screenshot from 2022-05-12 18-29-22.png (7.89 KiB) Viewed 1355 times
  • Reset.gt1 is a new version of the reset code which could possibly go into the DEVROM. Running this should be equivalent to a soft reset but with a fixed memory detection code (and a slightly different chord -- feedback welcome). This only works on ROMv5a because it uses SYS_ReadRomDir_v5 to find the MainMenu or the CardBoot programs instead of relying on hardcoded addresses computed during the ROM compilation.
    Reset.gcl
    (11.22 KiB) Downloaded 95 times
    Reset.gt1
    (934 Bytes) Downloaded 92 times
These work as far as I could test. But it would be useful to know whether they work on all Gigatrons, including those that use nonstandard chips, etc.
gfernval
Posts: 40
Joined: 24 Jan 2022, 00:39

Re: Memory detection

Post by gfernval »

How to compile TSTmem.c for v4, v5a and dev roms? (glcc -map=32k TSTmem.c ?)
And Reset.gcl? (python3 core\compilegcl.py Reset.gcl ?)
bmwtcu
Posts: 145
Joined: 01 Nov 2018, 12:02

Re: Memory detection

Post by bmwtcu »

lb3361 wrote: 12 May 2022, 22:35 But it would be useful to know whether they work on all Gigatrons, including those that use nonstandard chips, etc.
Confirmed to work with Xilinx Spartan 6 LX25, which definitely qualifies as nonstandard. (Running SDROM/v5a)
WhatsApp Image 2022-05-14 at 5.32.39 PM.jpeg
WhatsApp Image 2022-05-14 at 5.32.39 PM.jpeg (387.27 KiB) Viewed 1306 times
axelb
Posts: 41
Joined: 07 Jan 2021, 06:27

Re: Memory detection

Post by axelb »

Works perfectly with my 486 cache RAM!
Attachments
61512.png
61512.png (333.03 KiB) Viewed 1283 times
64k.png
64k.png (321.94 KiB) Viewed 1283 times
lb3361
Posts: 360
Joined: 17 Feb 2021, 23:07

Re: Memory detection

Post by lb3361 »

gfernval wrote: 14 May 2022, 21:33 How to compile TSTmem.c for v4, v5a and dev roms? (glcc -map=32k TSTmem.c ?)
And Reset.gcl? (python3 core\compilegcl.py Reset.gcl ?)
See the makefiles https://github.com/lb3361/gigatron-lcc/ ... t/Makefile and https://github.com/lb3361/gigatron-lb/b ... 2/Makefile

You may have to update the variables to the correct location of compilegcl.py and interface.json, or to select the target rom for TSTmem.c.
gfernval
Posts: 40
Joined: 24 Jan 2022, 00:39

Re: Memory detection

Post by gfernval »

A quick question, what should appear in the last glcc (compiled from latest sources) if you do "gclcc --version"?

GLCC_RELEASE_...
lb3361
Posts: 360
Joined: 17 Feb 2021, 23:07

Re: Memory detection

Post by lb3361 »

Code: Select all

$ glcc --version
GLCC_RELEASE_1.4-73-g1fb0fe4
This comes from command 'git describe --tags'
  • GLCC_RELEASE_1.4 is the tag of latest official version
  • 73 is the number of commits since the latest official version
  • 1fb0fe4 designates the hash id of the commit (usage in git checkout for instance).
A lot of things have changed. In particular the page zero usage has been changed to increase compatibility with at67's' forthcoming work. The runtime support for longs and floats now works entirely in area 0xc0-0xcf using either the vCPU emulation or using new instructions present in AT67's forthcoming ROM. The register file now lives in 0x50-0x7f by default but can be relocated elsewhere with option --register-base=xxxx. The code generator supports a newer version of AT67's ROM with native support for long integers, also used to speed up floating point emulation. There is a new map, --map=512k, for the two or three 512k Gigatron in existence (doc with option --info). Long integers are now aligned on 4 byte boundaries instead of 2 bytes boundaries. And a number of library functions have been improved.

I am going to release this as GLCC_RELEASE_1.5 !
gfernval
Posts: 40
Joined: 24 Jan 2022, 00:39

Re: Memory detection

Post by gfernval »

What gives the new glcc 1.5 when run glcc --version? (I use windows XP and cannot run git checkout)

Would like to compile https://github.com/kervinck/gigatron-ro ... ricks.vasm,
how to get bricks.gt1 from bricks.vasm? I have tried to run python3 core\vasm.py bricks.vasm but there is no output.
gfernval
Posts: 40
Joined: 24 Jan 2022, 00:39

Re: Memory detection

Post by gfernval »

it is "gtasm bricks.vasm", right?
gfernval
Posts: 40
Joined: 24 Jan 2022, 00:39

Re: Memory detection

Post by gfernval »

"glcc --version" returns exactly GLCC_RELEASE_1.5 (I have seen your binary glcc-1.5.zip, thanks)

"gtasm bricks.vasm" generates bricks.gt1 file, but I have to change the first byte of generated bricks.gt1 from 0x01 to 0x00
to make a correct bricks.gt1, once done this bricks.gt1 runs well (strange)
Post Reply