Expanding the range of QL Adventures

[omega]

Hi _o_,
your ideas are REMarkable! Do you need some specific type of screen for your conversions?

Thanks for compliments. I need to give credits to Francois Lanciault who came with QL implementation of "hi color" in 1990. I reinvented it again many years later. Just to the point of being remarkable I am not.

In case that we want to use graphics for existing adventure games, we need someone to rip-off graphics from amiga/pc. Then we neee to convert it to ql palette or dithvide with correct aspect ratio. Since dithvide consumes double size of standard screen, compression should be applied as well.

You may post whatever picture you like. From actual game, photo or wallpaper. Anything goes. I will post all modes to give you flavor of conversion.

[tcat]

Hi,

Encouraged by _o_, I have made some changes to `dithVide' dual screen driver.

It now basically accepts a screen mode parameter, also scans keyboard for a keypress while it counts down TV refresh frames (default 900). It is also slightly more memory efficient.

With the kind permission of _o_ I share the binary here, so we can all toy with various screen pictures. Updated sources will be pushed to QL Git.

dithvide2.zip

`dithVide' dual screen driver

(38.76 KiB) Downloaded 189 times

Command synopsis, from call in SuperBASIC:

Code: Select all

r 0 - sets low resolution mode
r 4 - sets high resolution mode
r 8 - sets mixed resolution mode

NOTE
You may need to supply graphics of your own OR from _o_ pages to experiment.
http://omega.webnode.com/products/sincl ... ithvide-2/

Name files as "1_dvd", and "2_dvd".
EDIT
In case of mixed mode, mode-4 picture is "1_dvd", mode-8 is "2_dvd" (hope I got the idea right)

Tested here on real `JS-ROM' machine.

Tomas

[Outsoft]

A very IMPRESSIVE JOB Tomas, compliments!!!

[tcat]

Hi,

Just pushed `dithVide' source to GIT.
One correction added, keyrow 0 (F1..F5) is now also scanned.
https://github.com/SinclairQL/dithVide

Tomas

[RWAP]

Hi,

Just pushed `dithVide' source to GIT.
One correction added, keyrow 0 (F1..F5) is now also scanned.
https://github.com/SinclairQL/dithVide

Tomas

Excellent - I have added my comments as an issue, but it should improve the speed of the screen swapping (based on my experiments when developing the scroll and pan routines for D-Day MKII and War In the East MKII)

[tofro]

Rich,

Although I normally disapprove of any assumptions on fixed addresses in QDOS, I think it is acceptable to assume the screen is at $20000 and $28000 in code that needs to assume it can switch the screen with a hardware register at another fixed address that is only valid on the original QL anyhow.

Agree on the other comment that your unrolled MOVEM loop is the fastest way to copy bytes around.

Tobias

[tcat]

Hi Rich,Tobias,

Thank you for your feedback, studying it now.
But I already feel you are right.
This would be basis for next release.

Tomas

[omega]

tcat,

You did very good job in restructuring the code and adding new features. Excellent work.

Rich,

I would prefer to keep the code lean and simple. Dithvide works on physical "Black QL" only. It is tightly connected with original QL HW, therefore keeping physical addressing of videorams and mc.stat is IMHO correct. Perhaps it would make sense to detect machine type and return to basic in case that machine won't support old graphic modes, mc.stat or CPU speed would be out of range.

Regarding unrolled mem copy code - it does make perfect sense for time critical operations. E.g. moving from graphics buffer to videoram to keep animation smooth. In our case, we are using this memory swap routine just at the beginning and in the end of operation (user will wait fraction of a second). I personally like the way as tcat made his initial suggestion, it is clean and lean.

omega

[RWAP]

OK fair enough - but does the Aurora support this hardware switching? As that supports higher resolutions in the original colour modes - it might need to be taken into account

[tofro]

OK fair enough - but does the Aurora support this hardware switching? As that supports higher resolutions in the original colour modes - it might need to be taken into account

All,
Aurora apparently supports dual screen modes both in MODE 4 and MODE 8 (not in any of its higher res or high-colour modes).

In MODE 4 and MODE 8 it fully emulates the QL screen circuitry, screen switching between SCR0 (at $20000) and SCR1 (at $28000) is done exactly in the same way as it works on the QL (by using the hardware register at $18063), and the screen memory is in exactly the same places. There doesn't seem to be any specifics that would need to be accounted for on Aurora other than making sure the screen MODE is correct. The way I understand the documentation, anything that runs on a standard QL should run unchanged on the Aurora.

There is some small difference in that the screen memory is mirrored into the high address range starting from $4C000 (or, rather, the other way round). So you can actually detect an Aurora board by writing to $20000 and checking whether the same value appears at $4C000. In this area, even in MODE 4 and 8, the screen memory layout is entirely different from a "normal" QL. SD.LINEL in the window definition block is constant 256, so for the dual-screen application it is not feasible to use this variable.

But because Aurora can use 256 colours anyhow in MODE256, there is probably not much need anyhow for the screen switching approach.

Tobias