The Sinclair QL Forum

Posted: **Sat Jan 04, 2025 12:26 pm**

Hi,

Just use another assembler, like: QMAC to assemble the files, thought there maybe changes required specific for the assembler in use. Which maybe need reading the manual!

Posted: **Sat Jan 04, 2025 5:53 pm**

Mark Swift wrote: Sun Dec 29, 2024 11:48 pm GINGE.gif & TOWER.gif

The use of amplitude modulated screens (dot diameter) will surely look better on higher resolution screens, unlike frequency modulated screens (dot spacing), which, even on low resolution screens, give apparently acceptable results.

I was thinking that there was still another option to explore, the color mixes that could be obtained through the OVER instruction, which would result in interesting dot zones in amplitude modulated screens, although I imagine not as interesting as it would be to have color addition through a palette with a larger number of colors.

Posted: **Fri Jan 10, 2025 9:13 am**

tofro wrote: Sat Jan 04, 2025 11:05 am Yep, GENS seems to be a bit long in the tooth for more "modern" systems. It doesn't honour default directories, and the <ALT>+something commands tend to collide with basically everything on a more modern, HOTKEYed system.

BTW: I found that <ALT>+"H" in GENS gives a help screen listing all commands.

So I played with it and did get it to work as advertised...well, at least everything ran as it should. Tried it out first in Q-emuLator and also in QL2K and it worked the same on both. It seems to try and create a high color high resolution picture, but it just flashes the screen between the two images and then has bars coming across. So I figured it was an emulator issue but it behaved exactly the same on my BBQL.

Not quite sure why it's not working. I'm assuming its author had it working successfully. Was there supposed to be any hardware added to it like a Gold Card? The assembly doesn't seem too complex. Part of its internal structure follows the BASIC boot program -- i.e. it sets aside memory in BASIC for 2048+32768+32768+32768, which the code assumes to figure out where each of the two screens are.

Code: Select all

*       dithVide for Sinclair QL
* /interrupt handler in supervisor mode/
*   (C) Omega 2006 (omega.webnode.com)

nm_frms		EQU	900
nm_lins		EQU	$0fa
ln_wait		EQU	$0006
bg_wait		EQU	$02d7	2e6
sv.plist	EQU	$3c	offset, frame linked list 2803c
sv.pcint	EQU	$35	copy of system interrupt
pc_intr		EQU	$18021	interrupt hw status register
mc_stat		EQU	$18063	master chip settings
screen1		EQU	$20000
screen2		EQU	$28000
*			bit 1	- screen off (1)
*			bit 3	- lores (1), hires (0)
*			bit 6	- (0) PAL, (1) NTSC
*			bit 7	- (0) VRAM starts $20000, (1) $28000

; save registers
; goto supervisor mode
start	trap	#0
	movem.l	d0-d7/a0-a6,-(a7)
; disable interrupt
	ori	#$0700,sr

	lea	ssvsp,a0
	move.l	sp,(a0)		save stack
	
	move.b	#$80,mc_stat	switch to 2nd vram, hires
	lea	stack,sp	new stack address
	move.l	#$28000,a6	sys_vars
	lea	frames,a0
	move.w	#nm_frms,(a0)

; save system variables
	move.l	#screen2,a0
	lea	screen,a1
	move.w	#$8000,d0
	jsr	ldir

	lea	start,a0
	add.l	#2048,a0	add code_size in basic
	add.l	#$8000,a0	addr of scr1 gfx
	move.l	a0,a2
	add.l	#$8000,a2
	
	move.l	#screen2,a1	addr of vram1
	move.w	#$8000,d0
	jsr	ldir
	move.l	a2,a0
	move.l	#screen1,a1
	move.w	#$8000,d0	next gfx follows
	jsr	ldir
	
;	jsr	clscr

	lea	flipper,a0	address of vector
	lea	lores,a2	address of routine
	move.l	a2,4(a0)	save routine address to vector
	move.l	a0,$2803c	save vector address to sv.plist

	andi.w	#$f8ff,sr	ei (enable interrupt)
	
loop	jmp	loop
	
exit	ori.w	#$0700,sr	di
	movem.l	(a7)+,a0	restore stack
	
; restore system variables
	move.l	a6,a1
	lea	screen,a0
	move.l	#$8000,d0
	jsr	ldir

	move.b	#0,mc_stat	switch to screen1, hires
; exit
	lea	ssvsp,a0
	move.l	(a0),sp		restore stack
	movem.l	(a7)+,d0-d7/a0-a6
	moveq	#0,d0		return no error
	move.w	#$0800,sr	user mode, EI
	rts

; clear both screens
clscr	move.l	#$8000,d0
	move.b	#$ff,d1
	jsr	clmemb
	move.l	#$8000,d0
	move.b	#0,d1
	jsr	clmemb

; ldir (memory move routine) slow
; a0 - from / a1 - to / d0 - size
ldir	move.b	(a0)+,(a1)+
	dbra	d0,ldir
	rts		

