I am beginning to think that my original objective is not possible. It looks as though it may not be possible to create an Oxford ring over serial with MEMU running in user space.
For testing, I switched to using an RPi as one node, using the inbuilt serial port, and my laptop with a USB to 3.3v TTL serial adaptor. With this configuration I don't seem to get any packet corruption, and I am able to get "Ring Initialised/Ring in Operation". However, shortly afterwards I get "Ring Error 01/02". My guess is that, on a multi-tasking operating system, MEMU gets suspended, and therefore stops responding quickly enough to the other node.
It is possible that it may work with MEMU-Pi, which runs as PID 0, with no other tasks running. However, on the RPi, the GPU periodically interrupts the ARM processor, so perhaps not. At the moment I don't have two spare RPi's to experiment with.
So for the moment it looks as though you need real hardware MTX or MTX Plus. I don't think REMEMOTECH has serial support at the moment.
I will continue to try and understand the ROM. It may be possible to patch this to change the timeout. But that would mean that MEMU would not link to a MTX with standard Node ROM.
NODE ROM Dissasembly
Re: NODE ROM Dissasembly
- Attachments
-
- Ring_Notes.pdf
- With RPi Test Log
- (53.4 KiB) Downloaded 484 times
-
Tony Brewer
- Posts: 108
- Joined: 08 Jan 2014 20:50
Re: NODE ROM Dissasembly
Bill, if it's a timing problem have you tried selecting a slow baud rate using the NODE BAUD command before initialising the Ring?
Last edited by Tony Brewer on 03 Feb 2015 19:39, edited 3 times in total.
Re: NODE ROM Dissasembly
Tony,
Have not tried that yet. My understanding was that the NODE BAUD command set the baud rate for channel 2, not for the ring.
As you suggest, editing LDCNST to return a high value might be better. However, if I resort to that, it will never interoperate with a real MTX, not unless that also has a patched ROM.
Unfortunately, I'm working next weekend, so it will be a couple of weeks before I get a chance to try this.
Bill.
Have not tried that yet. My understanding was that the NODE BAUD command set the baud rate for channel 2, not for the ring.
As you suggest, editing LDCNST to return a high value might be better. However, if I resort to that, it will never interoperate with a real MTX, not unless that also has a patched ROM.
Unfortunately, I'm working next weekend, so it will be a couple of weeks before I get a chance to try this.
Bill.
-
Tony Brewer
- Posts: 108
- Joined: 08 Jan 2014 20:50
Re: NODE ROM Disassembly
I've had another look at the code and the ring timeout period with only two nodes is over half a second at 19200 baud, over a second at 9600 baud, over two seconds at 4800 baud, etc. These are huge times and so I've deleted what I said about patching the ROM to increase the timeout.
There could be a buffer overflow or underrun problem at the default baud rate of 19200. Try 9600 with the command NODE BAUD 0,9600 and if that does not work try 4800. NODE BAUD can change the ring speed and I've attached the documentation (which I wrote by the way).
There could be a buffer overflow or underrun problem at the default baud rate of 19200. Try 9600 with the command NODE BAUD 0,9600 and if that does not work try 4800. NODE BAUD can change the ring speed and I've attached the documentation (which I wrote by the way).
Re: NODE ROM Dissasembly
Wile the Z80 emulator Andy uses for MEMU is good in most respects, it is not quite ideal with respect to interrupt handling. By default it has a latency of up to 1000 cycles (although the undocumented -iperiod switch can be used to reduce that). Also, there is no real interrupt acknowledge cycle, interrupts are tested for whether or not interrupts are enabled, and then silently ignored if not enabled.
By first draft emulation of the DART ignored the Interrupt Under Service Logic (IUS). It worked because of the high interrupt latency, and the high speed of the named pipes. I can't get away with that with real 19,2kb/s data transfer.
I have hacked the MEMU code so that it only tests for DART interrupts if interrupts are enabled on the CPU. And I have hopefully coded an emulation of the DART IUS logic as per Z80 Family Data Book.
I am testing on a two node ring. I initiate the ring on the first node. I am finding that the second node is hanging after receiving the first packet. There does not seem to be any RETI instruction to clear the received character interrupt following the <Ctrl+Z> at the end of the packet.
With that clue I need to take another look at the code. It also suggests that I don't yet fully understand all of the IUS logic in the DART.
For information, the relevent part of the log on the second node is:
By first draft emulation of the DART ignored the Interrupt Under Service Logic (IUS). It worked because of the high interrupt latency, and the high speed of the named pipes. I can't get away with that with real 19,2kb/s data transfer.
I have hacked the MEMU code so that it only tests for DART interrupts if interrupts are enabled on the CPU. And I have hopefully coded an emulation of the DART IUS logic as per Z80 Family Data Book.
I am testing on a two node ring. I initiate the ring on the first node. I am finding that the second node is hanging after receiving the first packet. There does not seem to be any RETI instruction to clear the received character interrupt following the <Ctrl+Z> at the end of the packet.
With that clue I need to take another look at the code. It also suggests that I don't yet fully understand all of the IUS logic in the DART.
For information, the relevent part of the log on the second node is:
Code: Select all
Interrupt under service 0x40 cleared by RETI: iflags = 0x00, ius = 0x00
Channel 0 Interrupts: 0 Special, 24 RX, 0 TX, 0 Status, 0 IUS, 24 RETI
Channel 0 Data: 24 Read, 0 Write
Transmit 0 Bytes, 0 <Ctrl+Z>, 0 NULL packets, 0 Next packet
Receive 25 Bytes, 0 <Ctrl+Z>, 0 NULL packets, 23 Next packet
Receive Ring Packet:
119ALPHA 0101FC5D
DART Channel 0: Received character = 0x1a
DART Channel 0: Set interrupt RX_Avail: iflags = 0x40
DART Interrupts: Flags = 0x40, ius = 0x40, base = 0xf0, vector = 0xfc
Read from DART port 0x00
DART Channel 0: Clear interrupt RX_Avail: iflags = 0x00
DART Channel 0: Read data = 0x1a
Write to DART port 0x02: 0x01
DART Channel 0 WR0: Select register 0
DART Channel 0 Command: Null Code
DART Channel 0: Received character = 0x1a
DART Channel 0: Set interrupt RX_Avail: iflags = 0x40
Write to DART port 0x02: 0x13
DART Channel 0 WR1: Ext Int Enable
DART Channel 0 WR1: Tx Int Enable
DART Channel 0 WR1: Int on all Rx characters (parity affects vector)
Read from DART port 0x02
DART Channel 0 RR0: Rx Character Available
DART Channel 0 RR0: Interrupt Pending
DART Channel 0 RR0: Transmit Empty
Write to DART port 0x02: 0x28
DART Channel 0 WR0: Select register 0
DART Channel 0 Command: Reset Tx Int Pending
DART Channel 0: Clear interrupt TX_Empty: iflags = 0x40
Write to DART port 0x00: 0x02
DART Channel 0: Transmit 0x02
Transmit character 0x02
Character sent
DART Channel 0: Set interrupt TX_Empty: iflags = 0x60
Read from DART port 0x02
DART Channel 0 RR0: Rx Character Available
DART Channel 0 RR0: Interrupt Pending
DART Channel 0 RR0: Transmit Empty
Write to DART port 0x02: 0x28
DART Channel 0 WR0: Select register 0
DART Channel 0 Command: Reset Tx Int Pending
DART Channel 0: Clear interrupt TX_Empty: iflags = 0x40
Write to DART port 0x00: 0x31
DART Channel 0: Transmit 0x31
Transmit character 0x31
Character sent
DART Channel 0: Set interrupt TX_Empty: iflags = 0x60
DART Interrupts: Flags = 0x60, ius = 0x40: Interrupt under service
*** At this point the DART has both receive and transmit interrupts outstanding, but will not raise
the transmit interrupt as it thinks receive interrupt (higher priority) is still under service.
Terminated Run ***
Channel 0 Interrupts: 0 Special, 1 RX, 0 TX, 0 Status, 316704 IUS, 0 RETI
Channel 0 Data: 1 Read, 2 Write
Transmit 2 Bytes, 0 <Ctrl+Z>, 0 NULL packets, 1 Next packet
Receive 1 Bytes, 1 <Ctrl+Z>, 0 NULL packets, 0 Next packet
Re: NODE ROM Dissasembly
Success at last 
A working Oxford Ring joining two computers over serial. I cannot quite claim RS232, as it is actually using 3.3v logic levels.
The (emulated) CTC was receiving interrupt acknowledge when interrupts were disabled and was then masking the RETI from the emulated DART.
Finally there was an embarrassing bug in my emulation of the TX empty interrupt, that was resulting in the OS transmit and receive buffers slowly filling. It is always the simple errors that are most difficult to find.
I will tidy up my code and then forward it to Andy. It should be noted that the code is Linux only, the Windows API for serial ports is completely different.
I will continue working on understanding the on-the-wire protocol, and the Node variables.
A working Oxford Ring joining two computers over serial. I cannot quite claim RS232, as it is actually using 3.3v logic levels.- Ring_Demo.jpg (436.18 KiB) Viewed 9729 times
Finally there was an embarrassing bug in my emulation of the TX empty interrupt, that was resulting in the OS transmit and receive buffers slowly filling. It is always the simple errors that are most difficult to find.
I will tidy up my code and then forward it to Andy. It should be noted that the code is Linux only, the Windows API for serial ports is completely different.
I will continue working on understanding the on-the-wire protocol, and the Node variables.
Re: NODE ROM Dissasembly
Good to hear about your progress
Mark
Mark
Standby alert “There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer in Somerset later in the year
Not as many MTXs as Dave!
Re: NODE ROM Dissasembly
Not much added to the disassembly, but rather more detail on the on the wire protocol.
I have discovered an undocumented limitation in the NODE SEND and RCV commands. The names of the variables sent and received must be no more than 8 characters, otherwise you receive an "Out of Range" error. This is because the names are included in the packet header.
I have discovered an undocumented limitation in the NODE SEND and RCV commands. The names of the variables sent and received must be no more than 8 characters, otherwise you receive an "Out of Range" error. This is because the names are included in the packet header.
- Attachments
-
- Ring_Notes.pdf
- (74.41 KiB) Downloaded 487 times
-
- node.zip
- (79.45 KiB) Downloaded 476 times
Re: NODE ROM Dissasembly
Hi Bill,
great stuff !
If it's OK with you, I'll put the notes on the site?
Can you just confirm that the ROM code is the same image as distributed in MEMU?
I can't get a machine to start when I blow that code into a ROM
regards
Dave
great stuff !
If it's OK with you, I'll put the notes on the site?
Can you just confirm that the ROM code is the same image as distributed in MEMU?
I can't get a machine to start when I blow that code into a ROM
regards
Dave
Re: NODE ROM Dissasembly
Dave,
Yes, please do host my note on your site. I did think before I posted my last that that would be a better solution than cluttering the forum.
You should mention that my note is building on the ROM disassembly provided by Tony Brewer. Also, it is still very much a work in progress. Understanding the transmit control block is what yielded much of the on the wire protocol, but I ran out of time over the weekend to follow up all the commands.
Yes, I confirm that the ROM image I am using is from Andy's distro. It is also consistent with the disassembly Tony produced.
It works fine in MEMU. I have been using the ROM listing to deduce what I think the protocol is, and then checking by running the command in MEMU and using the diagnostic output in my DART emulation to confirm what is actually sent.
In MEMU, I have just been using the standard ROMS (OS, BASIC & ASSEM) and using the NODE ROM as ROM7.
Things I have read, but not yet tested:
* The node ROM should work as ROM6 instead of ROM7.
* The NODE ROM should be compatible with the SDX ROM.
It sounds to me as if you need to use your diagnostics board to see if you can work out where your MTX is getting to when you try and boot with a NODE ROM.
Regards,
Bill.
Yes, please do host my note on your site. I did think before I posted my last that that would be a better solution than cluttering the forum.
You should mention that my note is building on the ROM disassembly provided by Tony Brewer. Also, it is still very much a work in progress. Understanding the transmit control block is what yielded much of the on the wire protocol, but I ran out of time over the weekend to follow up all the commands.
Yes, I confirm that the ROM image I am using is from Andy's distro. It is also consistent with the disassembly Tony produced.
It works fine in MEMU. I have been using the ROM listing to deduce what I think the protocol is, and then checking by running the command in MEMU and using the diagnostic output in my DART emulation to confirm what is actually sent.
In MEMU, I have just been using the standard ROMS (OS, BASIC & ASSEM) and using the NODE ROM as ROM7.
Things I have read, but not yet tested:
* The node ROM should work as ROM6 instead of ROM7.
* The NODE ROM should be compatible with the SDX ROM.
It sounds to me as if you need to use your diagnostics board to see if you can work out where your MTX is getting to when you try and boot with a NODE ROM.
Regards,
Bill.