Which z88dk version is good?

If you like transforming your statements into code, this is the place for you

Moderator: Programming Moderators

Henk de Groot
Posts: 28
Joined: Tue May 30, 2017 8:23 pm

Re: Which z88dk version is good?

Post by Henk de Groot » Fri Jul 07, 2017 11:37 pm

I was looking at the score now. Currently I'm using draw functions to draw the score, and when updating I need to undraw the parts I do not need. Maybe I choose a faster method later because it is not very fast this way, but as first prototype it will do. However this did not work the way I expected, fragments of the score are left behind.

So I made another sample program and sure enough, draw and undraw in the classic library do not cancel each other out!

Code: Select all

#include <stdio.h>
#include <graphics.h>

void main()
{
        int i;

        zx_border(INK_BLACK);
        zx_colour(PAPER_BLACK|INK_WHITE);

        clg();

        for(i = 0; i < 24; i++)
        {
                draw(81, 6 + i, 86, 6 + i);
        }

        (void) getchar();

        for(i = 0; i < 24; i++)
        {
                undraw(81, 6 + i, 86, 6 + i);
        }

        (void) getchar();
}
The compiler used doesn't matter, it is an anomaly in the classic library. I have not tried something similar using the new library, maybe I should.

One other annoying thing. I want a black background and white objects, this works, however when the program is finished and back in basic I can't see the characters I'm typing in the lower part of the screen, it didn't change colour like the rest. Maybe also this is something the new library fixed? I didn't find a library function to change the colour everywhere in the classic library. Of course I can start poking system variables but I think I shouldn't have to.

Alcoholics Anonymous
Posts: 513
Joined: Mon May 29, 2017 7:00 pm

Re: Which z88dk version is good?

Post by Alcoholics Anonymous » Sat Jul 08, 2017 4:03 am

Yes new issue.
One other annoying thing. I want a black background and white objects, this works, however when the program is finished and back in basic I can't see the characters I'm typing in the lower part of the screen, it didn't change colour like the rest.
I think it's a mistake to interact with the basic system. Once you use system variables you've lost a chunk of ram. It's rare that you'd want anything to do with the basic system because it's so slow. The only real exceptions are for writing programs that interact with basic, finding an easy way to interact with some peripherals that are intertwined with the basic rom, and maybe using the fp calculator to save a few bytes for floating point.

Those classic functions, besides changing border and attributes, are also poking their parameters into system variables. I'm not sure if there is a way besides poking into the system vars yourself or using those functions again to fix the colours on exit.
Maybe also this is something the new library fixed?
The newlib is independent of the rom. It doesn't use it at all nor does it interact with the system variables in any way. In fact, programs for the Next will be starting at address 0, replacing the ROM completely.

Henk de Groot
Posts: 28
Joined: Tue May 30, 2017 8:23 pm

Re: Which z88dk version is good?

Post by Henk de Groot » Sat Jul 08, 2017 8:47 am

Alcoholics Anonymous wrote:
Sat Jul 08, 2017 4:03 am
It's rare that you'd want anything to do with the basic system because it's so slow.
Yes, it is only for development, at the end it exits main(), so when I want to rerun I type RUN and it will load the tap file again. Especially for ZEsarUX which you have to use for sprites, since it is slow to start up (since it has to load TBBLUE and Esxdos) and horrible to shut down (close button does noting, you have to press F5, F10, Y or kill it with ^C from the xterm session). With fuse I just close the window and rerun the last command to restart but I can't use it with Next specific features like sprites.

Anyway nothing major. Of course when you want to have your program interact with for example microdrives or execute "." esxdos commands to load and save I think you may have to drop back to basic as well. Switching colours back or adding a poke for now works for me, just something I noticed.
The newlib is independent of the rom. It doesn't use it at all nor does it interact with the system variables in any way. In fact, programs for the Next will be starting at address 0, replacing the ROM completely.
I can understand this but I think using the low 16 kB memory may be messy. For example when Interface 1 is connected it triggers on various specific memory locations to extend the basic (the error routing at address 8 and some other locations). So the memory map will have holes that are no go area's because it will page-in the shadow rom of IF1. Other devices may have done the same kind of thing (for example trigger on the NMI address). This may also apply to emulators that watch the tape routine addresses and such. Unless the low part mainly contains the libraries and you carefully avoid those addresses (or not allow any device to be plugged in).

Alcoholics Anonymous
Posts: 513
Joined: Mon May 29, 2017 7:00 pm

Re: Which z88dk version is good?

Post by Alcoholics Anonymous » Sun Jul 09, 2017 1:36 am

Henk de Groot wrote:
Sat Jul 08, 2017 8:47 am
Of course when you want to have your program interact with for example microdrives or execute "." esxdos commands to load and save I think you may have to drop back to basic as well.
Microdrives and other peripherals are painful to use because they are intertwined with basic. They're reserving memory and interacting with the basic system so once you start using them you do have to play with basic, leaving the bottom memory alone.

esxdos exports a nearly posix api to machine code so there's no need to drop to basic to do anything. In the beginning I think we'll just do thin wrappers to load and save but it shouldn't be hard to integrate esxdos into c stdio so you can fprintf, fscanf, etc. from files.
I can understand this but I think using the low 16 kB memory may be messy. For example when Interface 1 is connected it triggers on various specific memory locations to extend the basic (the error routing at address 8 and some other locations). So the memory map will have holes that are no go area's because it will page-in the shadow rom of IF1. Other devices may have done the same kind of thing (for example trigger on the NMI address). This may also apply to emulators that watch the tape routine addresses and such. Unless the low part mainly contains the libraries and you carefully avoid those addresses (or not allow any device to be plugged in).
Yes we may end up tailoring something for the bottom 16k that walks around the triggers, load that in the bottom 16k and then link the rest of the program, placed somewhere higher, against that.

Post Reply