Econet for Atom

[KenLowe]

Does the PIC activity LED flash once when you press BREAK?

Yes, I'm pretty sure it did. However, it's now working again, so I can't double check that now. Whilst the machine was still powered up, I unplugged the ADF-10 module, and it immediately sprung back into life. I've plugged the ADF-10 back in again, and it's all still working as it should.

Screen grab

[hoglet]

Whilst the machine was still powered up, I unplugged the ADF-10 module, and it immediately sprung back into life. I've plugged the ADF-10 back in again, and it's all still working as it should.

That's sounding like a dodgy solder joint somewhere, maybe on the CPLD?

Dave

[KenLowe]

That's sounding like a dodgy solder joint somewhere, maybe on the CPLD?

Yeah. I'm just having a look at that right now.

[KenLowe]

Right, I've tried a completely different AtoMMC / Econet board, with a completely different ADF-10 module, and I'm seeing the same behaviour.

Right now, if I cycle power, it boots up ok to the ATOM + ATOMMC prompt after I hit BREAK. If I then ?#BFFE=2 and hit BREAK, I get the ATOM + ECONET prompt, which is all fine and as expected.

However, if I then try to switch back again with ?#BFFE=(7-1) (my 6 key isn't working!), it hangs and the prompt doesn't come back. If I then hit BREAK it starts working again, and has switched back to the ATOM + ATOMMC prompt.

I might remove the tube adaptor to see if that makes any difference...

[hoglet]

However, if I then try to switch back again with ?#BFFE=(7-1) (my 6 key isn't working!), it hangs and the prompt doesn't come back. If I then hit BREAK it starts working again, and has switched back to the ATOM + ATOMMC prompt.

I get exactly the same behaviour, and I think it's to be expected.

The Econet ROM grabs a lot of vectors, including OSRDCH and OSWRCH. When you change #BFFE from 2 back to 6, you are changing the #E000 ROM from Econet to AtoMMC. So all those vectors are now pointing to random code.

This causes an immediate crash, which BREAK then recovers from.

It's not as bad when going from AtoMMC to Econet, because AtoMMC doesn't revector OSRDCH and OSWRCH. But I imagine any file system operation would crash.

Is that the only hang you are seeing now?

Dave

[KenLowe]

However, if I then try to switch back again with ?#BFFE=(7-1) (my 6 key isn't working!), it hangs and the prompt doesn't come back. If I then hit BREAK it starts working again, and has switched back to the ATOM + ATOMMC prompt.

I get exactly the same behaviour, and I think it's to be expected. I also removed the Tube adaptor as a quick check, but it didn't change anything.

Ok. That's good to hear. I thought I had been able to switch back and forth previously, but perhaps not.

Is that the only hang you are seeing now?

So, right now, yes.

I'm going to leave it running with the board that has Econet ID 21 for a while. If that continues to work, I'll then switch back to the board with Econet ID 22 (this is the one that was hanging earlier) to see if it starts misbehaving again.

[KenLowe]

I'm going to leave it running with the board that has Econet ID 21 for a while. If that continues to work, I'll then switch back to the board with Econet ID 22 (this is the one that was hanging earlier) to see if it starts misbehaving again.

Board 21 continued to work without any issue, but swapping back to board 22 and the intermittent problem reappeared.

That's sounding like a dodgy solder joint somewhere, maybe on the CPLD?

Yeah. I'm just having a look at that right now.

I couldn't see anything obviously wrong, but it certainly appeared to be a bad contact somewhere, because flexing the board ever so slightly would get it working again briefly. I've run the soldering iron over the CPLD again and so far it's working fine, so hopefully that's fixed it. I'll leave this board connected to do an extended soak test .

[KenLowe]

Quick question. I checked the Atom Tube Interface thread, but couldn't find the answer there. Is it possible to use Econet when running a Co-Pro, and if so how do I go about initialising the file system? I would like to try and get some software running on the Atom Tube via Econet:

viewtopic.php?p=381355#p381355

[hoglet]

