ZX81: Plot, Unplot and test-point for LOWRES (64x44) screen
ZX81: Plot, Unplot and test-point for LOWRES (64x44) screen
FYI: Andy wrote some functions to support lowres plotting at ZX81:
https://www.sinclairzxworld.com/viewtop ... 842#p29689
Maybe this functions could be added to Z88DK?
Siggi
https://www.sinclairzxworld.com/viewtop ... 842#p29689
Maybe this functions could be added to Z88DK?
Siggi
Do you mean the "Interfacing to the ZX 81 BASIC" method for using the PLOT function from zx81.h?stefano wrote:lo rez plotting is already supported (-lgfx81), what's the difference with this function set?
The problem is that this is exactly the same speed as if it was done in ZX Basic (which means: very slow).
Or is there another built-in fast lo-res plot method already there in z88dk? I searched for something like that but didn't find anything.
there is a fast native mode already, you have everything including sprites an 'stencil' support, but I wouldn't recommend this resolution to display complex pictures converted from SVG!
there is also a medium resolution mode for the programmable graphics mods or an even lower resolution of 32x48x3 using the gray dithering present in the standard zx81 font
there is also a medium resolution mode for the programmable graphics mods or an even lower resolution of 32x48x3 using the gray dithering present in the standard zx81 font
i just noticed it is not clear in the current configuration, Il'll try tofix...
https://github.com/z88dk/z88dk/wiki/Pla ... clair-ZX81
https://github.com/z88dk/z88dk/wiki/Pla ... clair-ZX81
You should have also putsprite, draw_profile, point, fwd etc.. I used it e.g. to support graphics on the Campus LISP.
While working on the lo-rez graphics for the Kaypro II (pre-'84 versions) and Osborne 1 I found a nasty bug in this kind of implementation preventing the first row to be displayed correctly, I think the zx81 had a workaround for it but I'm checking all the target platforms.
If your code is faster and has the same functionality I have no objection to replace the existing stuff: please be aware that the z88dk "standard" expects the (0,0) address to be on the top-left corner.
While working on the lo-rez graphics for the Kaypro II (pre-'84 versions) and Osborne 1 I found a nasty bug in this kind of implementation preventing the first row to be displayed correctly, I think the zx81 had a workaround for it but I'm checking all the target platforms.
If your code is faster and has the same functionality I have no objection to replace the existing stuff: please be aware that the z88dk "standard" expects the (0,0) address to be on the top-left corner.
A few more questions about the graphics.h functions:
1. What is the purpose of the -lgfx81 parameter when compiling a program? For the ZX81 the result seems to be the same either with or without that parameter. Maybe because this is already the default setting for the ZX81 target?
2. I tried to use the plot and point functions for the ZX80 target. I have written a little test program that can be compiled for either the ZX81 or ZX80 (I hope my ZX80 compile parameters are correct):
It works perfectly on the ZX81.
On the ZX80, the plot() function works as well. However, the point() function does not, it makes the program crash. The z88dk wiki says "this function might not work correctly on all the platforms". If I add the -lgfx81 option when compiling the ZX80 version, the point() function works, but the plot() function no longer works correctly, as it obviously uses the wrong characters (from the ZX81 character set). Unfortunately there is no -lgfx80 option yet in z88dk, since there is no gfx80.lib file (only gfx81.lib).
Maybe the plot() and point() functions could easily be made ZX80-compatible for a future z88dk release?
Or should it work already and I am only doing something wrong?
3. While we are at it: I also tested plot() and point() on the Jupiter Ace target.
This compiles and runs without error. The point() function works correctly. However, the plotted pixels cannot be seen - maybe becaues the screen has a black background and plotting is done in black? Is there a way to change the background to white, or change the plot colour to white?
1. What is the purpose of the -lgfx81 parameter when compiling a program? For the ZX81 the result seems to be the same either with or without that parameter. Maybe because this is already the default setting for the ZX81 target?
2. I tried to use the plot and point functions for the ZX80 target. I have written a little test program that can be compiled for either the ZX81 or ZX80 (I hope my ZX80 compile parameters are correct):
Code: Select all
/* Plot Test by RobertK, 2018-03-14
Compile for ZX81:
zcc +zx81 -startup=2 -o plottest -create-app plottest.c
Compile for ZX80:
zcc +zx80 -o plottestZX80 -create-app plottest.c
*/
#include <stdio.h> // required for printf()
#include <graphics.h> // contains plot() and point() functions
void main()
{
printf("\n\n\n\n\n*** plot test ***\n\n");
plot(1,1);
plot(3,3);
plot(5,5);
printf("press any key to point-check\n\n");
fgetc_cons(); // wait for keypress
printf("point(3,3) (plotted) is %d\n",point(3,3));
printf("point(10,10) (blank) is %d\n",point(10,10));
fgetc_cons(); // wait for keypress
}
On the ZX80, the plot() function works as well. However, the point() function does not, it makes the program crash. The z88dk wiki says "this function might not work correctly on all the platforms". If I add the -lgfx81 option when compiling the ZX80 version, the point() function works, but the plot() function no longer works correctly, as it obviously uses the wrong characters (from the ZX81 character set). Unfortunately there is no -lgfx80 option yet in z88dk, since there is no gfx80.lib file (only gfx81.lib).
Maybe the plot() and point() functions could easily be made ZX80-compatible for a future z88dk release?
Or should it work already and I am only doing something wrong?
3. While we are at it: I also tested plot() and point() on the Jupiter Ace target.
Code: Select all
/* Plot Test by RobertK, 2018-03-14
Compile for Jupiter Ace:
zcc +ace -vn -create-app plottest.c -o pt.bin
load the program in the Jupiter Ace by typing
0 0 bload pt.bin
*/
#include <stdio.h> // required for printf()
#include <graphics.h> // contains plot() and point() functions
void main()
{
printf("%c",12); // clear the screen
printf("\n\n\n\n\n*** plot test ***\n\n");
plot(1,1);
plot(3,3);
plot(5,5);
// printf("press any key to point-check\n\n");
// fgetc_cons(); // wait for keypress
printf("point(3,3) (plotted) is %d\n",point(3,3));
printf("point(10,10) (blank) is %d\n",point(10,10));
fgetc_cons(); // wait for keypress
}
None, it is the default. The zx81 has a ridiculously large number of graphics libraries so they have to be in different library files.RobertK wrote:A few more questions about the graphics.h functions:
1. What is the purpose of the -lgfx81 parameter when compiling a program? For the ZX81 the result seems to be the same either with or without that parameter. Maybe because this is already the default setting for the ZX81 target?
It looks like there's an extra push bc, I've removed it so hopefully it'll be fixed in the next nightly. The graphics code is built in to the zx80 library so there's no need to link to an extra library.2. I tried to use the plot and point functions for the ZX80 target. I have written a little test program that can be compiled for either the ZX81 or ZX80 (I hope my ZX80 compile parameters are correct):
..snip
On the ZX80, the plot() function works as well. However, the point() function does not, it makes the program crash. The z88dk wiki says "this function might not work correctly on all the platforms".
I think stefano is going to have to answer these questions3. While we are at it: I also tested plot() and point() on the Jupiter Ace target.
The good news is: with the nightly build the point() call does not make the ZX80 program crash anymore, thanks.dom wrote:It looks like there's an extra push bc, I've removed it so hopefully it'll be fixed in the next nightly.
The bad news is: point() always returns 0 on the ZX80...
I have now written a little "neutral" (cross-platform) lo-res plot test program and tried it on various targets, see the compile commands and my notes in the comments at the top of the file.
Code: Select all
/* Plot(), Unplot() and Point() Test by RobertK, 2018-03-19
Compile command for the following targets:
=== ZX81 === (ok)
zcc +zx81 -startup=2 -o plottest_ZX81 -create-app plottest.c
=== ZX80 ===
zcc +zx80 -o plottest_ZX80 -create-app plottest.c
Note: z88dk point() function not working yet for this system
(calling it with 1.99B makes the program crash; with the
latest nightly build it does not crash but always returns 0)
=== Jupiter Ace ===
zcc +ace -vn -create-app plottest.c -o pt.bin
Note: compiles and runs without error, but plotted points
cannot be seen. Point() function returns inverse values.
Load the program on the Jupiter Ace by typing:
0 0 bload pt.bin
=== Galaksija === (ok)
zcc +gal -vn -create-app plottest.c -o plottest_galaksija.bin
Note: on the Galaksija computer type OLD to load a program from cassette.
=== VZ200 / Laser 210 / Laser 110 ===
zcc +vz -lm -o plottest_vz200.vz plottest.c
Note: plot() function outputs characters instead of pixels. Switching to
graphics mode required? "The graphics mode is automatically switched on
by calling ?clg? or printing CHR$ 12 or calling the vz_mode() function."
Point() function works correctly.
=== TRS-80 ===
zcc +trs80 -lndos -lm -create-app -o plottest_trs80.bin -subtype=disk plottest.c
Note: use a TRS-80 Model III, type "system" to exit Basic and run the .cmd file.
Clearing the screen does not work, everything else does.
=== Robotron Z1013 ===
zcc +z1013 -lm -create-app plottest.c -o plottest_robotron
Note: top line (plotted pixel at 1,1) not visible, everything else is ok
*/
#include <stdio.h> // required for printf()
#include <graphics.h> // contains plot() and point() functions
void main()
{
printf("%c",12); // clear the screen
printf("\n\n\n\n\n*** plot test ***\n\n");
printf("press any key to plot and unplot\n\n");
fgetc_cons(); // wait for keypress
plot(1,1);
plot(3,3);
plot(5,5);
unplot(5,5);
plot(7,7);
printf("press any key to point-check\n\n");
fgetc_cons(); // wait for keypress
printf("point(3,3) (plotted) is %d\n",point(3,3)); // should be 1
printf("point(5,5) (unplotted) is %d\n",point(5,5)); // should be 0
printf("point(10,10) (blank) is %d\n",point(10,10)); // should be 0
fgetc_cons(); // wait for keypress
}
So far, apart from the ZX81 the only other machine where I managed to get the program fully working is the Galaksija computer.
Further corrections and suggestions would be welcome.
Sorry for another dumb question, but what is the "zx80 library"? Or do you mean the zx81.h file, as there is no zx80.h file yet?dom wrote:The graphics code is built in to the zx80 library so there's no need to link to an extra library.
I've not forgotten about this, just too many things on the go at the moment.
I fixed the ZX80 problem a few days ago, so that port should be working correctly now.
+ace I'm a bit at a loss, I need to find some docs on the platform to investigate properly.
+vz200 - I need to find an emulator to start investigating
+trs80 - I have an emulator that works, so I should be able to fix clearing the screen without too much effort. I recently fixed the fgetc_cons() issue where it didn't wait for a keypress.
+z1013 - I've got an emulator so reproducing your problem should be easy.
Libraries:
The routines for each platform is contained within a file named [port]_clib.lib, this contains all the standard routines (string.h, stdio.h) and where there is only implementation, versions of graphics.h, fcntl.h that work on the device. If there are multiple implementations available for a machine (for examples ZX81 graphics, Spectrum fcntl) then they are split out into separate libraries - hence the -lgfx81, -lgfx81hr etc
I fixed the ZX80 problem a few days ago, so that port should be working correctly now.
+ace I'm a bit at a loss, I need to find some docs on the platform to investigate properly.
+vz200 - I need to find an emulator to start investigating
+trs80 - I have an emulator that works, so I should be able to fix clearing the screen without too much effort. I recently fixed the fgetc_cons() issue where it didn't wait for a keypress.
+z1013 - I've got an emulator so reproducing your problem should be easy.
Libraries:
The routines for each platform is contained within a file named [port]_clib.lib, this contains all the standard routines (string.h, stdio.h) and where there is only implementation, versions of graphics.h, fcntl.h that work on the device. If there are multiple implementations available for a machine (for examples ZX81 graphics, Spectrum fcntl) then they are split out into separate libraries - hence the -lgfx81, -lgfx81hr etc
The ZX80 and z1013 target versions work correctly now, thank you! I will test the TRS-80 version with the next nightly build. And thanks for your explanation about the target lib.
For many systems I simply use M.A.M.E. for testing (the M.E.S.S. system have been added there some time ago). For ZX81/ZX80/Jupiter Ace I use the EightyOne emulator.
I am currently trying to port a ZX81 game to the ZX80, and I have only one issue left (which could be a difficult one, I will probably post a new topic for that).
BTW, previously I could use the randomize() function for the ZX80 target, but with the new nightly build it is no longer available?
@dom and all the others involved: many thanks for all your effort, z88dk is such a great thing!
For many systems I simply use M.A.M.E. for testing (the M.E.S.S. system have been added there some time ago). For ZX81/ZX80/Jupiter Ace I use the EightyOne emulator.
I am currently trying to port a ZX81 game to the ZX80, and I have only one issue left (which could be a difficult one, I will probably post a new topic for that).
BTW, previously I could use the randomize() function for the ZX80 target, but with the new nightly build it is no longer available?
@dom and all the others involved: many thanks for all your effort, z88dk is such a great thing!
I've just checked rand() is available for both ZX80 and ZX81.
I replaced the old random number generator (which turned out to be not very random) in issue #579 (https://github.com/z88dk/z88dk/issues/579) so randomise() vanished at that point in time. You can seed with the normal srand() now.
I replaced the old random number generator (which turned out to be not very random) in issue #579 (https://github.com/z88dk/z88dk/issues/579) so randomise() vanished at that point in time. You can seed with the normal srand() now.
I have tested lo-res plotting on a few more systems: Philips VG5000, Mattel Aquarius, EG2000 and Sharp MZ-700.
I added another clear screen call at the end to make sure that the plotted points get cleared correctly.
Here is my updated test program, maybe you want to check the issues when you find the time.
I added another clear screen call at the end to make sure that the plotted points get cleared correctly.
Here is my updated test program, maybe you want to check the issues when you find the time.
Code: Select all
/* Plot(), Unplot() and Point() Test by RobertK, 2018-03-26
Compile command for the following targets:
=== ZX81 === (ok)
zcc +zx81 -startup=2 -o plottest_ZX81 -create-app plottest.c
=== ZX80 === (ok)
zcc +zx80 -o plottest_ZX80 -create-app plottest.c
Note: z88dk point() function not working yet for this system
(calling it with 1.99B makes the program crash; since nightly
build 2018-03-22 it works correctly)
=== Jupiter Ace ===
zcc +ace -vn -create-app plottest.c -o pt.bin
Note: compiles and runs without error, but plotted points
cannot be seen. Point() function returns inverse values.
Load the program on the Jupiter Ace by typing:
0 0 bload pt.bin
=== Galaksija === (ok)
zcc +gal -vn -create-app plottest.c -o plottest_galaksija.bin
Note: on the Galaksija computer type OLD to load a program from cassette.
=== VZ200 / Laser 210 / Laser 110 ===
zcc +vz -lm -o plottest_vz200.vz plottest.c
Note: plot() function outputs characters instead of pixels. Switching to
graphics mode required? "The graphics mode is automatically switched on
by calling ?clg? or printing CHR$ 12 or calling the vz_mode() function."
Point() function works correctly.
=== TRS-80 === (almost ok)
zcc +trs80 -lndos -lm -create-app -o plottest_trs80.bin -subtype=disk plottest.c
Note: use a TRS-80 Model III, type "system" to exit Basic and run the .cmd file.
Clearing the screen does not work with 1.99B, since nightly build 2018-03-24
this should work as well. Compiled program runs very unstable on the M.A.M.E.
emulator (version 0.170), many attempts are needed to get it running correctly.
=== Robotron Z1013 === (ok)
zcc +z1013 -lm -create-app plottest.c -o plottest_robotron
Note: top line (plotted pixel at 1,1) not visible with 1.99B,
since nightly build 2018-03-22 it works correctly.
=== Philips VG5000 ===
zcc +vg5k -create-app -lm plottest.c -o plottest_vg5000
Note: Everything works, except for that plot() function
outputs " characters instead of pixels.
Use the DCVG5K emulator (dcvg5k.free.fr) for testing
Attach the .k7 cassette file and type CLOAD to load the program
(note that the VG5000 has a French AZERTY keyboard so on most
other keyboard layouts you have to type CLOQD)
=== Mattel Aquarius ===
zcc +aquarius -lm -create-app plottest.c -o plottest_aquarius
Note: Everything works, except for that plotted pixels are not
all the same size. In the plot test the second pixel looks ok
while the first and third are too flat.
Use the "Virtual Aquarius" emulator for testing. Loading
instructions from the z88dk wiki:
from within the emulator, load the loader: cload
press ENTER twice, then play the ?_plottest_aquarius.caq? cassette file (loader)
at the ?OK? prompt, type RUN <ENTER>
press ENTER twice, then play the ?plottest_aquarius.caq? cassette file
wait? then have fun !
=== EG2000 ===
zcc +trs80 -lndos -lm -create-app -subtype=eg2000disk -o plottest_eg2000.bin plottest.c
Note: plotted points cannot be seen, everything else is ok.
Use the Genieous emulator (gaia.atilia.eu) for testing. See the TRS-80
loading instructions above (use "Autostart file" after entering SYSTEM)
=== Sharp MZ-700 ===
zcc +mz -lm -o adventure -create-app plottest.c -o plottest_sharpmz
Note: clearing the screen does not work, everything else is ok.
In M.A.M.E. attach the .mzt cassette file, then press L and Enter
to initiate loading, then use M.A.M.E.'s tape control to start the tape.
*/
#include <stdio.h> // required for printf()
#include <graphics.h> // contains plot() and point() functions
void main()
{
printf("%c",12); // clear the screen
printf("\n\n\n\n\n*** plot test ***\n\n");
printf("press any key to plot and unplot\n\n");
fgetc_cons(); // wait for keypress
plot(1,1);
plot(3,3);
plot(5,5);
unplot(5,5);
plot(7,7);
printf("press any key to point-check\n\n");
fgetc_cons(); // wait for keypress
printf("point(3,3) (plotted) is %d\n",point(3,3)); // should be 1
printf("point(5,5) (unplotted) is %d\n",point(5,5)); // should be 0
printf("point(10,10) (blank) is %d\n",point(10,10)); // should be 0
printf("\npress any key to clear screen\n");
fgetc_cons(); // wait for keypress
printf("%c",12); // clear the screen
printf("done.\n");
fgetc_cons(); // wait for keypress
}
Thankyou Robert,
the code rearrangements and my fuzzy way to commit changes must have broken something in the years.
The Jupiter ACE graphics lib is definitely broken, I'm fixing it soon. The original idea to support 64x48 graphics was abandoned to use the UDG (user defined characters) to support a 64x72 resolution, it should be activated with the clg() instruction... please don't waste your time trying it, as said it is broken.
My design intentions for the graphics library were to provide a limited set of standard resolutions (256x192, 128x64), so the earlier graphics libraries were cropping the pixels to simulate higher graphics modes. The results were not so nice as expected, especially when the sprites were used, not considering the resulting problems with point() or the never finished bksave() and getsprite().
In any case, when I began working with higher resolutions I left the lo-rez aside for a while, in example I took forever to spot a bug failing to plot on the top pixel row (and possibly messing the memory). Now it is hopefully fixed everywhere, but you might wish to add a similar test in your program (e.g. plotting a pixel on every corner using getmaxx/getmaxy). Another tip for your program is to avoid to use chr(12) to clear the screen, clg() would do it guaranteeing the proper graphics settings.
Coming soon: the J. Ace updated graphics libraries.. given the recent interest in low resolution modes (and the good quantity of now supported targets) I chose to provide both the 64x72 and the 64x48 variants.
the code rearrangements and my fuzzy way to commit changes must have broken something in the years.
The Jupiter ACE graphics lib is definitely broken, I'm fixing it soon. The original idea to support 64x48 graphics was abandoned to use the UDG (user defined characters) to support a 64x72 resolution, it should be activated with the clg() instruction... please don't waste your time trying it, as said it is broken.
My design intentions for the graphics library were to provide a limited set of standard resolutions (256x192, 128x64), so the earlier graphics libraries were cropping the pixels to simulate higher graphics modes. The results were not so nice as expected, especially when the sprites were used, not considering the resulting problems with point() or the never finished bksave() and getsprite().
In any case, when I began working with higher resolutions I left the lo-rez aside for a while, in example I took forever to spot a bug failing to plot on the top pixel row (and possibly messing the memory). Now it is hopefully fixed everywhere, but you might wish to add a similar test in your program (e.g. plotting a pixel on every corner using getmaxx/getmaxy). Another tip for your program is to avoid to use chr(12) to clear the screen, clg() would do it guaranteeing the proper graphics settings.
Coming soon: the J. Ace updated graphics libraries.. given the recent interest in low resolution modes (and the good quantity of now supported targets) I chose to provide both the 64x72 and the 64x48 variants.
I saw a comment about odd pixels on the Mattel Aquarius. Sadly there is very little we can do for it, the character set is so fancy and unbalanced. The bottom right pixel in a 2x3 matrix is totally missing while the bottom-right pixel in a 2x2 matrix is repeated twice, this is something I really can't understand because the font was accurately overloaded of any kind of different symbol and a duplicate like this is very odd (chr 26 = chr 224).
By the way I added a graphics variant: just use '-lgfxaq48' to bend your graphics resolution from 64x72 to 64x48, they are both compatible with the text mode.
By the way I added a graphics variant: just use '-lgfxaq48' to bend your graphics resolution from 64x72 to 64x48, they are both compatible with the text mode.
The VZ200. Its "operating system" (aka BASIC interpeter) is designed to switch back to text mode as soon as a character is being printed.
After this nightly build you should have a new function in all the mid and low-rez graphics drivers permitting to output some text in graphics mode. You just need to add the following parameter in your zcc command line:
-pragma-redirect=fputc_cons=putc4x6
After this nightly build you should have a new function in all the mid and low-rez graphics drivers permitting to output some text in graphics mode. You just need to add the following parameter in your zcc command line:
-pragma-redirect=fputc_cons=putc4x6
Hi Stefano
Regarding the Jupiter Ace: this one works great! Plotting on that machine is very fast compared to the ZX81.
There is only one problem left: clearing the screen does not clear the bottom line, please check if you can maybe fix this easily.
Regarding the Mattel Aquarius: you probably meant 80x48 instead of 64x48, because this is the resolution that -lgfxaq48 activates. Surprisingly, now all pixels look good!
Clearing the screen on the Sharp MZ works now.
And the VZ200 also works correctly now - I like the huge characters of its graphics mode. :-)
Here is the updated test program, it now also draws a screen border at the end.
The following target systems now work correctly:
ZX81 (64?48)
ZX80 (64?48)
Galaksija (64?48)
VZ200 / Laser 210 / Laser 110 (128?64)
TRS-80 (128?48) (the graphics part is probably ok, but the compiled program runs unstable in M.A.M.E.)
Robotron Z1013 (64?64)
Mattel Aquarius (80?48)
Sharp MZ-700 (80?50)
The following systems still have some issues:
Jupiter Ace (64x48)
Philips VG5000 (80?72)
EG2000 (160?100)
I have now added the following systems to the test program but haven't figured out yet how to test them:
ABC80 (78?72)
Nascom (96?48)
Philips P2000 (78?72)
Robotron Z9001 (80x48)
P.S. If you are wondering what I intend to do with all this: I would like to port my ZX81 game H-Tron to a few more systems. My primary target was the ZX80, but with its FAST-only mode this will be a difficult job.
But the Jupiter Ace looks more promising, I already have the demo mode working (and it runs very fast!).
Regarding the Jupiter Ace: this one works great! Plotting on that machine is very fast compared to the ZX81.
There is only one problem left: clearing the screen does not clear the bottom line, please check if you can maybe fix this easily.
Regarding the Mattel Aquarius: you probably meant 80x48 instead of 64x48, because this is the resolution that -lgfxaq48 activates. Surprisingly, now all pixels look good!
Clearing the screen on the Sharp MZ works now.
And the VZ200 also works correctly now - I like the huge characters of its graphics mode. :-)
Here is the updated test program, it now also draws a screen border at the end.
The following target systems now work correctly:
ZX81 (64?48)
ZX80 (64?48)
Galaksija (64?48)
VZ200 / Laser 210 / Laser 110 (128?64)
TRS-80 (128?48) (the graphics part is probably ok, but the compiled program runs unstable in M.A.M.E.)
Robotron Z1013 (64?64)
Mattel Aquarius (80?48)
Sharp MZ-700 (80?50)
The following systems still have some issues:
Jupiter Ace (64x48)
Philips VG5000 (80?72)
EG2000 (160?100)
I have now added the following systems to the test program but haven't figured out yet how to test them:
ABC80 (78?72)
Nascom (96?48)
Philips P2000 (78?72)
Robotron Z9001 (80x48)
P.S. If you are wondering what I intend to do with all this: I would like to port my ZX81 game H-Tron to a few more systems. My primary target was the ZX80, but with its FAST-only mode this will be a difficult job.
But the Jupiter Ace looks more promising, I already have the demo mode working (and it runs very fast!).
Code: Select all
/* Plot(), Unplot() and Point() Test by RobertK, 2018-03-31
Compile command for the following targets:
=== ZX81 (64?48) === (ok)
zcc +zx81 -startup=2 -Cz--disable-autorun -o plottest_ZX81 -create-app plottest.c
=== ZX80 (64?48) === (ok)
zcc +zx80 -o plottest_ZX80 -create-app plottest.c
Note: point() function was not working yet for this system
with 1.99B (calling it made the program crash), since nightly
build 2018-03-22 it works correctly.
=== Jupiter Ace (64x48) ===
zcc +ace -lgfxace -vn -create-app plottest.c -o pt.bin
Note: with 1.99B plotted points could not be seen, and the
point() function returned inverse values -> fixed since nightly
build 2018-03-28 (-lgfxace option added by Stefano for 64x48)
Last remaining issue: clearing the screen does not clear the bottom line.
Load the program on the Jupiter Ace by typing:
0 0 bload pt.bin
=== Galaksija (64?48) === (ok)
zcc +gal -vn -create-app plottest.c -o plottest_galaksija.bin
Note: on the Galaksija computer type OLD to load a program from cassette.
=== VZ200 / Laser 210 / Laser 110 (128?64) === (ok)
zcc +vz -lm -pragma-redirect=fputc_cons=putc4x6 -o plottest_vz200.vz plottest.c
Note from the z88dk wiki: "The graphics mode is automatically switched on
by calling ?clg? or printing CHR$ 12 or calling the vz_mode() function."
We use clg() in this example.
Works correcetly since nightly build 2018-03-31. Stefano:
"The VZ200. Its "operating system" (aka BASIC interpreter) is designed to switch
back to text mode as soon as a character is being printed.
After this nightly build you should have a new function in all the mid and low-rez
graphics drivers permitting to output some text in graphics mode.
You just need to add the following parameter in your zcc command line:"
-pragma-redirect=fputc_cons=putc4x6
=== TRS-80 (128?48) === (almost ok)
zcc +trs80 -lndos -lm -create-app -o plottest_trs80.bin -subtype=disk plottest.c
Note: use a TRS-80 Model III, type "system" to exit Basic and run the .cmd file.
Clearing the screen does not work with 1.99B, since nightly build 2018-03-24
this should work as well. Compiled program runs very unstable on the M.A.M.E.
emulator (version 0.170), many attempts are needed to get it running correctly.
=== Robotron Z1013 (64?64) === (ok)
zcc +z1013 -lm -create-app plottest.c -o plottest_z1013
Note: top line (plotted pixel at 1,1) was not visible with 1.99B,
since nightly build 2018-03-22 it works correctly.
=== Philips VG5000 (80?72) ===
zcc +vg5k -create-app -lm plottest.c -o plottest_vg5000
Note: Everything works, except for that plot() function
outputs " characters instead of pixels.
Use the DCVG5K emulator (dcvg5k.free.fr) for testing
Attach the .k7 cassette file and type CLOAD to load the program
(note that the VG5000 has a French AZERTY keyboard so on most
other keyboard layouts you have to type CLOQD)
=== Mattel Aquarius (80?48) === (ok)
zcc +aquarius -lm -create-app plottest.c -o plottest_aquarius
Note: Everything works, except for that plotted pixels are not
all the same size. In the plot test the second pixel looks ok
while the first and third are too flat.
Stefano: "I saw a comment about odd pixels on the Mattel Aquarius.
Sadly there is very little we can do for it, the character set is
so fancy and unbalanced. The bottom right pixel in a 2x3 matrix is
totally missing while the bottom-right pixel in a 2x2 matrix is
repeated twice, this is something I really can't understand because
the font was accurately overloaded of any kind of different symbol
and a duplicate like this is very odd (chr 26 = chr 224).
By the way I added a graphics variant [in nightly build 2018-03-29]:
just use '-lgfxaq48' to bend your graphics resolution from 64x72
to 64x48 [should be 80x48], they are both compatible with the text mode."
-> looks good now, the plotted pixels are all the same size now
Use the "Virtual Aquarius" emulator for testing. Loading
instructions from the z88dk wiki:
from within the emulator, load the loader: cload
press ENTER twice, then play the ?_plottest_aquarius.caq? cassette file (loader)
at the ?OK? prompt, type RUN <ENTER>
press ENTER twice, then play the ?plottest_aquarius.caq? cassette file
wait? then have fun !
=== EG2000 (160?100) ===
zcc +trs80 -lndos -lm -create-app -subtype=eg2000disk -o plottest_eg2000.bin plottest.c
Note: plotted points cannot be seen, everything else is ok.
Use the Genieous emulator (gaia.atilia.eu) for testing. See the TRS-80
loading instructions above (use "Autostart file" after entering SYSTEM)
=== Sharp MZ-700 (80?50) === (ok)
zcc +mz -lm -o adventure -create-app plottest.c -o plottest_sharpmz
Note: clearing the screen does not work in 1.99B, fixed since
nightly build 2018-03-29
In M.A.M.E. attach The .mzt cassette file, then press L and Enter
to initiate loading, then use M.A.M.E.'s tape control to start the tape.
=== ABC80 (78?72) ===
zcc +abc80 -lm -o plottest_abc80 -create-app plottest.c
Note from z88dk Wiki: "The pseudo graphics mode is supported. You first
need to issue a clg () command to set up the graphics page."
(still to be tested)
.BAC or .BAS file can be quickloaded and listed in M.A.M.E., but cannot be run
=== Nascom (96?48) ===
zcc +nascom -lm -o plottest_nascom -create-app plottest.c
(still to be tested)
=== Philips P2000 (78?72) ===
zcc +p2000 -o plottest_p2000 -create-app -lm plottest.c
(still to be tested)
=== Robotron Z9001 (80x48) ===
zcc +z9001 -lm -o plottest_z9001 -create-app plottest.c
(still to be tested)
*/
#include <stdio.h> // required for printf()
#include <graphics.h> // contains plot() and point() functions
// define the screen dimensions for the current system
#if defined(__ZX81__) || defined(__ZX80__) || defined(__ACE__) || defined(__GAL__) // ZX81, ZX80, Jupiter Ace, Galaksija
#define X_RES 64
#define Y_RES 48
#elif defined(__VG5000__) // Philips VG5000
#define X_RES 80
#define Y_RES 72
#elif defined(__AQUARIUS__) // Mattel Aquarius
#define X_RES 80
#define Y_RES 48
#elif defined(__VZ200__) // VZ200 / Laser 210 / Laser 110
#define X_RES 128
#define Y_RES 64
#elif defined(__TRS80__) // TRS-80
#define X_RES 128
#define Y_RES 48
#elif defined(__Z1013__) // Robotron Z1013
#define X_RES 64
#define Y_RES 64
#elif defined(__SHARPMZ__) // Sharp MZ-700
#define X_RES 80
#define Y_RES 50
#elif defined(__ABC80__) // Luxor ABC 80
#define X_RES 78
#define Y_RES 72
#elif defined(__NASCOM__) // Nascom
#define X_RES 96
#define Y_RES 48
#elif defined(__P2000__) // Philips P2000
#define X_RES 78
#define Y_RES 72
#elif defined(__Z9001__) // Robotron Z9001
#define X_RES 80
#define Y_RES 48
// #elif defined(kkk) // EG2000 // TODO: how to identify this TRS-80 sub-type? here __TRS80__ is defined -> dom will add constant for this system
// #define X_RES 160
// #define Y_RES 100
#else
#define X_RES 0
#define Y_RES 0
#endif
void main()
{
int x,y;
printf("%c",12); // clear the screen
printf("\n\n\n\n\n*** plot test (%d x %d) ***\n\n",X_RES,Y_RES);
printf("press any key to plot and unplot\n\n");
fgetc_cons(); // wait for keypress
#if defined(__VZ200__) || defined(__ABC80__)
clg(); // activate graphics mode
printf("%c",12); // we clear the screen...
printf("\n\n",12); // ...and move a little down because otherwise the huge letters of the VZ200 graphics mode wouldn't fit on the screen
#endif
plot(1,1);
plot(3,3);
plot(5,5);
unplot(5,5);
plot(7,7);
printf("press any key to point-check\n\n");
fgetc_cons(); // wait for keypress
printf("point(3,3) (plotted) is %d\n",point(3,3)); // should be 1
printf("point(5,5) (unplotted) is %d\n",point(5,5)); // should be 0
printf("point(10,10) (blank) is %d\n",point(10,10)); // should be 0
// check if the screen dimensions for this platform have been defined above
if (X_RES>0 && Y_RES>0)
{
printf("\npress any key to draw border\n");
fgetc_cons(); // wait for keypress
for (x = 0; x < X_RES; ++x)
{
plot(x,Y_RES-1);
plot(x,0);
}
for (y = 1; y < Y_RES; ++y)
{
plot(0,y);
plot(X_RES-1,y);
}
}
printf("\npress any key to clear screen\n");
fgetc_cons(); // wait for keypress
printf("%c",12); // clear the screen
printf("done.\n");
fgetc_cons(); // wait for keypress
}
Thanks, identifying that system works now. I check it like this to distinguish between the two systems:
BTW, it seems that compiling for the TRS-80 with the subtype "disk" is broken now. With yesterdays nightly when you compile like this...
zcc +trs80 -lndos -lm -create-app -o plottest_trs80.bin -subtype=disk plottest.c
...at this step...
PROCESSING lgfxtrs80.asm.m4
m4 -I "C:\Misc\z88dk\lib\config\\..\..\\lib\target\trs80\classic" -I "C:\Misc\z88dk\lib\config\\..\..\/src/m4" < "lgfxtrs80.asm.m4" > "C:\Users\ws09.PSC\AppData\Local\Temp\zccD5B53"
...you get a "file not found" error. Without the subtype parameter it works.
Code: Select all
...
#elif defined(__TRS80__) && !defined(__EG2000__) // TRS-80
#define X_RES 128
#define Y_RES 48
#elif defined(__TRS80__) && defined(__EG2000__) // EG2000
#define X_RES 160
#define Y_RES 100
#elif ....
zcc +trs80 -lndos -lm -create-app -o plottest_trs80.bin -subtype=disk plottest.c
...at this step...
PROCESSING lgfxtrs80.asm.m4
m4 -I "C:\Misc\z88dk\lib\config\\..\..\\lib\target\trs80\classic" -I "C:\Misc\z88dk\lib\config\\..\..\/src/m4" < "lgfxtrs80.asm.m4" > "C:\Users\ws09.PSC\AppData\Local\Temp\zccD5B53"
...you get a "file not found" error. Without the subtype parameter it works.