What Editor is best to use ?

[mk79]

Oh, right, I didn't remember that QD could be LRESPRed. Funnily enough this is the exact same bug that I diagnosed only a week ago in another tool and even wrote a blog post about: https://www.kilgus.net/2018/08/08/qdos-to-lrespr-or-not/.
The mechanism to distinguish between EX and LRESPR basically relied on undefined behaviour which works everywhere by chance except on QemuLator (in depth: the IOF.LOAD trap specification says D1 is undefined on return. Basically all QL drivers return something in there, just QemuLator returns 0. But 0 is perfectly valid, so QemuLator is not to blame here).

I have uploaded a new version B.03 that fixes this problem, just re-download the ZIP.

Cheers, Marcel

[Derek_Stewart]

Hi Marcel,

QD is the best editor for the QL... It is probably the last software I have bought,

I usually HOT_LOAD QD from a hotkey or a Button.

[janbredenbeek]

Oh, right, I didn't remember that QD could be LRESPRed. Funnily enough this is the exact same bug that I diagnosed only a week ago in another tool and even wrote a blog post about: https://www.kilgus.net/2018/08/08/qdos-to-lrespr-or-not/.

I used to test D1 from SMS.INFO (see Multimon source) but in these days of MultiBASICs that's no longer enough .
But I'm curious if comparing A6 to the start of the job code will guarantee that your code is executing as a job. This might be true when you EXEC or HOT_LOAD a program (since this allocates space for both code and data and then loads and executes the code) but what about HOT_RES, which only allocates space for the data (apart from a small job header)? Then A6 will point to the start of the small job header, which contains a JMP into the code loaded earlier by HOT_RES. So the comparison will fail and the code continues into the SMS.INFO call which will return a nonzero D1, and the code ends with err.nimp and RTS (which probably causes a crash since there's no valid return address on the stack).

Anyone already tried this?

Jan.

[mk79]

But I'm curious if comparing A6 to the start of the job code will guarantee that your code is executing as a job. This might be true when you EXEC or HOT_LOAD a program (since this allocates space for both code and data and then loads and executes the code) but what about HOT_RES, which only allocates space for the data (apart from a small job header)?

God damn it, you are right. I have updated both QD and my blog post with a new method I came up

Thanks! Cheers, Marcel

[janbredenbeek]

But I'm curious if comparing A6 to the start of the job code will guarantee that your code is executing as a job. This might be true when you EXEC or HOT_LOAD a program (since this allocates space for both code and data and then loads and executes the code) but what about HOT_RES, which only allocates space for the data (apart from a small job header)?

God damn it, you are right. I have updated both QD and my blog post with a new method I came up

Very clever new test . It is very unlikely that bit 6 of (A6) will ever become set under S*BASIC even if you have 1GB of RAM, because it's the relative pointer of the start of SB's buffer which starts right after the system variables (hence you would need 1GB of SB's system variables for it to become set ). Be sure that the first instruction is BRA or JMP though...
The test for $4AFB at 6(A6) would only fail if SB's buffer reaches 18939 (19195-256) bytes in size which is again unlikely (but perhaps a bit more likely than SB's system variables reaching 1GB...).

Jan.

[mk79]

Very clever new test . It is very unlikely that bit 6 of (A6) will ever become set under S*BASIC even if you have 1GB of RAM, because it's the relative pointer of the start of SB's buffer which starts right after the system variables (hence you would need 1GB of SB's system variables for it to become set ).

In SBASIC the buffer is allocated from the common heap when it is resized and as A6 is low the relative pointer can get huge very quickly (yes, I did actually try it )

The test for $4AFB at 6(A6) would only fail if SB's buffer reaches 18939 (19195-256) bytes in size which is again unlikely (but perhaps a bit more likely than SB's system variables reaching 1GB...).

I did consider relying on this until I’ve seen that the bottom 16 bits can be pretty much arbitrary due to the buffer moving freely in memory. Still very unlikely, but too likely for my stomach

Marcel

[Andrew]

Hi Marcel

now when I load QD2018 (latest version, start from flp1_, using boot_english renamed as boot) Qemulator does not hangs, but I need to press Ctrl-C to get a prompt - and at second Ctrl-C QD shows up with with no icons!


If I execute again EXEP QD - then it shows ok, with all icons
If I boot without LRESPR QD_english and then start it with EXEC QD - it starts ok, with all icons

[mk79]

now when I load QD2018 (latest version, start from flp1_, using boot_english renamed as boot) Qemulator does not hangs, but I need to press Ctrl-C to get a prompt

OK, strange. This looks more like a problem with the pointer environment (the red X is used when a sprite is not available in the current colour mode), but I'm afraid I cannot reproduce it here, not with Minerva or JS rom. What version does it show when you right click on the help icon?

Cheers, Marcel

[Andrew]

OK, strange. This looks more like a problem with the pointer environment (the red X is used when a sprite is not available in the current colour mode), but I'm afraid I cannot reproduce it here, not with Minerva or JS rom. What version does it show when you right click on the help icon?

Cheers, Marcel

version B.04

Later edit: you are right, Marcel - it is a color mode problem.
The fix is to add line :

Code: Select all

5 Mode 4

in the boot file

When Qemulator starts in TV mode it starts in mode 8

[M68008]

When Qemulator starts in TV mode it starts in mode 8

That's what every QL does.


Btw, you may already have found this, but just in case: adding

Code: Select all

LRESPR macmouse11

just after loading PTR_GEN allows using the PC mouse. (MacMouse11 can be found in the Q-emuLator\QL Software directory).