Is it possible to use Econet when running a Co-Pro, and if so how do I go about initialising the file system?

Sorry, no it isn't...the only file system that supports the Atom Tube is AtoMMC.

The filesystem needs to explicitely support tube data transfers, and none of the original Atom file systems did, because the Tube was never "a thing" for the Atom back in the day.

It will be tricky to add support, because there is so little free space in the Econet ROM.

Is this for the Ozmoo adventures?

Dave

[KenLowe]

Sorry, no it isn't...the only file system that supports the Atom Tube is AtoMMC.

The filesystem needs to explicitely support tube data transfers, and none of the original Atom file systems did, because the Tube was never "a thing" for the Atom back in the day.

It will be tricky to add support, because there is so little free space in the Econet ROM.

Aw, that's a shame!

Is this for the Ozmoo adventures?

Yes, exactly that! I suppose I can still try to get them running from AtoMMC...

[hoglet]

Yes, exactly that! I suppose I can still try to get them running from AtoMMC...

I wonder if a proper port to the Atom host, rather than Co Pro, would be more useful?

This could use additional memory provided by YARRB.

Dave

[roland]

It will be tricky to add support, because there is so little free space in the Econet ROM.

If it's for use with the tube you have plenty of memory available when you add the Econet code to *TUBE programme. You have memory from #400 to #7FFF for this, 31K ought to be enough. Just a thought though....

[KenLowe]

I wonder if a proper port to the Atom host, rather than Co Pro, would be more useful?

This could use additional memory provided by YARRB.

That certainly would be the ultimate goal, but I think the changes might be quite extensive.

SteveF would be the ideal guy for doing the port, but he's already indicated that he hasn't the capacity right now. So, I was basically looking for a simpler way to get it working, and porting the Co Pro version seemed the simplest and logical first step. Steve has given me some pointers, so I'm having a quick look through the loader code to see if I can make this work:

Joking aside, I've got a CoPro running on my Atom, so I'm not sure how close we would be to getting Ozmoo running on the Atom???

I suspect this is doable. Off the top of my head:

• Build the Ozmoo game with --no-tube-cache so it doesn't try to use free main/sideways RAM on the host to cache game data. This could probably be supported, but it would need Atom-specific code to be written.
• Build the Ozmoo game with --no-history so it doesn't try to play games with INSV on the host.
• Hack the loader so it doesn't try to run FINDSWR and just assumes there are 0 sideways RAM banks, or replace FINDSWR with a stub binary that just indicates 0 SWR banks are present.
• Make sure you choose a screen mode in the loader which the Atom supports.

Provided the Atom host code implements OSWORD &7F (for a DFS build) or OSGBPB (for a non-DFS build), it *might* then "just work". After all, most of the code is running on the copro - the main thing is to avoid or fix up the relatively small bits of Ozmoo which play around with the host even when running on the copro.

I have absolutely no experience with the Atom myself. I definitely won't have time to look at an Atom port in the near future, but I wouldn't absolutely rule out giving it a try at some point. If you or anyone else feels like having a go please do. I suspect an initial port of a specific game could be done by building a BBC version with the options above and just doing a little bit of manual hackery to copy files over to an Atom disc format and tweaking the loader. That experience would then be useful if we subsequently decide to try to incorporate Atom support directly into the build script.

As I say, I think this is interesting but I won't have time to look at it in the near future. I'm happy to be a back-seat driver in this thread and offer advice and encouragements if anyone feels like having a go.

Edited to add: I'd suggest starting off with a game small enough to fit on a single-sided DFS disc, as that avoids the interleaving of data across the two sides which just might trip things up if the Atom's discs are different. This might not be an issue, but better to play it safe to start with.

I was going to say that starting off with a small game (like Calypso?) that doesn't need virtual memory on a copro might avoid the need for OSWORD &7F/OSGBPB support, but I would have been wrong - we still need these OS calls to load the game data into memory on startup, even if there's no virtual memory used during play.

And I assume there's no reason Ozmoo couldn't run natively on the Atom without copro if there's an expansion which gives enough RAM to work with, if any experienced Atom developers feel like giving this a try. But the copro would almost certainly be an easier way to do this!

