Econet to AUN bridge on Raspberry Pi - released

discuss both original and modern hardware for the bbc micro/electron
User avatar
arg
Posts: 439
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

cr12925 wrote:
Sat Oct 09, 2021 6:08 pm
Ah. I may have misunderstood how the fifo works.
I'm only 99% sure myself, as the documentation is poor. I had a quick glance at the actual implementation to make sure I wasn't spouting total rubbish...
cr12925
Posts: 171
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

arg wrote:
Sat Oct 09, 2021 6:13 pm
cr12925 wrote:
Sat Oct 09, 2021 6:08 pm
Ah. I may have misunderstood how the fifo works.
I'm only 99% sure myself, as the documentation is poor. I had a quick glance at the actual implementation to make sure I wasn't spouting total rubbish...
I did notice the docs were not as informative as they might be…
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
cr12925
Posts: 171
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

Ok... latest findings.

Today I've made a cut down 'monitor only' kernel module, but it doesn't change much in terms of performance on its own. I've tried all sorts, including inserting the odd barrier here and there. What seems to happen is that sometimes data that should be in the middle of a packet ends up at byte 0 in the buffer (where the destination station should be). Now, there's already protection in the code which will discontinue reception if we get the RDA bit set (received data available) with the packet pointer at 0, because we should only get AP (address present) at that stage, so this isn't some weird thing where we're assuming (as the old module did) that RDA was as good as AP with ptr == 0.

There may be some weird problem with updating the packet pointer, but given that the whole IRQ routine is protected by a spinlock, that seems unlikely. I have been wondering if there is some bizarre bug whereby we get AP set, but the packet pointer (ptr) doesn't update or somesuch. It's very odd.

