Hi everyone,
I'm the author of
ql_dithvide, and I just wanted to share some thoughts after reading Mike’s incredible journey to get my messy code up and running. What a challenge!
You truly have my respect, Mike. I’m seriously impressed by how you managed to figure everything out—great job!
You were absolutely right about the inconsistent coding style. I put it together quickly and in a rush. It was also my first attempt at mc68k coding, so there was a lot of learning on the fly. I had planned to do much more with it, but unfortunately, my QL broke during development. In the end, I decided to publish the work in progress since I couldn’t continue. One thing I was particularly proud of, though, was cracking the interrupt handler. It’s a key "enabler" for coding demo effects on the QL.
Regarding the comments about display modes and color depth, I completely agree—each mode has its own pros and cons. For example, even the hi-res mode is an upgrade to existing hi-res as it allows for greater color depth within the basic palette. The most saturated colors are in the low-res mode, while the mixed mode gives quite special images.
One thing that you might not have noticed about
Mixed Mode is that every displayed line alternates between different display modes. What’s more, the order of the modes swaps with every interrupt. Here’s an example to illustrate:
Code: Select all
Loop:
interrupt odd
Mode 8 ; 1st line
Mode 4 ; 2nd line
Mode 8 ; 3rd line
Mode 4 ; 4th line
... until all 256 lines are shown
interrupt even
Mode 4 ; 1st line
Mode 8 ; 2nd line
Mode 4 ; 3rd line
Mode 8 ; 4th line
... until all 256 lines are shown
goto Loop
This approach is similar to the raster effects seen in ZX Spectrum demos, like Overscan from Busy, Shock Megademo, or Eklhaft2
https://www.youtube.com/watch?v=egJ7nIiv4ac (first part was made by me
, SID tune by Poke).
In Mixed Mode,
the display mode changes at a precisely timed moment when the ULA begins pulling data from video memory
for a specific line. Speaking of precise timing, there are two wait constants in the code that need to be adjusted for different QL setups. My setup was a BBQL with a Sandy Qboard (512k expansion). If I remember correctly, the upper 512k of expanded memory was “fast,” while the lower 128k (BBQL RAM) was “slow” due to the ULA accessing the memory.
Here are the constants:
bg_wait: This wait loop allows the beam to reach the first line of the monitor.
ln_wait: This wait loop lets the beam advance to the next line on the screen.
If you’re working with an unexpanded BBQL, you’ll likely need to reduce these constants since the code will run in contended memory, which slows things down. The slower the machine, the smaller these constants need to be.
Hope this helps clarify some of the code’s quirks! Thanks again, Mike, for all your hard work—it’s amazing to see this code being brought back to life.
Cheers, omega
PS: image conversion process is a bit tricky and requires several steps to get to the results. I am happy to convert some files for you.
You truly have my respect, Mike. I’m seriously impressed by how you managed to figure everything out—great job!
, SID tune by Poke).