The Sinclair QL Forum

tofro wrote: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.

I dont know whether theres an error in the documentation or just my setup (Qmac 1.06, the latest) but there is no default dataspace of 4k; any dataspace has to be specified. My calculation of 32b was for the number of user code bsr's, movem.l's, etc. (Presumably the trap code uses the supervisor stack.)

pjw wrote:

tofro wrote: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.

I dont know whether theres an error in the documentation or just my setup (Qmac 1.06, the latest) but there is no default dataspace of 4k; any dataspace has to be specified. My calculation of 32b was for the number of user code bsr's, movem.l's, etc. (Presumably the trap code uses the supervisor stack.)

The 4k default data space information comes from the original GST MAC documents. - It could well be the Quanta version changed this.
I typically use the GST linker (thus no "-nolink") and specify data space in the LINK file, so don't have experience with non-linked EXEs.

Tobias

Very useful info thanks.
Everything now appears to be solved. I'd just composed a long reply mentioning that the QMAC docs were wrong about the 4K and that I needed DATA and have just seen you've mentioned it in the interim. This reply is now considerably shorter.

I've just solved the Qmon problem. I'm using the version from https://www.kilgus.net/smsqe/qmon/. If, under Qemulator, I allow it to install via its boot file then it freezes when "qmon progname" is typed. However, if I manually install it via (e.g.) "lrespr flp1_qmon" then it doesn't subsequently freeze when invoked with a program name. The reason it worked on the real hardware is that I'd had to use lresp as my SGC clone system went into an infinite booting loop when it hit the boot file. That had slipped my mind.

I take solace from the fact that my original post mentioned the stack as a potential problem. Sometimes, when things don't work, you've just got to keep reminding yourself that no magic is involved except, of course, for that little wisp of magic smoke you see when the stack bumps into the RTS. It's usually the obvious things or nuances of an unfamiliar platform (or, in this case, both).

Thanks muchly for all the various suggestions & help. Now that's working I've got two debugging techniques available (printing and monitoring) rather then the zero I had before.

Alan