My listing is eating itself...?

[TMD2003]

(Text link for those who can't see the image: http://www.rickdangerous.co.uk/zx/ql/qltrouble.png)

This listing is one of the not-so-secret bits from a QL program I'm almost finished with, and at the moment it stands at 22K of SuperBASIC. So, all things considered, it's not exactly filling up the QL's memory. I'm loading the program into QemuLator, with the JS ROM, and I've tried Toolkit II both on and off. I'm editing on Notepad++, with the file held on an ancient 128MB flash drive, which is vastly larger than I'll ever need for simple text files, formatted in FAT.

Most of the time, lrun_program_bas will get the program to run - but not every time. Sometimes, it stops with this "bad line" error right from the start. Other time, it will run just fine - but when I break into it to alter a line or test a procedure, once again it won't start. And the corruption you see above isn't always obvious; sometimes I'll get the "At 9680 bad line" error, and on listing the program in the 9600s, it'll look fine - the same with a couple of window-definition procedures I've put at 10000 and 11000. Also, the line 999 STOP sometimes shows this corruption, and sometimes it doesn't, as well as line 1030 which is just a variable. It always seems to be the same lines that are corrupted.

I've saved an extra version of the program from Notepad++ as a new, clean text file (then made it LF-only), loaded that and it's still corrupting.

I've saved another version of the text file on the hard drive instead of the USB flash drive, and it's still corrupting.

I've then trimmed a copy of that down to a few of the procedures (so I can get one right), and it's still corrupting.

At this stage, I am out of ideas as to what could be causing the trouble.

What happen? Someone set up QL listing the bomb, by the looks of things.

[Martin_Head]

Are you loading any SuperBASIC extensions, or other machine code stuff. That's the kind problems you can get if the maths stack gets messed up.

What you can get, is like a time bomb. If the maths stack gets messed up, every thing seems OK for a while, then BANG, things fall over nowhere near the actual problem.

[TMD2003]

There's no machine code, that's for certain - and as for any extensions, I'm trying to get it working with Toolkit II, as that's QemuLator's default settings and I want to make it easy for total noobs - but the corruption happens whether I leave Toolkit II on or switch it off.

I suppose the next step is to see what QLAY does... but as the program involves sound I have to get that correct on QemuLator first.

EDIT: the plot thickens...

There is a solitary character from the QL's custom set, i.e. ä, which I know is CHR$ 128. This comes out as a euro symbol in the text editor. However, if I put the euro symbol in via the text editor, QemuLator will show it as three corrupted characters. I have to enter the ä in QemuLator, then save it to the simulated-microdrive, then copy that text across. The first thing I will do is remove that and use CHR$(128) instead.

However...

I typed PRINT CHR$(128) and it gave a "bad name" error. So I NEWed the program. PRINT CHR$(128)... "bad name", again. RUN, even with no program in memory... that's right, "bad name".

The only way I can get the program to run mostly-reliably is to stop the emulation, restart it and LRUN the program I'm editing in the text editor.

[dilwyn]

In addition to what Martin said about maths stack problems from machine code extensions, there are some pretty weird bugs in SuperBASIC which can lead to later problem on some ROM versions. I'd suggest you read Simon Goodwin and Mark Knight's articles from QL World and QL Today.
http://www.dilwyn.me.uk/docs/basic/index.html

Examples:
Trying to EDIT a line after breaking into a procedure (problem 14 in Simon's article)

Use of VER$ in certain circumstances seems to cause a corruption, e.g. The machine may crash if you try to test VER$ without copying it to a temporary variable first. T$=VER$: IF “JS”=T$ will work will but IF “JS”=VER$ stops the “JS” ROM in its tracks.

JS ROMs will not let you use a procedure parameter as a SELect variable unless it is the last one in the DEFinition, best to copy to a temporary variable first.

Some problems occur when you have too many LOCal variables on a line in a procedure or function (I think the limit on ROMs affected is about 9 local variables per procedure, one of the indications it's happened is spurious keywords starting to appear at the end of a program)


It is of course well worth copying the file to the screen (use COPY_N or VIEW commands to do this) to look for any signs of corruption in the file itself.

[TMD2003]

Some problems occur when you have too many LOCal variables on a line in a procedure or function (I think the limit on ROMs affected is about 9 local variables per procedure, one of the indications it's happened is spurious keywords starting to appear at the end of a program).

Spurious chequerboard characters have also started to appear in the listing. QLAY seems fine so far... but maybe, just maybe, it's my line with 18 local variables that's causing the problem! (xa,ya, where a=1 to 9).

I would never have guessed that.

Is if also possible that trying to READ those 18 variables all on one line is a problem?

[NormanDunbar]

Check Notepad++, I think it defaults to UTF8 (without a BOM) for the character set. The QL's single byte characters mostly match up, but some are multi-byte in UTF8 and will probably cause problems.

Try copying the file to SCR_ to see if anything pops out at you.

Also I think 9 local variables is fine, but more will corrupt.


Cheers,
Nor,.

[NormanDunbar]

However, if I put the euro symbol in via the text editor, QemuLator will show it as three corrupted characters]

That's UTF8.


Cheers,
Norm.

[dilwyn]

Sounds more likely that your editor is inserting extra bytes for non-ASCII characters - as Norman said, if the editor is set to UTF8/unicode character sets, it may be inserting more than one byte to represent a characters with a code of 128 or higher. But the QL doesn't do UTF8, so certain high character codes may be represented by the editor as 2, 3, or 4 bytes. So you might need a UTF8 to QL character set conversion routine or program.

Norman wrote an article on UTF8 in one of his assembly language eComics. I'm currently grappling with the subject with my QLirc software.

Don't know if the editor being used is set to UTF8 or whatever, so may be barking up the wrong tree here.

As you said, your best bet is not to use any of the extended character set (codes >127) directly, but use CHR$(n) instead. One less possible source of problems to worry about.

[stevepoole]

Hi,

Have you tried entering 'EXTRAS' when you first load the program ? This will list all the elements in the name table....

I see your name table is currupt when you call 'INK', (just before 'STRIP' & 'PAPER' ...

Either you have redefined the word 'ink', or have an illegal INK parameter ?


Or, try dividing your LOCAL statements over as many seperate lines of nine, as required.

Perhaps this will help .

Steve.

[NormanDunbar]

Norman wrote an article on UTF8 in one of his assembly language eComics.

That would be Issue 7. Grab the pdf and code files from https://github.com/NormanDunbar/QLAssem ... ses/latest.


Cheers,
Norm.