LPRINT on ZX81?
Hi Stefano
I played around with zx_hardcopy() in standard text mode. It seems, that it calls directly the rom rountine (which saves space). Correct?
The current behavoir is:
- 22 text lines are lprinted (like in BASIC), but the C program can use AFAIK all 24 screen lines. Thus the 2 last lines are missing.
- BREAK within the hardcopy-routine cancels printing AND terminates the C program (returns to BASIC)!
Siggi
I played around with zx_hardcopy() in standard text mode. It seems, that it calls directly the rom rountine (which saves space). Correct?
The current behavoir is:
- 22 text lines are lprinted (like in BASIC), but the C program can use AFAIK all 24 screen lines. Thus the 2 last lines are missing.
- BREAK within the hardcopy-routine cancels printing AND terminates the C program (returns to BASIC)!
Siggi
before adding further options: could you try by including -lgfx81udg? it should do what you are asking for being also able to print alternate character sets (it should also work with the kempston and quicksilva interfaces). I'm fixin the row limit on gfx81udg right now, thank you for pointing it out: my own comments in the zx81 rom disassembly fooled me ($16 is 22, not 24!)
On adding colums to the ZX PRINTER output, we have few different choices.
We can be flexible on fonts avoiding the ZX81 character set conversion and keeping a parameter to choose the font and its size, otherwise we can squeeze a 4 bit font in ZX81 format (uppercase only etc..) which would save memory. We can also think at a proportional font.
..what would you prefer ?
We can be flexible on fonts avoiding the ZX81 character set conversion and keeping a parameter to choose the font and its size, otherwise we can squeeze a 4 bit font in ZX81 format (uppercase only etc..) which would save memory. We can also think at a proportional font.
..what would you prefer ?
Hi Stefano
I think, the printer should be able to print what is visible on screen. Thus IMHO a proportional font is (currently ;-) not necessary.
I should be possible to print 64 chars/line, like ANSI mode does on screen(same font).
Do you know ZEDIT? The first ZX81 ASCII/Unicode text editor (supports also Zeddy-font and German special characters).
I would be happy, if I could print such a text document WYSIWYG ...
http://forum.tlienhard.com/phpBB3/viewt ... f=2&t=2270
Latest version there:
http://forum.tlienhard.com/phpBB3/viewt ... =25#p32459
Siggi
I think, the printer should be able to print what is visible on screen. Thus IMHO a proportional font is (currently ;-) not necessary.
I should be possible to print 64 chars/line, like ANSI mode does on screen(same font).
Do you know ZEDIT? The first ZX81 ASCII/Unicode text editor (supports also Zeddy-font and German special characters).
I would be happy, if I could print such a text document WYSIWYG ...
http://forum.tlienhard.com/phpBB3/viewt ... f=2&t=2270
Latest version there:
http://forum.tlienhard.com/phpBB3/viewt ... =25#p32459
Siggi
impressive. An interesting quick way could be to write a non optimized program in c printing the text picking it at 8000h using the same Unicode font provided by zedit, but I have the impression that the horizontal resolution is more than 256 pixels.. it seems to me it is using a 6 bit font on 47 colums or so.. need to check better, though.
I'm quite sure it has about 48 columns and a 6 bit font, thus 288 horizontal pixels the zx printer can't, in my knowledge surpass the 255 bytes limit. .. but we could try to write some test program and see what happens adding few extra pixels !
more probably all we can do is to use a smaller font or handle the wordwrap with less columns
more probably all we can do is to use a smaller font or handle the wordwrap with less columns
Hi Stefano
maybe some printers would allow to print more pixels: the SEIKOSHA GP50S hardware is AFAIK designed for 40 chars/line,but I don't know, whether its software will support that. And my Alphacom has equal white borders left and right of the text, so it seems not to support more than the Sinclair printer. So I think, more pixels should not be used.
Pokemon wrote about the resolution on screen:
maybe some printers would allow to print more pixels: the SEIKOSHA GP50S hardware is AFAIK designed for 40 chars/line,but I don't know, whether its software will support that. And my Alphacom has equal white borders left and right of the text, so it seems not to support more than the Sinclair printer. So I think, more pixels should not be used.
Pokemon wrote about the resolution on screen:
Siggi48 Zeichen / 20 Zeilen im normalen Modus
72 Zeichen / 30 Zeilen im Zoom Modus
Considering all the limits I chose to try with a 5 pixel wide font, it will provide 51 columns.
By slightly optimizing the font data is 441 bytes for the standard zx81 characters only (no lowercase etc), plus a 256 bytes buffer for the graphics printing (I can make it temporary by moving it on the stack) and the actual code.
It is possible to choose another font (can you ask about the expected encoding? is it true 16 bit unicode or compressed to a single byte ?) so a printing tool for the 48 columns mode will still be feasible.
By slightly optimizing the font data is 441 bytes for the standard zx81 characters only (no lowercase etc), plus a 256 bytes buffer for the graphics printing (I can make it temporary by moving it on the stack) and the actual code.
It is possible to choose another font (can you ask about the expected encoding? is it true 16 bit unicode or compressed to a single byte ?) so a printing tool for the 48 columns mode will still be feasible.
Hi Stefano
Olli sent a reply to my question. Here is what he wrote:
Siggi
Olli sent a reply to my question. Here is what he wrote:
Hope that helps. If there are more questions: ...The text is UTF-8 unicode, so all ASCII chars are still normal bytes, and all unicode chars >127 are multi-byte, as prescribed by the UTF-8 standard. Zeditor allows the number of characters per line to be set by the user, it is just that the display limits are 36/72 chars depending on the zoom mode. So the user cold adapt to whatever the printer provides. The ZX graphics characters are translated to the corresponding unicode characters, at least for those that have a corresponding unicode symbol. Ctrl-Z or Nul marks the end of the text.
Siggi
Hi Stefano
here some infos, about Unicode chars, that ZEDIT supports:
- the ZX81 block graphics: https://unicode-table.com/en/blocks/block-elements/
- German special characters (??, ??, ??, ? (lower and uppercase)): https://unicode-table.com/en/blocks/latin-1-supplement/
Here some pictures:
http://forum.tlienhard.com/phpBB3/downl ... hp?id=5696
http://forum.tlienhard.com/phpBB3/downl ... hp?id=6794
Siggi
here some infos, about Unicode chars, that ZEDIT supports:
- the ZX81 block graphics: https://unicode-table.com/en/blocks/block-elements/
- German special characters (??, ??, ??, ? (lower and uppercase)): https://unicode-table.com/en/blocks/latin-1-supplement/
Here some pictures:
http://forum.tlienhard.com/phpBB3/downl ... hp?id=5696
http://forum.tlienhard.com/phpBB3/downl ... hp?id=6794
Siggi
Ok, I have a prototype ready, zx _lprintc5 .. it should be available after the next nightly.
At the moment the buffer is statically linked in and there is still a problem with the horizontal chr shifting but it gives a rough idea.
The font is slightly compacted (I could have done it better) and should act the same of zx_lprintc.
let me know your opinion
At the moment the buffer is statically linked in and there is still a problem with the horizontal chr shifting but it gives a rough idea.
The font is slightly compacted (I could have done it better) and should act the same of zx_lprintc.
let me know your opinion
https://user-images.githubusercontent.c ... 56d924.png
.. a printing sample
.. a printing sample
on the 64 columns mode, you can test the output quality already, by calling zx_hardcopy in wrx mode.. I'm not expecting differences.
lprintc5 is not as flexible as the ansi driver, I used the sprite skeleton which sounded easier and better to optimize the code and font size. There's also a gain in speed, even if it was just nice to have.
the buffer could be hardcoded at a fixed position in high memory but can't be volatile.
An easy to get extra (at almost no cost) is a blank row between the text lines. . can I add it?
lprintc5 is not as flexible as the ansi driver, I used the sprite skeleton which sounded easier and better to optimize the code and font size. There's also a gain in speed, even if it was just nice to have.
the buffer could be hardcoded at a fixed position in high memory but can't be volatile.
An easy to get extra (at almost no cost) is a blank row between the text lines. . can I add it?