Advanced BASIC Editor PACK

[Michael Brown]

Hi All,

As you may be aware Football Manager was compacted/compressed using this tool as it needed to load at &1300 instead of &E00 to not only work from disc, but also be able to save files, so &1100 was no good, it had to be &1300 meaning &500 had to be chopped from the program to fit.
Before, TOP was higher which caused "NO ROOM AT LINE..." errors.
The compactor/compressor removed wasted space and shortened variables amongst other things to make TOP equal to what it should have been if the game had been loaded from tape, effectively stopping any "NO ROOM" errors.

There are several other games that have been transferred to disc that could benefit from this tool.

Below is a list of possible candidates.

Stolen Lamp
Johnny Reb
Testmatch Cricket
Pettigrews Diary
First Moves Chess
Confrontation
Special Ops
Redcoats
Identify Europe
Bridge Master
The Boss
Soccer Supremo
Oxbridge
and
Division One 85.

Some of these games seem to work ok to start, but sometimes error out later in play.

It will be trial and error.
I can confirm the first one I believe to now be running correctly is Division One.
I have been able to restore this game so that you can save your team to disc and reload it and I have managed to compact the main game so it runs at &1300 with TOP the same as if loading the tape.

A file called SG is saved which has all your players set up.
I will be adding the f0 option to set these players up as per Soccer Supremo once I have found or created some new instructions for the game.

In the meantime, if someone would like to playtest this game and let me know if there are any errors.
I have tried a few things and seems OK, but it may need longer/harder testing.

It would be great if all the above games could be made to work, but this will be a slow process as it has to be done right.

If OK, then Soccer Supremo will be the next to sort.
Mick.

DIVISIONONETEST.zip

(11.42 KiB) Downloaded 95 times

[lurkio]

Something to bear in mind when using the Pack routine in the PRES Advanced BASIC Editor ROMs is what Richard Russell pointed out about the introduction of resident integer variables -- you need to be aware that it might cause problems if the BASIC program being Packed uses CLEAR or RUN or CHAIN:

• viewtopic.php?f=54&t=18388&p=259555#p259555

[Michael Brown]

Thanks for that.
I will check each game as I compact them.

Strange, so Klingon%=123:CLEAR:P.Klingon% returns No such variable.
Yet K%=123:CLEAR:P.K% returns 123

again, thanks, I have made a note.

Mick.

[lurkio]

Strange, so Klingon%=123:CLEAR:P.Klingon% returns No such variable. Yet K%=123:CLEAR:P.K% returns 123

Yes, the values of the resident integer variables A%, B%, ..., Z%, and @% aren't changed by CLEAR or RUN or NEW or CHAIN or even by pressing Break or Ctrl-Break!

[daveejhitchins]

Something to bear in mind when using the Pack routine in the PRES Advanced BASIC Editor ROMs is what Richard Russell pointed out about the introduction of resident integer variables -- you need to be aware that it might cause problems if the BASIC program being Packed uses CLEAR or RUN or CHAIN:

• viewtopic.php?f=54&t=18388&p=259555#p259555

I actually use this feature in two way in the MGC MKII Menu:
(1) To pass variables through to the main Menu from the BOOT sequence.
(2) I use the resident integer variables for the most used variables to just gain that extra bit of speed - which has become a bit of an obsession with the MGCs Menu! Getting there . . .

Dave H

[lurkio]

I actually use this feature in two way in the MGC MKII Menu: (1) To pass variables through to the main Menu from the BOOT sequence. (2) I use the resident integer variables for the most used variables to just gain that extra bit of speed ...

Oh, sure, resident integer variables are really useful.

They're a potential problem only if the Pack routine in the PRES Advanced BASIC Editor uses them to replace regular "non-resident" integer vars and if you don't realise what the implications are!

E.g. if the program you're Packing relies on CLEAR to reset erase all integer vars, then you can't substitute res int vars for any of them because they won't be reset erased by the CLEAR.

[daveejhitchins]

I actually use this feature in two way in the MGC MKII Menu: (1) To pass variables through to the main Menu from the BOOT sequence. (2) I use the resident integer variables for the most used variables to just gain that extra bit of speed ...

Oh, sure, resident integer variables are really useful.

They're a potential problem only if the Pack routine in the PRES Advanced BASIC Editor uses them to replace regular "non-resident" integer vars and if you don't realise what the implications are!

E.g. if the program you're Packing relies on CLEAR to reset all integer vars, then you can't substitute res int vars for any of them because they won't be reset by the CLEAR.

