Econet Immediate Operations & BeebEm

[KenLowe]

Yes. It is. I started some further tests Berben to BeebEm. This was one of those. Poke to BeenEm BbC from a BeenEm Master worked. Reading back the poked values with a peek, didn’t.

Ok, again that's working fine for me; both Poke BeebEm Beeb from a BeebEm Master, and then Peek BeebEm Beeb from a BeebEm Master.

A couple of things to note:

1. Make sure that you Untick the 'Freeze when inactive' flag in the BeebEm Options menu for all instances you have running.
2. If you're using the 'Peek' code I posted earlier, make sure to adjust the length% variable in line 70 to match what you expect to receive, otherwise it might throw out the PRINT $txbuffer% at line 270. You may want to ditch line 270 altogether, do a more basic hex dump of the txbuffer%.

[cr12925]

Yes. It is. I started some further tests Berben to BeebEm. This was one of those. Poke to BeenEm BbC from a BeenEm Master worked. Reading back the poked values with a peek, didn’t.

Ok, again that's working fine for me; both Poke BeebEm Beeb from a BeebEm Master, and then Peek BeebEm Beeb from a BeebEm Master.

If you use wireshark to catch the local AUN traffic, does that reveal anything?

C

[markusher]

OK, I think I found the root cause of most of the issues. Router had changed my IP address, and it was statically assigned to the old on in the hpbridge.cfg. So traffic was going to the bridge but not getting back.

Much better results now with Peeking and Poking.

One thing I noticed, was logging on to a physical file server from BeeBEm in BBC mode NFS 3.60
Logging on to physical fileserver 254 from BeebEm station 106 sends it with the AUN station

Code: Select all

Idle
91.001 -> 254 Scout #80 (99) 
91.001 -> 254 Scout #80 (99) 
91.001 -> 254 Scout #80 (99) 
91.001 -> 254 Scout #80 (99) 

and it doesn't succeed

logging on from a Master 128 BeebEm - same binary, same computer, same config files, different station number, uses the econet station number

Code: Select all

105 -> 254 Scout #80 (99)
105 -> 254 Examine (3 22 11)

254 -> 105 Scout #80 (90)
254 -> 105 Data 000000r80

etc etc and succeeds.

Code: Select all

--econet.cfg--
#FileStore E01
0 252 192.168.1.51 32772
0 254 192.168.1.51 32774
BeebEm
0 105 192.168.1.10 32775
0 106 192.168.1.10 32776

--econet-hpbridge.cfg--
DYNAMIC 91 AUTOACK
WIRE NET 1 ON DEVICE /dev/econet-gpio
FILESERVER ON 1.252 PATH /home/econet/econetfs
EXPOSE HOST 1.252 ON PORT 192.168.1.51:32772
EXPOSE HOST 1.254 ON PORT 192.168.1.51:32774
AUN MAP HOST 1.105 ON 192.168.1.10 PORT 32775 AUTOACK
AUN MAP HOST 1.106 ON 192.168.1.10 PORT 32776 AUTOACK

[cr12925]

Isn’t that difference just because the m128 in beebem is assigned an address and port which is specifically mapped in your bridge config and the beebem B is not?

Not clear why the FS won’t talk to net 91 mind you…

C

[markusher]

They are both assigned a port and mapped, at least it looks like they are in the attached config.

105 -> BeebEm Master
106 -> BeebEm BBC

Do I need to update the EEPROM again since the changes have been made. I already updated it with the initial v2.1 pre?

[cr12925]

They are both assigned a port and mapped, at least it looks like they are in the attached config.

105 -> BeebEm Master
106 -> BeebEm BBC

Do I need to update the EEPROM again since the changes have been made. I already updated it with the initial v2.1 pre?

No, should be fine

C

[cr12925]

They are both assigned a port and mapped, at least it looks like they are in the attached config.

105 -> BeebEm Master
106 -> BeebEm BBC

Do I need to update the EEPROM again since the changes have been made. I already updated it with the initial v2.1 pre?

For some reason the bridge is seeing the bbc b traffic from a port number it doesn’t have a host map for, so it’s allocating a dynamic station. If you email me some debug of that happening (-zz -piO -n40) I’ll figure out why.

Edit: You’ve not got more of your funky ^Ms in your config file again, have you??!

Best

C

[markusher]

No funkyness in the config file this time. That has been put well and truly to bed.
I'm still getting consistent behaviour as described when logging on from a BBC BeebEm to a physical filestore.
logs are in your inbox

[cr12925]

No funkyness in the config file this time. That has been put well and truly to bed.
I'm still getting consistent behaviour as described when logging on from a BBC BeebEm to a physical filestore.
logs are in your inbox

My rambling suppositions are now in yours…

C

[markusher]

Fixed. Typo in the port number on bridge.cfg Hangs head suitably in shame.

[KenLowe]

