Odd - Interesting - Forgotten

[tofro]

so the only to do this in QDOS is leave thd Systdm Variable slone and use an allocated 32K of memory for the copy of the screen memory.

Well, what the DithVIDE program does is: Copy the first 32k of the picture to screen memory, then allocate 32k for a second picture, then suspend QDOS by entering Supervisor Mode, then save the system variables and supervisor stack to allocated space, then copy the second 32k from the buffer to the second screen memory, then enter a loop to flip between the two screens in high frequency.

[bwinkel67]

Well, what the DithVIDE program does is: Copy the first 32k of the picture to screen memory, then allocate 32k for a second picture, then suspend QDOS by entering Supervisor Mode, then save the system variables and supervisor stack to allocated space, then copy the second 32k from the buffer to the second screen memory, then enter a loop to flip between the two screens in high frequency.

Yup, it seems as simple as that....and my changes just try to do this a bit more memory efficiently. The code itself seems a bit messy as there are inconsistencies (which makes sense since it was likely put together quickly). I don't know enough about 68K assembly to understand the nuances, but sometimes it hard codes an address, sometimes it uses a label of that same address, and sometimes it uses LEA vs MOVE.L to set a register and I haven't researched the difference between the two commands.

The original code also was allocating 2K for the program but it only assembled to about 960 bytes and then the "screen" variable sits at the end of that 960, which didn't align with the 2K boundary for the second screen, So the system variables weren't exactly overwriting the entire 2nd screen saved on the heap, as it was shifted off by about 1K...but I guess it really didn't matter as long as it was using allocated heap memory, not going outside that, and being consistent where it grabbed the system variables when restoring.

When I made the changes, I tried to stick to the original author's inconsistencies and seemingly got it to work on a 128K system -- on Q-emuLator, albeit with fast pulsing (i.e. hires) or slow flashing (i.e. mixed). Unfortunately I'm not home until Tuesday so I won't get a chance to see if it will actually work on my US QL. Did anyone try my newest DOOM.MDV in mixed mode to see if the combined DOOM picture came up on real hardware running JS ROM in high color?

[bwinkel67]

...then enter a loop to flip between the two screens in high frequency.

Although here there's a bit of logic that needs to change the screen mode when it flips images so that whoever is decoding video ram into a screen image knows which resolution to do it in so you don't get those cross-resolution artifacts (like flashing horizontal lines).

[tofro]

and sometimes it uses LEA vs MOVE.L to set a register and I haven't researched the difference between the two commands.

LEA means "load effective address" - It simply loads an address register with the address of a label.

Code: Select all

		org 	100000
label 	dc.l 	0

start		lea 	label(pc),a0

