Turbo TK

[pjw]

Can someone riddle me this:

Turbo toolkit comes in various versions, including one specifically for SMSQ/E which, among other things, leaves out some duplicates, such as PEEK$ etc for the benefit of the more versatile SMSQ/E implementations. However, more recently SMSQ/E has had PEEK_F and POKE_F added, and these are still present in Turbo TK which overwrites the better SMSQ/E ones.

No big deal, one might think, just rename the Turbo ones to something else, like PEEK_X, POKE_X. However, if I do that then the turbo parser_task no longer works: It seems to need Turbo TK's variant of PEEK_F and/or POKE_F.

I cant see why this should be. At the most basic level these commands are identical: <float> = PEEK_F(<addr>), POKE_F <addr>, <float> are, and work, exactly the same. Clearly something else is going on, but what? And can it be fixed?

[Martin_Head]

I don't know if this is of any help.

In my decompiler notes, I note that some of the Turbo toolkit commands are handled internally by the compiled program.
So instead of calling the loaded SuperBASIC command, it uses a built in routine.

My notes show PEEK$ and POKE$ being like this. But not PEEK_F. I don't seem to have POKE_F in my notes.

I can't remember off hand how I decided which commands were handled internally, or externally. It may have been trial and error.

Maybe during compiling, if it finds an externally handled Turbo toolkit command, like PEEK_F. It checks that command has actually been loaded, rather than a built in one. In case the Turbo toolkit command is overwriting a built in command.
If it's internally handled, it doesn't bother checking

[pjw]

Thanks for your input, Martin. Ive now taken a closer look:
Its PEEK_F Turbo's parser doesnt like, specifically SMSQ/E's PEEK_F! If I load my own ancient version of PEEK_F over SMSQ/E's all's fine. SMSQ/E's PEEK_F does some extra tests: "; 2005-12-29 2.02 Ensures that PEEK_F only returns valid floats (MK)". Could this have something to do with it?

[pjw]

<>
SMSQ/E's PEEK_F does some extra tests: "; 2005-12-29 2.02 Ensures that PEEK_F only returns valid floats (MK)". Could this have something to do with it?

Yup, thats the one that does it! For some reason parser_task PEEK_Fs some location that returns a float with an exponent of $F000 which apparently is not a legal float. Turbo ignores it by simply correcting it. I dont see how to fix it without fixing parser task or breaking a proper PEEK_F.

[pjw]

I figured it out and made a provisional fix. You can now have your cake and eat it: Keep SMSQ/E's enhanced PEEK_F and POKE_F and still be able to compile with Turbo!
Attached is a package with the patches you need. This is mainly for SMSQ/E users. Qdos users need only bother if they also happen to use my PEEK & POKE toolkit which implements all SMSQ/E's enhanced PEEK/POKE commands.

[pjw]

Duh! Turns out I wasnt up to date with Turbo: Version 5.09 seems to be the latest, not 4.20. However, the same conditions apply, so get your fix here! (Apologies to those who downloaded the previous version in vain. ) After a while, if there are no complaints and no further developments, I'll ask Dilwyn nicely if he'll put it up on his site.

[Derek_Stewart]

Hi Per,

Are you able to compile Turbo Toolkit?

I have some old backups from the Q60 days which I was given an early version of Turbo Toolkit source to test compile on the Q60.

Unfortunately, I will have use a Q60 to access the hard drives, so might take a while to repair 2 boards I have...

[pjw]

Hi Per,

Are you able to compile Turbo Toolkit?
<>

Not yet, Derek. First Ive got to find the time to read the manual. It doesnt seem to work without But even then it might not be straightforward as Id have to figure out what can safely be taken out. The Turbo TK code is a bit of a mess as the original source code is MIA, so it is based on partially disassembled code patched and added to by different authors over many years! Some people might enjoy that kind of thing.. Any takers?

[ones' complement]

Is it worth the trubo ?

[pjw]

Is it worth the trubo ?

Surely no trouble can be too small for someone who still keeps their microdrives ticking over