The Sinclair QL Forum

thorsinclair wrote: Fri Jan 10, 2025 2:11 pm

The Mode 4 mixing isn't really useful, in my opinion, as you can "colour mix" two MODE 4 screens as much as you like, you still won't get any blue and yellow. I think it only makes sense to mix two MODE 8 pictures.

Wasn't he mixing a Mode 4 and a Mode 8 picture?

There are 3 modes: mixing mode 4 w/mode 4 (hires), mixing mode 8 w/mode 8 (lores), and mixing mode 4 w/mode 8 (mixed). The above "mode 4 mixing isn't really useful" refers to mixing of mode 4 w/mode 4 since, as tofro pointed out, you only have red and green to mix so you wouldn't get blue.

dex wrote: Fri Jan 10, 2025 1:39 pm Source included:
http://speccy.trilogic.cz/zaloha_zilog/ ... dithvide.c
http://speccy.trilogic.cz/zaloha_zilog/ ... E/dithvide

First one works, second one just sits and waits...looks to be identical to first but missing a suffix.

dex wrote: Fri Jan 10, 2025 1:39 pm (The author usualy provides no documantation for his projects, because “it is so simple, must be obvious for everyone”. )

So think we all until someone else needs to make heads or tails of it :-/

dex wrote: Fri Jan 10, 2025 1:39 pm As Omega is ZX Spectrum user, he did just some very dirty coding for QL (at basic speed, PAL, with Sandy SuperQboard, as described on his web), improvement and more clean coding is needed for sure.

The thing that tripped me up is he left his source code in mix mode 8 w/mode 8 but included all examples that were mix mode 4 w/mode 8 and so I spent a couple of days chasing my tail

dex wrote: Fri Jan 10, 2025 1:39 pm I expect that the Magnetic Scroll Interpreter display routine is the much cleaner one.

I'm sure but I don't have access to it.

bwinkel67 wrote: Fri Jan 10, 2025 3:31 pm

dex wrote: Fri Jan 10, 2025 1:39 pm I expect that the Magnetic Scroll Interpreter display routine is the much cleaner one.

I'm sure but I don't have access to it.

You do, the source code is on Github.It is, however, embedded in the adventure interpreter, you'd need to extract ipcom_asm and mode8i_asm. It's also not using the 50Hz interrupt, but rather polls the interrupt register, so, works a bit differently (It does, however, include code for interrupt support, but that is largely untested as I realized the interrupt version cannot easily be made compatible with a keypress check and all hardware and ROMs). As a result, that code is maybe not much cleaner than anyone else's, because it has to touch the hardware registers and keyboard processor comms directly.

bwinkel67 wrote: Fri Jan 10, 2025 3:31 pmsecond one just sits and waits...looks to be identical to first but missing a suffix.

Should contain a binary for Linux.
Pity iOS does not allow me to add it as attachement.

Ok, I've created a new set of MDV files. The DITHVIDE.MDV is the assembler, monitor, source, with the DOOM images loaded. The DOOM.MDV, and DLAIR.MDV each have a shortened boot file that allows you to try all three modes: lores (mode 8), hires (mode 4), and mixed on the associated image files (I created three bin files assembled accordingly). I can only fit two 32K images on an MDV so that's why I have two MDVs. The boot file is set up to have a list of images, that's why it keeps asking for an image. Not sure what the _dvd extension is all about but these are all basically screen files.

For DOOM.MDV use mixed or hires...I think mixed is supposed to be the correct one since the two DOOM images are mixed mode. On Q-emulator, the hires (i.e. mode 4) works the best here whereas the mixed tries to quickly switch the screen but not fast enough to get any effect. I'm guessing on a real QL you'd see the actual hi-color image. Unfortunately I had access to my QL yesterday but today I'm traveling and only have a laptop with emulators, so I cannot try them on real hardware until next week -- someone want to let me know if it works?

For DLAIR.MDV, I'm not sure which mode to use as hires, once again, works well, but I'm guessing that mixed ought to work but the colors just flash as horizontal lines (like when you load a mode 4 image in mode 8). The lores does not as it gives you lots of flashing. If I load the DLAIR screens into the JavaScript-based Screen Viewer, they both come up as mode 4 so I'm guessing they are both hires images.


What I want to do next is try and trim down the assembly to use less memory so I can run it on a 128K QL. It basically sets aside 32K to copy the system variables at address $28000 since it uses that as vram2. I think the code basically stops the QL in its tracks, makes a copy of that memory starting at $28000, then uses that memory as the second video buffer to be able to switch quickly between the two images, and when done, copies that saved 32K back to $28000 to restore all he system variables. However, I don't believe you need to set aside that much memory for system variables...how much memory does it actually take?

HI,

Minerva can do all this, it can enable te Second Screen, (VRAM2), move System Variables and has fast memory move vectors. Just read the Minerva manual.

Derek_Stewart wrote: Sat Jan 11, 2025 7:01 am Minerva can do all this, it can enable te Second Screen, (VRAM2), move System Variables and has fast memory move vectors. Just read the Minerva manual.

So you are saying QDOS cannot do this?

Minerva is basically the 'last' ROM version of QDOS - so it's still QDOS as such.

But previous QDOS versions are not taking second VideoRAM into consideration, although it is implemented in hardware.
Minerva can move system variables and make the VRAM2 area free for the user.

That’s why Omega!s routine (QDOS compatible) does things to make the VRAM2 free, like …
1) Start supervisor mode, disable interrupt
2) Move 32k of the system variables from $28000 to ram (at the end of the routine).
…
8) Restore system variables
9) Return to QDOS.

I'm working on reducing the memory requirements. Currently it sets aside 96K to store the two pictures and a copy of the system variable area. An easy reduction was to just swap one of the pictures with system variables and that reduced it down to 64K (plus 2K for program itself). That version is currently working but is still too big to run in 128K. I plan to reduce it to a little over 32K by loading the first image into video memory directly from MDV via LBYTES and then swapping the system variable area with the second image. That should give enough space to run.