LCC for the Gigatron. Take two.

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

Re: LCC for the Gigatron. Take two.

Post by lb3361 »

at67 wrote: 22 Oct 2022, 02:10 It is an excellent tool in gaining more vCPU time for your application, the only real issue with it is that the final output of the mixed 4 channel audio samples is never output to XOUT during the blanked scanlines. So depending on your application, how much audio it uses and how many scanlines you blank, some audio distortion will invariably be introduced.
I also noticed that frameCount is counting too slowly if you set videoTop_v5=240, but correct if you leave one displayed scanline with videoTop_v5=238. Is this the same bug?

Update: I checked the code and realized, as explained by at67, that sound is not processed while scanlines are blanked by videoTop_v5. In addition, when one sets videoTop_v5 to 240, the code that tests that one has reached the end of the screen is skipped. This not only means that frameCount is wrong (apparently halved) but also that the signal sent to the monitor makes no sense. Therefore the highest value one should give to videoTop_v5 is 238, leaving a single row of pixels at the bottom of the screen (which could be useful anyway).
lb3361
Posts: 360
Joined: 17 Feb 2021, 23:07

Re: LCC for the Gigatron. Take two.

Post by lb3361 »

I spend some time hacking the lcc common code to support two new keywords, __near and __far. They keywords act as type qualifiers like const or volatile and are supposed to indicate where variables of that type should be allocated.

I hope that, in a distant future, variables declared with __far types will live in banked extension memory. However this requires a lot of additional work because one needs to modify the lcc common code to deal with pointers of different sizes, and, in order to have reasonable performance, one also needs to define new vCPU instruction to peek/poke far pointers.

However there is already a very valuable use. Variable declared with __near types are placed in page zero. The linker keeps track of the remaining page zero location and transparently allocate space for these variables. The compiler is informed of their location and can generate more compact code to manipulate them.
  • The first application was to rewrite the <gigatron/sys.h> file. This file used to give access to the standard Gigatron variables using clumsy defines. Now it simply contains a collection of extern __near declarations. The actual locations are then provided by the interface.json file.

    Code: Select all

    extern __near byte zeroConst;
    extern __near byte memSize;
    extern __near byte entropy[3];
    extern __near byte videoY;
    extern __near byte frameCount;
    extern __near byte serialRaw;
    ...
    
  • The second application was to save a lot of console code by storing the console state in page zero. The main effect was added by simply adding the keyword __near to both the declaration and the definition of variable console_state.

    Code: Select all

    extern __near struct console_state_s {
    	int  fgbg;		/* fg and bg colors   */
    	char cy, cx;		/* cursor coordinates */
    	char wrapy, wrapx;	/* wrap/scroll enable */
    } console_state;
    
    The console code also used to cache pointers to the console_state variables in order to produce better code. This was no longer useful. This simple changes saves 150 bytes on program sizes. For instance the sieve programs are down to 2500 bytes.
veekoo
Posts: 121
Joined: 07 Jun 2021, 07:07

Re: LCC for the Gigatron. Take two.

Post by veekoo »

There might be problem with compiler. I modified my ascbrot.c and ascjulia.c a bit and those GT1s don't run at my Gigatron or Web emulator. With gtemu-at67 it seems to work. Then I tried the original codes from stuff/veekoo and those behaved the same way. Now I have diffrent GT1s that don't work. The GT1s from forum are good and work. So there might be something with compiler. Probably something releated text graphics and console. All my other programs work.

My setup is Gigatron TTL ROMv5a / 64K RAM and pluggy reloaded. GLCC is the latest.
veekoo
Posts: 121
Joined: 07 Jun 2021, 07:07

Re: LCC for the Gigatron. Take two.

Post by veekoo »

Perhaps there is something upgraded in the latest GLCC that involves text graphics and console. I am pretty sure the source codes in my programs are fine but the GT1s from latest don't seem to work. This problem is only with ascbrot.gt1 and ascjulia.gt1, all the other programs work. My GT1s from forum thread are also fine, but they have been compiled ages ago.
lb3361
Posts: 360
Joined: 17 Feb 2021, 23:07

Re: LCC for the Gigatron. Take two.

Post by lb3361 »

Can you share the source code of the precise version of ascbrot that doesn't work, as well as sufficient information to reproduce what doesn't work. There are many versions around and I do not know with which one to start. Here, all seems to work...
Attachments
ascjulia.gt1
(3.99 KiB) Downloaded 109 times
ascbrot.gt1
(4 KiB) Downloaded 99 times
veekoo
Posts: 121
Joined: 07 Jun 2021, 07:07

Re: LCC for the Gigatron. Take two.

Post by veekoo »

Strange thing. Those files don't work. Tested in Web emulator. Then I used original source code found in every glcc stuff/veekoo/ and they didn't work when compiled.

I used https://gigatron.io/emu-dev/

Compiled ./build/glcc -map=32k -rom=v5a ../CODE/ascbrot.c -o ../CODE/ascbrot.gt1
and ./build/glcc ../CODE/ascbrot.c -o ../CODE/ascbrot.gt1