; clmemb (clear mem) slow
; a0 - where / d0 - size / d1 - with what
clmemb	move.b	d1,(a0)+
	dbra	d0,clmemb
	rts

flipper:
	dc.l	0,0
lores:
	movem.l	d0-d7/a0,-(a7)
	lea	vram_l,a0
	eor.b	#$80,(a0)
	move.b	(a0),mc_stat
	lea	frames,a0
	subi.w	#01,(a0)
	movem.l	(a7)+,d0-d7/a0
	beq	exit
	rts

hires:
	movem.l	d0-d7/a0,-(a7)
	lea	vram_h,a0
	eor.b	#$80,(a0)
	move.b	(a0),mc_stat
	lea	frames,a0
	subi.w	#01,(a0)
	movem.l	(a7)+,d0-d7/a0
	beq	exit
	rts

mixed:
	movem.l	d0-d4/a0,-(a7)
	move.b	#%00000010,mc_stat	screen off
	lea	vram_m,a0
	move.b	(a0),d0
	move.b	#%10001000,d1
	move.w	#bg_wait,d4
bg_wlp	dbra	d4,bg_wlp
	move.w	#nm_lins,d2
nm_llp	move.w	#ln_wait,d3
	move.b	d0,mc_stat
	eor.b	d1,d0
ln_wlp	dbra	d3,ln_wlp
	nop
	nop
	nop
	nop
	dbra	d2,nm_llp
	eor.b	d1,(a0)
	lea	frames,a0
	subi.w	#01,(a0)
	movem.l	(a7)+,d0-d4/a0
	beq	exit
	rts

modes	dc.l	0		lores
	dc.l	0		hires
	dc.l	0		mixed
frames	dc.w	0
vram_l	dc.b	%00001000	ram 0 lores
vram_m	dc.b	%00000000	ram 0 hires
vram_h	dc.b	%10000000	ram 0 hires
ssvsp	dc.l	0
	ds.b	$0200
stack	
screen

I even created a lower resolution version but no difference -- i.e. 512x184 seemed to work in 128K where I simply changed the assembly to use hex $5C00 instead of $8000 and mimicked that in the BASIC: 2048+23552+23552+23552.

The original BASIC boot program also starts the monitor and creates a RAM disk, but all that seems to not be needed. Attached is a zip file with 3 MDV images. The first is how it was distributed, but with just the DOOM image files since I ran out of space on the MDV image. The other two use a simplified BASIC boot program that directly runs the binary (I cal it hires_bin) and asks for the image files. But I was not able to get the high color images on actual hardware, so no idea why it's failing.

[Edit: removed HIRES.zip as it was wrong]

[Edit: yes, yes, I call it HIRES...I realize it's not higher dot-pitch, it's more colors, but whatever :-/]

Posted: **Fri Jan 10, 2025 10:33 am**

The program doesn't need special hardware, only a memory expansion.

The fact that it flickers as hell on QEmulator is what I said above - The polling interrupt just doesn't seem to end up at a constant 50Hz on the emulators.

In fact, the program is (as you said) in theory pretty simple: Loads the wo overlaid pictures into screen memory at $20000 and $28000, then switches between them using the 50Hz interrupt, "mixing" the colors of the first and second picture, so you get a 25Hz full picture using the fact that our eyes are just too slow to see the flicker. So it can, in theory, display 64 colours, but only 32 are unique (green in first and blue in second looks the same as vice versa).

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.

