Tip: -Dprintf=mincprintf ist a good option, not having to change the source code at all printf occurences
I did this with reverse.c. From 11k down to 9k.
Then I changed scanf to console_waitkey:
If you want to really see what goes into the generated code, you should use option "--frags" of the compiler/linker which tells you where all the pieces of code go in memory. For instance you can easily see whether you still have stdio things in the generated code.
For instance, when you added -Dprintf=mincprintf, you saved on the printf code, but many of its dependencies were still included because they are necessary for implementing scanf. So when you further removed scanf, you non only saved on the scanf code, but also on all the common dependencies that suddenly became useless. For instance, both printf and scanf requires the stdio support but also cause many helping routines to be include such as strtol to convert strings into longs. This routine then requires long support, etc. All this under-used code adds up quickly.
You'll see also that there is still a lot of cruft remaining in the console code.
Note: The glcc options are listed when you type glcc without argument. The linker options are displayed when you type "glink -h" or "glcc -h". The lcc driver (which is ancient) passes some of the glcc options to the linker. In particular it passes all the double-dashed options to the linker. For instance you can play with options --debug, --info, or --no-runtime-bss-initialization...
Is there some documentation about _console_reset/clear()?
What are the parameters for example in gtmine:
_console_reset(0x3f38);
_console_clear((char*)((8+8*14)<<8), 0x030a, 8);
Is there something like gotoxy(x,y) cursor/printf positioning, independent to 32k/64k/128k?
After reading your thread, I realized that I made a mistake by not sticking to the more-or-less standard conio.h interface. So I just added a new include file <conio.h>: https://github.com/lb3361/gigatron-lcc/ ... on/conio.h. The output functions are thin wrappers to the output function of console.h. Both <conio.h> and <gigatron/console.h> are inter-operable. I would be grateful if you had the time to test them.
This was also an opportunity to improve the input functions. Input on the gigatron is tricky because the pluggy keyboard was added as an afterthought. Combinations of button presses can produce codes that resemble ascii characters. Things are even worse if you are unfortunate enough to have a famicom "type C" controller. So the library provides multiple options: simple, with heuristics to distinguish keyboard presses from button presses, and with autorepeat. For instance you can write
#include <conio.h>
KBGET_AUTOREPEAT;
int main(...)
{
and have all input functions sort out the keyboard or button presses, with autorepeat. I am not sure this is the best way to implement such options, but it works. Suggestions are very welcome.
Super simple test program attached. v0 is NOT using conio.h. v1 is using conio.h clrscr(), but reprints the complete screen all the time
This one v1, also one need to "hammer" on the keys to make snake move? Something destroys key pressed in the meantime?
The current one uses also kbhit, getch and putch. putch doesnt seem to work at all? Here now some delay function needs to be inserted,
otherwise, snake moves way to fast
It uses the controller keys (arrows on the keyboard).
The keyboard was unresponsive because of the strange way the keyboard is interfaced to the Gigatron. Whenever a key is pressed, the serialRaw variablecontains the ascii code for only about 60 milliseconds, regardless of whether the key remains depressed or not. If you do not capture the key during this interval, it is lost. The controller buttons and the arrow keys on the keyboard work differently. The corresponding bit in the buttonState variable remains zero as long as the button is depressed. This leaves more time to capture it. The interaction between ascii keys and button presses can be complicated...
The nochan option to -map=32k cuts the three sound channels that use a couple bytes at the end of pages 2, 3, and 4. This provides a contiguous memory range large enough to contain the fields array. Then the program fits on a gigatron 32k. The fragmented memory of the 32k machine is always a challenge because there is no space large enough to contain any object bigger than 250 bytes..
Thank you!
Lot of information
But your snake.c code does not run as expected? You removed the needed lastkey logic.
(Or I am a bit lost).
Also the program does not respond to any key press whether in Mac Emu and also not in gtemuat67.
I attach here my last the NONE working source, with lastkey logic incorporated.
Maybe you see / find out why no keypress at all are recognized.
(After cursor keys not doing anything, I switched back to w,a,s,d for movement.
If ps2 movement is not really possible in Gigatron, I may change to Game controler input and have a look at gtmine for that.
Here is a version incorporating the input logic from gtmine.
However. This one ends after one round with score zero??
(Maybe its not my day, today. I will take a break )
My version above was working in gtemuAT67. But you have to make sure the keyboard emulation is in the proper mode. When you type CTRL+K, you cycle through three modes named "Kbd", "PS2", and "HwKbd". The mode name is displayed at the bottom of the right panel. The "Kbd" mode emulates the Famicom controller, with keys WASD for the arrow buttons, and keys . and / for the A and B buttons. The "PS2" mode emulates the pluggy keyboard. The ascii keys emit their own code, the arrow keys work like the arrow buttons, and tab and esc for the A and B buttons.
So with my code, if you're in "Kbd" mode, you can use the WASD keys. If you're in "PS2 mode", you must use the arrow keys.
There is no point using the input logic of GtMine. the KBGET_AUTOBTN; thing does that for you already.