(I have confirmed that the erroneous data we see on PiZero and 3 in the monitor is indeed what the kernel is dumping to userspace, so it isn't a bug in userspace - though I have taken steps check that too.)

I noticed on boot there was a message saying an 'on demand CPU governor was being enabled' unless shift was pressed. So I booted with shift held down, and that improved reliability. It was even better when I ran the monitor on an SSH connection - probably because there were no screen writes for reasons discussed earlier. In both cases, even on a 3, packets were being missed - but fewer of them, and there were fewer erroneous packets too.

Oddly, running the bridge seemed fairly reliable - but that may be because it discontinues packets it is not interested in anyway. Reliable on reception anyway - transmission on a Pi3 (and probably 0) suffered from more collisions than on a 4, so that loading anything of meaningful size off the PiFS failed.

Still loads of IRQs when the ADLC did not appear to have its IRQ bit set, too - and RX Idle interrupts when the line was not very idle (I was doing a repeated *LOAD of a 16k file from a real Beeb from a v1 PiFS). (4120 reps and counting...)

Really can't work out what this is - but it might not be happening in AUN mode, which is just downright odd. (Then again, it might just be jettisoning packets...)

If I can sort out the collisions on transmit, the bridge itself may well work on a 3 or 0. However, if, for example, I have a slightly dodgy v2 hardware implementation, those might simply be mis-reads of SR1. That might also explain the dodgy packets, since a misread of SR2 could be flagging AP when it shouldn't be, so that I'm reading what I think is the start of a packet that isn't.

Ken - any chance you could try the latest dev push on your v2 hardware, just in case I have an odd hardware issue here please? Another logic trace might be handy too, whilst running the monitor on a repeated *Load between two beebs, see if you get malformed packets and, if you do, what the logic analyser shows.

For info, my experimentation has revealed that when I put X bytes into the fifo, I then try to retrieve a record in econet_readfd() and I'll get the same number of bytes out as a record. Thus the routine which ditches a record off the fifo will actually be ditching a complete packet. Removing that made no odds to the problem... nice idea though. I also tried a variant which only put a packet on the fifo if the fifo was empty - that didn't solve it either, so it's something more deep rooted - hence my thought that it may be a hardware problem with my v2 breadboard.

Best

C.
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
User avatar
KenLowe
Posts: 2143
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by KenLowe »

cr12925 wrote:
Sun Oct 10, 2021 12:58 pm
Ken - any chance you could try the latest dev push on your v2 hardware, just in case I have an odd hardware issue here please? Another logic trace might be handy too, whilst running the monitor on a repeated *Load between two beebs, see if you get malformed packets and, if you do, what the logic analyser shows.
Results seem pretty similar to the previous version. With the monitor, Pi3 is definitely better than PiZero, but both do loose packets and incorrectly report station / net, with both limited logging and full logging.

With PiZero in bridge mode, I see the following when I try to *LOAD a file from the Pi FS. I don't think I've seen that error before:

Code: Select all

   FS:            from   0.248 Load ADFS130
L-->E: to   0.248 from   0.253 port 0x90 ctrl 0x80 seq 0x00004020 len 0x0010 00 . 00 . 00 . 30 0 00 . 00 . 00 . 30 0 00 . 00 . 00 . 40 @ 00 . 03 . 0c . 59 Y
L-->E: to   0.248 from   0.253 port 0x92 ctrl 0x80 seq 0x00004024 len 0x0500 00 . 00 . 00 . 4c L a3 . 9a . 82 . 18 . 30 0 41 A 63 c 6f o 72 r 6e n 20   41 A 44 D 46 F 53 S 00 . 31 1 2e . 33 3 30 0 00 . 28 ( 43 C 29 ) 31 1 39 9 38 8 33 3 20   41 A 63 c 6f o 72 r 6e n 00 . a0 .  ...
L-->E: to   0.248 from   0.253 port 0x92 ctrl 0x80 seq 0x00004028 len 0x0500 03 . d0 . e9 . 28 ( a6 . b2 . f0 . 63 c 18 . 08 . a0 . 00 . 28 ( bd . fd . 0d . 7d } fd . 0e . 08 . d9 . 34 4 10 . f0 . 06 . a6 . b2 . 28 ( 4c L 6b k 85 . e8 . c8 . c0 . 03 . d0 . e7 . 28 ( a6 . b2 .  ...
ERROR: to   0.248 from   0.253 - Unknown error (ffffff02)
E-->L: to   0.253 from   0.248 port 0x99 ctrl 0x80 seq 0x00004020 len 0x0007 90 . 12 . 01 . 02 . 03 . 06 . 0d .
L-->E: to   0.248 from   0.253 port 0x90 ctrl 0x80 seq 0x0000402c len 0x0011 00 . 00 . 02 . 00 . 0a . 4b K 45 E 4e N 20   20   20   20   20   20   20   00 . 0d .
E-->L: to   0.253 from   0.248 port 0x99 ctrl 0x80 seq 0x00004024 len 0x0006 90 . 15 . 01 . 02 . 03 . 02 .
L-->E: to   0.248 from   0.253 port 0x90 ctrl 0x80 seq 0x00004030 len 0x0027 00 . 00 . 10 . 53 S 6b k 69 i 64 d 6f o 67 g 2d - 30 0 31 1 20   20   20   20   20   20   20   4b K 45 E 4e N 20   20   20   20   20   20   20   4c L 69 i 62 b 72 r 61 a 72 r 79 y 20   20   20
E-->L: to   0.253 from   0.248 port 0x99 ctrl 0x80 seq 0x00004028 len 0x0009 90 . 03 . 01 . 02 . 03 . 03 . 00 . 0b . 0d .
L-->E: to   0.248 from   0.253 port 0x90 ctrl 0x80 seq 0x00004034 len 0x00d6 00 . 00 . 0b . 0b . 21 ! 42 B 4f O 4f O 54 T 20   20   20   20   20   20   20   20   57 W 52 R 2f / 20   20   00 . 41 A 44 D 46 F 53 S 31 1 33 3 30 0 20   20   20   20   20   20   57 W 52 R 2f / 20    ...
E-->L: to   0.253 from   0.248 port 0x99 ctrl 0x80 seq 0x0000402c len 0x0009 90 . 03 . 01 . 02 . 03 . 03 . 0b . 0b . 0d .
L-->E: to   0.248 from   0.253 port 0x90 ctrl 0x80 seq 0x00004038 len 0x002b 00 . 00 . 02 . 02 . 54 T 52 R 41 A 43 C 45 E 52 R 4f O 4d M 20   20   20   20   20   57 W 52 R 2f / 20   20   00 . 5a Z 4f O 52 R 4b K 31 1 20   20   20   20   20   20   20   44 D 57 W 52 R 2f / 20    ...
E-->L: to   0.253 from   0.248 port 0x99 ctrl 0x80 seq 0x00004030 len 0x0009 90 . 03 . 01 . 02 . 03 . 03 . 0d . 0b . 0d .
L-->E: to   0.248 from   0.253 port 0x90 ctrl 0x80 seq 0x0000403c len 0x0005 00 . 00 . 00 . 00 . 80 .
E-->L: to   0.253 from   0.248 port 0x99 ctrl 0x80 seq 0x00004034 len 0x000d 90 . 02 . 92 . 02 . 03 . 41 A 44 D 46 F 53 S 31 1 33 3 30 0 0d .
   FS:            from   0.248 Load ADFS130
L-->E: to   0.248 from   0.253 port 0x90 ctrl 0x80 seq 0x00004040 len 0x0010 00 . 00 . 00 . 30 0 00 . 00 . 00 . 30 0 00 . 00 . 00 . 40 @ 00 . 03 . 0c . 59 Y
L-->E: to   0.248 from   0.253 port 0x92 ctrl 0x80 seq 0x00004044 len 0x0500 00 . 00 . 00 . 4c L a3 . 9a . 82 . 18 . 30 0 41 A 63 c 6f o 72 r 6e n 20   41 A 44 D 46 F 53 S 00 . 31 1 2e . 33 3 30 0 00 . 28 ( 43 C 29 ) 31 1 39 9 38 8 33 3 20   41 A 63 c 6f o 72 r 6e n 00 . a0 .  ...
L-->E: to   0.248 from   0.253 port 0x92 ctrl 0x80 seq 0x00004048 len 0x0500 03 . d0 . e9 . 28 ( a6 . b2 . f0 . 63 c 18 . 08 . a0 . 00 . 28 ( bd . fd . 0d . 7d } fd . 0e . 08 . d9 . 34 4 10 . f0 . 06 . a6 . b2 . 28 ( 4c L 6b k 85 . e8 . c8 . c0 . 03 . d0 . e7 . 28 ( a6 . b2 .  ...
ERROR: to   0.248 from   0.253 - Unknown error (ffffff02)
PiZero monitoring 16k file by *LOAD ADFS130 3000:

Code: Select all

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

ECO->:to   0.239 from   0.248  size 000a 88 00 00 1e 00 00                                            ......
ECO->:to   0.248 from   0.239  size 0008 01 00 60 03                                                  ..`.
ECO->:to   0.239 from   0.248  size 0006 80 99                                                        ..
ECO->:to   0.248 from   0.239  size 0004
ECO->:to   0.239 from   0.248  size 0012 90 00 01 02 03 49 20 61 6d 20 4b 45 4e 0d                    .....I am KEN.
ECO->:to   0.248 from   0.239  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 90                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 000a 05 00 01 02 04 00                                            ......
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.239 from   0.248  size 0006 80 99                                                        ..
ECO->:to   0.248 from   0.239  size 0004
ECO->:to   0.239 from   0.248  size 0011 90 02 92 02 04 41 44 46 53 31 33 30 0d                       .....ADFS130.
ECO->:to   0.248 from   0.239  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 90                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0022 0e 00 00 80 ff ff 00 80 ff ff 00 40 00 0f 55 87 41 44 46 53  ...........@..U.ADFS
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 00 00 00 4c a3 9a 82 18 30 41 63 6f 72 6e 20 41 44 46 53 00  ...L....0Acorn ADFS.
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 03 d0 e9 28 a6 b2 f0 63 18 08 a0 00 28 bd fd 0d 7d fd 0e 08  ...(...c....(...}...
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 8e 1b 10 ad 2d 10 8d 15 11 8d 1c 10 ad 2c 10 8d 14 11 8d 1d  ....-........,......
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 04 bd 1e 10 9d 15 10 ca d0 f7 a9 0a 8d 1a 10 a9 00 8d 1e 10  ....................
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 db e6 b7 b0 d7 ad 2b 10 c9 04 f0 10 a9 86 20 f4 ff 8a d0 05  ......+....... .....
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 10 ef b1 f2 c9 21 b0 dd 20 a7 9d a2 00 bd e3 9e 30 c1 20 a0  .....!.. .......0. .
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 41 90 98 c9 47 b0 94 e9 36 9d 15 10 ca 10 db e8 20 5a a3 30  A...G...6....... Z.0
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 a0 03 b9 70 10 99 14 11 e0 00 f0 03 9d 1a 10 e8 88 10 ef 20  ...p...............
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 8c d5 10 c0 3a b0 e2 98 38 e9 30 90 dc 85 cf aa bd ac 11 f0  ....:...8.0.........
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 d5 c9 d0 1c ca 10 f6 ad 9a 10 8d b7 10 20 80 b9 20 d3 89 20  ............. .. ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 90                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 00 00                                                        ..
ECO->:to   0.239 from   0.248  size 0004

Code: Select all

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

ECO->:to   0.239 from   0.248  size 000a 88 00 00 1e 00 00                                            ......
ECO->:to   0.248 from   0.239  size 0008 01 00 60 03                                                  ..`.
ECO->:to   0.239 from   0.248  size 0006 80 99                                                        ..
ECO->:to   0.248 from   0.239  size 0004
ECO->:to   0.239 from   0.248  size 0012 90 00 01 02 04 49 20 61 6d 20 4b 45 4e 0d                    .....I am KEN.
ECO->:to   0.248 from   0.239  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 90                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 000a 05 00 01 02 04 00                                            ......
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.239 from   0.248  size 0006 80 99                                                        ..
ECO->:to   0.248 from   0.239  size 0004
ECO->:to   0.239 from   0.248  size 0011 90 02 92 02 04 41 44 46 53 31 33 30 0d                       .....ADFS130.
ECO->:to   0.248 from   0.239  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 90                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0022 0e 00 00 80 ff ff 00 80 ff ff 00 40 00 0f 55 87 41 44 46 53  ...........@..U.ADFS
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 00 00 00 4c a3 9a 82 18 30 41 63 6f 72 6e 20 41 44 46 53 00  ...L....0Acorn ADFS.
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.239 from   0.248  size 0004
ECO->:to 101.114 from 117.113  size 038d 69 72 65 64 00 80 02 ca bd 00 0e 99 3a 10 88 10 f6 c8 a6 b3  ired........:.......
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 8e 1b 10 ad 2d 10 8d 15 11 8d 1c 10 ad 2c 10 8d 14 11 8d 1d  ....-........,......
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 04 bd 1e 10 9d 15 10 ca d0 f7 a9 0a 8d 1a 10 a9 00 8d 1e 10  ....................
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 db e6 b7 b0 d7 ad 2b 10 c9 04 f0 10 a9 86 20 f4 ff 8a d0 05  ......+....... .....
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 c0 a2 02 bd 14 11 9d 52 10 ca 10 f7 30 bb a5 c0 f0 26 a9 3b  .......R....0....&.;
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 10 ef b1 f2 c9 21 b0 dd 20 a7 9d a2 00 bd e3 9e 30 c1 20 a0  .....!.. .......0. .
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 41 90 98 c9 47 b0 94 e9 36 9d 15 10 ca 10 db e8 20 5a a3 30  A...G...6....... Z.0
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 a0 03 b9 70 10 99 14 11 e0 00 f0 03 9d 1a 10 e8 88 10 ef 20  ...p...............
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 8c d5 10 c0 3a b0 e2 98 38 e9 30 90 dc 85 cf aa bd ac 11 f0  ....:...8.0.........
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 65 73 00 86 cf 8c a0 10 98 10 03 4c e1 b2 20 df 8f f0 05 a9  es.........L.. .....
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0504 d5 c9 d0 1c ca 10 f6 ad 9a 10 8d b7 10 20 80 b9 20 d3 89 20  ............. .. ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 92                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0404 8d 0e 0d c8 b1 b0 8d 0f 0d 24 a1 30 05 a9 5f 8d 05 0d 24 cd  .........$.0.._...$.
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 80 90                                                        ..
ECO->:to   0.239 from   0.248  size 0004
ECO->:to   0.248 from   0.239  size 0006 00 00                                                        ..
ECO->:to   0.239 from   0.248  size 0004

Code: Select all

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

0000000a --- PACKET ---
         DST Net/Stn 0x00/0xef
         SRC Net/Stn 0x00/0xf8
00000000 ef 00 f8 00 88 00 00 1e 00 00                                                                   ..........
0000000a --- END ---

00000008 --- PACKET ---
         DST Net/Stn 0x00/0xf8
         SRC Net/Stn 0x00/0xef
00000000 f8 00 ef 00 01 00 60 03                                                                         ......`.
00000008 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xef
         SRC Net/Stn 0x00/0xf8
00000000 ef 00 f8 00 80 99                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xf8
         SRC Net/Stn 0x00/0xef
00000000 f8 00 ef 00                                                                                     ....
00000004 --- END ---

00000012 --- PACKET ---
         DST Net/Stn 0x00/0xef
         SRC Net/Stn 0x00/0xf8
00000000 ef 00 f8 00 90 00 01 02 04 49 20 61 6d 20 4b 45 4e 0d                                           .........I am KEN.
00000012 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xf8
         SRC Net/Stn 0x00/0xef
00000000 f8 00 ef 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xf8
         SRC Net/Stn 0x00/0xef
00000000 f8 00 ef 00 80 90                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xef
         SRC Net/Stn 0x00/0xf8
00000000 ef 00 f8 00                                                                                     ....
00000004 --- END ---

0000000a --- PACKET ---
         DST Net/Stn 0x00/0xf8
         SRC Net/Stn 0x00/0xef
00000000 f8 00 ef 00 05 00 01 02 04 00                                                                   ..........
0000000a --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xef
         SRC Net/Stn 0x00/0xf8
00000000 ef 00 f8 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xef
         SRC Net/Stn 0x00/0xf8
00000000 ef 00 f8 00 80 99                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xf8
         SRC Net/Stn 0x00/0xef
00000000 f8 00 ef 00                                                                                     ....
00000004 --- END ---

00000011 --- PACKET ---
         DST Net/Stn 0x00/0xef
         SRC Net/Stn 0x00/0xf8
00000000 ef 00 f8 00 90 02 92 02 04 41 44 46 53 31 33 30 0d                                              .........ADFS130.
00000011 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xf8
         SRC Net/Stn 0x00/0xef
00000000 f8 00 ef 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xf8
         SRC Net/Stn 0x00/0xef
00000000 f8 00 ef 00 80 90                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xef
         SRC Net/Stn 0x00/0xf8
00000000 ef 00 f8 00                                                                                     ....
00000004 --- END ---

00000022 --- PACKET ---
         DST Net/Stn 0x00/0xf8
         SRC Net/Stn 0x00/0xef
00000000 f8 00 ef 00 0e 00 00 80 ff ff 00 80 ff ff 00 40 00 0f 55 87 41 44 46 53 31 33 30 20 20 20 20 20 ...............@..U.ADFS130
00000020 ff 4c                                                                                           .L
00000022 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xef
         SRC Net/Stn 0x00/0xf8
00000000 ef 00 f8 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xf8
         SRC Net/Stn 0x00/0xef
00000000 f8 00 ef 00 80 92                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xef
         SRC Net/Stn 0x00/0xf8
00000000 ef 00 f8 00                                                                                     ....
00000004 --- END ---

00000504 --- PACKET ---
         DST Net/Stn 0x00/0xf8
         SRC Net/Stn 0x00/0xef
00000000 f8 00 ef 00 00 00 00 4c a3 9a 82 18 30 41 63 6f 72 6e 20 41 44 46 53 00 31 2e 33 30 00 28 43 29 .......L....0Acorn ADFS.1.30.(C)
00000020 31 39 38 33 20 41 63 6f 72 6e 00 a0 04 24 cd 10 15 b1 b0 99 26 10 88 d0 f8 a5 cd 09 40 85 cd a9 1983 Acorn...$......&.......@...
00000040 c4 20 06 04 90 f9 60 24 cd 50 0e a9 84 20 06 04 08 78 a5 cd 29 bf 85 cd 28 60 08 ad 41 fc 85 cc . ....`$.P... ...x..)...(`..A...
00000060 ad 41 fc c5 cc d0 f4 28 60 a0 00 a9 01 48 20 56 80 29 02 d0 f9 68 8d 40 fc 8d 42 fc 20 56 80 29 .A.....(`....H V.)...h.@..B. V.)
00000080 02 f0 f9 60 ad 00 10 85 ce 60 4c a6 82 20 05 83 86 b0 84 b1 20 c7 a6 a0 05 b1 b0 c9 2f f0 2b c9 ...`.....`L.. ...... ......./.+.
000000a0 1b f0 27 20 80 80 10 1a 20 c6 80 f0 d6 c9 04 d0 11 a0 19 24 ff 30 d3 38 e9 01 d0 f7 ca d0 f4 88 ..' .... ..........$.0.8........
000000c0 d0 f1 c9 40 f0 04 c6 ce 10 de a5 cd 29 20 d0 21 20 00 ba f0 1b 48 a0 06 b1 b0 0d 17 11 8d d2 10 ...@........) .! ....H..........
000000e0 c8 b1 b0 8d d1 10 c8 b1 b0 8d d0 10 68 8d d3 10 60 a0 06 b1 b0 0d 17 11 30 d6 20 65 80 c8 b1 b0 ............h...`.......0. e....
00000100 85 b2 c8 b1 b0 85 b3 c8 b1 b0 c9 fe 90 07 c8 b1 b0 c9 ff f0 03 20 27 80 a0 05 b1 b0 20 1b 83 c8 ..................... '..... ...
00000120 b1 b0 0d 17 11 8d 33 11 4c 29 81 b1 b0 20 1b 83 20 0f 83 10 05 70 03 c8 d0 f1 a0 05 b1 b0 29 fd ......3.L)... .. ....p........).
00000140 49 08 f0 78 20 0f 83 18 50 01 38 a0 00 24 cd 50 0c a2 27 a0 10 a9 00 08 2a 20 f0 81 28 20 0f 83 I..x ...P.8..$.P..'.....* ..( ..
00000160 30 2c 24 cd 70 16 b0 07 b1 b2 8d 40 fc 90 05 ad 40 fc 91 b2 c8 d0 e6 e6 b3 4c 59 81 b0 08 ad e5 0,$.p......@....@........LY.....
00000180 fe 8d 40 fc 90 d7 ad 40 fc 8d e5 fe b0 cf 20 43 80 20 0f 83 ad 40 fc 20 0f 83 a8 20 56 80 29 01 ..@....@...... C. ...@. ... V.).
000001a0 f0 ef 98 ae 40 fc f0 03 4c 82 82 aa 29 02 f0 03 4c 3a 82 a9 00 a6 b0 a4 b1 29 7f 60 a0 00 24 cd ....@...L...)...L:.......).`..$.
000001c0 70 3e 20 0f 83 30 c7 70 0c b1 b2 8d 40 fc c8 d0 f8 e6 b3 50 ed ad 40 fc 91 b2 c8 d0 f8 e6 b3 70 p> ..0.p....@......P..@........p
000001e0 e1 ee 28 10 d0 08 ee 29 10 d0 03 ee 2a 10 a2 27 a0 10 60 78 20 06 04 a0 00 20 f8 81 20 fb 81 60 ..(....)....*..'..`x .... .. ..`
00000200 a2 27 a0 10 20 0f 83 10 03 4c 8a 81 70 18 08 a9 06 20 ef 81 ea ea ea ad e5 fe 8d 40 fc c8 d0 f4 .'.. ....L..p.... .........@....
00000220 20 dd 81 28 50 de 08 a9 07 20 ef 81 ea ea ea ad 40 fc 8d e5 fe c8 d0 f4 20 dd 81 28 70 c6 20 65  ..(P.... ......@....... ..(p. e
00000240 80 a9 03 aa a8 20 1b 83 ad 33 11 29 e0 20 1b 83 20 1b 83 88 10 fa 20 0f 83 ad 40 fc 9d d0 10 ca ..... ...3.). .. ..... ...@.....
00000260 10 f4 ad 33 11 29 e0 0d d2 10 8d d2 10 20 0f 83 ae d3 10 ad 40 fc 20 0f 83 ac 40 fc d0 08 29 02 ...3.)....... ......@. ...@...).
00000280 d0 04 8a 4c b1 81 a9 ff 4c b1 81 a2 15 a0 10 20 89 80 d0 0a 60 ad 2f 10 8d 17 11 4c d7 8b c9 25 ...L....L...... ....`./....L...%
000002a0 f0 f3 c9 65 f0 ef c9 6f d0 13 a9 7e 20 f4 ff 20 76 84 20 48 83 11 45 73 63 61 70 65 00 c9 04 d0 ...e...o...~ .. v. H..Escape....
000002c0 14 20 48 83 cd 44 72 69 76 65 20 6e 6f 74 20 72 65 61 64 79 00 c9 40 f0 13 20 d3 89 aa 20 53 83 . H..Drive not ready..@.. ... S.
000002e0 c7 44 69 73 63 20 65 72 72 6f 72 00 20 2b 83 c9 44 69 73 63 20 70 72 6f 74 65 63 74 65 64 00 20 .Disc error. +..Disc protected.
00000300 01 83 d0 9a 60 20 1b 83 60 a9 01 08 58 28 24 cd d0 f7 60 48 20 56 80 29 20 f0 f9 68 24 cc 60 20 ....` ..`...X($...`H V.) ..h$.`
00000320 0f 83 70 06 8d 40 fc a9 00 60 68 68 4c 8a 81 ae 2f 10 e8 d0 17 ae 2e 10 e8 d0 0b a0 02 b9 14 11 ..p..@...`hhL.../...............
00000340 99 2c 10 88 10 f7 ad 17 11 8d 2f 10 20 d3 89 a5 cd 29 ef 85 cd a2 00 68 85 b2 68 85 b3 a5 cd 29 .,......../. ....).....h..h....)
00000360 ef 85 cd a0 00 c8 b1 b2 99 00 01 d0 f8 8a f0 4f a9 20 99 00 01 8a c9 30 b0 06 20 2d 84 4c 83 83 ...............O. .....0.. -.L..
00000380 c9 3a b0 f6 20 49 84 a2 04 c8 bd 1c 84 99 00 01 ca 10 f6 ad d2 10 0a 2a 2a 2a 20 3e 84 c8 99 00 .:.. I.................*** >....
000003a0 01 a9 2f c8 99 00 01 ad d2 10 29 1f a2 02 d0 03 bd d0 10 20 2d 84 ca 10 f7 c8 a9 00 99 00 01 ad ../.......)........ -...........
000003c0 d5 10 f0 32 a2 0b 88 bd 21 84 c8 99 00 01 ca 10 f6 ad d5 10 20 49 84 98 48 a9 c6 8d d8 10 20 a0 ...2....!........... I..H..... .
000003e0 84 ec d5 10 08 a2 99 28 f0 07 cc d5 10 d0 05 a2 9c 20 a7 84 68 a8 ad ce 10 d0 03 20 a2 a7 a9 00 .......(......... ..h...... ....
00000400 8d 00 01 99 01 01 20 43 80 ad 01 01 c9 c7 d0 0d a2 9c 20 a7 84 a2 99 20 a7 84 20 76 84 4c 00 01 ...... C.......... .... .. v.L..
00000420 3a 20 74 61 20 20 6c 65 6e 6e 61 68 63 20 6e 6f 20 48 4a 4a 4a 4a 20 36 84 68 20 3e 84 c8 99 00 : ta  lennahc no HJJJJ 6.h >....
00000440 01 60 29 0f 09 30 c9 3a 90 02 69 06 60 2c 5f 84 a2 64 20 59 84 a2 0a 20 59 84 b8 a2 01 08 86 b3 .`)..0.:..i.`,_..d Y... Y.......
00000460 a2 2f 38 e8 e5 b3 b0 fb 65 b3 28 48 8a 50 05 c9 30 f0 05 b8 c8 99 00 01 68 60 a2 0c a9 ff 9d 2b ./8.....e.(H.P..0.......h`.....+
00000480 10 9d 13 11 ca d0 f7 20 49 a1 20 49 a1 a0 00 98 99 00 0f 99 00 0e 99 00 12 c8 d0 f4 60 45 2e 0d ....... I. I................`E..
000004a0 53 50 2e 0d a0 ff a2 00 4c f4 ff a0 84 4c f7 ff 0d 53 45 59 00 48 75 67 6f ad 37 10 0d 38 10 0d SP......L....L...SEY.Hugo.7..8..
000004c0 39 10 d0 01 60 a2 00 ec fe 0f b0 32 e8 e8 e8 86 b2 a0 02 ca bd 00 0e d9 34 10 b0 04 a6 b2 d0 e7 9...`......2............4.......
000004e0 d0 03 88 10 ee a6 b2 ca ca ca 86 b2 18 08 a0 00 28 b9 34 10 79 37 10 08 dd 00 0e f0 04 28 4c 88 ................(.4.y7.......(L.
00000500 85 e8 c8 c0                                                                                     ....
00000504 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xef
         SRC Net/Stn 0x00/0xf8
00000000 ef 00 f8 00                                                                                     ....
00000004 --- END ---

00000006 --- PACKET ---
         DST Net/Stn 0x00/0xf8
         SRC Net/Stn 0x00/0xef
00000000 f8 00 ef 00 80 92                                                                               ......
00000006 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xef
         SRC Net/Stn 0x00/0xf8
00000000 ef 00 f8 00                                                                                     ....
00000004 --- END ---

00000504 --- PACKET ---
         DST Net/Stn 0x00/0xf8
         SRC Net/Stn 0x00/0xef
00000000 f8 00 ef 00 03 d0 e9 28 a6 b2 f0 63 18 08 a0 00 28 bd fd 0d 7d fd 0e 08 d9 34 10 f0 06 a6 b2 28 .......(...c....(...}....4.....(
00000020 4c 6b 85 e8 c8 c0 03 d0 e7 28 a6 b2 a0 00 18 08 28 bd fd 0e 79 37 10 9d fd 0e 08 e8 c8 c0 03 d0 Lk.......(......(...y7..........
00000040 ef 28 a0 02 a6 b2 18 bd fd 0e 7d 00 0f 9d fd 0e e8 88 10 f3 ec fe 0f b0 0f bd 00 0f 9d fd 0e bd .(........}.....................
00000060 00 0e 9d fd 0d e8 d0 ec ca ca ca 8e fe 0f 60 a0 00 18 08 b9 34 10 9d 00 0e 28 bd 00 0f 79 37 10 ..............`.....4....(...y7.
00000080 9d 00 0f 08 c8 e8 c0 03 d0 e9 28 60 a6 b2 f0 35 18 08 a0 00 28 bd fd 0d 7d fd 0e 08 d9 34 10 f0 ..........(`...5....(...}....4..
000000a0 04 28 4c c1 85 e8 c8 c0 03 d0 e9 28 a0 00 a6 b2 18 08 28 bd fd 0e 79 37 10 9d fd 0e 08 e8 c8 c0 .(L........(......(...y7........
000000c0 03 d0 ef 28 60 ad fe 0f c9 f6 90 0d 20 2b 83 99 4d 61 70 20 66 75 6c 6c 00 ae fe 0f e4 b2 f0 10 ...(`....... +..Map full........
000000e0 ca bd 00 0e 9d 03 0e bd 00 0f 9d 03 0f 4c d8 85 a0 00 b9 34 10 9d 00 0e b9 37 10 9d 00 0f e8 c8 .............L.....4.....7......
00000100 c0 03 d0 ee ad fe 0f 69 02 8d fe 0f 60 a2 00 8e 5d 10 8e 5e 10 8e 5f 10 ec fe 0f f0 ef a0 00 18 .......i....`...]..^.._.........
00000120 08 28 bd 00 0f 79 5d 10 99 5d 10 08 c8 e8 c0 03 d0 ef 28 4c 14 86 a2 ff 86 b3 e8 ec fe 0f 90 7c .(...y]..]........(L...........|
00000140 a6 b3 e0 ff d0 3a 20 09 86 a0 00 a2 02 38 b9 5d 10 f9 3d 10 c8 ca 10 f6 b0 0e 20 2b 83 c6 44 69 .....: ......8.]..=....... +..Di
00000160 73 63 20 66 75 6c 6c 00 20 2b 83 98 43 6f 6d 70 61 63 74 69 6f 6e 20 72 65 71 75 69 72 65 64 00 sc full. +..Compaction required.
00000180 a0 02 ca bd 00 0e 99 3a 10 88 10 f6 c8 a6 b3 18 08 28 bd fd 0d 79 3d 10 9d fd 0d 08 e8 c8 c0 03 .......:.........(...y=.........
000001a0 d0 ef 28 a0 00 a6 b3 38 08 28 bd fd 0e f9 3d 10 9d fd 0e 08 e8 c8 c0 03 d0 ef 28 60 a0 02 e8 e8 ..(....8.(....=...........(`....
000001c0 e8 86 b2 ca bd 00 0f d9 3d 10 90 3b d0 30 88 10 f2 a6 b2 a0 02 ca bd 00 0e 99 3a 10 88 10 f6 a6 ........=..;.0............:.....
000001e0 b2 ec fe 0f b0 0f bd 00 0e 9d fd 0d bd 00 0f 9d fd 0e e8 d0 ec ad fe 0f e9 03 8d fe 0f 60 a6 b3 .............................`..
00000200 e8 d0 04 a5 b2 85 b3 a6 b2 4c 37 86 e6 b4 d0 02 e6 b5 60 20 cf a4 20 6e 8d a0 00 8c c0 10 b1 b4 .........L7.......` .. n........
00000220 29 7f c9 2e f0 08 c9 22 f0 04 c9 20 b0 02 a2 00 60 a0 0a 20 1a 87 f0 10 88 10 f8 20 48 83 cc 42 )......"... ....`.. ....... H..B
00000240 61 64 20 6e 61 6d 65 00 a0 09 b1 b6 29 7f 99 62 10 88 10 f6 c8 a2 00 e0 0a b0 41 bd 62 10 c9 21 ad name.....)..b..........A.b..!
00000260 90 3a 09 20 8d 2b 10 c0 0a b0 1b 20 1a 87 f0 1b c9 2a f0 38 c9 23 f0 09 09 20 cd 2b 10 90 0c d0 .:. .+..... .....*.8.#... .+....
00000280 04 e8 c8 d0 d2 60 20 1a 87 d0 b0 20 1a 87 c9 23 f0 17 c9 2a f0 13 88 10 f2 c9 ff 60 c0 0a f0 e5 .....` .... ...#...*.......`....
000002a0 20 1a 87 f0 e0 c9 2a f0 03 c9 00 60 c8 bd 62 10 29 7f c9 21 90 1d e0 0a b0 19 8a 48 98 48 20 53  .....*....`..b.)..!.......H.H S
000002c0 87 f0 0a 68 a8 68 aa e8 d0 e3 e0 00 60 68 68 a9 00 38 60 c0 0a b0 f8 b1 b4 c9 21 90 f2 c9 2e f0 ...h.h......`hh..8`.......!.....
000002e0 ee c9 22 f0 ea c9 2a f0 c3 d0 df 20 cf a4 20 c5 93 20 de a6 a0 00 b1 b6 f0 13 20 2d 87 f0 10 90 .."...*.... .. .. ........ -....
00000300 0e a5 b6 69 19 85 b6 90 eb e6 b7 d0 e7 c9 0f 60 01 00 0e ff ff 08 00 00 00 02 00 01 00 12 ff ff ...i...........`................
00000320 08 00 00 02 05 00 c9 30 90 23 c9 38 90 0c 09 20 c9 61 90 19 c9 69 b0 15 e9 00 48 a5 cd 29 20 d0 .......0.#.8... .a...i....H..) .
00000340 04 68 29 03 48 68 29 07 4a 6a 6a 6a 60 4c 37 87 20 0f 87 f0 f8 20 0f 87 f0 1f c9 3a d0 6a 20 08 .h).Hh).Jjjj`L7. .... .....:.j .
00000360 87 ae 2f 10 e8 d0 06 ad 17 11 8d 2f 10 20 1a 87 20 22 88 8d 17 11 20 08 87 ae 17 11 e8 d0 03 8e ../......../. .. ".... .........
00000380 17 11 a5 cd 09 10 85 cd a2 0c a0 88 20 8b 82 a5 cd 29 ef 85 cd ad 2e 10 10 0b a0 02 b9 14 11 99 ............ ....)..............
000003a0 2c 10 88 10 f7 a0 88 a2 17 20 8b 82 a9 02 8d 14 11 a9 00 8d 15 11 8d 16 11 20 68 b4 a0 00 20 1a ,........ ............... h... .
000003c0 87 c9 2e d0 24 20 08 87 a0 00 20 1a 87 29 fd c9 24 f0 a3 20 f5 b4 20 4f 94 d0 28 c8 8c a2 10 20 ....$ .... ..)..$.. .. O..(....
000003e0 1a 87 c9 2e d0 22 4c 91 89 a9 24 8d 62 10 a9 0d 8d 63 10 a9 cc 85 b6 a9 94 85 b7 a9 02 8d c0 10 ....."L...$.b....c..............
00000400 a9 00 60 20 e7 87 f0 35 60 a5 b4 48 a5 b5 48 98 18 65 b4 85 b4 a9 00 65 b5 85 b5 20 cf a4 a5 b4 ..` ...5`..H..H..e.....e... ....
00000420 8d d6 10 a5 b5 8d d7 10 68 85 b5 68 85 b4 a2 01 a0 03 b1 b6 10 01 e8 8e c0 10 a9 00 60 a0 00 20 ........h..h................`..
00000440 1a 87 c9 21 90 c3 c9 22 f0 bf c9 2e f0 03 c8 d0 ee 8c a2 10 a0 03 b1 b6 30 1f 20 5e 89 f0 f5 a9 ...!..."................0. ^....
00000460 ff 60 18 a5 b6 69 1a 85 b6 90 02 e6 b7 a0 00 b1 b6 f0 ec 20 2d 87 d0 ea 60 a0 09 b1 b6 10 16 29 .`...i............. -...`......)
00000480 7f 91 b6 20 86 8f 20 48 83 b0 42 61 64 20 72 65 6e 61 6d 65 00 ad a2 10 38 65 b4 85 b4 90 02 e6 ... .. H..Bad rename....8e......
000004a0 b5 ad 2e 10 c9 ff d0 0b a0 02 b9 14 11 99 2c 10 88 10 f7 a2 0a bd 17 88 9d 15 10 ca 10 f7 a2 02 ..............,.................
000004c0 a0 16 b1 b6 9d 1b 10 99 fe 10 c8 ca 10 f4 20 87 82 4c d2 88 ad c0 10 48 ad 2f 10 c9 ff f0 0f 8d .............. ..L.....H./......
000004e0 17 11 a9 ff 8d 2f 10 a2 0c a0 88 20 8b 82 ad 2e 10 c9 ff f0 2c aa a0 0a b9 17 88 99 15 10 88 10 ...../..... ........,...........
00000500 f7 8e 16 11                                                                                     ....
00000504 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x00/0xef
         SRC Net/Stn 0x00/0xf8