I would suppose you have a US QL? These have slightly different ULAs to implement a 60Hz screen (I don't know if there are other differences). The "mixed" mode will likely not work on a US QL as it apparently has timing loops adjusted to Europe's 50Hz. The "hires" and "lores" (where both screens are expected to have the same resolution should, however, work on any ULA.

What I think is missing in the above code is within the loop I set PC.INTR (bit 3) to re-arm the interrupt.

What's also a bit hairy is that the code simply patches the first entry of the polling interrupt list with its own routine (effectively disabling whatever might be already there) instead of using the proper system call.

Posted: **Fri Jan 10, 2025 11:28 am**

tofro wrote: Fri Jan 10, 2025 10:33 am The program doesn't need special hardware, only a memory expansion.

The fact that it flickers as hell on QEmulator is what I said above - The polling interrupt just doesn't seem to end up at a constant 50Hz on the emulators.

I expected it not to work on the emulators. What I was saying is that it doesn't work on real hardware either...it behaves exactly the same way as on the emulators. [Edit...see follow up post where I think I understand now what's going on...I think :-/]

tofro wrote: Fri Jan 10, 2025 10:33 am 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.

I think the below MDV file is what it is supposed to look like...I just loaded two mode 8 images (i.e. low resolution) and the streaking is gone. It gives a steady picture on my US QL and sort of works on Q-emuLator as well, though its refresh rate is so slow you can see the shimmering.

HIRES2.zip: (53.41 KiB) Downloaded 54 times

tofro wrote: Fri Jan 10, 2025 10:33 am What's also a bit hairy is that the code simply patches the first entry of the polling interrupt list with its own routine (effectively disabling whatever might be already there) instead of using the proper system call.

I will poke more around with it. It's pretty interesting and I really want to get the images that he has on his website.

Posted: **Fri Jan 10, 2025 11:30 am**

tofro wrote: Fri Jan 10, 2025 10:33 am I would suppose you have a US QL? These have slightly different ULAs to implement a 60Hz screen (I don't know if there are other differences). The "mixed" mode will likely not work on a US QL as it apparently has timing loops adjusted to Europe's 50Hz. The "hires" and "lores" (where both screens are expected to have the same resolution should, however, work on any ULA.

Oh, I see what you're saying. If he's relying on 50Hz timings and I'm giving a 60Hz clock, then it gets off and finds itself in a mode that's contrary to the image. Is it a matter of fixing some counters in his code? I will have to read it more closely.

Could someone try one of the HIRES-256 mdv images from my first zip file to see if they work since all I have is a US QL. If using vDrive, the mdv image names will have to be shortened to 8 characters since it seems to want 8.3 where 3 is MDV.

Posted: **Fri Jan 10, 2025 11:48 am**

bwinkel67 wrote: Fri Jan 10, 2025 11:30 am
tofro wrote: Fri Jan 10, 2025 10:33 am I would suppose you have a US QL? These have slightly different ULAs to implement a 60Hz screen (I don't know if there are other differences). The "mixed" mode will likely not work on a US QL as it apparently has timing loops adjusted to Europe's 50Hz. The "hires" and "lores" (where both screens are expected to have the same resolution should, however, work on any ULA.
Oh, I see what you're saying. If he's relying on 50Hz timings and I'm giving him a 60Hz clock, then it gets off and finds itself in a mode that's contrary to the image. Is it a matter of fixing some counters in his code? I will have to read it more closely.

For the "hires" and "lores" modes, the screen refresh rate shouldn't really matter - You simply flip the pages a bit faster than we do (and get a little less flicker). The "mixed" mode, however, is not likely to work properly. The code as you attached it, seems to use "lores" mode only, though.

Posted: **Fri Jan 10, 2025 12:02 pm**

tofro wrote: Fri Jan 10, 2025 11:48 am The code as you attached it, seems to use "lores" mode only, though.

This code here is what you're referring to I'm guessing:

Code: Select all

	lea	flipper,a0	address of vector
	lea	lores,a2	address of routine
	move.l	a2,4(a0)	save routine address to vector
	move.l	a0,$2803c	save vector address to sv.plist

	andi.w	#$f8ff,sr	ei (enable interrupt)
	
loop	jmp	loop

So I'll need to change lores to mixed and see what happens. Is that odd "jmp loop" trying to be a stop without terminating the code?

So it shouldn't have worked at all in mixed mode. But I'm betting I'm still going to run into 50Hz vs 60Hz issues and this code does have some wait values, plus some filler NOPs to get the timing just right:

Code: Select all

mixed:
	movem.l	d0-d4/a0,-(a7)
	move.b	#%00000010,mc_stat	screen off
	lea	vram_m,a0
	move.b	(a0),d0
	move.b	#%10001000,d1
	move.w	#bg_wait,d4
bg_wlp	dbra	d4,bg_wlp
	move.w	#nm_lins,d2
nm_llp	move.w	#ln_wait,d3
	move.b	d0,mc_stat
	eor.b	d1,d0
ln_wlp	dbra	d3,ln_wlp
	nop
	nop
	nop
	nop
	dbra	d2,nm_llp
	eor.b	d1,(a0)
	lea	frames,a0
	subi.w	#01,(a0)
	movem.l	(a7)+,d0-d4/a0
	beq	exit
	rts

Thanks for all your help. It's getting me past all these hurdles. I really should have read the code but I was so busy trying to get the files in the correct format. I did go through the beginning to understand how it aligned with the BASIC, but never went further.

Posted: **Fri Jan 10, 2025 1:39 pm**

Original DithvIDE was created for ZX Spectrum (Commodore 64 later added), main part of it being the image conversion utitity, which created the two screens.
But the conversion utility does not support QL.
Source included:
http://speccy.trilogic.cz/zaloha_zilog/ ... dithvide.c
http://speccy.trilogic.cz/zaloha_zilog/ ... E/dithvide
(The author usualy provides no documantation for his projects, because “it is so simple, must be obvious for everyone”. )
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.

I expect that the Magnetic Scroll Interpreter display routine is the much cleaner one.

Posted: **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?

The Sinclair QL Forum

Odd - Interesting - Forgotten

Re: Odd - Interesting - Forgotten

Re: Odd - Interesting - Forgotten

Re: Odd - Interesting - Forgotten

Re: Odd - Interesting - Forgotten

Re: Odd - Interesting - Forgotten

Re: Odd - Interesting - Forgotten

Re: Odd - Interesting - Forgotten

Re: Odd - Interesting - Forgotten

Re: Odd - Interesting - Forgotten

Re: Odd - Interesting - Forgotten