The Sinclair QL Forum

Posted: **Wed Jan 22, 2020 6:09 pm**

I'm a newbie on the QL but am experienced in M68K assembler on other platforms (Atari/Amiga/etc). I've therefore been collecting software utilities (emacs/qmac/c68/etc) for my twin Goteks (I have a Tetroid SGC clone providing the floppy interface for them). I also have a registered copy of Qemulator (Windows 10).

To start getting familiar with the assembler and the nuances of QDOS I thought I'd try modifying (for GST/qmac) the Andrew Pennell program to print d1.l as hex. It appears here (cut and paste has slightly affected the formatting):

Code: Select all

	TITLE	First QL gst/qmac program

	SECTION CODE


MT.FRJOB	equ	$05

Base	bra.s	Start
	ds.b	6-(*-Base)
	dc.w	$4afb
	dc.w	$06			Length of program name
	dc.b	'ASSTST'		Program name

Start
	move.l	#$12aa34cc,d1		Test number to print
	bsr.s	PrtHex
	moveq	#-1,d1
	clr.l	d3
	moveq	#MT.FRJOB,d0		End program
	trap	#1


* Subroutines

* Print d1.l as hex
PrtHex	moveq	#7,d0
Phlp	rol.l	#4,d1
	move.l	d1,-(a7)
	and.l	#$0f,d1
	cmp.b	#$09,d1
	ble.s	Phdig
	addq.b	#$07,d1
Phdig	add.b	#'0',d1
	bsr.s	CPrint
	move.l	(a7)+,d1
	dbf	d0,Phlp
	rts


* Char to print in d1.b
CPrint	movem.l	d0-d1/d3/a0-a1,-(a7)
	movea.l	#$00010001,a0		Channel #1 remains open
	moveq	#-1,d3
	moveq	#5,d0
	trap	#3
	movem.l	(a7)+,d0-d1/d3/a0-a1
	rts

	END

My problem is twofold.
First, the above program (compiled under Qemulator), runs fine on my real hardware but freezes when I attempt to run it using Qemulator. If I comment out the trap #3 of the IO.SBYTES routine the program will at least run to completion.

Secondly, I tried running the program under Qmon. Again that works on real hardware but freezes without even producing a register display under Qemulator.

Though it would be nice to have, I can see why Qmon might not work under emulation (competition over exceptions etc) but I'm puzzled why Qemulator won't run the simple hex print program. Perhaps I haven't read the right manual yet and I'm missing some QDOSy thing or have otherwise blundered in a spectacular way (e.g. do I, for example, need to allocate some heap space for a7)?

Alan

Posted: **Wed Jan 22, 2020 6:35 pm**

Hi and welcome!

QEmulator should work just fine with QMon. No limitations.
You didn't say how you compiled and linked (and started) the program. Assumption is you linked it into an executable and started with EXEC
Program looks fine so far, should work on any platform, at least directly after boot. The assumption it makes that #$00010001 is a valid channel id is, however, a dangerous one. Don't ever trust a channel id that you haven't opened yourselves, except 0.

When a program does immediately crash the Emulator and doesn't even properly run up, most of the time reasons are the following:

Data size is odd, which causes the program to start up with an un-even stack pointer (That is, an immediate address error exception)
Executable header is garbled somehow. This happens a lot when files are zipped up or unpacked with native (instead of QDOS) zip and unzip or files are carelessly moved back and forth between native and QDOS file systems.

Check your program length on both platforms - I bet it's different between native and Q-Emulator
Check your program with a dump to screen or hexdump - I bet it's different again.

Read (and follow) carefully http://www.dilwyn.me.uk/gen/pcqlxfer/index.html - This is the biggest hurdle when people start with the QL.

Tobias

Posted: **Wed Jan 22, 2020 8:13 pm**

Thanks for that Tobias. Much appreciated. To answer your points:

I compiled and linked the source using qmac with: ew flp1_qmac ; "flp2_hex -nolink"
The resulting program was run as either: ew flp2_hex_bin or qmon flp2_hex_bin

I had previously CONFIGured both qmac and qlink to produce type 1 output, leaving the rest of the config options as defaults.

Agreed about the channel. I had tried an IO.OPEN of a CON device and used the resulting ID, but that didn't make a difference.

I'm aware of the unzip gotcha, having been bitten by it several weeks ago when I first started. Back then I fixed it using Rich's modified unzip to unzip the unzip.zip package (that's a sentence I don't want to write again) and have subsequently used that on the Qemulator side. I never use unzip on the windows side. A typical unzip operation to add another program from the net to my set of utilities might be: ew flp1_unzip ; "mdv2_emacs.zip - d flp3_" (where MDV2 is an attached Windows folder containing the internet downloads - OK as it is just reading the source zip; all the flp devices are QL filesystems). I've not had any header problems since.

All my main QL work is done using floppy image files created using Qemulator. I produce files within these images using Qemulator. If I want to run the program on my real hardware I just copy the floppy image files to a USB memory stick and then plug it into a Gotek. No zip files or copies to mounted W10 folders are involved. Therefore precisely the same image and files-within-image are being used on both Qemulator and the real hardware. I can't therefore see how the file sizes or data sizes might differ. Besides, the executables are being produced using the assembler on the Qemulator so you might expect that, if there was a header problem, the program would work under Qemulator and fail when I transfer it to real hardware - the reverse is happening.

Anyway, I'll see if I can find a utility (or superbasic command) that'll show the file sizes and section/segment sizes.

Edit: I forgot to add that I can run Qmon under Qemulator by typing "qmon" after the boot file has been invoked and I do get the "Qmon>" prompt etc. It's only when I use it with the hex program that it freezes.

