Some of my Gigatron LCC programs
Forum rules
Be nice. No drama.
Be nice. No drama.
Some of my Gigatron LCC programs
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.
- Attachments
-
- pi2_dev_32k.gt1
- (16.93 KiB) Downloaded 97 times
-
- hello_dev_32k.gt1
- (6.72 KiB) Downloaded 107 times
Re: Some of my Gigatron LCC programs
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.
Another program is a simple keystroke detection program.
- Attachments
-
- pi2.c
- (345 Bytes) Downloaded 100 times
-
- getkey.c
- (224 Bytes) Downloaded 102 times
-
- getkey_v5a_32k.gt1
- (6.86 KiB) Downloaded 95 times
Re: Some of my Gigatron LCC programs
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.
- Attachments
-
- getkey4_v5a_32k bug.gt1
- (7.07 KiB) Downloaded 101 times
-
- getkey2_v5a_32k bug.gt1
- (7.08 KiB) Downloaded 90 times
-
- getkey4.c
- (395 Bytes) Downloaded 96 times
-
- getkey2.c
- (377 Bytes) Downloaded 95 times
Re: Some of my Gigatron LCC programs
Yep. utoa breaks for small bases like base 2.
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:
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.
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);
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. */
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.