00000000 ef 00 f8 00                                                                                     ....
00000004 --- END ---

00000004 --- PACKET ---
         DST Net/Stn 0x80/0xef
         SRC Net/Stn 0x02/0xf8
00000000 ef 80 f8 02                                                                                     ....
00000004 --- END ---
User avatar
arg
Posts: 439
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

cr12925 wrote:
Sun Oct 10, 2021 12:58 pm
For info, my experimentation has revealed that when I put X bytes into the fifo, I then try to retrieve a record in econet_readfd() and I'll get the same number of bytes out as a record. Thus the routine which ditches a record off the fifo will actually be ditching a complete packet.
OK, sorry you are right and I got it wrong. The magic is in the fact that you declared econet_rx_queue as kfifo_rec_ptr_2 which via some amazing contortions of macros ends up adding a 2-byte field to the front of each record written. kfifo_in() ends up in a call to __kfifo_in_r() which either writes the entire packet plus the (in this case) 2-byte header, or writes nothing at all if no space. Vanilla kqueues are just byte queues with no record structure and kfifo_in() on such a queue that is nearly full will write as many bytes as will fit and discard the rest.

For reference:
https://elixir.bootlin.com/linux/v5.10. ... ifo.h#L519
https://elixir.bootlin.com/linux/v5.10. ... ifo.c#L438

