Strange behaviour disabling tube in software when running from Econet

[SteveF]

Over in the PLASMA thread, shifters74 has discovered some interestingly inconsistent behaviour. I've created the attached test case to demonstrate this.

The source code (in beebasm format) is in the .zip file along with a .ssd but I'll inline it here for reference:

Code: Select all

tube = $027A
OSARGS = $FFDA
OSBYTE = $FFF4
OSWRCH = $FFEE
lptr = $AA
osbyte_read_high_order_address = $82

    org $2000
.start

.TubeOff
    TYA:BPL NOTTUBE              :\ Tube already disabled
    LDA #0:STA tube              :\ Clear Tube presence flag
    LDA &FFB7:STA lptr+0         :\ Point to default vectors
    LDA &FFB8:STA lptr+1
    LDY #&20
.TubeOffEvent
    LDA (lptr),Y:STA &200,Y      :\ Reset EVENTV
    INY:CPY #&22:BNE TubeOffEvent
    JSR ServiceInit              :\ Initialise ROMs
    JSR ReselectFS               :\ Reselect current filing system

.NOTTUBE
    LDA	#osbyte_read_high_order_address
    JSR	OSBYTE
    TYA
    JSR printhex
.HANG
    JMP HANG

.ReselectFS
    LDA #0:TAY:JSR OSARGS   :\ Get current filing system
    TAY:LDX #18:BNE Service :\ Reselect filing system
.ServiceInit
    LDX #&37
.Service
    LDA #143:JMP OSBYTE     :\ Issue service call

.printhex
    PHA
    LSR A
    LSR A
    LSR A
    LSR A
    JSR printhex4
    PLA
    AND #$F
.printhex4
    TAX
    LDA hexdigits,X
    JMP OSWRCH
.hexdigits
    equs "0123456789ABCDEF"
.end

save "TEST", start, end, $ff2000, $ff2000

