cant run files using qubide

[Martin_Head]

Just a thought?

What about the old RESPR problem of not working after any jobs have been started. Does qubide or the sd card adaptor have any jobs running? Or did that problem get fixed in Minerva, like SMSQE?

Martin Head

[tofro]

No, none of that. The QL says "out of memory", not "in use" as it would if jobs were running.

It is also apparently not the good, old "dataspace lost" problem, as the program Vincent is trying to run is not an executable job, but code that is RESPR-LOADed and CALLed, thus does not need any data space. (Although I agree the problem and solution cannot be mentioned often enough No, that solution does not help here )

The reason the RESPR command is not working is:

The BOOT finds out RAMTOP from the system variables, thus the amount of installed memory and basically the RESPR command tries to get all but some of it. The "but some" is based on an otherwise empty QL with maybe some headroom for a floppy based system (for buffer and map) with no other extensions loaded (This was done in copy-protected programs to make sure there's no debugger or somesuch loaded) This does not take into account that there might already be other allocations, like QubIDE buffers & maps (which is much more as the marginal headroom provided for a floppy) and RESPRed memory like for TK2 - and thus RESPR fails.

My proposal was to look at the amount of still free memory from the system variables and get all but some of that. That should work, but may obviously end up at some other base address. In case the code loaded is written position independent, as it should, that should work.

If it still doesn't work, the "- 200000" bytes headroom (which is not so much as it looks, as it is based on addresses, not number of bytes and thus includes ROM, screen memory and system variables) that is part of the RESPR memory allocation should be increased, maybe doubled for starters.

Regards,
Tobias

[gillvm]

No, none of that. The QL says "out of memory", not "in use" as it would if jobs were running.

It is also apparently not the good, old "dataspace lost" problem, as the program Vincent is trying to run is not an executable job, but code that is RESPR-LOADed and CALLed, thus does not need any data space. (Although I agree the problem and solution cannot be mentioned often enough No, that solution does not help here )

The reason the RESPR command is not working is:

The BOOT finds out RAMTOP from the system variables, thus the amount of installed memory and basically the RESPR command tries to get all but some of it. The "but some" is based on an otherwise empty QL with maybe some headroom for a floppy based system (for buffer and map) with no other extensions loaded (This was done in copy-protected programs to make sure there's no debugger or somesuch loaded) This does not take into account that there might already be other allocations, like QubIDE buffers & maps (which is much more as the marginal headroom provided for a floppy) and RESPRed memory like for TK2 - and thus RESPR fails.

My proposal was to look at the amount of still free memory from the system variables and get all but some of that. That should work, but may obviously end up at some other base address. In case the code loaded is written position independent, as it should, that should work.

If it still doesn't work, the "- 200000" bytes headroom (which is not so much as it looks, as it is based on addresses, not number of bytes and thus includes ROM, screen memory and system variables) that is part of the RESPR memory allocation should be increased, maybe doubled for starters.

Regards,
Tobias

Hi Tobias,
An update, I have got most of my other apps working now by editing the boot file and in most cases its been a case of updating the flp with win and all seems to work fime. However the spook app still refuses to work. I've tried various values as suggested and the best I can do is a blank screen with no errors. I did find the value requested before and posted as a reply, but not sure if you saw this. Your help would be most appreciated to get this app working finally.(btw the boot file already contains the respr command with that value)
Many thanks
Vincent

[RWAP]

The problem with SPOOK is that it needs 128K RAM to work - you will struggle unless you start Minerva with SHIFT F2 (or similar) which starts it in 128K mode.

[Derek_Stewart]

The problem with SPOOK is that it needs 128K RAM to work - you will struggle unless you start Minerva with SHIFT F2 (or similar) which starts it in 128K mode.

Hi,

I used QEMulator, set the ram to 128K, speed Original QL.

The game, Spook or Pacman... now runs OK.

If QEMulator speed is set at Full of Gold card, the game is too fast.

I wonder if the code can be disassembled and made to run as normal QL job, running under any QL environment. But this would be harder than converting old basic programmes to run under SMSQ/E.

I will have think about this over a mince pie and glass of wine...

[gillvm]

No, none of that. The QL says "out of memory", not "in use" as it would if jobs were running.

It is also apparently not the good, old "dataspace lost" problem, as the program Vincent is trying to run is not an executable job, but code that is RESPR-LOADed and CALLed, thus does not need any data space. (Although I agree the problem and solution cannot be mentioned often enough No, that solution does not help here )

The reason the RESPR command is not working is:

The BOOT finds out RAMTOP from the system variables, thus the amount of installed memory and basically the RESPR command tries to get all but some of it. The "but some" is based on an otherwise empty QL with maybe some headroom for a floppy based system (for buffer and map) with no other extensions loaded (This was done in copy-protected programs to make sure there's no debugger or somesuch loaded) This does not take into account that there might already be other allocations, like QubIDE buffers & maps (which is much more as the marginal headroom provided for a floppy) and RESPRed memory like for TK2 - and thus RESPR fails.

My proposal was to look at the amount of still free memory from the system variables and get all but some of that. That should work, but may obviously end up at some other base address. In case the code loaded is written position independent, as it should, that should work.

If it still doesn't work, the "- 200000" bytes headroom (which is not so much as it looks, as it is based on addresses, not number of bytes and thus includes ROM, screen memory and system variables) that is part of the RESPR memory allocation should be increased, maybe doubled for starters.

Regards,
Tobias

Hi Tobias,
An update, I have got most of my other apps working now by editing the boot file and in most cases its been a case of updating the flp with win and all seems to work fime. However the spook app still refuses to work. I've tried various values as suggested and the best I can do is a blank screen with no errors. I did find the value requested before and posted as a reply, but not sure if you saw this. Your help would be most appreciated to get this app working finally.(btw the boot file already contains the respr command with that value)
Many thanks
Vincent

Ok,
I have now got the Spook program to load up by adjusting the RESPR value in the boot file from 200000 to 350000. I get sound and the keys work but the picture is scrambled.
Any suggestions?

Ho Ho Ho and Merry Christmas to all!

[Derek_Stewart]

Hi,

I not tried this on a real QL, but I can only get the program to work in Qemulator with 128K of ram and running at Original QL speed. Other speeds may the game unplayable.

Looking at the BOOT program a little closer, the variable D find the Ramtop of the memory, which I got to be 200000

So I replaced the calculated value of E with an absolute value of 62144, which is 262144 - D

So the line for E reads:

E = RESPR (62144)

The game only worked correctly in a 128K environment in Qemulator.

On real QL with more than 128K ram, you will have to use Shift F2/F3 on the Minerva start up screen, If not using Minerva then a memory cut routine is required, but I am not sure if a reliable routine fo JS, JM etc... is available.

The game does not rn in SMSQ/E... which is not unsurprising.

The reasons for this is that the game was written when only 128K QL computers were available and memory expansions were very expensive.

To run correctly on all QL platforms, the assembler code may need some modification.

[tofro]

To run correctly on all QL platforms, the assembler code may need some modification.

I had a quick look with a disassembler - That game has apparently not been written in assembler, but rather in some sort of threaded code (Forth, maybe?) which I reasonably can't be bothered with....

I seem to recall that some of the QL Forth dialects had some sort of de-compiler. Maybe someone with a greater affinity to that language wants to give it a try?

Tobias

[Luk]

Hi, my Spook runs fine on QL expandend with Q-Disk +256K.
Also tried it on Q-emulator 356K and works allright.

Enclosed the boot program, hope this helps?
(or the game is another version? i know ik had it on MD once, but is it this version?...forgotten...)

Code: Select all

5 MODE 8
6 OPEN#3,scr_512x256a0x0:PAPER#3,0:CLS#3
100 D=PEEK_L(163872)
110 E=RESPR(D-200000)
120 LBYTES flp1_CDS,E
130 LBYTES flp1_CD,E+6002
140 PAUSE 200
150 CALL E+6002

[Derek_Stewart]

Hi,

I have the SPOOK programmes stored in a QXL.WIN file on WIN1_ and altering the device in the boot file to WIN1_ the game works up to 896K on Qemulator. Which means it will run on a Trump Card.

I will try this on a real QL and report back.