Strange BASIC XE behaviour using BLOAD

[TGB1718]

I saved a GR.8 screen to disk to save time redrawing it and tried using BLOAD to restore the screen.

However I found that using BLOAD in a program, terminates the program as soon as the file is loaded.

To test this I saved page 6 to disk and tried this.

 

20 Bload "D:TEMP.SAV"
30 Goto 30

The file loads and the program terminates,  never gets to line 30,

BSAVE works as expected. This behaviour doesn't seem to be documented.

 

I played for a while and have found a fix for anyone who may have tried and given up

 

10 Set 9,1:Trap 30
20 Bload "D:TEMP.SAV"
30 If Err(0)=32

45   Trap 40000
40   Goto 80
50 Else
60   Goto 90
70 Endif
80 Goto 80
90 Trap 40000: ? "ERROR ";Err(0)
100 End

 

The SET 9,1 generates a trappable error (32) on termination of BLOAD, so easy to detect and the program jumps to line 80.

If the error is something different (disk/file error), then that can be processed too.

[Rybags]

So does it fix the problem?

 

Possibly it expects an init or run address which wouldn't be present for a screen dump.

 

[TGB1718]

47 minutes ago, Rybags said:

So does it fix the problem?

 

Possibly it expects an init or run address which wouldn't be present for a screen dump.

Yes, that code fixes it, BLOAD doesn't use the run address, the manual says it just uses the load address

and ignores RUN and/or INIT vectors, there are no parameters with BLOAD

 

There is a way to use the RUN vector with one of the SET commands SET 8,0 which does not

push anything onto the stack like normal BASIC and then use A=USR(DPEEK($2E0))

[Alfred]

Looking at the cartridge source, it seems BLOAD was an afterthought because it's not implemented properly. As mentioned above, RUN/INIT addresses are ignored, although loaded. The XBL routine merely opens the file, checks for the $FFFF header and then just loads each segment. What the code doesn't do is handle the EOF case when it's looking for the next header. A true binary loader, if EOF is detected at this point would invoke the RUN address. Instead BASIC XE invokes IOTEST to examine the error and if it's not the BREAK key, it does nothing. XBL then sees the error and simply exits via ERRNSF which is "File not LOAD format", error code 21, which is wrong. My guess is XBL is called via the LOAD command to handle loading a BASIC program and it handles the EOF case. Someone then thought of it for loading binary files, but neglected to handle the EOF properly.

Edited October 23, 2022 by Alfred

[Mathy]

Hello guys

 

If somebody is going to fix the source code and recompile it, please have a look at the bank switching code too.

 

Sincerely

 

Mathy

 

Edited October 24, 2022 by Mathy

[Alfred]

13 minutes ago, Mathy said:

Hello guys

 

If somebody is going to fix the source code and recompile it, please have a look at the bank switching code too.

 

Sincerely

 

Mathy

 

Why, is there something wrong with it ? It's not bugged as far as I know.

[TGB1718]

9 hours ago, Alfred said:

Why, is there something wrong with it ? It's not bugged as far as I know.

It's not so much bugged as you have no control over the banks manually, BXE always resets PORTB

no matter what you try to set it to

[Alfred]

13 hours ago, TGB1718 said:

It's not so much bugged as you have no control over the banks manually, BXE always resets PORTB

no matter what you try to set it to

Ok, but I'm not really seeing the problem. I suppose it might be a problem in normal mode,  but in Extended mode I expect the code keeps jamming PortB because it needs to make sure the correct bank is enabled to process the current statement. Or are you talking about the case where say there are more than 4 banks, like a 256KXL or something, and you can't access all those other banks ?

[TGB1718]

11 hours ago, Alfred said:

Ok, but I'm not really seeing the problem. I suppose it might be a problem in normal mode,  but in Extended mode I expect the code keeps jamming PortB because it needs to make sure the correct bank is enabled to process the current statement. Or are you talking about the case where say there are more than 4 banks, like a 256KXL or something, and you can't access all those other banks ?

No, just normal 130XE banks, like you I could understand in EXTEND mode, but normal mode you

should be able to access the banks if required, but PORTB always reads 243.

This simple test shows banking doesn't work in normal mode. I just POKE 1,2,3 or 4 into the

first byte of each bank and then read the byte back from each bank.

 

10 Pb=54017:Port=16384
20 Bank0=225:Bank1=229:Bank2=233:Bank3=2
37:Normal=253
30 Poke Port,Normal
40 Poke Pb,Bank0:Poke Port,1
50 Poke Pb,Bank1:Poke Port,2
60 Poke Pb,Bank2:Poke Port,3
70 Poke Pb,Bank3:Poke Port,4
80 Poke Pb,Normal:? Peek(Port)
90 Poke Pb,Bank0:? Peek(Port)
100 Poke Pb,Bank1:? Peek(Port)
110 Poke Pb,Bank2:? Peek(Port)
120 Poke Pb,Bank3:? Peek(Port)
130 Poke Pb,Normal

 

The output:-

RUN
4
4
4
4
4

Ready

 

Because Bank switching hasn't worked, it's poking the numbers into normal RAM, so when you read back

all you get is the last number "Poked" which was 4 that didn't go to banked RAM, just overwrote

the last value in normal RAM.

 

Obviously if you can't access 130XE RAM banks, you also can't access any RAM bank switched by PORTB

Edited October 25, 2022 by TGB1718

[Alfred]

I expect the answer is the cart is not differentiating between Extended and Normal and just sets PortB in case it’s in Extended mode, thereby saving some bytes by not testing some flag.

[Mathy]

Hello guys

 

BASIC XE crashes after I enter EXTEND.

 

Sincerely

 

Mathy

 

[Alfred]

4 hours ago, Mathy said:

Hello guys

 

BASIC XE crashes after I enter EXTEND.

 

Sincerely

 

Mathy

 

Must be a bad cart file, I'm not aware of any issues with Extend in either 4.1 or 4.2

[Mathy]

Hello Albert

 

51 minutes ago, Alfred said:

Must be a bad cart file, I'm not aware of any issues with Extend in either 4.1 or 4.2

 

Or it somehow screws with PORTB.

 

Sincerely

 

Mathy

 

[TGB1718]

9 hours ago, Mathy said:

Or it somehow screws with PORTB.

 

Sincerely

 

Mathy

EXTEND takes complete control of the banking system as it moves all your BASIC code into extended memory,

so understandable you couldn't use any banking commands, but just calling the EXTEND command shouldn't

cause any crashes, as suggested, maybe a bad cart or extend module.

[Alfred]

It occurs to me that the same reasoning could apply to portb in normal mode: it keeps stuffing portb to make sure the statement bank is always present.