Thanks, Martin.

I'm not sure I know exactly how IRQs and stuff work, so I'll do some reading around tonight and see if I can get a grip on what you're talking about.

Before I bother Tom with another disc image, I'll see if I can convert the pseudocode I wrote above to reset the any of the remaining Plus 1 values that aren't being used for level data, into assembler and append it to Rich's code. It probably won't affect the K glitch, but I think it best to complete the routine as I envisaged before hassling him again.

I did forget to try last night the K-Glitch image with the single-level-relocate routine with the original levelset to see if that makes any difference (the other image without the single-level-relocate routine uses the standard levels). At the moment the K-Glitch image has a line 30 which patches over the original level data with new levels (to test Rich's routine). This means that that part of the Plus 1's workspace does end up looking like (starting at &0D68):

20 13 02 02 12 04 11 17

instead of:

20 12 0c 18 0f 17 0b 01

as it does in the unglitched image without the single-level-relocate routine, as that uses the original level data. It's /possible/ that one of those other values is important and somehow causing the glitch. The extra bit of pseudocode I want to add in should reset as many of them back to their default values as I can manage (including the &BB value at &0D69 you refer to, which is always trampled over atm with different values depending on the level data), so it's possible it might have an effect.

If I get time, I'll also try rewriting the reverse-engineered joystick patch to be more legible as Rich has explained to me some of the wonders of two-pass assembly, that I didn't have a working knowledge of when I did the original disassembly (though I've handed out the original source code to Tom and Rich so that's not too big of an issue).

Sam.

Ah-hah!

When I use the original levels, the K glitch disappears!

Overwriting &06D8 - &06DF with the correct Plus 1 values fixes the glitch ... so my hunch paid off.

This means I only need to convert the pseudocode I posted above into assembler to complete the routine.

Finally! Something is finally doing what it's supposed to ... !

That still leaves the ADFS issue which I'm stumped on and, Martin, there's now your recent issue running this version on your work beeb. I'll try to finish this version off and send it over so you can try it again ... and maybe also on your unmodified beeb.

Sam.

Sorry... Bit late and some of this is way over my head.....

For my level storage which can varry in size I've made a pointer table and just index that to find the correct starting location for the level data.....

The assembler takes care of the rest....

LEVELDHI .byte >Level01,>Level02,>Level03,>Level04, etc etc...
LEVELDLO .byte <Level01,<Level02,<Level03,<Level04, etc etc....

Level01 .byte xx, xx, xx, xx, etc, $FF(end)
Level02 .byte xx, xx, xx, xx, xx, xx, xx, etc, $FF(end)

You could also have a Size table, by doing a bit of subtraction.....

If the data was less than 256 bytes for each you could do..... ( I think)

LevelSize .byte Level02-Level01, Level03-Level02, etc, etc.....

I don't need to worry about sizes of data as I'm only parsing them and use $FF as the Terminator byte, and not copying....

Regards, Colin

@ColinD, you and me both.

Rich is a long-suffering code guru, who has put up with my feeble CE hacking attempts many times over the years. It's his own fault for writing such a cracking extra colours patch five years ago ... which I've been building on like a house of cards ever since!

Your method looks good, but I have to resort to hacking on what's there. As Rich says, ideally one day someone will take the disassemblies we have of the game and take the next step to create a modern assembler source file which can be modified at will. Until then, my mission is to hack away on the original and bring it as many new features as possible. Unfortunately, the game was never designed with joystick support in mind, so inadvertantly causes problems on the Electron by overwriting the workspace used by the Plus 1 to provide joystick functionality. Hence, my attempts to move things out of the way.

OK,

So here's what I've come up with. Hopefully Rich and/or Martin can sanity check this for me.

This is my pseudocode ...



Which is meant to say: if the start address of the level /above/ the one we've moved out of the way, is above each value of the rest of the plus 1's workspace that I'm interested in (&0D68-&0D6F), then reset that value. If the next level starts on top of one of those values, then leave them as they are.

So I've come up with the following assembler. Does it look anywhere close?

And, judging from the size of this routine, is there any neater way of doing it that I'm missing?

Hmmm ... hang on ... I've just compared this routine with the test in Rich's original routine, and it seems identical ... so maybe mine isn't doing greater than (>) like it should. Maybe it's doing <= like Rich's ... errr ...

Sam.

Hmm ..

Should it look like:



?

Specifically, I'm not sure if that's correctly doing a greater than (> &0D69) comparison ...

Sam.

No, using ADC isn't what you want to do. I won't create confusion by sticking my oar into the actual code since Rich will probably add/alter what's needed but just to help you understand a little better...

In the first code, Rich was effectively performing a 16 bit comparison of the pointer addresses and the target address to determine a less than or equal to condition. I say 'effectively' because he uses CMP for the ls bytes and SBC for the ms bytes. CMP is actually an odd instruction in that it does internally do an [A-data] instruction but non-destructively such that only the flags are set as a result. Here, he uses CMP to set/reset the Carry flag for subsequent use in the following SBC. The advantage of using CMP for comparisons is that the initial state of the Carry flag doesn't matter because it will be explicitly set to a 1 or a 0 depending on the result of the CMP and will not be influenced by the entry state of Carry. He then uses SBC which performs a destructive [A-data] and this is affected by the entry state of the carry flag brought forward from the CMP. (The code actually looks odd at first sight becasue a CMP is almost always followed by a branch instruction.)

Therefore (easy for me to say), a test for 'greater than' as opposed to 'less than' or 'equal to' is defined by approriate branching on the state of the C & Z (zero) flags following CMP and/or SBC. Simplistically then, you might use the same sequence to perform the comparison but replacing BCC with BCS can invert the logical outcome. (Simplistically because you may also need to invoke an additional branch condition or conditions such as BEQ, BPL or BMI to cater for the specific outcome requirement.)

Thus, your changing the SBC to ADC (add with carry) wouldn't achieve what you're after.

Thanks, Martin.

Shortly after posting that, I did some more googling around and found this article, 6502.org Tutorials: Compare Instructions - Beyond 8-bit Unsigned Comparisons by Bruce Clark, which showed me that ADC isn't at all what I wanted. Duh. I also took a look through some of the books on assembly language linked from the assembly language section of the RS Useful Docs page. Problem was, I couldn't get my head around exactly what I did need for a greater than comparison, so didn't post a follow-up.

From what you've just said, and a helpful note I've had from Rich, does this line of pseudocode:


where pointerstable looks like:


look like it translates into this:


And does it work without modifying X (which will be needed again for the next comparisons in the chain)?

Sam.

P.S. I'm aware that this falls over if X is 8, i.e. the last level, but that's so unlikely to happen in the real world that I'm burying my head in the sand and ignoring that case to save bothering anyone else with it.

OK, so who spotted the deliberate errors?


I needed to put in the full 16-bit constant value, for the MOD and DIVs to work. Duh! And I also had to add one to that value in order to make it > than and not >=.

For completeness, I figured this out with the help of the program I wrote included below.

Patch as I originally designed, is now complete. I'll bung you a disc image and maybe you can do a little bit of testing with it, Martin. This is a paired down version of what will go in the final product ... from my testing, the only thing that I know it doesn't work with, which I consider an issue (but is probably out of my capabilities to fix) is ADFS on the Electron.

Would be nice if you could test it on a beeb that has DFS and ADFS fitted. I can't imagine why it would conflict with that, but just for completeness.

I also discovered why you had an issue with one of the previous builds on your beeb, Martin ... and it was entirely your own fault. Only kidding ... but for some reason, it turns out I can't drop PAGE down to &1100 on a Beeb with DFS. Not even &1200. Based on trial and error, it looks like &1300 is the magic number. Don't know why that is, as I'm not doing anything but reading from disc ... and makes me a bit concerned that not everything is going to fit together in one patch anymore.

Got a lot of work ahead of me to find out, tho ...

Sam.

Stop the clock! Hey, I just re-tested and it looks like now the ADFS issue is fixed too.

Perhaps it was something to do with the Plus 1 being overwritten, but it all seems to work fine now.

Hurrah! God bless us, every one!

Do your worst with it, Martin, when the fuss at your end dies down and let me know if you find any incompatibilities with any of the common BBC/Electron hardware ...

Sam.

Managed a quick play last night and everything held together ok on an Elk and my development Beeb, both under DFS.

Well done that man...

This problem can be caused by a disc that uses an exec !BOOT file (*OPT 4,3). Pages &1100 and &1200 are used as workspace to open and read the contents of the boot file and would get trampled on when a program is loaded at the lower PAGE address.

Say the program you want to run is called CE, your !BOOT file will look something like this:

*BASIC
PAGE=&1100
CHAIN"CE"

This will fail because at the time of loading CE, the !BOOT file is still open so the program will overwrite the DFS workspace.

If !BOOT is changed to the following, it will work:

*BASIC
*KEY 0 PAGE=&1100|MCHAIN"CE"|M
*FX138,0,128

This sets up a function key definition and puts the key F0 into the keyboard buffer. The commands won't actually be run until after the !BOOT file has closed and control is returned back to BASIC. At that time it's safe to overwrite the DFS workspace because it's no longer in use.

Another alternative is to CHAIN a stub program from your !BOOT file:

!Boot:


Loader:


The *FX 119 forcibly closes all *EXEC / *SPOOL files in case for some reason there are more characters pending in the !Boot file.

BTW Sam - great work! Glad you managed to get it all working well in the end

Excellent news. Though Rich of course gets the most credit, as he wrote the most important 90% of the routine. I even managed to screw up compiling it, first time round.


Paul, that sounds /exactly/ like what's going wrong. I had some vague ideas along those lines, but didn't have time to formulate my thoughts into an actual question worth posting, as I was too busy finishing off the rest of this patch last night. Sounds like you're way ahead of me, tho ... I'll give it a go tonight, and I reckon your suggestion should sort it out - I'm pretty sure everything worked fine, if I just skipped the !BOOT part and ran the code directly. Down the line, those extra &200 bytes will /really/ come in handy too, I suspect.

Many thanks, that was very timely and useful advice!

Sam.

haha. I think everyone has got some brief time to spare over their lunch breaks. Replies coming thick and fast, now.


Good to know, Rich. In my case, I think I will try out Paul's approach first because I have a real problem with the number of files that are on the disc. I'm pretty sure I'm going to hit the 31 limit, and that's even with me combining several menus into one program. Can't afford the luxury of another file, I'm afraid!


Thanks to all you folk on the good ship, RS. I've still got a /lot/ of refactoring work to pull it all together.

I'm sure there's a more efficient way to write the bits of assembler that I wrote, but so long as it works and I can fit it all memory at the same time (which remains to be seen), it's good enough for me. Come to think of it, I'm sure someone with a bit more talent could probably have come up with a more reliable method of getting the joystick on the Electron working with any possible user-defined levels, where my method will fall-over with a small number of possible levelsets under certain conditions. But, then, that might head out of the loader patch territory and into the completely compile a new-enhanced version of the game, which I've been studiously avoiding.

With this patch, I was working on the make-it-good-enough-even-if-its-not-perfect mentality whilst trying-not-to-outstay-my-welcome-with-the-friendly-assembler-gurus who frequent this place, and this routine passes both my criteria ...

Sam.

No need for a separate program, just add it to the start of an existing menu..

10 IF PAGE>&1100 A%=119:CALL&FFF4:PAGE=&1100:CHAIN"SELF"
20 PRINT"Rest of menu"

And if you need to combine multiple menus, as long as they can all fit into memory at the same time, you can still do it..

Probably the wrong thread for this..

Thanks, Rob.

As it happens the !BOOT issue is only a problem for the test image I'm working on. The final disc image should work in a slightly different way. Interesting note about the multiple menus - I have seen that before, and looks handy. I've already got that bit written tho. I'll bear it mind, in case it comes up again in future.

Sam.

Just for completeness and to finish off this thread, I thought I'd post that I realised the assembler logic I appended to Rich's patch was overusing labels because it was too procedure-y.

I've saved some bytes by rewriting the logic so rather than jumping out to a separate routine, it is more linear and the branches simply skip ahead if the inverse condition is true. So the logic line looks like:


and the resultant code looks like:


Which saves me a bunch of extraneous labels and removes a load of JMP instructions too.

Sam.