Not too bad, though. As we know where they are stored a simple FOR NEXT loop could be used to clear them! But of course, as you say, you do need to be aware of them . . .

Dave H

[lurkio]

so Klingon%=123:CLEAR:P.Klingon% returns No such variable.

Yes, CLEAR seems to be resetting the VARTOP "pointer":

Code: Select all

10 GOSUB 80
20 Klingon%=5:PRINT"Klingon%=5"
30 GOSUB 80
40 CLEAR:PRINT"CLEAR"
50 GOSUB 80
60 PRINT"PRINT Klingon%":PRINT Klingon%
70 END
80 PRINT"LOMEM=&"STR$~LOMEM" VARTOP=&"STR$~(!2AND&FFFF):RETURN

Result of RUNning the program above:

Code: Select all

>RUN
LOMEM=&19A1 VARTOP=&19A1
Klingon%=5
LOMEM=&19A1 VARTOP=&19AF
CLEAR
LOMEM=&19A1 VARTOP=&19A1
PRINT Klingon%

No such variable at line 60
>_

[Rich Talbot-Watkins]

The only time this could be a problem, as far as I can tell, is in the case highlighted by Richard's example in the other thread, where you write:

Code: Select all

A=A+1

without having previously defined A.

While this is apparently valid BBC BASIC, I suspect the language wasn't designed with this in mind, and only works as a consequence of how variable assignment is implemented (creating a new variable before evaluating the right hand side). Any code which relies on this gets everything it deserves, in my slightly facetious opinion!

[lurkio]

The only time this could be a problem, as far as I can tell, is in the case highlighted by Richard's example in the other thread, where you write:

Code: Select all

A=A+1

without having previously defined A.

This isn’t directly related to CLEAR, but there is another scenario where careless use of PRES ABE’S Pack with resident int vars can bite you on the bum:

If Program1 sets V% to some value and later CHAINs Program2, and if you’ve used Pack on Program2 (but not on Program1), and, in Program2, Pack has substituted V% for some original var (say Vogon%), and if Program2 at some point CHAINs Program1 again... then you have a problem! V% will now be whatever Program2 set it to, instead of what Program1 set it to, which probably isn’t what the non-Packed Program1 was expecting!

[Deleted User 9295]

While this is apparently valid BBC BASIC, I suspect the language wasn't designed with this in mind, and only works as a consequence of how variable assignment is implemented

It certainly happens "as a consequence of how variable assignment is implemented" but I think you're doing Sophie an injustice by suggesting that it wasn't intentional. As I point out in the other thread the BBC specification called for a good degree of compatibility with Microsoft BASIC, in which that behaviour definitely is guaranteed.

[Rich Talbot-Watkins]

Yes, fair enough. I remember from MS BASIC on my old Oric-1 that variables were created on first use (along with the other MS quirks of only the first two characters being significant, and arrays being dimensioned by default to 10 elements!).

Still not really fond of the paradigm personally, but if people use it, it has to be taken into account when crunching, as you said.

[Deleted User 9295]

Still not really fond of the paradigm personally

In that case what alternative approach would you propose for creating a variable if it doesn't already exist, but not changing its value if it does? Again as I mention in the other thread, such functionality is useful in a cleanup routine, which may be run as the result of an asynchronous event such as pressing the Escape key.

[lurkio]

... the BBC specification ...

Incidentally, was the following method of determining the value of VARTOP part of any original specification?:

Code: Select all

DIM A% -1

(from beebwiki)

[Rich Talbot-Watkins]

In that case what alternative approach would you propose for creating a variable if it doesn't already exist, but not changing its value if it does? Again as I mention in the other thread, such functionality is useful in a cleanup routine, which may be run as the result of an asynchronous event such as pressing the Escape key.

I guess I don't really see why it's necessary at all - just initialise it to zero at the beginning! As far as I can tell, this would be functionally identical, and arguably clearer too.

[Deleted User 9295]

Incidentally, was the following method of determining the value of VARTOP part of any original specification?

Well, as I said there was never a specification of BBC BASIC with that sort of detail. Even the existence of a contiguous heap wasn't assumed, although I expect that was a popular memory management scheme of the day. But that code follows from the general format of the use of DIM to allocate memory of a certain size and return a pointer to it:

Code: Select all

      DIM mem% size%-1

Your example simply corresponds to setting size% to zero, i.e. 'return a pointer but allocate no memory'. The equivalent code for returning the bottom of the stack, without actually reserving any extra stack, is (in ARM BASIC V and later):

