LCC for the Gigatron. Take two.

[lb3361]

Thanx. Good to know. Seems like floating point calculations are more benefitting from dev7.rom.

The floating point code benefits just a little bit more:
* the speed ratio between longfract and fpfract2 is 2.3 for romv5 and 2.2 for dev7.
* the speed ratio between dev7 and v5a is 4.5 for fpfract2 and 4.3 for longfract.

This is not too surprising since the same new opcodes are used to manipulate long integers or the floating poing mantissa. On the one hand, the longfract code needs to perform an additional right shift after the multiplication. On the other hand, the floating point routines needs to compute the exponent and to normalize the mantissa, something that takes more time than just an additional shift.

Question about gtemuAT67 what to put in loader_config.

Code: Select all

RomName2    = dev7.rom
RomType2    = 0xf8

RomType for all devroms, including dev7.rom is 0xf8. RomType for romv6 is 0x48. But you also need to change gtemuAT67 to not reject this rom type as unknown. Example at https://github.com/lb3361/gigatron-rom/ ... 2837de8ca4

[veekoo]

Still I kept wondering about proper integer fractals. I modified the long integer version a bit with trial and error. This is not good at any standards but something to measure how fast it could be. This is not final version. Something to work on.

Test for Mandelbrot fractal, screen size 40x30, iterations 16.

Intfract.gt1 - parameters: 1,40,30. Took: 43 sec

edit. files removed because of new versions

[lb3361]

Intfract_dev7.gt1 - parameters: 1,40,30. Took: 15 sec

I did not expect it to be much faster, but I had forgotten the dev7 integer multiplication instruction which is very effective here.

A potentially interesting comparison would be with the official devrom from the main repository (compile with -rom=dev6) which has at67's native multiplication, lifted with permission in preparation for the doomed romv6. I would expect about 22 sec of runtime.

[veekoo]

So far I have found out:
Long integer version worked with 8192(13-bit) multiplier/divider and numbers fit in long integer space. Enough to accurate and maybe zoom in.160x120 screen works.

Integer version now works with 32(5-bit) multiplier/divider and numbers fit in integer space. Basic view is so and so accurate and no zoom ins. Max of 80x60 screen.

Also 64(6-bit) showed some response but there were artifacts in picture. 160x120 screen possible.

Those who have dev6 rom there is attached file.

edit. files removed because of new versions

[lb3361]

Summary (fresh timings)

Code: Select all

a. Intfract.gt1, running on rom v5a 		-- params: 1,40,30. Took: 43 sec
b. Intfract_dev6.gt1, running on dev rom	-- params: 1,40,30. Took: 22.5 sec
c. Intfract_dev6.gt1, running on dev7 rom 	-- params: 1,40,30. Took: 16.8 sec
d. Intfract_dev7.gt1, running on dev7.rom 	-- params: 1,40,30. Took: 14.5 sec

• (b)-(a) is the time saved with the native multiplication as a SYS call.
• (c)-(b) is the time saved by the new fsm-based native multiplication, still as a SYS call.
• (d)-(c) is the time saved by using the new opcodes, including the multiplication opcode which cuts the multiplication setup time.

Marcel's mandelbrot.gt1 program built in the rom uses integers with 7 bits of fractional part and a table-based multiplication that only works for numbers in range -8.0 to +8.0. This is just enough for a full 160x120 view. Zooming in is impossible. A faster version was written for the dev6 rom using the table approach of quertyface (see https://forum.gigatron.io/viewtopic.php?p=2738). The 320x240 version written for the Gigatron 512k uses 8 bits of fractional part to support the added resolution for the same full view of the Mandelbrot set (https://forum.gigatron.io/viewtopic.php?p=2892). All these versions can be quite fast but remain very limited in what they can show.

Your versions can be competitive in speed and can be more capable, but not necessarily at the same time

[veekoo]

In youtube there is a channel where they do "battle royale" with 8-bit or 16-bit machines. They measure how Mandelbrot performs in each machine. If you have spare time have a look.

https://youtube.com/playlist?list=PLPSr ... 8BTT3uceqU

https://youtube.com/playlist?list=PLPSr ... -hqJDLPD0G

Some of codes and executables in https://github.com/SlithyMatt/multi-mandlebrot

Edit. Actually they used Mandelbrot, screen size 32x22 and 15 iterations. Gigatron TTL is in this group probably as fast as rest of them 8-bits.

This was the battle royal for 8-bit machines. Now we found out how Gigatron TTL compares.

Mandelbrot set 32x22pix and 15 colors/iterations

