FullHD81 - an improved video driver

[zsolt]

This works with nearly all programs but I think you internal movement of data into system variables section is the problem here.

Sorry, but it is hard to believe. I think, your device driver writes back some infos into the sv-area (as in case of Siggi's MeFisDOS variant: SEED & COORDS), or it just starts displaying - regardless of the CDFLAG - before it passes the control to the demo program.
My "low class Zeddy" does not do that.

So where is the goal of this programming or is it just an academic approach ?

If you are thinking a little bit (maybe) it turns out, that if we use less system resources (ie. memory) for displaying, then we have more places for programming (for example a game program with lots of sprites and music samples).

The "FullHD81demo.p" is not more than a demoprogram...

...which is optimised for tape loading...

I was hoping that the loading time values - on the picture above - speak for themselves.

What is the goal of this and the other forums? To share the ideas, solutions, experiences and the opinions (with less arrogance).

HTH,
Zsolt

[PokeMon]

So where is the goal of this programming or is it just an academic approach ?

If you are thinking a little bit (maybe) it turns out, that if we use less system resources (ie. memory) for displaying, then we have more places for programming (for example a game program with lots of sprites and music samples).

Hi Zsolt,

if you think further - it might be a nice goal to use less memory for an application but when there could be nothing else run than this nice demo program I ask myself for what the reduction of a few hundred bytes was useful as I can not stop your program. So how can I use the few hundred extra bytes when starting your application ? I might be wrong but in my eyes your demo seems a bit overengineered.

Maybe with a few modifications more people may benefit from your nice graphics. But up to you.

Regards,
Karl

[PokeMon]

This works with nearly all programs but I think you internal movement of data into system variables section is the problem here.

Sorry, but it is hard to believe. I think, your device driver writes back some infos into the sv-area (as in case of Siggi's MeFisDOS variant: SEED & COORDS), or it just starts displaying - regardless of the CDFLAG - before it passes the control to the demo program.
My "low class Zeddy" does not do that.

Not sure what exactly it is - but I give just control to your application after loading.
But I use BASIC to get back to the application as it is loaded as BASIC program.
This stage is maybe a bit different from the ROM routines but do work very well with other HRG programs like Bodo Wenzels testbild.p or the HRG-ms solution from Mathias Swatosch:
http://www.swatosch.de/zx81/

There maybe an issue with FAST/SLOW mode. I do not change the display mode myself as this is more an application part. Maybe the BASIC systems is in FAST mode after loading and you expect this for your program as starting condition. As I just go back to the BASIC system and do not enter FAST mode for the ZX81 session there can be problems as the loading routine from ROM is bypassed and only some important system variables are set (STKBOT, STKEND, ERR_NO=$4000, FLAGS=$4001). I could maybe try to start your application with NMI switched off or resp. in FAST mode.

[siggi]

Hi,
I think the extra pixels are invisible on a traditional CRT TV:

Hi Zsolt
even on LCD displays some pixels are not visible, depending on the screen format:

P1100024_800x600.JPG (70.94 KiB) Viewed 2579 times

P1100025_800x600.JPG (114.62 KiB) Viewed 2579 times

P1100026_800x600.JPG (118.55 KiB) Viewed 2579 times

The last screen format is not really 4:3, but "letter" format (after having done a small hardware patch to the display chip ).

Siggi

BTW: I could load the demo using my USB driver, despite it patches some bytes in the system variable area (Mefisdos does not patch the system variables, but uses the printer buffer as storage for its variables during runtime).

[siggi]

Maybe the BASIC systems is in FAST mode after loading and you expect this for your program as starting condition.

The "normal" Zeddy loads the program in FAST mode and when going back to the loaded program remains in FAST mode or switches to SLOW mode, depending on the state of the new loaded CD-FLAG (= how the program expects).

HTH Siggi

[PokeMon]

Yes - that's maybe the problem. I avoided calling the $0207 routine (SLOW/FAST) as there have been problems to get the system in a suitable state then. The LOAD routine does quite a lot and I was too tired to explore this deeply and found another way back to the BASIC system. Maybe this SLOW/FAST step is skipped and doing so will solve the problem.

[zsolt]

I could load the demo using my USB driver, despite it patches some bytes in the system variable area (Mefisdos does not patch the system variables, but uses the printer buffer as storage for its variables during runtime).

I know - it is not by chance that you was able to read in - but it could be more elegant if the ERROR_C and the SIZE would be readable as a function (without using the system variables):

LET ERROR=USR FGETERROR
IF ERROR<>0 THEN GOTO
LET SIZE=USR FGETSIZE

Nice pictures
Thanks,
Zsolt