Code: Select all

      DIM stack% LOCAL -1

In my BASICs you can use this code (but only with the special case -1 parameter) anywhere, not just in a PROC/FN.

[Deleted User 9295]

I guess I don't really see why it's necessary at all - just initialise it to zero at the beginning!

A proponent of the 'information hiding' programming concept (which I very much am!) would not be keen on that.

[Rich Talbot-Watkins]

Yes, I'm also a big proponent of that, but I'm not sure if BASIC, in general, promotes that concept because it's not strictly scoped: a variable, once created, exists and is visible globally for evermore (unless hidden by an explicit more local scope, in BBC BASIC).

With global variables, if they must exist, I'd rather have them declared upfront so you can manage your expectations about the global state of a program. You could possibly say that one use of this paradigm is as a way of implementing C/C++ static local variables, i.e. a variable which remembers its value from one function call to the next. However, without strict scoping, it's not really the same, because, once declared, anyone else can access and modify it.

[Deleted User 9295]

Yes, I'm also a big proponent of that, but I'm not sure if BASIC, in general, promotes that concept because it's not strictly scoped: a variable, once created, exists and is visible globally for evermore (unless hidden by an explicit more local scope, in BBC BASIC).

Yes and no. That is indeed true of normal scalar variables, and arguably it's a weakness of BBC BASIC, but it's not true of arrays and (in the case of my BASICs) structures, which really do have local scope, or at least effectively so. For example consider the following program:

Code: Select all

      PROCtest
      PRINT scalar
      PRINT array(0)
      END

      DEF PROCtest
      LOCAL scalar, array()
      DIM array(5)
      scalar = 123
      array(0) = 456
      ENDPROC

which results in:

Code: Select all

         0
Bad use of array
>

I'm not making any grandiose claims for this, but I've always thought it to be an interesting feature (even if it's 'obvious' to anybody who understands BBC BASIC's internal workings).

With global variables, if they must exist, I'd rather have them declared upfront so you can manage your expectations about the global state of a program.

I do largely agree, but it can result in this kind of code:

Code: Select all

      Global = 0
      ON ERROR PROCcleanup : QUIT
      REM More initialisation
      Global = FNallocate

The Global variable is naturally declared and initialised near the beginning of the program, which is to me sufficient to satisfy the needs of "managing global state"; the additional initialisation to zero before the ON ERROR is solely a requirement of your dislike for the += construct and I'd rather it wasn't there.

Another issue that concerns me is that if you forget to include that 'extra' zero-initialisation an error may result in PROCcleanup, and generally I prefer to avoid the possibility of another error occurring in an error handler. Using += to force a variable to exist without changing its value may allow you to code a handler which cannot 'fail'.

You could possibly say that one use of this paradigm is as a way of implementing C/C++ static local variables

No need to in my BASICs, which have them anyway!

[Rich Talbot-Watkins]

I think it's fair to say that every language has its idioms, and BBC BASIC is no exception. I think you've sold the construct pretty well, and I can see how it's useful in those contexts. I haven't seen it used very much, and the last time I did was as a hack to allow a one line program to call itself recursively while still initialise itself on entry. That struck me as "dirty", and from there the aversion stuck!

I've been immersed in C++ development for so long now that it's hard to imagine structuring a program in a vastly different way, where ideally everything is strictly locally scoped as much as possible, and globals are reserved for very specific and special circumstances.

[Deleted User 9295]

it's hard to imagine structuring a program in a vastly different way, where ideally everything is strictly locally scoped as much as possible, and globals are reserved for very specific and special circumstances.

That's exactly how I try to code my BBC BASIC programs, there's nothing about the language (at least, not modern versions) that means you need to do anything different. Libraries are a particular case of when globals should be avoided, for a start it's difficult to ensure that the name of the global won't clash with another in the calling program or another library.

If I can't find an acceptable alternative to using a global I'll give it a name like GlobalName@LibraryName which with luck will be unique (I've not yet resorted to using a UUID), but I prefer to avoid globals altogether, for example by passing an opaque structure as a parameter or leveraging the PRIVATE statement (the equivalent in my BASICs to C's static).

[Michael Brown]

Here's Division One '85' with some instructions I have created.
This game will require play testing to make sure all aspects now work correctly after compacting.
From the playing I have done, it seems OK.

If it proves fine, then I will put it onto my Disc112 over the old edited version.

Mick.

DIVISIONONETEST.zip

