FullHD81 - an improved video driver

[dr beep]

At the cost of a display routine of app. 300 bytes you could make a screensize 336x200 in same memorysize of screen.

[dr beep]

Might fit in a app. 160 bytes routine, 1 line more in display to add.

Timing can become an issue since in uppermemory you can't run an opcode of 6 tstates.

Edit: solution must be found in the working of R-register, but I think it can be done (336x200).

[dr beep]

Either R register is falso or timing is false.

Routine in 160 bytes is not possible. In app. 200 it must be.

[dr beep]

The 328 pixels routine has flaws

Cp (hl)

Must be

Cp 6 ; any number

And the add doesn't work either so how was that done previously?
Edit : add is in lower memory.
Will have to do with other registers.
Ixh, ixl iyh or iyl

[dr beep]

Routine for 328 still not working, but problem found.
Working on alternate routine......

328 must be possible with stack on screenarea at 50 bytes more.

[zsolt]

Hi,

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

I need a better photographer

FullHD81demo.png (607.29 KiB) Viewed 3433 times

Zsolt

[dr beep]

Hi,

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

FullHD81demo.png

Zsolt

So no need to make effort in more width then!

[PokeMon]

I just tried to let it run on the ZXmore but it doesn't work.
Just after loading it hangs while the testbild.p from Bodo works good.

testbild.jpg (103.91 KiB) Viewed 3412 times

So in my eyes it has to do with startup and the saving bytes used (stack). I don't understand this approach as this is a program which can never be stopped after started and needs about 10k memory for displaying the fullhd image. So where is the advantage for people (other than just to show that you could save bytes) while the program can be run on 16k systems only ?

As you did spend some time on your tools for generating those graphical p files it would maybe more helpful to other people to have a plain basic program which could be started and stopped manually as well (return to BASIC). The testbild.p is a BASIC program which can be stopped with SPACE and can be adjusted in position with SHIFT 5/6/7/8.

So just an idea to get more use of your program.

testbild.p

(11.45 KiB) Downloaded 222 times

[zsolt]

Hi,

I just tried to let it run on the ZXmore but it doesn't work.
Just after loading it hangs while the testbild.p from Bodo works good.

Let me know please, what loader method did you use? The FullHD81demo uses the system variables area as code space (see the source in the attachment of the first post). As far as I remember, your fastloader (for example) did not like these new executables.

I know Bodo's excellent work. If you read the first post, it will turn out. And there are (in the post) the answers to your "questions" too. To show the differences, i made a little comparison using your IDE's wav converter capability, and two pictures.

this is the other

Zeddybild.png (6.01 KiB) Viewed 3391 times

The result:

take a look at the loading times

WAVs.PNG (45.92 KiB) Viewed 3391 times

Regards,
Zsolt

[PokeMon]

I don't use audio to load.
The ZXmore is new high class Zeddy which reads data from USB and is transferred into memory directly without using the ROM load routine ever.
This works with nearly all programs but I think you internal movement of data into system variables section is the problem here.
This is just pure binary copy into the memory from $4009 upwards. The 10k data is loaded in 1/10th second - not comparable with any WAV loader.

What I didn't get is the advantage of a few hundred bytes spare data which can not be used by nothing, not supporting the BASIC structure or return to BASIC and can not be started without 16k RAM. So where is the goal of this programming or is it just an academic approach ?

Cheers, Karl