The load/exec addresses on the code are set so it loads into the host. The code then disables the tube if present (using a version of JGH's code here) and finally calls OSBYTE &82 to read the high order address, and prints the high byte of the high order address in hex before deliberately hanging.

Since the tube is explicitly disabled if present, I think this should always print FF. And it does when I run it in b-em from DFS, and it does for shifters74 when run from MMFS, but when run from ANFS with the tube active it prints 00.

I am planning on discarding this code in PLASMA anyway so it doesn't matter in a practical sense, but I'm curious as to why this happens. Am I doing something wrong?

[tom_seddon]

NETV gets a chance to to override OSBYTEs - does the ANFS do this by default?

MOS 1.20: https://tobylobster.github.io/mos/mos/S-s15.html#SP22
MOS 3.20: https://github.com/tom-seddon/mos320/bl ... .s65#L9081

The three NETV hook flags are:

$25e - econetInterceptionStatus - OSBYTE 206 (&CE) Read/write Econet OS call interception [MasRef D.2-66]
$25f - econetInputInterpretationStatus - OSBYTE 207 (&CF) Read/write Econet input interpretation [MasRef D.2-66]
$260 - econetOutputInterpretationStatus - OSBYTE 208 (&D0) Read write Econet output [MasRef D.2-67]

So you might need to set all three to $00 after reselecting the FS.

--Tom

[jgharston]

What are you entering with Y set to? That code is expecting Y to hold the current Tube state, viz:
LDY tube:JMP TubeOff

What do you get if you set Y before calling OSBYTE to read HIADDR, eg:
.NOTTUBE
LDY #&12 ; add here
LDA #osbyte_read_high_order_address

[SteveF]

What are you entering with Y set to? That code is expecting Y to hold the current Tube state, viz:
LDY tube:JMP TubeOff

D'oh! Good spot, so the code I posted is clearly wrong. However, the previous version of the test case I asked shifters74 to try out didn't have this particular bug, so there may still be something interesting here. I'll prepare a new version and post over in the other thread.

What do you get if you set Y before calling OSBYTE to read HIADDR, eg:
.NOTTUBE
LDY #&12 ; add here
LDA #osbyte_read_high_order_address

I'll include this in the new test case.

NETV gets a chance to to override OSBYTEs - does the ANFS do this by default?

Thanks Tom, this is a good suggestion. I won't add this to the test case immediately to keep things simple but if fixing the above bug doesn't resolve it I will ask shifters to try that too.

[sweh]

FWIW I don't see this with a model B and NFS3.60 nor with a M128 with ANFS 4.25; they both report FF.

[SteveF]

shifters74 has tried the new version which fixes the bug JGH spotted and also adds the LDY #$12 and still gets the same behaviour. Here's the code for reference and I'll attach it as well:

Code: Select all

tube = $027A
OSARGS = $FFDA
OSBYTE = $FFF4
OSWRCH = $FFEE
lptr = $AA
osbyte_read_high_order_address = $82

    org $2000
.start

.TubeOff
    LDY tube
    TYA:BPL NOTTUBE              :\ Tube already disabled
    LDA #0:STA tube              :\ Clear Tube presence flag
    LDA &FFB7:STA lptr+0         :\ Point to default vectors
    LDA &FFB8:STA lptr+1
    LDY #&20
.TubeOffEvent
    LDA (lptr),Y:STA &200,Y      :\ Reset EVENTV
    INY:CPY #&22:BNE TubeOffEvent
    JSR ServiceInit              :\ Initialise ROMs
    JSR ReselectFS               :\ Reselect current filing system

.NOTTUBE
    LDY #&12
    LDA	#osbyte_read_high_order_address
    JSR	OSBYTE
    TYA
    JSR printhex
.HANG
    JMP HANG

.ReselectFS
    LDA #0:TAY:JSR OSARGS   :\ Get current filing system
    TAY:LDX #18:BNE Service :\ Reselect filing system
.ServiceInit
    LDX #&37
.Service
    LDA #143:JMP OSBYTE     :\ Issue service call

.printhex
    PHA
    LSR A
    LSR A
    LSR A
    LSR A
    JSR printhex4
    PLA
    AND #$F
.printhex4
    TAX
    LDA hexdigits,X
    JMP OSWRCH
.hexdigits
    equs "0123456789ABCDEF"
.end

save "TEST", start, end, $ff2000, $ff2000

FWIW I don't see this with a model B and NFS3.60 nor with a M128 with ANFS 4.25; they both report FF.

Thanks, that's interesting - albeit confusing! What type of co pro are you using, just in case it matters?

I'll probably try producing a version of the test using Tom's suggestion later, although since it isn't going wrong for sweh I'm not so optimistic that's it. This feels like one of those cases where I'm doing something stupid that will be obvious in hindsight...

[shifters74]

Hi Steve,

Just to check my sanity(!) again i have rerun these.

On a BBC B with Copro with NFS3.62 (DNFS302 ROM). This machine has an integraB with stock OS 1.2.

This was tested with switching the machine on without co-pro enabled. Doing *CONFIGURE TUBE and CTRL-BREAK. Seeing the tube was active and then logging in to ECONET and running *TEST. It returned $FF

However if i then power off the BBC B, switch back on with co-pro already enabled and logging in to ECONET and running *TEST, it returns 2 blank lines and no output what so ever!

I have repeated this behaviour several times.

On a Master with Copro (internal Pi3A if it matters), ANFS 4.25 and a RetroClinic Selectable OS which says MOS 3.5

This was tested with switching the machine on without co-pro enabled. Doing *CONFIGURE TUBE and CTRL-BREAK. Seeing the tube was active and then logging in to ECONET and running *TEST. It returned $00

Power off the Master, switch back on with co-pro already enabled and logging in to ECONET and running *TEST, it returns $00.

Let me know if you want those tests repeated with MMFS too.

shifters

[SteveF]

Thanks shifters74, I appreciate you taking the time to do this - I know that feeling of "is this really happening?"

It's odd that the BBC B shows two different behaviours depending on whether the tube is initially active or not; at least the Master seems to be more consistent. I got my hopes up when I saw you were using MOS 3.5 as I had been testing with MOS 3.2 in b-em, but it doesn't seem to make any difference in b-em running from DFS at least - I still get FF.

I hope someone will have some thoughts on what might be going on here. I will probably produce a version of the test following Tom's suggestion to reset the network vectors later, although I am not super optimistic.

If you feel keen to test with MMFS that might be a useful data point, but please don't go to extra trouble. You could always wait until I've produced a new version of the test anyway.

[BeebMaster]

This is with "test3" and Pi Tube Direct (external) co-pro 1 at Station 201 (MOS 3.50):

[BeebMaster]

P.S. the Tube is still "on" after pressing BREAK, is that right?

[BeebMaster]

I can only get &FF - with real internal 65C102 (Tube 1.10) on Master 128 Station 114 MOS 3.20, ANFS 4.25, and real internal 65C102 (Tube 1.20) on Master 128 Station 86 MOS 3.20, ANFS 4.25, and on BBC B OS 1.20 NFS 3.60 Station 129 with real external 6502 cheese wedge - same whether the cheese wedge is on at boot or powered on later.

[sweh]

FWIW I don't see this with a model B and NFS3.60 nor with a M128 with ANFS 4.25; they both report FF.

Thanks, that's interesting - albeit confusing! What type of co pro are you using, just in case it matters?

EDIT CORRECTION:

The model B has a Matchbox CoPro running 4Mhz 65c02 (*FX151,230,0).
The Master128 has a Kortink 65C102 internal copro.

[BeebMaster]

As I noted in the other thread, it's the load/exec address having the top byte clear which causes the problem, this means the code is loaded in the parasite not the host:

[SteveF]

As I noted in the other thread, it's the load/exec address having the top byte clear which causes the problem, this means the code is loaded in the parasite not the host:

Excellent, I think you've cracked it! Thanks! I should have looked more closely at the screenshot shifters posted over in the other thread.

shifters74 - can you please confirm the problem goes away if you make the load/exec addresses &ffff2000?

P.S. the Tube is still "on" after pressing BREAK, is that right?

That sounds right, I don't think the disable code does anything to stop the tube being re-initialised on BREAK.

Matchbox CoPro running 4Mhz 65c02 (*FX151,230,0) on both machines.

Thanks!

[BeebMaster]

Be interesting to see what file transfer method has been used to get the file from the DFS disc image to Econet. Hopefully utilities should know to interpret a DFS FFnnnn address as FFFFnnnn on Econet or ADFS.

[sweh]

As I noted in the other thread, it's the load/exec address having the top byte clear which causes the problem, this means the code is loaded in the parasite not the host:

I deliberately set the addresses to FFFF2000 on my Pi Bridge before testing, so that would match your observations!

Code: Select all

% cat TEST.inf 
0    FFFF2000 FFFF2000 3

[shifters74]

Hi Steve,

Running on Master and BBC with LOAD/EXEC at &FFFF2000 from power on with no-copro, then enabling co-pro, CTRL-BREAK, log into econet and running *TEST - $FF
Running on Master and BBC with LOAD/EXEC at &FFFF2000 from power on with copro, log into econet and running *TEST - $FF

All my server files have LOAD/EXEC addresses of 00FFxxxx. i understand the xxxx bit being the 16 bit address for main memory, but can some one explain to me what the upper 16 bits are for/mean as i am a bit ignorant of how they relate to econet and co-pro/no co-pro load/execution.

Thanks from the noob

shifters

[shifters74]

Be interesting to see what file transfer method has been used to get the file from the DFS disc image to Econet. Hopefully utilities should know to interpret a DFS FFnnnn address as FFFFnnnn on Econet or ADFS.

I use DiscImageManager to extract the TEST file as TEST and TEST.inf, i then have a python script that converts the .inf into a format used by PiFS and then scp the files over ethernet to the pi.

edit: The format of the LOAD/EXEC address is FFxxxx from DiscImageManager and thats what my script outputs for both in the inf file!

Shifters

[BeebMaster]

The convention in storing file information is that FFFFnnnn refers to the host processor memory location nnnn which as it's a 6502 is limited to 64K of addresses, and 0000nnnn refers to the second processor memory. As this might be more than 64K such as 80186, ARM second processors etc. the address might overflow into the top two bytes but it will still be treated as referring to second processor memory as long as the top two bytes are not FFFF.

On filing systems like DFS which don't have the space to fit 32-bit addresses, it's abbreviated to FFnnnn for host and 00nnnn for second processor.

[BeebMaster]

Official explanation, chapter 9 of 6502 Second Processor User Guide:

[shifters74]

The convention in storing file information is that FFFFnnnn refers to the host processor memory location nnnn which as it's a 6502 is limited to 64K of addresses, and 0000nnnn refers to the second processor memory. As this might be more than 64K such as 80186, ARM second processors etc. the address might overflow into the top two bytes but it will still be treated as referring to second processor memory as long as the top two bytes are not FFFF.

On filing systems like DFS which don't have the space to fit 32-bit addresses, it's abbreviated to FFnnnn for host and 00nnnn for second processor.

Thanks Beebmaster!

I am still a little confused (even reading the official explanation!).

If the program has LOAD/EXEC address of FFFFxxxx does that mean it cant run on the co-pro - you would need an additional copy of the program that has a LOAD/EXEC address of 0000xxxx for that?

What happens when you try to run a 0000xxxx program on a machine with out a co-pro?

Does that mean if you run a program with FFFFxxxx even with a co-pro it will load and run it on host, not the co-pro even if its active?

thanks

shifters

[BeebMaster]

Gosh. It's all getting a bit deep, I had to go out for the evening to think it through.

I think by and large that's right. One way to think about it is to think of a two processor system where the two processors use different CPUs. In this case, it's very important that executable code is running in the correct processor otherwise it won't work.

The host processor is always going to be a 6502 but the second processor might by 80186, ARM, Z80 etc. So anything written in 6502 code must run in the host processor or it won't run - setting the load & exec addresses as FFFFnnnn ensures this. Similarly any code we write for the parasite CPU needs to run in the second processor or the code won't be understood, so we set it to 0000nnnn to force it to run in the second processor.

If there is no second processor active then the code will always load in the host processor but will fail to run correctly if it's written for a different CPU.

When using a non-6502 second processor and trying to select a built-in language ROM, written in 6502, it is copied over to the second processor's language workspace but then fails to run with "I cannot run this code" or "This is not ARM code" etc. error.

When using disc or Econet based library utility commands, these are set to load/exec at FFFFnnnn in the host processor because they are written in 6502, and won't run if loaded locally into the second processor.

Much of the time none of this is particularly apparent to the user, because most of the time the second processor is a 6502 so the code is always going to run whether it's loaded in host or parasite, but it may not run as expected if it's executed in the "wrong" processor. For example, the L3 file server code is 6502 so it technically will work even without being run in a second processor, but it doesn't work because it loads too low in memory for the host processor overwriting workspace - so it has load & exec address of 00000400 to ensure it runs in the second processor.

Using the current language, such as BASIC, complicates things further because programs are always loaded in the currently active processor no matter what the load/exec addresses say as it's not possibly to easily directly access the "other" processor memory when running a language. It's complicated even further by there being implementations of BBC BASIC for many if not all of the second processors, so it can get harder and harder to fathom out which area of memory and which CPU is actually being used when running some BASIC!

[BeebMaster]

Quick example using *DISCS which is intended to run in the host processor and works from ARM second processor, but if we change the load/exec addresses to run it in the second processor, ARM doesn't understand:

But both versions work when the second processor is a 6502, but the second processor version may unintentionally overwrite something in the second processor workspace at that location:

[shifters74]

Thanks Beebmaster!!

That was a very clear explanation and clears up the areas i was confused about!

Today on my PiFS i will need to change many .inf files to correct this!

Many thanks!

Shifters

[BeebMaster]

I think when an inf file is being interpreted, it should convert an address of FFnnnn to FFFFnnnn if it is being moved to filing systems which support 32-bit addresses. I think they all do except DFS, and possibly derivatives of DFS like memory-card implementations.

[sweh]

I think when an inf file is being interpreted, it should convert an address of FFnnnn to FFFFnnnn if it is being moved to filing systems which support 32-bit addresses. I think they all do except DFS, and possibly derivatives of DFS like memory-card implementations.

Since 00FFnnnn is a valid load address on copros with 16MB of RAM, I would say that whatever software generates those inf files (or xattr attributes) might want to do the fixup. PiFS, itself, won't generate them unless instructed to by a client, and PiFS inf files are not the same as those generated by most DFS extraction tools (eg my own perl scripts).