[KenLowe]

Anyway, I would suggest going forward we use Charlie's 3.0 boot loader and 3.0 firmware on this hardware, and I'll keep my repository just for the older AtoMMC 2.0

Sorry for jumping back to this old post. I recently received two PICs from AliExpress, with the intention of building three different AtoMMC systems. These two new PICs are to be used in my AtoMMC / Econet boards (one for each of my Atoms), and the original PIC is to be returned to my SirMorris board. I installed the latest bootloader and firmware on the new PICs and they all work fine on my AtoMMC / Econet board, but I'm having problems getting the original PIC to work on my SirMorris board. I'm getting a NOT READY error. The PIC has the latest v3 bootloader, and I've tried installing the older '3minus' firmware (atommc25.bin), but that doesn't seem to be installing (no flickering LEDs). I tried renaming this file to atommcv3.bin but that didn't do anything either. I suspect the latest bootloader is unable to read the card because it doesn't quite match my specific SirMorris board pinout. However, I'm not sure I can just go back to version 2.9 either:

It must be running a custom boot loader that still happened to be called version 2.9.

Is there a 'release' version of the custom v2.9 firmware available that supports my '3minus' SirMorris board???

TIA!

Edit: Actually, I might have a go at building this myself, from here. It looks like I should be able to run the script from a Windows command prompt, as long as I have MPLAB C18 installed. I'll obviously need to swap pins around a bit to match my card. Is it just the standard / eval version of MPLAB C18 that I need to use? I'll probably need to install it in a VM as it's a 32bit application.

Charlie has published the sources for these in this repository, but I'm not aware of any official binary releases.

I've not tried these before, so I had a go at building them. I needed to do some hacking to the build script, because I don't have the ihexdump program. So I used the same process that I used for the 2.x firmware (a java program I wrote called pichextobin). They do pretty much the same thing - add a header with a magic number and checksum onto the firmware file, so the AtoMMC boot loader can tell it's legitimate.

I note that there is a file called HexDumo-D.exe in the repo BIN directory, and this gets called by one of the batch files. Does this add the header with a magic number and checksum onto the firmware file?

[KenLowe]

Right, after much messing with VMs and Windows ISOs, I eventually got a working version of Win7-x86 up and running, which allowed me to install the MPLAB C18 compiler for the PIC18. I then downloaded the AtoMMC2 firmware from here, modified the mmc.h file in the BootLoader folder to swap MISO and MOSI (C4 and C5) around and ran the included BootLoader-manualbuild.bat script from the Windows command prompt, which built the atommc-25.hex file. I was able to program that onto my PIC using my TL866-II along with the config and EEPROM settings discussed earlier in this thread, and once that was finished, I placed the PIC back into my SirMorris AtoMMC board.

I then took the atommc3minus firmware that was previously posted in this thread, stuck that on a 128k partitioned SDCard, and plugged that into my AtoMMC board. I powered up the Atom, and the LEDs began flickering on the AtoMMC board (good sign!). Once the flickering stopped, I was greeted with the ATOM + ATOMMC2 prompt, and I'm once again able to use my SirMorris AtoMMC board. A quick test with the ASA, and all is looking good! .

[hoglet]

I then took the atommc3minus firmware that was previously posted in this thread, stuck that on a 128k partitioned SDCard, and plugged that into my AtoMMC board. I powered up the Atom, and the LEDs began flickering on the AtoMMC card (good sign!). Once the flickering stopped, I was greeted with the ATOM + ATOMMC2 prompt, and I'm once again able to use my SirMorris AtoMMC board. A quick test with the ASA, and all is looking good! .

Sorry Ken, I intended to reply to this thread, but got distracted and completely forgot.

Glad you have this sorted now, and you are now well setup for future AtoMMC PIC hacking!

BTW, I've just started setting up my PiEcoBridge. I'll ley you know how that goes.

Dave

[KenLowe]

Glad you have this sorted now, and you are now well setup for future AtoMMC PIC hacking!