(12.84 KiB) Downloaded 66 times

PS Soccer Supremo to follow soon!

[Michael Brown]

Ref Stolen Lamp. This can be removed from the list as it loads at &1200 from original tape so no need to compact.

Oxbridge doesn't compact enough to work so will have to be left as it is. Just means you can't save to disc.
Also Identify Europe won't benefit as machine code is loaded from &B00 upwards so can't work.
Lastly, Special Ops only loses a minimum of space so isn't worth doing.

The ones that do compact so far (and I will post here when I get chance) are...
Johnny Reb
Pettigrew's Diary
First Moves Chess
Confrontation
Redcoats
The Boss
and Soccer Supremo.

Mick.

[sweh]

Oxbridge doesn't comp[act enough to work so will have to be left as it is. Just means you can't save to disc.
Also Identify Europe won't benefit as machine code is loaded from &B00 upwards so can't work.

I wonder if it's worth creating an "0E00" series of disks for special cases like this? They may only work on machines with PAGE at 0E00 (e.g. MMFS SW and Master versions). That's what I did, BITD, for a handful of games.

[Michael Brown]

Hi Stephen,
Sounds good to me.

I am hopeful that using the PACK program that most of the problem games can be compacted correctly and then work on a basic BBC B with a DFS at &1100 and above.

I really want to get the games working as they would originally and do away with the need for DTRAP and also be able to save any score/position files to a blank disc.

Mick.

[Michael Brown]

One game that needed DTRAP was First Moves Chess.
This was due to the instruction section CH.IR3 needing to be downloaded to &E00 in order to show the instructions without getting a "no room at line..." error.
This new test disc features a compacted instruction file that now runs at &1100 with TOP being equal or less than the original tape file that ran at &E00.
This removes the need to reactivate the disc drive and so removes the need for DTRAP.
I have played it and it seems OK, but if anyone else would like to give it a go and let me know what you think.

regards,
Mick.

FirstMovesChessTEST.zip

(14.29 KiB) Downloaded 75 times

[Michael Brown]

The Boss could only save a game to tape as it needed to be run from &E00.

This new test disc features a compacted BOSS file that now runs at &1300 so you can save your score to disc.
I was unable to compact/remove exactly &500 of data to match TOP, but this version is fairly close (around &350 of space removed).

I have played it and it seems OK, but if anyone else would like to give it a go and let me know what you think.

regards,
Mick.

thebossTEST.zip

(8.85 KiB) Downloaded 69 times

[Michael Brown]

Johnny Reb was interesting as it ran from tape at &1200, but to save a file to disc it needs running at &1300 removing &100 from its REBEL12 file to avoid any possible "no room errors" as I am sure there was one.

This new test disc features a compacted game that now runs at &1300 so you can save your score to disc.
Only spaces were removed so everything else should be as it was.

I have played it and it seems OK, but if anyone else would like to give it a go and let me know what you think.

regards,
Mick.

JohnnyRebTEST.zip

(10.82 KiB) Downloaded 69 times

[Michael Brown]

Another game that needed DTRAP was Pettigrew's Diary.
This was due to each of the three chapters of the game needing to be downloaded to &E00 in order work without getting a "no room at line..." error.
This new test disc features compacted a CHAPTER1 and CHAPTER2 file that now both run at &1100 with TOP being equal or less than the original tape file that ran at &E00. CHAPTER3 is untouched and downloads to &E00 as no further disc loading is required.
This removes the need to reactivate the disc drive and so removes the need for DTRAP.
I have played it and it seems OK, but if anyone else would like to give it a go and let me know what you think.

regards,
Mick.

pettigrewTEST.zip

(27.41 KiB) Downloaded 69 times

PS passwords for the game (if you want to skip sections) are SOHO, VITE and ESCARGOT

[Michael Brown]

Soccer Supremo was interesting. The version I had was only able to load the "new season" data files at the start and then only play one per game.

This new test disc features a compacted game that now runs at &1300 so you can not only save your score (SG) to disc, but also play all the seasons in order as per original tape.
As a bonus, you can now also play the Euro Cups game (provided you have saved the SG file from the first game to a blank disc).

I have played both and they seem OK, but if anyone else would like to give them a go and let me know what you think.

regards,
Mick.

SoccerSupremoTest.zip

(14.68 KiB) Downloaded 68 times

SoccerSupremoEuroCupsTest.zip

(9.23 KiB) Downloaded 71 times

PS I have saved a SG file to the Euro Cups disc but you can use your own from the game if you want.