Back on topic, did you push the source of the stripped-down driver anywhere?
dp11
Posts: 1332
Joined: Sun Aug 12, 2012 9:47 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by dp11 »

I think I would measure with a scope the worst case time between nIRQ being asserted and nCS going low.
cr12925
Posts: 171
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

What are the semantics of AUN retransmits?

Suppose an AUN box sends an AUN data packet to another AUN station but the ACK or NAK reply gets lost. Does the first station retransmit ?

If so, does it change the sequence number ? If it doesn’t, does the receiver (which will get an apparent duplicate) acknowledge it again but silently drop the duplicate, or might it process it a second time?

(I am working on some retransmit/concurrency stuff in userspace. Given Kl’s similar experiences to mine on v2 hardware on 3 and 0, I am now at a loss on that front, though I suspect the bridge might flukily work given the nature of the addressing corruption because the module will silently drop most of the bad packets as being uninteresting or runts! Not my preferred approach….)

C

Cheers

Chris
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
User avatar
arg
Posts: 439
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

In real AUN:
  • I believe real retransmits are done at user level (like in the classic API for Econet tx where retries are the responsibility of the user program), hence they have distinct sequence numbers - undesirable but the system can’t tell the difference between a retry and a new Tx. Possibly under RiscOS using newer APIs that do retries for you, they might have the same seq
  • Even without deliberate retries with same seq, duplicates can arise due to UDP semantics which permit packts to be duplicated.
  • Receiving systems must ack all received duplicates, as the sender is presumed not to have seen the original ack
  • It’s not actually essential to kill detected duplicates since Econet semantics permit duplicate reception, but obviously desirable