Ha. I wish!

Using the atommcv2 firmware, I tried to build the main firmware today, and whilst it seems to have created the atommc25.bin file successfully, it's not working in my card. It does install, and reports the firmware version as 2.D when I do a *HELP, but it hangs when I issue a *CAT command. I have swapped the MISO & MOSI pins around, and I haven't touched the IRQ pin assignment. These are the assignments I've used in the build...

mmcio.h:

Code: Select all

#define SPI_CS_PIN PORTCbits.RC2
#define SPI_CS_TRIS TRISCbits.TRISC2

#define SPI_DIN_PIN PORTCbits.RC4
#define SPI_DIN_TRIS TRISCbits.TRISC4

#define SPI_DOUT_PIN PORTCbits.RC5
#define SPI_DOUT_TRIS TRISCbits.TRISC5

#define SPI_SCK_PIN   PORTCbits.RC3
#define SPI_SCK_TRIS  TRISCbits.TRISC3

atmmc2io.h:

Code: Select all

#define ASSERTIRQ()  PORTCbits.RC6 = 0; TRISCbits.TRISC6 = 0;
#define RELEASEIRQ() TRISCbits.TRISC6 = 1;

Switching back to your 3minus firmware, and everything starts working again. Any pointers as to what I might be doing wrong?

Another thing I'm struggling with is how to change the version number that gets reported on *HELP. Looking through the scripts, I thought this would change when I changed the ASCII number in the buildnumberwin.txt file. I see this filtering through to the #DEFINE within the buildnumber.h file, but it doesn't seem to change the reported build number. Have I misunderstood how this works???

The final thing I was looking to do was switch to the v3 firmware, and adjust the IRQ back to the original pin, but there are no build scripts with the version on Charlies site, and I was struggling to adapt the v2 script to work with the v3 firmware. Have you been able to build the v3 firmware?

[hoglet]

I have swapped the MISO & MOSI pins around in the mmcio.h file, and I haven't touched the IRQ pin assignment.

As far as I recall, that's the only change I made when I build the 3minus firmware (which should be tagged 2E).

Checking github suggests the same:
https://github.com/hoglet67/AtoMMC2Firm ... d00e705e98

Switching back to your 3minus firmware, and everything starts working again. Any pointers as to what I might be doing wrong?

That should be the same as what you have built.

Does my version show as version 2E in *HELP?

Another thing I'm struggling with is how to change the version number that gets reported on *HELP. Looking through the scripts, I thought this would change when I changed the ASCII number in the buildnumberwin.txt file. I see this filtering through to the #DEFINE within the buildnumber.h file, but it doesn't seem to change the reported build number. Have I misunderstood how this works???

The *HELP version number comes from these two #defines:
https://github.com/hoglet67/AtoMMC2Firm ... mmc2.h#L11

The final thing I was looking to do was switch to the v3 firmware, and adjust the IRQ back to the original pin, but there are no build scripts with the version on Charlies site, and I was struggling to adapt the v2 script to work with the v3 firmware. Have you been able to build the v3 firmware?

I have, but it took a bit of hacking, because I don't have the ihexdump program. I had to replace this with a Java program I wrote a while back called pichextobin:
https://github.com/hoglet67/AtoMMC2Firm ... ichextobin

Dave

[KenLowe]

I have swapped the MISO & MOSI pins around in the mmcio.h file, and I haven't touched the IRQ pin assignment.

As far as I recall, that's the only change I made when I build the 3minus firmware (which should be tagged 2E).

Checking github suggests the same:
https://github.com/hoglet67/AtoMMC2Firm ... d00e705e98

Ah, sorry, I missed the atommc3plus branch. That has most of the answers!

Does my version show as version 2E in *HELP?

Yes, it does.

The *HELP version number comes from these two #defines:
https://github.com/hoglet67/AtoMMC2Firm ... mmc2.h#L11

Yes, that was the bit I was missing.
I notice that the buildnumber.txt file also changed. Is that a critical change, and is it linked in any way to VSN_MAJ / VSN_MIN?

