#2270 1520 printer emulation, assertions, wrong output

[pottendo]

hi, the Biorythm demo from the 1520 demo disk: https://d64hunter.remotecpu.com/disk/625110/download
triggeres several assertions:

[..]
plot1520: Error - ../../../latest/vice/src/printerdrv/drv-1520.c 433: assertion from_y > 0 failed: -31
plot1520: Error - ../../../latest/vice/src/printerdrv/drv-1520.c 434: assertion to_y > 0 failed: -31
[..]
plot1520: Error - ../../../latest/vice/src/printerdrv/drv-1520.c 431: assertion to_x <= MAX_COL failed: 481
plot1520: Error - ../../../latest/vice/src/printerdrv/drv-1520.c 433: assertion from_y > 0 failed: -144
plot1520: Error - ../../../latest/vice/src/printerdrv/drv-1520.c 434: assertion to_y > 0 failed: -148
plot1520: Error - ../../../latest/vice/src/printerdrv/drv-1520.c 430: assertion from_x <= MAX_COL failed: 481
plot1520: Error - ../../../latest/vice/src/printerdrv/drv-1520.c 431: assertion to_x <= MAX_COL failed: 481
[...]

the output bmp shows some obvious flaws - see (print.dump000.png - converted from BMP)
An attempt fixed with AI vibe-fixing results in AIFixed.png
(validation of the fix has not yet been done)

bye, pottendo

[pottendo]

AI (GPT-6 Luna) assisted fix for: PR #2270
Pending character-size settings are applied on sec-address changes; map plotter
Y coordinates into bitmap rows, and preserve the full vertical drawing extent.
Remove invalid positive-Y assertions for valid plotter coordinates.

See attached patch.
Looks reasonable - the output now is consistent with the pic already posted here; The diskimage contains several 1520 test programs, incl. the Biorhythm program, which triggers the issue. Other tests from this disk seem to produce correct results. To be verified by an owner of a (working) mps 1520 plotter.
bye, pottendo

[Olaf Seibert]

The "AI solution" applied the change "Pending character-size settings are applied on sec-address changes" only to that secondary address, and the principle applies to the other ones too. The biorhytm program did a stupid thing: print#3,0; note the semicolon. The parser in the driver assumed that you'd always get a CR at the end, but here it is left out.

The coordinate problems are because the program goes way too far up the page, much more than I had left available as "rolling back the paper". For now I increased that and that fixes the issue.

I do want to be smarter in the vertical direction though. If I let more paper hang out of the plotter, then I want to skip the unused part and not put it in the bitmap output. Same at the bottom. This can clearly be improved.

[Olaf Seibert]

I see now that the graphics output driver that converts the pixels from the 1520 to a bmp file, wants to have the "paper size" up front. No wonder that my attempts to omit the long strips of empty paper didn't work!
I may have to fix this, somehow...