cr12925
Posts: 171
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

arg wrote:
Sun Oct 10, 2021 6:53 pm
In real AUN:
  • I believe real retransmits are done at user level (like in the classic API for Econet tx where retries are the responsibility of the user program), hence they have distinct sequence numbers - undesirable but the system can’t tell the difference between a retry and a new Tx. Possibly under RiscOS using newer APIs that do retries for you, they might have the same seq
Since posting, I found a page on mdfs.net that suggests re-txes are with same sequence number… it would suit my purposes if I can do so - do you think that’ll work? (Sounded like it would from one of your other points…)

Ta

C
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
User avatar
arg
Posts: 439
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

cr12925 wrote:
Sun Oct 10, 2021 7:39 pm
Since posting, I found a page on mdfs.net that suggests re-txes are with same sequence number… it would suit my purposes if I can do so - do you think that’ll work? (Sounded like it would from one of your other points…)
Yes, if you are doing them then it’s the best option. Just don’t rely on everyone else doing so.
User avatar
KenLowe
Posts: 2143
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by KenLowe »

arg wrote:
Sat Oct 02, 2021 11:17 am
Mating connector for the daughterboard: farnell 2847182
That mating connector has actually given me an idea for another problem I hadn't solved to my satisfaction...
KenLowe wrote:
Mon Aug 09, 2021 5:39 pm
Where it becomes a bit more challenging is trying to get the 40 pin RPi header and the dual 5 / 17 pin Econet headers to co-exist on the board. The biggest issue is that when the board is plugged into the RPi, the dual 5 / 17 pin Econet headers would clash with the ethernet & USB sockets on the RPi.
There is sufficient clearance on the underside of the board for me to solder both 5 and 17 pin 90 degree headers (both would need to point inwards), so that when the board is plugged into either the RPi3 or 4, the 90 degree headers will still clear the USB & ethernet sockets. I can then make 2 small adaptor PCBs that have the mating connectors soldered to one side of the board, and the extended header pins on the other side. When using the combo board in Master Econet mode, it would just be a case of sliding these adaptors onto the 90 degree headers, and then plugging the board into the Master. The adaptor PCB might need to be slightly thicker (2mm) than standard so that the solder ends of the header pins don't stick out beyond the top of the PCB - otherwise they might clash with the black plastic surround that holds the pins together in the 90 degree headers (I'm not sure what the proper name is for that part of the header!). I think that should work!

Looks like Toby could get me the parts in the correct lengths:

BCS-105-F-S-HE
BCS-117-F-S-HE

These exact parts are not listed on their site, but they will normally add to their site if you ask.
User avatar
arg
Posts: 439
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

KenLowe wrote:
Mon Oct 11, 2021 12:16 am
There is sufficient clearance on the underside of the board for me to solder both 5 and 17 pin 90 degree headers (both would need to point inwards), so that when the board is plugged into either the RPi3 or 4, the 90 degree headers will still clear the USB & ethernet sockets. I can then make 2 small adaptor PCBs that have the mating connectors soldered to one side of the board, and the extended header pins on the other side. When using the combo board in Master Econet mode, it would just be a case of sliding these adaptors onto the 90 degree headers, and then plugging the board into the Master. The adaptor PCB might need to be slightly thicker (2mm) than standard so that the solder ends of the header pins don't stick out beyond the top of the PCB - otherwise they might clash with the black plastic surround that holds the pins together in the 90 degree headers (I'm not sure what the proper name is for that part of the header!). I think that should work!
If going with that idea, I'd suggest adding a duplicate set of holes for the 5-pin, so that both of the 90-deg headers point in the same direction - you can then have a single adaptor PCB rather than two, and it feels like it will be a lot more stable.

However, that all sounds a bit fiddly. If the objective is to make the Master pins demountable, how about going to longer pins and having a socket at the PCB end? Various possibilities, but these (as used on the Atom Econet interface!!) are quite attractive:

https://www.molex.com/molex/products/pa ... 0022142054
https://www.molex.com/molex/products/pa ... 0022173172