The final thing I was looking to do was switch to the v3 firmware, and adjust the IRQ back to the original pin, but there are no build scripts with the version on Charlies site, and I was struggling to adapt the v2 script to work with the v3 firmware. Have you been able to build the v3 firmware?

I have, but it took a bit of hacking, because I don't have the ihexdump program. I had to replace this with a Java program I wrote a while back called pichextobin:
https://github.com/hoglet67/AtoMMC2Firm ... ichextobin

Ah, ok. I've just spotted the linux build.sh script file. I should be able to port that over to Windows - apart from the ihexdump piece. I'll work on this later, once I get the v2 firmware built.

[hoglet]

I notice that the buildnumber.txt file also changed. Is that a critical change, and is it linked in any way to VSN_MAJ / VSN_MIN?

It's not linked to VSN_MAJ / VSN_MIN.

The purpose of the build number is to make sure successive builds have some difference in the first 8KB of the file, which is all the CRC covers. The CRC is used by the boot loader to check if the firmware on the SD card differs from what is already programmed.

Ah, ok. I've just spotted the linux build.sh script file. I should be able to port that over to Windows - apart from the ihexdump piece. I'll work on this later, once I get the v2 firmware built.

I can push my build changes my fork tomorrow if you like.

Dave

[KenLowe]

Right, I'm not sure what was going wrong earlier, but that's the firmware now building, installing and functioning correctly from both the original atommc2 master branch and the atomc3plus branch. At one stage the AtoMMC wouldn't accept firmware upgrades from any source and in the end I had to reflash the bootloader onto the PIC. Once I'd done that, everything started to work, so I'm not sure if there was an underlying problem that was causing the earlier hangs that I had reported. Anyway, they've all gone away now and everything's working as it should.

Next up, I'm going to see if I can get a patched version of the V3 firmware working on the board...

Edit: ...and I now have the V3 bootloader, and V3 firmware running on my SirMorris AtoMMC board! I had to create some windows scripts, based on the scripts included with the V2 firmware files, and the OSX script in the V3 firmware files. I was also able to reuse the HexDump-D.exe file from the V2 firmware files to create the V3 firmware binary from the hex file.

I've changed the version number of the bootloader and main firmware files to v3.1, but would be happy to change these back to v3.0, or to something completely different, if that's appropriate.

[hoglet]

I've changed the version number of the bootloader and main firmware files to v3.1, but would be happy to change these back to v3.0, or to something completely different, if that's appropriate.

I understood the original purpose of the version was to indicate changes in the protocol between the AtoMMC hardware and the AtoMMC ROM.

I would suggest leaving them at v3.0, as nothing has changes protocol-wise.

But that's just my opinion, Charlie may have a different view.

Dave

[KenLowe]

I understood the original purpose of the version was to indicate changes in the protocol between the AtoMMC hardware and the AtoMMC ROM.

I would suggest leaving them at v3.0, as nothing has changes protocol-wise.

But that's just my opinion, Charlie may have a different view.

I don't have a strong opinion. I can easily change it back. The only reason I did this, is because we increased the equivalent v2 firmware to version 2.E.

The reason for questioning this is because I'll probably take a fork of v3, and create my own branch with these changes.

[hoglet]

I don't have a strong opinion. I can easily change it back. The only reason I did this, is because we increased the equivalent v2 firmware to version 2.E.

You are right, we did...

But I deliberately haven't merged that into master.

It's unfortunate this has got so confusing, but that's down to different iterations of the hardware. There is no way a simple major.minor version number schememe can adequately deal with that.

So on balance you are probably right to increment it.

Maybe what I'll try to do is to keep this post up to date with what's out there:
viewtopic.php?p=378472#p378472

What build/version are you planning to distribute with your combined AtoMMC/Econet boards?

Dave

[KenLowe]