Not entirely sure how helpful this is, but I've created a patched version of NFS3.34 that runs on the Master. The patch changes the INTON / INTOFF addresses, and reads the Station ID from memory location &2800 instead of CMOS.

• If I load this patched version onto a BeebEm Master it no longer receives NOTIFY messages.
• If I load this patched version onto a real Master it can still receive NOTIFY messages.
• If I load a station ID patch only (not INTON / INTOFF) version onto a real Beeb it can still receive NOTIFY messages.

[KenLowe]

Fixed. Typo in the port number on bridge.cfg Hangs head suitably in shame.

It's so easily done. I was chasing my tail for hours the other evening because of a misconfigured BeebEm econet.cfg file!

[cr12925]

Not entirely sure how helpful this is, but I've created a patched version of NFS3.34 that runs on the Master. The patch changes the INTON / INTOFF addresses, and reads the Station ID from memory location &2800 instead of CMOS.

• If I load this patched version onto a BeebEm Master it no longer receives NOTIFY messages.
• If I load this patched version onto a real Master it can still receive NOTIFY messages.
• If I load a station ID patch only (not INTON / INTOFF) version onto a real Beeb it can still receive NOTIFY messages.

So something in NFS 3 and probably ANFS 4.18 is tickling a bug in BeebEm…?

Wonder if this is just OSPROC (ctrl &85) or the other 4-way immediates as well … does poke (ctrl &82?) work to a BeebEm BBC B or a M128 with your patched v3? IIRC, it did. USRPROC I think is testable with *Fast (ie from the BBC B) which uses it for signalling, and JSR (&83) should be easy to test I think…

I’ve a hunch this is just OSPROC failing but I can’t tell yet.

C
C

[markusher]

Chasing it too often recently

One thing I remember, is the timings with a debug version of BeebEm can sometimes effect some of the econet operations. It's always worth validating the behavior with a release version.

It looks like a cold, wet weekend here so now all the test stations are working as they should, I'll hopefully be able to look at the operations some more, especially as I don't have Repton3 on the econet to distract me this time. I did notice, sometimes when peeking the BBC BeebEm from the Master BeebEm, that the data didn't always come through the first 1 or 2 times, but then it did on subsequent tries. Yes, Freeze when inactive is disabled by default on all these machines.

[KenLowe]

does poke (ctrl &82?) work to a BeebEm BBC B or a M128 with your patched v3?

Yes, that's still working to both.

[cr12925]

If you mod your hacked nfs v3 to read the station number from somewhere else, put it on a beebem m128, and *LOAD the FAST binary (which loads at &2800 Unhappily…), can you then send a successful JSR &2800 to that m128 ? (It should cause the *FAST binary to start I think…)

C

[KenLowe]

No, FAST did not start with the patched 3.34 (with station ID now at &2000) on my BeebEm Master. It starts ok with ANFS. And it also started on my real Master with patched 3.34.

In all above cases I was trying to start it from a BeebEm beeb with an unpatched NFS3.60 ROM.

[KenLowe]

I've been working on a disassembly of NFS3.34. It's mainly uncommented, but fairly well developed:

viewtopic.php?t=28993

Now that we know we can break BeebEm Master Econet Immediates with this version of NFS, I'm hoping this disassembly, coupled with the fixed BeebEm debugger, will make it easier to spot what's going wrong in BeebEm.

[cr12925]

Given, IIRC:

Code: Select all

            BeebEm.    Real
BBC B. NFS3 FAIL.      Works
M128.  ANFS Works.     Works
M128.  NFS3 FAIL.      Works

… this appears to be some odd interaction between NFS3 and BeebEm.

Question is what?

C

[KenLowe]

Well, with the disassembly of NFS3.34, and with the BeebEm debugger fixed, I'm hoping I can start to trace what's happening in BeebEm!

[BeebMaster]

Is there any special reason why NFS 3.34 is being used? It works differently to NFS 3.40 and later, as it still has the concept of "privileged" stations with numbers 240 to 254, which can't be protected from immediate operations. So maybe the way that interacts with BeebEm is causing the problem?

[KenLowe]

It's just a version I had to hand, and it does cause the immediates to fail when run on the BeebEm Master, so it should be good enough to test with. 3.40 and 3.60 fail on a BeebEm beeb in the same way, so I'd expect them to fail on the Master too, if they were also patched. I am hoping to do a disassembly of 3.40 as well, at some point.

[markusher]

Some of the source code in the filestore MOS is shared with NFS that may give you some quick wins for some of the code segments.

[SKS1]

You do know that the DNFS source is up on GitHub? i.e. NFS 3.60

https://github.com/stardot/AcornDNFSv300

[KenLowe]

Yup, but I find it almost impossible to follow! However, I am using it to help comment the version I'm currently working on. There's a lot of similarities, once I've figured out some of the notation used in the DNFS disassembly.

Also, I'm using this as a bit of a testing ground for another ROM disassembly that I want to do.