Page 1 of 1
Some of my Gigatron LCC programs
Posted: 08 Feb 2022, 17:52
by denjhang
I have some knowledge of C language, but I have little knowledge of gcl and gtbasic. Here are some programs I tried to write using LCC.
Re: Some of my Gigatron LCC programs
Posted: 08 Feb 2022, 18:16
by denjhang
I wrote a simple PI calculation program that doesn't seem to be very fast, about the same speed as MS-Basic.
Another program is a simple keystroke detection program.
Re: Some of my Gigatron LCC programs
Posted: 08 Feb 2022, 19:24
by denjhang
I seem to have triggered some bug, which appears to be a virus program that will make the Gigatron freeze and make noises and you will have to hard reboot to get back to normal.
Re: Some of my Gigatron LCC programs
Posted: 08 Feb 2022, 19:39
by lb3361
Yep. utoa breaks for small bases like base 2.
Code: Select all
/* Functions to convert integers to strings. The buffer should be eight
bytes long for ints and sixteen bytes for longs. Radix should be in
range 2 to 36. Note that the return value is not usually equal to
buffer because the digits are generated backwards. */
extern char *itoa(int value, char *buf8, int radix);
extern char *utoa(unsigned int value, char *buf8, int radix);
extern char *ltoa(long value, char *buf16, int radix);
extern char *ultoa(unsigned long value, char *buf16, int radix);
Obviously, 0xffff in base 2 takes more than 8 characters to represent. My mistake!. Initially these routines did only base 10. Then I added the radix without thinking of the buffer size. This is only used in printf where radix is 8, 10, or 16. So I just changed the comment to:
Code: Select all
/* Functions to convert integers to strings. The buffer should be
eight bytes long for ints and sixteen bytes for longs. Radix should
be in range 8 to 36. Smaller radix might overflow the buffer. Note
that the return value is not usually equal to buffer because the
digits are generated backwards and stored from the end of the
buffer marching towards the beginning. */
Note that when a Gigatron program crashes, there is no guarantee that you'll be able to reset it by pressing select. Because the vCPU instructions opcodes are basically the address of the instruction code in the ROM, executing anything incorrect can derail the carefully timed ROM loop.
Also the execution of the pi program is dominated by the software emulation of floating point arithmetic. This is going to be slow. Turning then into native code might speed this up multiple times (four or five maybe...) but is also quite tricky.