which have the socket itself on the top side of the PCB and the pins coming up through holes. The holes are normally small and non-plated in the interest of better registration, but you could hedge your bets and go with PTH (which will need to be slightly larger so as not to stick) so that you have the option to just solder the pins in as per original.

The one snag with this plan is the two fixing holes that are just in the wrong place! The 5-pin could probably fit with the bulky part of the connector facing the other way, leaving room for the fixing hole and just needing you to re-layout the resistors (losing some of your inhibitions about neat rows!), but for the 17-pin either needs the fixing hole to go or else a complete re-layout of most of the board to allow the 6854 to move up.
User avatar
KenLowe
Posts: 2143
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by KenLowe »

arg wrote:
Mon Oct 11, 2021 8:36 am
However, that all sounds a bit fiddly. If the objective is to make the Master pins demountable, how about going to longer pins and having a socket at the PCB end? Various possibilities, but these (as used on the Atom Econet interface!!) are quite attractive:

https://www.molex.com/molex/products/pa ... 0022142054
https://www.molex.com/molex/products/pa ... 0022173172

which have the socket itself on the top side of the PCB and the pins coming up through holes. The holes are normally small and non-plated in the interest of better registration, but you could hedge your bets and go with PTH (which will need to be slightly larger so as not to stick) so that you have the option to just solder the pins in as per original.

The one snag with this plan is the two fixing holes that are just in the wrong place! The 5-pin could probably fit with the bulky part of the connector facing the other way, leaving room for the fixing hole and just needing you to re-layout the resistors (losing some of your inhibitions about neat rows!), but for the 17-pin either needs the fixing hole to go or else a complete re-layout of most of the board to allow the 6854 to move up.
Yeah, that's similar to what I was thinking about earlier:
KenLowe wrote:
Mon Aug 09, 2021 5:39 pm
The second, and more elaborate solution would be to use pass through sockets (something like this) on the bridge board for the 5 / 17 pin Econet headers. These would solder onto the top of the bridge board PCB (with a cut out in the PCB to access the sockets from underneath), and therefore avoid clashing with the RPi ethernet & USB sockets. If you wanted to move the bridge module from the RPi and use it as a plain Econet module for the Master, you would plug in a 5 pin and 17 pin male header strip into the underside of the pass through socket, and then plug the whole thing into the Master. In this mode of operation, the unused 40 pin RPi header would under-hang, but I don't think it would clash with anything on the Master; although I'd need to verify this by measurement.
Those SAMTEC ones seem to take up slightly less space than the Molex ones, but would still require me to move the 6845, which is something I'd prefer not to do at this late stage!

Edit: Moving the 6845 wasn't as much of a challenge as I initially anticipated. It was helped by the fact that I reduced the resistor footprint from 0805 to 0603 earlier. I don't have the correct 3D model for the through board sockets, but you get the idea:
Updated PCB Layout
Updated PCB Layout
3D render with through board sockets for 5 / 17 pin headers
3D render with through board sockets for 5 / 17 pin headers
3D render - underside view
3D render - underside view
User avatar
arg
Posts: 439
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

KenLowe wrote:
Mon Oct 11, 2021 9:57 am
Those SAMTEC ones seem to take up slightly less space than the Molex ones, but would still require me to move the 6845, which is something I'd prefer not to do at this late stage!

Edit: Moving the 6845 wasn't as much of a challenge as I initially anticipated. It was helped by the fact that I reduced the resistor footprint from 0805 to 0603 earlier. I don't have the correct 3D model for the through board sockets, but you get the idea:
Exactly which of those SAMTEC parts have you used? The SMT ones on the datasheet looked to have the connections staggered either side so that whichever way round you used them you still ended up fouling the fixing screw. Your footprint now looks more like the Molex ones?

Seems good if this actually works.
User avatar
KenLowe
Posts: 2143
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by KenLowe »

arg wrote:
Mon Oct 11, 2021 3:46 pm
KenLowe wrote:
Mon Oct 11, 2021 9:57 am
Those SAMTEC ones seem to take up slightly less space than the Molex ones, but would still require me to move the 6845, which is something I'd prefer not to do at this late stage!

Edit: Moving the 6845 wasn't as much of a challenge as I initially anticipated. It was helped by the fact that I reduced the resistor footprint from 0805 to 0603 earlier. I don't have the correct 3D model for the through board sockets, but you get the idea:
Exactly which of those SAMTEC parts have you used? The SMT ones on the datasheet looked to have the connections staggered either side so that whichever way round you used them you still ended up fouling the fixing screw. Your footprint now looks more like the Molex ones?

Seems good if this actually works.
Ah, sorry. I went for a different Valcon component in the end which is very similar to the Molex KK part. So that would be:

B24-05-BGA1
B24-17-BGA1
User avatar
KenLowe
Posts: 2143
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by KenLowe »

arg wrote:
Mon Oct 11, 2021 8:36 am
If the objective is to make the Master pins demountable, how about going to longer pins and having a socket at the PCB end? Various possibilities, but these (as used on the Atom Econet interface!!) are quite attractive:

https://www.molex.com/molex/products/pa ... 0022142054
https://www.molex.com/molex/products/pa ... 0022173172

which have the socket itself on the top side of the PCB and the pins coming up through holes
Just looking at the Molex datasheet a bit further, it looks like you've referenced two different material types. If I've read the datasheet correctly, the 22-14-2xx4 is material P909 (overall tin) whereas 22-17-3xx2 is material 208 (select gold), where xx is the number of circuits. That said, and again if I've read the datasheet correctly, I think the Molex housing (the 4455-N2 part) is just a little bit too big, with an overall width of 7.7mm. For the 17 pin header, I really need the footprint to be no wider than 5.2mm. The Valcon part is only 3.81mm (2.54 + 2.54/2) wide, so it looks like it's probably the better part.
User avatar
arg
Posts: 439
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

KenLowe wrote:
Mon Oct 11, 2021 5:42 pm
Just looking at the Molex datasheet a bit further, it looks like you've referenced two different material types. If I've read the datasheet correctly, the 22-14-2xx4 is material P909 (overall tin) whereas 22-17-3xx2 is material 208 (select gold), where xx is the number of circuits. That said, and again if I've read the datasheet correctly, I think the Molex housing (the 4455-N2 part) is just a little bit too big, with an overall width of 7.7mm. For the 17 pin header, I really need the footprint to be no wider than 5.2mm. The Valcon part is only 3.81mm (2.54 + 2.54/2) wide, so it looks like it's probably the better part.
Yes, I wasn't particularly careful about which ones I selected; in reality it's more a case of what we can get hold of. If using tin pins we don't particularly want any gold at all (though I have a suspicion that the sockets on the Master are gold...), but where the datasheets offer all these combinations, distributors often only stock one.

Anyhow, those Valcon do indeed look a better bet than the Molex.
User avatar
arg
Posts: 439
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

Looking at the layout, I'm now less happy that R4 has got back into the block with other stuff crammed up against it. Probably doesn't really matter.

Your tracking around the new connector is a bit eccentric - looping round from the top row of holes to the bottom ones and then up between. This would make a tiny bit of sense if the top ones were the through holes for the pins (and so might turn non-plated) and the bottom ones to be actually soldered, but I think it's the other way around?
User avatar
KenLowe
Posts: 2143
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by KenLowe »

arg wrote:
Mon Oct 11, 2021 9:12 pm
Looking at the layout, I'm now less happy that R4 has got back into the block with other stuff crammed up against it. Probably doesn't really matter.
Yeah, I wasn't overly happy with the routing around R4 either. I'll revisit that.
arg wrote:
Mon Oct 11, 2021 9:12 pm
Your tracking around the new connector is a bit eccentric - looping round from the top row of holes to the bottom ones and then up between. This would make a tiny bit of sense if the top ones were the through holes for the pins (and so might turn non-plated) and the bottom ones to be actually soldered, but I think it's the other way around?
I fixed that earlier this evening. It wasn't a deliberate routing choice. It's just the way the tracks were originally routed before I added the extra header row. I am planning to keep both rows as PTH. It gives me the option of soldering in a standard header in the lower row.
Revised routing around the 17 pin header
Revised routing around the 17 pin header
cr12925
Posts: 171
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

Ok, something interesting I have noted.

With a v2 breadboard and the latest dev module (which has had a few variables marked volatile but is otherwise the same as the GH push I think), I noticed that occasionally bit 8 will be erroneously read as set when it should be unset when reading the FIFO. I noticed this on watching a directory listing which contained the word "Archive" and it was erroneously read as "Archi.e", where the '.' was read as &f6 instead of &76 (i.e. high bit set when it shouldn't be).

If that were to happen on a register read, it would give an apparent IRQ status (on SR1) when there was no IRQ. Equally, if the read is just wonky in both directions, it would give no IRQ when in fact there was one.

This might be just my breadboard, but since KL is experiencing something similar, I wonder if there may be a hardware problem?

I can find no other reason why we'd get the corrupt packets (which, I have identified, are absolutely plainly packets which start in the middle of a packet's worth of data - so the source/dest station/net numbers are generally actually ASCII data in the case of a directory listing), and I wonder if the Zero and 3 are just not quite quick enough to pick up the data off the data bus level shifter after nCS has gone inactive. I.e. is what is happening that the SR reads are a bit flakey and causing the module to see a new packet when it shouldn't? (E.g. if bit 0 is similarly flakey so as to have flagged address present when it isn't.)

Any ideas?
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
User avatar
KenLowe
Posts: 2143
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by KenLowe »

