BASin news – bugs fixed, release 14d on the way

Well, I’ve not been working on the 2D game engine for a while now – BASin is taking all my time. Back on WOS Forums, a guy called Jimmy reported some rather interesting bugs, which I suppose I might as well discuss here. 

The biggest problem is the Watches – a small part of BASin’s debugging suite. Basically, a Watch is a piece of information that is updated as a program runs. BASin supports a few types of these – you can watch variables, sysvars, memory addresses and the one that caused all the problems… The expression watch.

Expression watches are a small expression in Sinclair BASIC, such as “a+b*2”, which are passed to a dummy emulation to be evaluated as if the Spectrum itself were doing it. As such, they can take quite a while to get an answer from, but they’re generally pretty quick.

The problem was that Jimmy had written a small program which called USR 7962 – a valid expression which executed a small stub of code which upon return left the amount of used memory in BC, which was then passed back to BASIC. You can try it – type in PRINT 65536-USR 7962 to get a view of the number of available memory bytes. This worked fine in a BASIC program in BASin.

It didn’t work fine in an evaluated expression, such as a Watch. Finding out why was something of a pain!

In order to evaluate an expression, a copy of the current memory is made, and the expression POKEd into memory at E_LINE. The sysvar CH_ADD is set up to point to it, SP is set to 65534, with a value of $FFFF poked in, and then emulation is started from SCANNING in the ROM. The idea being that when SCANNING performs its final RET, it will loop back round to address 0, which is trapped and then the result extracted from memory and served up to the user. There are two passes – one with SYNTAX set in the FLAGS, to test for errors, and then one more pass to actually perform the evaluation.

The test that Jimmy had made utilised an unbalanced GOSUB system, such as:

10 GO SUB 20

20 GO TO 10

Which would, in theory (and indeed, in practice) allow the GO SUB stack to grow unchecked. The USR 7926 call would then report the dwindling amount of memory as the program runs. In the Watch, though, the USR 7962 result never changed. After much head-scratching, I decided that it must be because when the expression is POKEd in, STKEND isn’t updated properly. 


As it turns out, SP is subtracted to find the end of usable memory. My routine sets SP to 65535… With that fixed, the result at least looks ok. 

Until someone else comes along, reporting that another expression fails. This is because it’s expecting there to be some 5-byte suffixes attached to numbers in the expression. No problem – I add those before the expression is tokenised, and away we go – all fixed!

Only now, USR 7962 doesn’t work anymore, and gives “illegal evaluation” and “Expression timed out” errors. 

After much more head scratching, it turns out that the USR function (and indeed, any function that calls FP-TO-BC) doesn’t want the 5-byte suffixes. So how do I get them all to work together? After a lot more head scratching, it turns out that the only time you should add the 5-bytes is after you’ve syntax checked… 

And now it all works fine. I’ve even managed to massively speed up evaluation, too! The new maintenance release of BASin will be along shortly – I’m adding some new stuff (like MIDI emulation for the PLAY command) and then I’ll release. All the bugs that have been reported so far are fixed.


Here’s a list of stuff I’ve fixed so far:

Fixed – The debugger’s flow control buttons (run, step etc) will also resume from a BASIC breakpoint now.

Fixed – The debugger’s program flow buttons would not properly reflect the state the emulation was in, and so wouldn’t single step or run from a breakpoint. (Jimmy)

Fixed – BASin can no longer be made to emulate a +2 by paging the editor ROM in inappropriately. (Jimmy)

Fixed – Some evaluations (like USR 7962, the “free RAM” routine), would time out or give “Illegal expression”. Lesson for today: “Don’t fuck with the stack pointer”. (Jimmy)

Fixed – keywords that follow other keywords (THEN GO TO etc) would not tokenise properly if there’s a space in the 2nd keyword – GO TO, GO SUB, DEF FN etc. (Ref)

Fixed – You can now save your SCREEN$ as .scr files from the paintbox. (ZXBruno)

Fixed – OVER 1 mode in the paintbox appeared twiced on the menu.(ZXBruno)

Fixed – Expressions can no longer OUT in the z80 core, so a lot of USR xxxxx expressions no longer screw with BASin. (Jimmy)

Fixed – Expression evaluations timeout a lot sooner now – typically after one frame of opcodes, rather than 5 seconds of emulation. This speeds up Watches quite dramatically.

Fixed – Expression evaluations execute very much faster now that redundant code has been removed.

Fixed – The Token Table tool was showing the wrong number for the keywords.

Fixed – The editor will no longer lock up if you insert either a SPECTRUM or PLAY token into a string.

Fixed – The Token Table now updates itself if your program changes from a 128k to a 48k compatible program, and vice-versa.

Fixed – BIN numbers were being truncated by the first digit. (AOwen)

Fixed – Binary notation numbers after a $C4 (BIN Token) inside a string were getting an extra (and unnecessary) 5 byte float value inserted. (AOwen)

Fixed – The token table returned the wrong token for keywords.

Fixed – Crash when deleting a watch whilst the program is running. (Jimmy)

Fixed – OPEN # and CLOSE # weren’t tokenised properly. (Jimmy)

Fixed – The parser no longer accepts CAT EXP as valid BASIC – BASin does not yet support +3 BASIC. (Jimmy)

Fixed – Getting command help on words like PRINT would return instead the help for INT. This also affected the right-click context menu for commands and variables with similar names. (Jimmy)

Fixed – The SPECTRUM command will terminate your program with report 0, rather than actually dropping to the 48k editor, thus rendering the BASin editor useless. (Jimmy)

Fixed – Clicking “Okay” in the Binary files handler when no binary is selected would cause a crash, even though this is something you should be able to do. (BadBeard)



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: