LPRINT on ZX81?
Hello Siggi,
in my intention zx_hardcopy() is bound to the graphics library currently in use and varies depending on the graphics mode.
The graphics buffer being printed is the one defined by, e.g. the wrx driver. Since the buffer is memory demanding I tested it with the #pragma directive:
#pragma output hrgpage = 36096
ZX_LPRINTC is much simpler, it just calls RST 16 after enabling the printer flag, (then resets the printer flag in case the ROM will be used elsewhere).
I tested it all on eightyone and all looked in working order, but we all know that there are relevant differences when you try the code on the real hardware
in my intention zx_hardcopy() is bound to the graphics library currently in use and varies depending on the graphics mode.
The graphics buffer being printed is the one defined by, e.g. the wrx driver. Since the buffer is memory demanding I tested it with the #pragma directive:
#pragma output hrgpage = 36096
ZX_LPRINTC is much simpler, it just calls RST 16 after enabling the printer flag, (then resets the printer flag in case the ROM will be used elsewhere).
I tested it all on eightyone and all looked in working order, but we all know that there are relevant differences when you try the code on the real hardware
Hi Stefano
I noticed that DSTAR heavily plays aroound with the I register ans uses its own font. When I pressed 0 I got the standard char set and got block graphics on screen. Then pressing z gave the same character pattern on printer :-)
I then added a line (before the I regiser is modified) to print a startup message
but nothing is LPRINTed at startup. But when I press z for hardcopy I get a (probably buffered) text string printed above the hardcopied screen. Thus the end character to trigger printout of the buffered data seems to be wrong? I am using 0x0A and 0x0D:
Siggi
I noticed that DSTAR heavily plays aroound with the I register ans uses its own font. When I pressed 0 I got the standard char set and got block graphics on screen. Then pressing z gave the same character pattern on printer :-)
I then added a line (before the I regiser is modified) to print a startup message
Code: Select all
#ifdef __ZX80__
gen_tv_field_init(0);
#endif
zx_lprints("Startup main program");
Code: Select all
void zx_lprints(char *s)
{
int i;
for (i=0; i < strlen(s); i++)
zx_lprintc(i);
zx_lprintc(10);
zx_lprintc(13);
}
I compiled using this
zcc +zx81 -clib=wrx -subtype=wrx -create-app -startup=4 -O2 -o dstarwrx dstar.c
zcc +zx81 -create-app -startup=4 -O2 -o dstar dstar.c
and
// added by SE 21-07-2018
#include <zx81.h>
#include <string.h>
#pragma output hrgpage = 8192
DSTAR.P shows the correct screen, hardcopy prints wrong block graphics
DSTARWRX.P shows a weird pixel screen, which is not affected by any key press. But z (hardcopy) copies the same weird pixel pattern to printer
Thus hardcopy seems to work in a WRX environment. But not DSTAR.
Siggi
zcc +zx81 -clib=wrx -subtype=wrx -create-app -startup=4 -O2 -o dstarwrx dstar.c
zcc +zx81 -create-app -startup=4 -O2 -o dstar dstar.c
and
// added by SE 21-07-2018
#include <zx81.h>
#include <string.h>
#pragma output hrgpage = 8192
DSTAR.P shows the correct screen, hardcopy prints wrong block graphics
DSTARWRX.P shows a weird pixel screen, which is not affected by any key press. But z (hardcopy) copies the same weird pixel pattern to printer
Thus hardcopy seems to work in a WRX environment. But not DSTAR.
Siggi
If I understood the source code of zx_lprintc correct, the handling of 0x0D or 0x0A is wrong: in that case A is loaded with $76n (end of line in ZEDDY CHARSET). Then this char is put into the conversion routine asctozx81, which does lead to another character, which does not trigger printing the buffered data!
IMHO that conversion may not be done in this case.
Siggi
IMHO that conversion may not be done in this case.
Siggi
Code: Select all
.doput
IF STANDARDESCAPECHARS
cp 10 ; CR?
jr nz,NoLF
ELSE
cp 13 ; CR?
jr nz,NoLF
ENDIF
ld a,$76
.NoLF
IF FORzx80
;; LPRINT-CH
ELSE
;ld ix,16384
call restore81
set 1,(ix+1) ; Set "printer in use" flag
ENDIF
.charpos
ld hl,0
call asctozx81
;bit 6,a ; filter out the dangerous codes
;ret nz
call 16
I try to elaborate what I meant, I worked on three different driver types, a simple jump into the ROM, character based variants and graphics based variants.
dstar on the zx81 can be run in all the possible graphics mode, moreover the version provided in the zx81 folder works in text mode, either using the normal font or by redefining the characters (or , iirc also by using graphics symbols available with the quicksilva expansion). the rom driver points always to the original rom font location, but I provided a variant for the mid resolution graphics (gfx81udg) which uses the ? register to find the font position. I that way it still works in text mode but the graphics symbols should be printed. the graphics mode is yet another option (well many options, they depend on the hrg mod in use...)
mixing text and graphics is still possible up to a certain level, but you must know what you are doing, e.g. copytxt() could move your text to gfx, the the zx_hardcopy in wrx mode could fit
dstar on the zx81 can be run in all the possible graphics mode, moreover the version provided in the zx81 folder works in text mode, either using the normal font or by redefining the characters (or , iirc also by using graphics symbols available with the quicksilva expansion). the rom driver points always to the original rom font location, but I provided a variant for the mid resolution graphics (gfx81udg) which uses the ? register to find the font position. I that way it still works in text mode but the graphics symbols should be printed. the graphics mode is yet another option (well many options, they depend on the hrg mod in use...)
mixing text and graphics is still possible up to a certain level, but you must know what you are doing, e.g. copytxt() could move your text to gfx, the the zx_hardcopy in wrx mode could fit
Where can I get this generic version?stefano wrote:got it, either include gfx81udg, or use the generic dstar version
When I search on github for DSTAR, I find page
https://github.com/z88dk/z88dk/wiki/dstar
When I click at "Click here to view the source code of dstar.c or its header file" I get "404: Not Found"
When I search in the old WIKI for DSTAR, I find page
https://www.z88dk.org/wiki/doku.php?id= ... ects:dstar
When I click at "Click here to view the source code of dstar.c ..." I get
which does not really help ....The z88dk project's CVS data is in read-only mode, so the project may have switched over to another source-code-management system. To check, visit the Project Summary Page for z88dk and see if the menubar lists a newer code repository, such as SVN or Git.
The CVS data can be accessed as follows. You can run a per-module CVS checkout via pserver protocol:
cvs -z3 -d:pserver:anonymous@a.cvs.sourceforge.net:/cvsroot/z88dk co -P z88dk
cvs -z3 -d:pserver:anonymous@a.cvs.sourceforge.net:/cvsroot/z88dk co -P z88dk-bin
You can view a list of files or copy all the CVS repository data via rsync (the 1st command lists the files, the 2nd copies):
rsync -a a.cvs.sourceforge.net::cvsroot/z88dk/
rsync -ai a.cvs.sourceforge.net::cvsroot/z88dk/ /my/local/dest/dir/
If you are a project admin for z88dk, you can request that this page redirect to another repo on your project by submitting a support request.
Siggi
well, the way I used to print wrx graphics can is very close to the Spectrum one. its core loop output 8 rows in graphics mode, and it shouldn't be difficult to feed a buffer with a different font .
that inner loop will surely become a function available to all the Sinclair clones. I'd like to create also a tiny variant for a single graphics row, which could be handy for direct driving the zx printer graphics from within a C program, but I don't know if the timing will be correct.
that inner loop will surely become a function available to all the Sinclair clones. I'd like to create also a tiny variant for a single graphics row, which could be handy for direct driving the zx printer graphics from within a C program, but I don't know if the timing will be correct.
Such a function would also be nice to do a hardcopy of a single line (or several lines as a "window") of a HIRES screen. Then its paramters should be the address of the graphics and its length, because such a graphic line within the HIRES screen is NOT a null-terminated C string.stefano wrote:I'd like to create also a tiny variant for a single graphics row, which could be handy for direct driving the zx printer graphics from within a C program, but I don't know if the timing will be correct.