cr12925 wrote:
Wed Oct 13, 2021 5:55 pm
Ok, something interesting I have noted.

With a v2 breadboard and the latest dev module (which has had a few variables marked volatile but is otherwise the same as the GH push I think), I noticed that occasionally bit 8 will be erroneously read as set when it should be unset when reading the FIFO. I noticed this on watching a directory listing which contained the word "Archive" and it was erroneously read as "Archi.e", where the '.' was read as &f6 instead of &76 (i.e. high bit set when it shouldn't be).
That sounds similar to the issue I reported before, when I couldn't communicate with servers if the station / server number was an odd (or was it even???) number (ie not reading bit 0 correctly). I'm not sure if that was ever properly understood or resolved?
marcelaj1
Posts: 388
Joined: Wed Apr 29, 2020 5:07 pm
Location: Surrey
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by marcelaj1 »

KenLowe wrote:
Wed Oct 13, 2021 6:16 pm
That sounds similar to the issue I reported before, when I couldn't communicate with servers if the station / server number was an odd (or was it even???) number (ie not reading bit 0 correctly). I'm not sure if that was ever properly understood or resolved?
I thought I read that Econet transmissions were checksummed.
Ashley.
cr12925
Posts: 171
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

marcelaj1 wrote:
Wed Oct 13, 2021 6:30 pm
KenLowe wrote:
Wed Oct 13, 2021 6:16 pm
That sounds similar to the issue I reported before, when I couldn't communicate with servers if the station / server number was an odd (or was it even???) number (ie not reading bit 0 correctly). I'm not sure if that was ever properly understood or resolved?
I thought I read that Econet transmissions were checksummed.
Absolutely they are - the suspected issue here is not corruption on the wire side of the ADLC but corruption reading the data and status info off the ADLC on the cpu side.

Best

C
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
User avatar
arg
Posts: 439
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

KenLowe wrote:
Wed Oct 13, 2021 6:16 pm
That sounds similar to the issue I reported before, when I couldn't communicate with servers if the station / server number was an odd (or was it even???) number (ie not reading bit 0 correctly). I'm not sure if that was ever properly understood or resolved?
That was explained by the chip being in extended address mode - if the LSB of the address byte is clear, then the next byte is treated as part of the address also. I think the cause was simply software not explicitly setting the mode (and nRST not forcing it either), but certainly the traces were very clear and consistent (and didn't suggest any hardware failure).

If we do now have hardware issues:
  • There's the possibility of reading the value too early, due to failure to 'see' the BUSY signal. There was no sign of this happening on the traces previously examined, but it's a theoretical possibility as we don't totally understand the bus architecture on the Pi.
  • There's the possibility of reading the byte late and the bus having floated meanwhile. Use of the LVCH part on the final version is intended to fix this, if it is actually a real problem.
  • Long wires picking up interference, ground bounce etc. on breadboards giving problems that real hardware won't show.
  • Something else...
It would be good to get some more analyser captures if it can be persuaded to fail reliably. Last time round it really didn't look like hardware issues, but things may have changed.
User avatar
KenLowe
Posts: 2143
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by KenLowe »

arg wrote:
Wed Oct 13, 2021 9:48 pm
KenLowe wrote:
Wed Oct 13, 2021 6:16 pm
That sounds similar to the issue I reported before, when I couldn't communicate with servers if the station / server number was an odd (or was it even???) number (ie not reading bit 0 correctly). I'm not sure if that was ever properly understood or resolved?
That was explained by the chip being in extended address mode - if the LSB of the address byte is clear, then the next byte is treated as part of the address also. I think the cause was simply software not explicitly setting the mode (and nRST not forcing it either), but certainly the traces were very clear and consistent (and didn't suggest any hardware failure).

If we do now have hardware issues:
  • There's the possibility of reading the value too early, due to failure to 'see' the BUSY signal. There was no sign of this happening on the traces previously examined, but it's a theoretical possibility as we don't totally understand the bus architecture on the Pi.
  • There's the possibility of reading the byte late and the bus having floated meanwhile. Use of the LVCH part on the final version is intended to fix this, if it is actually a real problem.
  • Long wires picking up interference, ground bounce etc. on breadboards giving problems that real hardware won't show.
  • Something else...
It would be good to get some more analyser captures if it can be persuaded to fail reliably. Last time round it really didn't look like hardware issues, but things may have changed.
I can get some analyser captures. dp11 was asking for some scope traces that I can get as well. I've also got a couple of LVCH devices that I can now plug into my breadboard.
User avatar
KenLowe
Posts: 2143
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by KenLowe »

KenLowe wrote:
Thu Oct 14, 2021 2:02 am
I can get some analyser captures. dp11 was asking for some scope traces that I can get as well. I've also got a couple of LVCH devices that I can now plug into my breadboard.
Right, here are some new captures when running monitor on a RPiZero. This is with the very latest code, and using a LVCH level shifter instead of the more standard LVC. I'm seeing the same issues that I saw before. With full logging enabled on the monitor, there is a lot of packet loss. With brief logging enabled, there is significantly less packet loss (perhaps none, but I haven't checked). The screen capture shows the difference between full (left) and brief (right) logging. Both traces are capturing the same 16k *LOAD ADFS130 3000 file transfer between wired station and wired server.
*LOAD ADFS130 3000 with full and brief logging
*LOAD ADFS130 3000 with full and brief logging
1510.zip
Pulseview files
(528.17 KiB) Downloaded 1 time
Edit: When switching to bridge mode (still with the PiZero), and running *LOAD ADFS130 3000 on a BeebEm station to load a file from wired FS 239, I saw the following dmesg errors:

Code: Select all

[Oct15 22:15] ECONET-GPIO: econet_irq_read(): AUN: Valid frame received, length 0504, but was expecting Scout and this wasn't
[  +0.002852] ECONET-GPIO: econet_irq_read(): AUN: Valid frame received, length 0004, but was expecting Scout and this wasn't
[  +0.003171] ECONET-GPIO: econet_irq_read(): RX Overrun
[  +0.109424] ECONET-GPIO: econet_irq_read(): AUN: Valid frame received, length 0504, but was expecting Scout and this wasn't
[  +0.007423] ECONET-GPIO: econet_irq_read(): RX Overrun
[  +0.102649] ECONET-GPIO: econet_irq_read(): AUN: Valid frame received, length 0504, but was expecting Scout and this wasn't
[  +0.007316] ECONET-GPIO: econet_irq_read(): RX Overrun
[  +0.102841] ECONET-GPIO: econet_irq_read(): AUN: Valid frame received, length 0504, but was expecting Scout and this wasn't
[  +0.007127] ECONET-GPIO: econet_irq_read(): RX Overrun
[  +0.102699] ECONET-GPIO: econet_irq_read(): AUN: Valid frame received, length 0504, but was expecting Scout and this wasn't
[  +0.007343] ECONET-GPIO: econet_irq_read(): RX Overrun
[  +0.102802] ECONET-GPIO: econet_irq_read(): AUN: Valid frame received, length 0504, but was expecting Scout and this wasn't
[  +0.007182] ECONET-GPIO: econet_irq_read(): RX Overrun
[  +0.102897] ECONET-GPIO: econet_irq_read(): AUN: Valid frame received, length 0504, but was expecting Scout and this wasn't
[  +0.007103] ECONET-GPIO: econet_irq_read(): RX Overrun
[  +0.103076] ECONET-GPIO: econet_irq_read(): AUN: Valid frame received, length 0504, but was expecting Scout and this wasn't
[  +0.006919] ECONET-GPIO: econet_irq_read(): RX Overrun
[  +0.103120] ECONET-GPIO: econet_irq_read(): AUN: Valid frame received, length 0504, but was expecting Scout and this wasn't
[  +0.006871] ECONET-GPIO: econet_irq_read(): RX Overrun
[  +0.103239] ECONET-GPIO: econet_irq_read(): AUN: Valid frame received, length 0504, but was expecting Scout and this wasn't
[  +0.007871] ECONET-GPIO: econet_irq_read(): RX Overrun
[  +0.102079] ECONET-GPIO: econet_irq_read(): AUN: Valid frame received, length 0504, but was expecting Scout and this wasn't
[  +0.006811] ECONET-GPIO: econet_irq_read(): RX Overrun
[  +0.102486] ECONET-GPIO: econet_irq_read(): AUN: Valid frame received, length 0504, but was expecting Scout and this wasn't
[  +0.007598] ECONET-GPIO: econet_irq_read(): RX Overrun
[  +0.102480] ECONET-GPIO: econet_irq_read(): AUN: Valid frame received, length 0504, but was expecting Scout and this wasn't
[  +0.007498] ECONET-GPIO: econet_irq_read(): RX Overrun
[  +0.073950] ECONET-GPIO: econet_irq_read(): Unhandled state - SR1 = 0xa0, SR1 = 0x80
User avatar
KenLowe
Posts: 2143
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by KenLowe »

dp11 wrote:
Sun Oct 10, 2021 4:43 pm
I think I would measure with a scope the worst case time between nIRQ being asserted and nCS going low.
Here's a zoomed in version of the previous logic traces. Both traces are showing a period where nIRQ has pulsed low.
Trace of *LOAD ADFS130 3000 with full and brief logging. Monitoring period where nIRQ is low
Trace of *LOAD ADFS130 3000 with full and brief logging. Monitoring period where nIRQ is low
Interesting that the left hand trace (where full logging was active and packets were being dropped) that the nCS signal dropped low four times during the period where nIRQ was low. After that, things seem to go wrong:
Full logging, with the occasional 4th nCS pulse on nIRQ pulse
Full logging, with the occasional 4th nCS pulse on nIRQ pulse
The right hand trace (where brief logging was active, and less (or possibly no) packets were being dropped) shows the nCS signal dropping low only three times. It seems to do that consistently, so I guess that is correct behaviour:
Brief logging, with consistent 3 nCS pulses on each nIRQ pulse
Brief logging, with consistent 3 nCS pulses on each nIRQ pulse
cr12925
Posts: 171
Joined: Sat Mar 09, 2019 9:31 pm
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by cr12925 »

Ok, here are some observations on Ken's recent helpful posts:

First point - some good news - the traces look normal to me

In fact both of the traces (the ones in the previous post side by side) are normal. The left hand one shows the end of a frame arriving (SR2= 0x02), which is why there is a fourth pulse on nCS: the module is doing a write to CR2 to clear the frame valid status. (That is likely to account for the periodic fourth pulses - they'll be end of frame signals.) The one on the right is a straight read from the FIFO, which self-resets the 'Received Data Available' flag, so no write is needed.

Second point - what are all these RX Overruns, and why is the module thinking the 3rd part of a 4-way in a data burst ought to be a scout?

What is perplexing me is the dmesg log. On the one hand, it seems rock solidly stable in showing receiver overruns. On the other, it's receiving large data packets (which are undoubtedly each the third packet in a 4-way exchange which comprises part of the bulk transfer that happens on a *LOAD).

So, those 0x0504 byte packets will have come *from* wired station 239 (because 239 is the fileserver). Problem is, that the FS will only send those packets if it received an ACK to the Scout it sent (i.e. packets 1 & 2 of the same 4-way exchange happened). That ACK (stage 2 of the 4-way) is sent by the module on the Pi, replying to the FS's scout at the start of each of of its packets in the data burst.

Why, then, is the module not seeing the data packet (which will surely have turned up on time from a real BBC) as stage 3 in the 4-way, instead of complaining that it was expecting a Scout?

Well, the answer may lie in the fact that there is a timer in the module which resets the AUN state machine if it thinks its last transmission (e.g. an ACK) was so long ago that whatever turns up next in read mode must be the start of a new inbound exchange. One of the issues with Pi Zero's on v1 hardware was, I think, that the timings required to waggle nCS (for example) didn't work, and that may have been some issue with the timing routines, which rest on the same timer function call that both versions use to detect a stalled 4-way handshake. [Edit: Can't be that. The module puts a dmesg log entry out when it does that reset, and they don't appear in KL's log.]

Furthermore, there are all these regular RX Overruns. When the module detects an overrun from the ADLC, it will abort reception. I had wondered if there was some way in which the module was getting, say, an overrun on the Scout reception from the server and then seeing the data packet (part 3 of 4) at a time when it expected a scout - but that can't be right because to get the 0x0504 length packet, the module *must* have just sent an ack to the server. My best guess, therefore, is that the overruns are actually previous attempts by the server to send the 0x0504 byte data packet and they've failed. Now, I can't see why they would fail and succeed alternately.

I will look into the timing question and see if I can find anything obvious. I think the overruns are largely out of my control - they arise when the FIFO isn't emptied fast enough by the CPU.

Third point - that curious last entry in the dmesg log

The last line of the dmesg log is very odd. It shows the module having read the status registers inconsistently (and I'm going to assume the second reference to SR1 should say SR2 and I've made a typo [just checked: yes I have - it is indeed SR2]):

SR1 = 0xA0 = IRQ present and frame complete. (I.e. looks like it arose on transmit).
SR2 = 0x80 = Received data available.

The inconsistency is: RDA (in SR1 or SR2) ought not to be set on a frame complete flag. If anything were set, it would be 'AP' (Address Present), but that wouldn't happen during the final phases of TX because the module puts the RX circuitry in reset. So that top bit on SR2 is wrong. It is also wrong for another reason, namely that RDA in SR1 is unset, and the two mirror each other.

So either the ADLC has produced something very wonky in its status registers, or the module has not managed to read the SRs accurately. Since it's the top bit of SR2 which is probably wrong, that is consistent with the fluke discovery I made the other day that a data byte inside a packet was misread as 0xf6 when it should have been 0x76. (Top bit of FIFO is read on the same data line as top bit of SR1, SR2, etc. - because they all come across the same bus).

Conclusions

The timer problem (issue 2) is something I suspect may be fixable in software. Issue three looks like hardware and is consistent with what I've seen here on my breadboard.

Now, @arg and other have referred to things like ground bounce and other possible causes - but I am afraid my talent expires well before understanding what those are so I have no easy way of working out whether they are the problem, or what to do to test that; still less fix it! Is it possible that there is a feature of the v2 design which means that occasionally one or more data lines will be mis-read through the GPIO (for whatever reason), thus for example generating problems like:

- Overrun flag where there is no overrun, causing frame reception abort
- Address Present when there isn't, causing the module to start a new frame when it shouldn't (and hence the occasional packets with data in the address space)
- The unhandled state (like the one above)
- Data bytes being lost out of packets because RDA wasn't flagged when it should have been on IRQ, hence all the runts I see off my breadboard in monitor mode, and unreliable reception in that mode.

What is clear is that, even on a PiZero, v2 is capable of receiving a 1.25k (+4 bytes) frame successfully, albeit the module doesn't know what to do with it because it thinks it has come out of sequence, so that in principle the thing is mostly working.

Also clear is that in a very dodgy unusable way, a PiZero on v2 hardware in *bridge* mode will actually do something - e.g. I have managed to log into PiFS on a Zero from a BBC, but nothing much beyond that works. That illustrates that transmission is probably largely OK, but may be suffering similar SR read problems as reception.

Whilst the traces KL has produced look normal to me, I wonder if the bus read failures are so intermittent that we just haven't managed to catch one yet to see what is going on?
2 x Master 128, 1x BBC B, Viglen floppy drives, 2 x Econets, 3 x Econet-AUN bridges, organist, former purveyor of BBS software...
User avatar
KenLowe
Posts: 2143
Joined: Mon Oct 18, 2004 5:35 pm
Location: UK
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by KenLowe »

cr12925 wrote:
Sat Oct 16, 2021 8:13 am
In fact both of the traces (the ones in the previous post side by side) are normal. The left hand one shows the end of a frame arriving (SR2= 0x02), which is why there is a fourth pulse on nCS: the module is doing a write to CR2 to clear the frame valid status. (That is likely to account for the periodic fourth pulses - they'll be end of frame signals.) The one on the right is a straight read from the FIFO, which self-resets the 'Received Data Available' flag, so no write is needed.
Ah. You're right. I've just had a look at the end of a frame on both traces, and both have the forth pulse on nCS. I'm on a different PC now with a larger monitor, so it's easier to put these traces above and below each other. The upper trace is with full logging, and the lower one is with brief logging. I'll zoom in on the +45mS, but that will need to be later today. I've got other things to do right now:
Screen capture showing the start with both full logging (upper) and brief logging (lower)
Screen capture showing the start with both full logging (upper) and brief logging (lower)
Attachments
PulseView 05.zip
Zipped up version of the screen capture
(118.11 KiB) Downloaded 1 time
User avatar
arg
Posts: 439
Joined: Tue Feb 16, 2021 2:07 pm
Location: Cambridge
Contact:

Re: Econet to AUN bridge on Raspberry Pi - released

Post by arg »

cr12925 wrote:
Sat Oct 16, 2021 8:13 am
Well, the answer may lie in the fact that there is a timer in the module which resets the AUN state machine if it thinks its last transmission (e.g. an ACK) was so long ago that whatever turns up next in read mode must be the start of a new inbound exchange.
I think such a timeout ought to be really long (like 10 seconds or more) as it's a watchdog of last resort and should never happen.
The normal case (including most error situations) is that the line idle interrupt tells you that the handshake is over and the next thing on the line is a scout. I can't think of legitimate reasons for missing that interrupt - if you are late on handling Tx interrupts then you will still be flag-filling and the idle situation will happen later (or you detect you've had a Tx underrun in which case you know it's game over); if you are slow on handling Rx interrupts then the idle state will latch until you do get around to reading it.
I think the overruns are largely out of my control - they arise when the FIFO isn't emptied fast enough by the CPU.
They partly are and partly aren't - especially on the Zero with only a single core.

Interrupt latency caused by other kernel drivers (notably the WiFi in this case) is totally outside your control and if too large could make the whole thing unworkable on the Zero (except applications that don't need the WiFi - so local server rather than bridge). The latency seen in the earlier set of traces was notable but not _that_ bad, though of course that wasn't an exhaustive test and it's possible that the WiFi imposes occasional much larger latency that we just didn't happen to see in the capture.

But the other side is how much work you do in your own interrupt handler - which is currently huge in comparison to the minimum possible. Of course it's questionable how much effort is worth putting in to get close to the minimum when the alternative is to just say "don't use a zero".

It would be useful to know how much the other device latency is actually the source of the problem; it may be possible to get a closer idea of this from the traces, since your driver usually reads the SR as pretty much the first thing in the interrupt handler, so the delay IRQ -> first SR read (or at least the variance in that) is a close indication of latency caused by other devices.
Post Reply

Return to “8-bit acorn hardware”