Compiler version GLCC_RELEASE_2.1-27-g082361c

btw. It tilts and starts snakes. Snakes in the nest? :lol:
lb3361
Posts: 360
Joined: 17 Feb 2021, 23:07

Re: LCC for the Gigatron. Take two.

Post by lb3361 »

This was in fact a conflict with the Loader!

The traditional Loader prepares everything then goes into a loop that was apparently designed to only use certain memory locations in the screen buffer. Except that this is not the case: it still uses a couple zero page variables at address 0x3a to 0x41 to cache the addresses of the custom loader SYS calls. Because the loader can only load one segment in page zero, this means that loading anything below 0x42 is effectively forbidden when one uses the loader (0x44 for ROMv3 and earlier, but GLCC never targets those.)

It did not show in gtemuAT67 because, unlike the online emulator, gtemuAT67 does not rely on the loader protocol to load gt1 files. It does not show with DEV7ROM because its loader because it is entirely native. It does not show when loading files from the SPI SD card because this does not involve the Loader at all. I could not test ROMvX0 which also has a native loader because this loader does not seem to work in the online emulator...

Anyway, this was fixed in GLCC by just changing glink to avoid using anything below 0x42 in ROM < 7.
Attachments
ascjulia.gt1
(3.99 KiB) Downloaded 116 times
ascbrot.gt1
(4 KiB) Downloaded 117 times
veekoo
Posts: 121
Joined: 07 Jun 2021, 07:07

Re: LCC for the Gigatron. Take two.

Post by veekoo »

Ok thanx. It seems to affect over half of my programs. Allthough only minority showed some problems and mostly those with console.

ascbrot.gt1 -> fixed / showed problems
ascjulia.gt1 -> fixed / showed problems
burnship.gt1 -> ok
burnshipX.gt1 -> ok
gfxbrot.gt1 -> fixed
gfxbrotx.gt1 -> fixed
gfxjulia.gt1 -> fixed
gfxjuliax.gt1 -> fixed
longbrot.gt1 -> ok
longjulia.gt1 -> ok
newlottosimu.gt1 -> fixed / showed problems
newlottosimufix.gt1 -> fixed / showed problems
rndbrot.gt1 -> fixed
rndjulia.gt1 -> fixed

My programs in forum should work anyway...compiled ages ago and tested

Looking at the list of programs, I am tempted to create all-in-one fractal program. Basically it's the same code in most of those. Difference in mandelbrot, julia and burning ship is very small. This avoids my principle of quick and dirty code.
lb3361
Posts: 360
Joined: 17 Feb 2021, 23:07

Re: LCC for the Gigatron. Take two.

Post by lb3361 »

Glad to know they all work now.

Btw it seems to me that you once asked whether glcc can build programs for ROMvX0.
There are in fact three ways to go:
  • Use -rom=vx0. This tries to use some (but not all) the new vx0 instructions. This code should have nice speedups on longs, and some improvement on floats. But it can break any time because at67 made clear that the instruction set and instruction encoding can change from version to version.
  • Use -rom=v6-- (with minus minus) which compiles code similar to ROMv6 but without the CMPHI/CMPHS instructions that were displaced. This code should run on all recent roms (dev rom, v6 rom, vx0 rom, dev7 rom) but not on romv5a because it uses the native multiplication and memory copy operations. Speed is a bit slower than v5a.
  • Use -rom=v4. The code is less efficient, takes more space, but should run for all roms >= 4.
I have no experience with the vX0 loader and the pluggy browser.
The SD-SPI browser works fine with the latest last version of system.gt1 (which is compiled with v6--, thanks to axelb)
veekoo
Posts: 121
Joined: 07 Jun 2021, 07:07

Re: LCC for the Gigatron. Take two.

Post by veekoo »

lb3361 wrote: 05 May 2023, 14:46 Btw it seems to me that you once asked whether glcc can build programs for ROMvX0.
There are in fact three ways to go:
  • Use -rom=vx0. This tries to use some (but not all) the new vx0 instructions. This code should have nice speedups on longs, and some improvement on floats. But it can break any time because at67 made clear that the instruction set and instruction encoding can change from version to version.
  • Use -rom=v6-- (with minus minus) which compiles code similar to ROMv6 but without the CMPHI/CMPHS instructions that were displaced. This code should run on all recent roms (dev rom, v6 rom, vx0 rom, dev7 rom) but not on romv5a because it uses the native multiplication and memory copy operations. Speed is a bit slower than v5a.
  • Use -rom=v4. The code is less efficient, takes more space, but should run for all roms >= 4.
I have no experience with the vX0 loader and the pluggy browser.
The SD-SPI browser works fine with the latest last version of system.gt1 (which is compiled with v6--, thanks to axelb)
Good to know. Yes I think I will compile my programs to 32/64K RAM and ROMv4 or ROMv5a and use 64K RAM + ROMv5a + Pluggy Reloaded machine. When one of those advanced ROMs come mainstream, I will jump in the train. While waiting I'll keep testing these new programs/games with emulators. I have already transferred some of my programs to Linux-X86 so the C programs have a future in there also.
Post Reply