loads a0 with 100000 (don't try this at home because "org" is a big no-no for most QDOS programs)

MOVE.L looks at stuff at addresses

Code: Select all

data 	dc.l 		1234

test1 	move.l 	data(pc),a0

test2 	move.l 	#data,a0		; not very useful

test1 loads a0 with the contents of data, i.e loads 1234 into a0.
test2 loads a0 with the offset of data from the beginning of the program (which is not very useful, normally). For some QL assemblers, the (pc) is optional (because its implicit), which might confuse you.

[bwinkel67]

I've been playing around with some of the images on the DITHVIDE website. Most don't work well on Q-emuLator. The mixed mode just flashes and the hires doesn't really give you any improved pictures since you only have red and green colors to dither together (ok, and black and white). Note that I expect the mixed mode will give the best images on real hardware, but all I have at the moment is Q-emuLator.

The lores, though, does kind of give you some interesting images. Now when you run it, it quickly pulses since Q-emuLator isn't able to mimic a QL's video signal 100%.

RTYPE_lores_dithvide.gif (7.99 MiB) Viewed 635 times

If you record that video and play it back and then take a picture, you kind of get what the effect ought to be (RTYPEl in lores found on RTYPEl.MDV):

This is one of the two original mode 8 images (the other image looks very similar to this one):

...and if you want to play with it yourself on Q-emulator (there are two MDVs, one for lores and one for mixed mode, though mixed only works on real hardware):

RTYPE.zip

(112.15 KiB) Downloaded 18 times

[bwinkel67]

What kind of color depth are we looking at here? I'm guessing the following:

• hires -> 4 x 4 = 16 (though a weird color palette with no blue, so just shades of red, green, grey, and brown)
• lores -> 8 x 8 = 64
• mixed -> 4x4 x 8 = 128 (see below **)

(**) So for mixed I'm assuming that for each of the 256 pixels in mode 8, you get two pixesl in mode 4 since its resolution is 512 horizontal. Am I off here? If not, that's pretty good as I recall my 90s mac has 16-color and 256-color models before I upgraded to 24-bit color, which was millions.

[tofro]

What kind of color depth are we looking at here? I'm guessing the following:

• hires -> 4 x 4 = 16 (though a weird color palette with no blue, so just shades of red, green, grey, and brown)
• lores -> 8 x 8 = 64
• mixed -> 4x4 x 8 = 128 (see below **)

(**) So for mixed I'm assuming that for each of the 256 pixels in mode 8, you get two pixesl in mode 4 since its resolution is 512 horizontal. Am I off here? If not, that's pretty good as I recall my 90s mac has 16-color and 256-color models before I upgraded to 24-bit color, which was millions.

Your color depth calculations for hires and lowers are somewhat correct - in theory.

When we're talking about unique colours, however, it's much less. Keep in mind that, in lores, for example, it makes no difference whether you're switching between blue in one screen and yellow in another or vice versa - both give the impression of the same green. so it's in fact 8 colours in hires, and 32 in lores (with no blue and yellow tones in hires, though. Just shades of green and red).

Your "mixed" figure is off. This gives 6 bits/pixel, displaying 32 colours in theory, minus the non-unique ones 16. Mixed mode does have an additional limitation as your choice of colours for every second pixel is limited by the fact that two adjacent mode 4 pixels are always mixed with one single mode 8 pixel. So, for two adjacent pixels, you have a choice of 8 colours, and 16 colours for the first one of a pair.

[bwinkel67]

Your color depth calculations for hires and lowers are somewhat correct - in theory.

When we're talking about unique colours, however, it's much less. Keep in mind that, in lores, for example, it makes no difference whether you're switching between blue in one screen and yellow in another or vice versa - both give the impression of the same green. so it's in fact 8 colours in hires, and 32 in lores (with no blue and yellow tones in hires, though. Just shades of green and red).

Right, because of duplication where green over blue and blue over green is the same thing.

Your "mixed" figure is off. This gives 6 bits/pixel, displaying 32 colours in theory, minus the non-unique ones 16. Mixed mode does have an additional limitation as your choice of colours for every second pixel is limited by the fact that two adjacent mode 4 pixels are always mixed with one single mode 8 pixel. So, for two adjacent pixels, you have a choice of 8 colours, and 16 colours for the first one of a pair.

Ok, here I guess I was thinking of it the wrong way. I looked at it from the standpoint of a monitor's pixels, separate from how the QL stored it in memory. So the monitor's pixels would be turned on or off and perhaps I assumed incorrectly that in mode 4, 512 pixel per line could separately be activated and in mode 8, it would be pairs of pixels sharing the same color (i.e. 256 resolution gives 2 pixels to get to 512):

Code: Select all

+---+---+
|   |   |   mode 4 image
+---+---+
|       |   mode 8 image
+-------+

So I thought since it is flashing two pixels for mode 4 and interlacing it for every one pixel in mode 8, you'd have:

Code: Select all

+---+---+
| 4 | 4 |   mode 4 image each with 4 possible colors so: 4 x 4
+---+---+
|   8   |   mode 8 image with possible colors so: X 8
+-------+

And so I came up with 4 x 4 X 8 for possible color choices. In this case would you have that many duplicates since "green x red X green" would be different from "green x green X red" etc?

[bwinkel67]

Wait, now that I think about it, that really means you have 4 x 8 colors per pixels for mixed...I get now what you were trying to say...just had to work through it myself

[bwinkel67]

More fun with this...I'm trying to figure out how to create my own pictures. I did contact the original author to see if I could get his ImageJ plugin that automates part of this (not 100% sure if it takes an image and then generates the two interlaced images). However, I just wanted to create a color test image of all possible colors for each mode.

So if I articulate all combinations, here's what I come up with for palettes (note that o here means black...think of it as off or obsidian):

lores = 36 distinct colors (256 per line)

w - w r g b c m y o
r - r g b c m y o
g - g b c m y o
b - b c m y o
c - c m y o
m - m y o
y - y o
o - o


mixed = 26 distinct colors (512 per line **)

w - w r g b c m y o
r - r g b c m y o
g - g b c m y o
o - b c m y o


hires = 10 distinct colors but missing all hues of blue (512 per line)

w - w r g o
r - r g o
g - g o
o - o


(**) The caveat here is that it's not really 512 resolution, since one of the two colors always needs to take up two pixels (i.e. in mixed mode, the low resolution images always shares the same color with 2 pixels).

Also, this assumes that blue + yellow gives a different green than what we get with green + green, green + white, or green + black.