Final BASIC Leaderboard
-----------------------
Commander X16: 23sec
BBC Micro: 1min 37sec
Amstrad CPC 464: 1min 39sec
Atari 800: 2min 16sec
Apple ][: 2min 45sec
Commodore 64: 3min 23sec
Sinclair ZX Spectrum: 4min 33sec

Final Assembly Leaderboard
--------------------------
Commander X16: 3.2sec
BBC Micro: 12.7sec
Amstrad CPC 464: 12.9sec
Sinclair ZX Spectrum: 13.5sec
Commodore 64: 26.4sec

Gigatron TTL Comparison - C
---------------------------
intfract_dev7.gt1 parameters 1,32,22. Took 7.43sec
longfract_dev7.gt1 parameters 1,32,22. Took 22.11sec
fpfract2_dev7.gt1 parameters 1,32,22,14. Took 45.76sec

intfract.gt1 parameters 1,32,22. Took 23.42sec
longfract.gt1 parameters 1,32,22. Took 1min 29.89sec
fpfract2.gt1 parameters 1,32,22,14. Took 3min 28.56sec

[NEO]

I have 2 questions to C programs:
(1.) Are studio file functions fopen, fread, fwrite, fseek, fclose are supported for SD card file access ?
(2.) How much free space for allocation is available for a C program with the 128kb system memory ?

[lb3361]

(1.) Are studio file functions fopen, fread, fwrite, fseek, fclose are supported for SD card file access ?
(2.) How much free space for allocation is available for a C program with the 128kb system memory ?

(1) Not yet. One has to write an OS first. But the library is designed to eventually support this.

(2) Depends on the Rom. With dev128k7.rom you can use options -rom=dev7 -map=128k and have 62KB of contiguous memory available. But you have to use banking to poke the frame buffer, which is delicate. With older roms, the screen buffer is in the usual place, so you have about 10KB in the form of screen buffer holes, and 32KB above address 0x8000.

[lb3361]

I made several improvements to GLCC after petersieg's thread (https://forum.gigatron.io/viewtopic.php?t=431). They currently are in the head of the GLCC repository and will appear in the next release after a bit of testing time.

Conio interface

I added an include file <conio.h> https://github.com/lb3361/gigatron-lcc/ ... on/conio.h that offers a more familiar interface to the console code. In the process I also made the console code a bit smaller, partly because more parts are hand coded in assembly code, and partly because it only understands the CR, LF, and BS control codes by defaults. The full handling comes back if one uses stdio.

Selectable input driver

I took advantage of the conio work to rethink the way the input code works. Input on the Gigatron is a mess because the pluggy keyboard was added as an afterthought. The Pluggy keyboard and the Famicom controller can emit the same codes to mean completely different things, e.g. an ascii key or a combination of buttons. Certain controllers, known as Type C controllers, can emit ascii codes for simple button presses.

The new include file <gigatron/kbget.h> https://github.com/lb3361/gigatron-lcc/ ... on/kbget.h provides three alternative drivers to handle these problems in increasingly sophisticated ways.

• The default driver replicates the previous GLCC behavior and is suitable for keyboard centric applications.
• A more advanced driver provide a much better experience for applications that rely on the buttons and need a responsive interface. Although the design of the Gigatron input makes it impossible to fully distinguish keypresses from button presses, I believe that I found a very usable approximation (this was not easy). See the comments in the include file for an explanation.
• A third one adds autorepeat.

The simplest way to select one of these drivers is to use the new linker option '--option':

Code: Select all

stuff/conio % glcc -o TSTkbgetc.gt1 TSTkbget.c --option=KBGET_AUTOREPEAT
stuff/conio % glcc -o TSTkbgetb.gt1 TSTkbget.c --option=KBGET_AUTOBTN
stuff/conio % glcc -o TSTkbgeta.gt1 TSTkbget.c --option=KBGET_SIMPLE

Selectable formatting code for printf-like functions

The complexity of the ANSI C printf specification has long been a problem because the printf library code is too bulky. GLCC already offers a simpler function called mincprintf that is very compact but is annoyingly limited. I was trying to provide a more balanced one called midcprintf when I realized that it would be better to offer a choice of low-level formatting engines that will be used by all printf-like functions: printf, cprintf, sprintf, etc.

The new include files <gigatron/printf.h> https://github.com/lb3361/gigatron-lcc/ ... intf.h#L69 defines a function pointer '_doprint' that can either be the default '_doprint_c89' or the more compact '_doprint_simple' which takes one third of the size and yet is far more capable than mincprintf.

The simplest way to select one is again to use the new linker option '--option' :

Code: Select all

% glcc -o TSTmem.gt1 TSTmem1.c  --option=PRINTF_C89 && wc -c TSTmem1.gt1
    5213 TSTmem.gt1
% glcc -o TSTmem.gt1 TSTmem2.c  --option=PRINTF_SIMPLE && wc -c TSTmem2.gt1
    4056 TSTmem.gt1

Note that using cprintf instead of printf still saves the stdio overhead. These options are just about the formatting routine that is used by all printf-like functions save for mincprintf, which has its own, and midcprintf, which always uses _doprint_simple.

[veekoo]

It seems that the latest compiler has some changes to the console and my programs seem to tilt when run in ROMv5a or ROMv6. So problems lies in the compiler or should I change somethings in the code. Its workaround to avoid using stdio.h and printf/scanf. Here is some of the code:

Code: Select all

#include <stdlib.h>
#include <string.h>
#include <gigatron/console.h>
#include <time.h>

int readint(const char *prompt)
{
	char buffer[32];
	cprintf(prompt, strlen(prompt));
	console_readline(buffer, sizeof(buffer));
	return atoi(buffer);
}

void main()
{
  int b0[5],bb[5],i,ii,total,game,sw,it;
  long cash,jp,saldo;
  int bt0[2],bbt[2];
  int totalbt,eit,egame;
  int sil; //printout silence mode
  int cup; //cupoung silence mode
  int big; //big saldo annoucements mode 0-10000

  cprintf("Eurojackpot simulation:\n"); 
  eit=readint("\nNbr of iterations:");
  egame=readint("Nbr of games:");
  sil=readint("Printout silence 0/1:");
  cup=readint("Cupoung silence 0/1:");
  big=readint("Big saldo info 0/nbr:");
  
  srand(time(0));

GLCC Release 2.2 seems to otherhand work well for ROMv5a.