Out of interest, I also tried various combinations of Boot Loader and Firmware
- 2.9 Boot Loader (hoglet) + 3.0 Firmware (hoglet) - works - but IRQ and Firmware Update broken - LOAD benchmark 13.75s
- 2.9 Boot Loader (hoglet) + 3.0 Firmware (charlie) - works - but IRQ and Firmware Update broken - LOAD benchmark 8.35s
- 3.0 Boot Loader (charlie) + 3.0 Firmware (hoglet) - NOT READY error when accessing SD Card
- 3.0 Boot Loader (charlie) + 3.0 Firmware (charlie) - works - LOAD benchmark 8.35s

Sorry this is so confusing - there are two different "3.0" firmware build (my hacky one and Charlie's). Charlie's is better for this hardware as it uses the PIC's SPI hardware, which is possible because MOSI and MISO are now connected to the correct pins. That gives a pretty decent speed up. The benchmark above loads a total of ~120KB of data.

<---SNIP--->

Anyway, I would suggest going forward we use Charlie's 3.0 boot loader and 3.0 firmware on this hardware, and I'll keep my repository just for the older AtoMMC 2.0

Dave

I don't have a strong opinion. I can easily change it back. The only reason I did this, is because we increased the equivalent v2 firmware to version 2.E.

You are right, we did...

But I deliberately haven't merged that into master.

It's unfortunate this has got so confusing, but that's down to different iterations of the hardware. There is no way a simple major.minor version number schememe can adequately deal with that.

So on balance you are probably right to increment it.

Maybe what I'll try to do is to keep this post up to date with what's out there:
viewtopic.php?p=378472#p378472

What build/version are you planning to distribute with your combined AtoMMC/Econet boards?

Dave

Based on all the earlier discussions, I think my preference would be to have both my 'V3' SirMorris AtoMMC board and my 'V4' combo Econet / AtoMMC boards based on Charlie's atommc-v3 firmware. The atommc-v3 firmware appears to already cater for both of these board revisions, with a simple V4HARDWARE compile time switch to toggle between the two:

https://github.com/charlierobson/atommc ... 744b4f0814

What I might do, is update the version numbering code, so this same V4HARDWARE compile time switch will generate v3.0 for the more common V4 hardware (either my combo Econet / AtoMMC board, or Roland's V4 board), and v3.1 for my more unusual SirMorris board - similar to what you've done with the atommcv2 firmware, in the atommc3plus branch.

[hoglet]

That sounds reasonable.

It's definitely worth using Charlie's atommc-v3 firmware as it uses the hardware SPI interface in the PIC, so is about twice as fast as the version 2 hardware.

It's a shame the V4HARDWARE #define doesn't also change the version number to 4.x. But I guess that ship has sailed now, and making that change at this stage would just I think cause further confusion.

Dave

[KenLowe]

It's a shame the V4HARDWARE #define doesn't also change the version number to 4.x. But I guess that ship has sailed now, and making that change at this stage would just I think cause further confusion.

Indeed. I thought exactly the same.

[KenLowe]

Right, I was getting myself a bit confused, but I think I understand what's happening...

I've created a V3 hardware build (software v3.1) and a V4 hardware build (software v3.0), and both software versions work in both of my hardware setups. I did not expect that. I expected the v3.1 software to fail in my V4 hardware, and for the v3.0 software to fail in my V3 hardware.

I'm passing /DV4HARDWARE parameter through the command prompt to define the hardware version, and I'm happy that the compiler is using this, because it's setting the version number according to the /DV4HARDWARE. I was struggling to figure out why the conditional IRQ configurations were having no apparent affect. But then I realised that I've got AtoMMC interrupts disabled via *CFG (C0), so I'm guessing that's why any of the two firmwares are working on any of the two boards!

I've pushed the changes I made to my atommc3minus branch: https://github.com/kgl2001/atommc-v3/tree/atommc3minus

[hoglet]

But then I realised that I've got AtoMMC interrupts disabled via *CFG (C0), so I'm guessing that's why any of the two firmwares are working on any of the two boards!

Indeed - the only difference between the V3 and V4 hardware is the PIC pin assigned to IRQ.

And IRQ is only used to initialize the the #A000 version of AtoMMC, and then only when bit 5 of *CFG is one.

Dave

[hoglet]

back onto the topic of Atom Econet.....

I've been doing some testing of the library commands (DISCS, INF, PROT, REMOTE, UNPROT, USERS, VIEW). These originally ran against the Econet 2.40 ROM, and a couple of years ago I updated them for the Econet 3.50 ROM. What I found was USERS, VIEW, REMOTE, didn't work.

After lots of disassembling and tracing the code, I've concluded that it's because of some protocol changes between Econet V2 and V3.

Here's a summary of what needed to change:

*USERS:
- this uses the read_loggon_on_users file server command (command code 15)
- the user names in the response are 0D terminated, rather than being padded with spaces

*VIEW:
- this uses the PEEK immediate command to read the remote screen mode (#B000) and and screen (#8000 onwards)
- the PEEK command code needed changing to &81 (it was &84)

*REMOTE:
- the uses the REMOTE OS PROCEDURE call with Procedure Number 2 to start the remote session
- the REMOTE OS PROCEDURE command code needed changing to &85 (it was &9C)
- the format of the command also needed changing a bit

With the above changes all the commands now work, at least between to Atom nodes.

Given the way the *VIEW command works, it's not surprising this doesn't work correctly with a Beeb (and the documentation confirms this is expected). I was hoping that *REMOTE might work between a Beeb and an Atom, but it doesn't, it just hangs (either way around).

Here's a econet-monitor session showing an Atom (station &AA) trying to take control of a Beeb (station &FD):

Code: Select all

pi@pi4hog:~/PiEconetBridge/utilities $ ./econet-monitor 
Econet Monitor waiting for traffic

0000000a --- PACKET ---
         DST Net/Stn 0x00/0xfd
         SRC Net/Stn 0x00/0xaa
00000000 fd 00 aa 00 85 00 02 00 ca 03                                                                   ..........
0000000a --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0xfd
00000000 aa 00 fd 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0xfd
         SRC Net/Stn 0x00/0xaa
00000000 fd 00 aa 00 ca                                                                                  .....
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0xfd
00000000 aa 00 fd 00                                                                                     ....
00000004 --- END ---

And for reference a good session betweem two Atoms:

Code: Select all

pi@pi4hog:~/PiEconetBridge/utilities $ ./econet-monitor 
Econet Monitor waiting for traffic

0000000a --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00 85 00 02 00 8d 01                                                                   ..........
0000000a --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00 8d                                                                                  .....
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c2                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 3e                                                                                  ....>
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c1                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 3e                                                                                  ....>
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00 80 c1                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00 48                                                                                  ....H
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c2                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 48                                                                                  ....H
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c1                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 48                                                                                  ....H
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00 80 c1                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00 45                                                                                  ....E
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c2                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 45                                                                                  ....E
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c1                                                                               ......
00000006 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c1                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 45                                                                                  ....E
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00 80 c1                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00 4c                                                                                  ....L
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c2                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 4c                                                                                  ....L
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c1                                                                               ......
00000006 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c1                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 4c                                                                                  ....L
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00 80 c1                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00 4c                                                                                  ....L
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c2                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 4c                                                                                  ....L
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c1                                                                               ......
00000006 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c1                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 4c                                                                                  ....L
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00 80 c1                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00 4f                                                                                  ....O
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c2                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 4f                                                                                  ....O
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 80 c1                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

00000005 --- PACKET ---
         DST Net/Stn 0x00/0xaa
         SRC Net/Stn 0x00/0x03
00000000 aa 00 03 00 4f                                                                                  ....O
00000005 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0x03
         SRC Net/Stn 0x00/0xaa
00000000 03 00 aa 00                                                                                     ....
00000004 --- END ---

The updated command sources are here:
https://github.com/hoglet67/AtomEconet/ ... r/commands

Looking at the REMOTE source, it's expecting callback packets (C1 = OSRDCH, C2 = OSWRCH), these never arrive from the Beeb. More debugging needed....

Is there any documentation on the protocols used by *REMOTE?

Dave