Alan

Posted: **Wed Jan 22, 2020 9:45 pm**

Which ROM are you using on q-emulator as that may explain the difference.

Posted: **Wed Jan 22, 2020 10:12 pm**

Hi Rich,

I'm using the default on Qemulator i.e. JS with TK2 back ROM. My current real hardware is AH plus the SGC clone expansion card (I have some JM ones waiting for me to install).

Alan

Posted: **Wed Jan 22, 2020 10:25 pm**

ajb wrote:My problem is twofold.
First, the above program (compiled under Qemulator), runs fine on my real hardware but freezes when I attempt to run it using Qemulator. If I comment out the trap #3 of the IO.SBYTES routine the program will at least run to completion.

Hi Alan,
Its ages since I created a job in assembler. I mainly write toolkits. IIRC you need some stack space! Make the following alterations (first and last lines) and your job should work:

Code: Select all

   ...
   data 24              ; some dataspace (sloppy estimate)

MT.FRJOB   equ   $05

Base   bra.s   Start
   ds.b   6-(*-Base)
   dc.w   $4afb
   dc.w   $06         Length of program name
   dc.b   'ASSTST'      Program name

Start

   lea.l 0(a6,a5.l),a7     grab all dataspace for stack
   ...

Posted: **Wed Jan 22, 2020 10:55 pm**

pjw wrote: Hi Alan,
Its ages since I created a job in assembler. I mainly write toolkits. IIRC you need some stack space! Make the following alterations (first and last lines) and your job should work:
Code: Select all
   ...
   data 24              ; some dataspace (sloppy estimate)

MT.FRJOB   equ   $05

Base   bra.s   Start
   ds.b   6-(*-Base)
   dc.w   $4afb
   dc.w   $06         Length of program name
   dc.b   'ASSTST'      Program name

Start

   lea.l 0(a6,a5.l),a7     grab all dataspace for stack
   ...

Per,
actually, no. By default, a7 of a newly started job points to the end of the data space (provided there is some), which is good enough. Only if the job received some opened channels from QDOS, (a6,a5) is actually different from a7. When there are no channels on the stack, your proposed code doesn't do anything.

Tobias

Posted: **Wed Jan 22, 2020 11:27 pm**

tofro wrote:
pjw wrote: Hi Alan,
Its ages since I created a job in assembler. I mainly write toolkits. IIRC you need some stack space! Make the following alterations (first and last lines) and your job should work:
Code: Select all
   ...
   data 24              ; some dataspace (sloppy estimate)

MT.FRJOB   equ   $05

Base   bra.s   Start
   ds.b   6-(*-Base)
   dc.w   $4afb
   dc.w   $06         Length of program name
   dc.b   'ASSTST'      Program name

Start

   lea.l 0(a6,a5.l),a7     grab all dataspace for stack
   ...
Per,
actually, no. By default, a7 of a newly started job points to the end of the data space (provided there is some), which is good enough. Only if the job received some opened channels from QDOS, (a6,a5) is actually different from a7. When there are no channels on the stack, your proposed code doesn't do anything.

Tobias

Ah, yes. I recall now. However, Allen's code was missing the dataspace. Looking more closely, it should be more like 32b

Posted: **Thu Jan 23, 2020 8:03 am**

Thanks for the suggestions. It looks like 2 separate problems. It seems that my Qmon will freeze on Qemulator with anything so it's probably best to return to that after the hex print is sorted out (except to say in passing that AH is no better with Qemulator).

The stack definitely looks to be a problem. I decided to simplify the program to just calling the IO.SBYTES subroutine with a character held in d1. It worked without the enclosing movems but not with. Adding a bit of DATA appears to have fixed that. I'll build the program back up in stages to see whether it falls over at any other place.

Am I right in assuming, from what you've said, that the preferred method of initialising an a7 stack on the QL platform is just to reserve some DATA?

Anyway, I'll return to the problem after walking the hound and then report back.

Alan

Posted: **Thu Jan 23, 2020 9:29 am**

ajb wrote: The stack definitely looks to be a problem. I decided to simplify the program to just calling the IO.SBYTES subroutine with a character held in d1. It worked without the enclosing movems but not with. Adding a bit of DATA appears to have fixed that. I'll build the program back up in stages to see whether it falls over at any other place.

Am I right in assuming, from what you've said, that the preferred method of initialising an a7 stack on the QL platform is just to reserve some DATA?

Well, a job in the QL looks roughly like that, allocated in one single block of memory:

<Job header>
<code>
<data space and stack>

(This is classic QDOS and EXEC_W - with certain extensions like HK II and the Thing Extension, the three areas can be subdivided, re-used and spread across various memory areas. We don't look into that yet)

The data space of a job roughly resembles the joint .bss (from bottom) and .stack (from top) in classic operating systems. When started, (A6, A4) point to the beginning, a7 to the end of that area. If you don't code a DATA directive (or create code that is linked), the toolset will assume a default data space of 4K, which is by far enough for most trivial programs. 24 bytes (just realizing that statement) is thus a bit on the frugal end

.
What apparently happened is that the stack ran backwards into your code overwriting the rts instruction of your subroutine - Bad things tend to happen after that, you were lucky the QL didn't explode

. Why the BBQL doesn't care? It apparently runs a different QDOS version that can live with a bit less stack.

Tobias

The Sinclair QL Forum

Emulation program freeze

Emulation program freeze

Re: Emulation program freeze

Re: Emulation program freeze

Re: Emulation program freeze

Re: Emulation program freeze

Re: Emulation program freeze

Re: Emulation program freeze

Re: Emulation program freeze

Re: Emulation program freeze

Re: Emulation program freeze