NODE ROM Dissasembly

[Bill B]

Over the past few months I have been wasting my spare time trying to get MEMU talk over real serial hardware. Only limitted succsess, it sends and receives characters, but when I try and establish a NODE ring between two copies of MEMU over serial links I get ring errors.

In an effort to understand this, I decided to have a go at disassembling the NODE ROM to try and understand how it works. Probably over-ambitious.

I have made some progresss over the holiday periond but there is still much to do. Since progress will now be slow, I thought I would post what I have so far so that others may contribute.

All the NODE variable names and code labels given are entirely my own invention and may be misleading or just plain wrong.

I don't suppose that anybody involved at the time might have tucked away a notebook giving the variable usage or on the wire protocol?

[Dave]

Hi Bill,

good work - and not a waste of time!

I don't know whether he has any documents squirrelled away, but Tony worked on Node back in the day, so may be able to shed some light on this

regards
Dave

[thewiz]

That looks good, thanks for having ago at this.

I thought that two instances of Memu could talk to each other. It that right? If so the problem would point at being a handshake (HW/SW?)/parity/dropped character issue.

How are you converting DART config to 16550A?

Is there any specific part of the ROM that you need help with? (no promises )

Paul

[Bill B]

Paul,

Yes, for Linux I produced a simple emulation of the DART using named pipes to connect two or more copies of MEMU together, and this will produce a working NODE ring. What I have been doing is trying to extend that emulation using the Linux termios API to send the data over any type of serial port. This has the advantage that it should work for USB-Serial ports (which is what I am using) as well as 16550A. However one possible issue is the OS overhead may be introducing too much delay in data transmission.

Thanks for offer to help. It should be obvious from the listing which parts I have made some progress with, and where I have yet to go. When I understand something, I try and add a comment and change the auto-generated labels to something more meaningful.

As advertised, there is at least one place where the listing is just plain wrong. I mixed up the tokens for LIST and INPUT (can't tell the difference between 8 and B). I will post an update next weekend.

One interesting quirk I have discovered. You can use the low numbered BASIC ROM tokens as alternatives to some of the NODE commands, so for example:

NODE REM,"Test"

Has exactly the same effect as:

NODE NAME,"Test"

What makes this interesting is that the alternate form is slightly more memory efficient. "REM" is stored as a 1 byte token, whereas "NAME" is spelled out in 4 ASCII bytes.

[Tony Brewer]

I don't suppose that anybody involved at the time might have tucked away a notebook giving the variable usage or on the wire protocol?

I don't know whether he has any documents squirrelled away, but Tony worked on Node back in the day, so may be able to shed some light on this

As Dave says, I worked on the Ring at Memotech and I printed the source code at various stages which I have kept for thirty years. Much of this I treated as scrap paper in the late 1980s, using the blank side for new ideas that generally came to nothing. Recently I have looked at these sheets again and putting the ones I separated in their right order was quite an interesting exercise.

I don't have a complete set and some of the code is not the final version but it is certainly very much better than nothing. I disassembled the ROM and added labels and comments from the printouts to create a new single source file in M80 format. I hadn't finished before getting distracted but here it is anyway:

Node1.zip

Memotech Ring recreated source file

(30.51 KiB) Downloaded 526 times

Non-original labels and comments are enclosed in [ ]. As I might add to the source file in future I suggest you make a copy and put your own comments in that.

[Dave]

Hi Tony,

No, just about to email you

Regards
Dave

[Bill B]

Tony,

Thanks for this. Certainly saves me a lot of work. But then I was enjoying the challenge.

I may be able to solve one little mystery in your disassembly. At the top of your code you have

Code: Select all

	DB	0CBH,2AH,0,0	;DS 4 [values unimportant]

And then further down:

Code: Select all

; >> NO EXECUTION PATH TO HERE <<
	DB	52H		;"R"
	DB	49H		;"I"
	DB	31H		;"1"
	DB	30H		;"0"
	DB	0D7H		;"W"+80H
	DB	84H		;
	DB	52H		;"R"
	DB	69H		;"i"
	DB	6EH		;"n"
	DB	67H		;"g"
	DB	0C9H		;"I"+80H

A possible interpretation of this is:

Code: Select all

                DEFW    ROMID, #0000                            ; 0008 2008 CB 2A 00 00

And:

Code: Select all

ROMID:          DEFS    "RI10"                                  ; 0ACB 2ACB 52 49 31 30
; Screen output
                RST     OSPRSR                                  ; 0ACF 2ACF D7
; Send 4 bytes to screen.
                DEFB    #84                                     ; 0AD0 2AD0 84
                DEFS    "Ring"                                  ; 0AD1 2AD1 52 69 6E 67
                RET                                             ; 0AD5 2AD5 C9

I have a note somewhere that states that the address at #2008 in a ROM should point to a 4 byte identification string, followed by executable code, and that this was used by a Memotech ROM Menu system.

[Tony Brewer]

Bill, thanks for that info which looks very plausible. "RI10" must stand for "Ring ROM version 1.0" but it certainly wasn't the first version of the software! The Node ROM took months to write and disassembling it with nothing much to go on is not easy.

The original source code was in at least five files for the Variables, Ring Executive, Transmitted Data Command Interpreter, Received Data Command Interpreter and Commands. The Ring Executive deals with the low-level serial interface. Some variables have fake names with their addresses such as YF046 because I don't have the final version of the source code for them. An asterisk-only comment means a line or section of code differs from my printouts.

If you have any questions please ask but you've done very well by yourself so far.

[Bill B]

There are some sneeky bits of self modifying code in there, which I would have struggled with without Tony's listing. Of the two I have noticed so far, one is relativly minor and makes the code work from any ROM slot, not just ROM 7. The other one appears to be much more fundemental to the code, toggling an instruction between NOP and DEC HL. There may be others that I have not yet come across.

I have attempted to merge Tony's comments with mine in the attached listing. All errors and omissions are mine.

I have only just begun to work through this to understand how it all works, see my notes, which I will expand as I learn more.

It would appear that, apart from the start of packet (0x02) and end of packet (0x1A) characters, the entire on the wire protocol is printable ASCII characters. When binary data (such as program source) has to be transfered it is sent as ASCII coded hex values. Given that an 8-bit data path is available this seems somewhat inefficient. I don't know whether this was done for ease of debugging.

It does suggest that my next move should be to modify MEMU to capture and log these packets so that I can see the exchanges more easily.

[Bill B]

I have now got ring packet logging working, and have added a couple of examples to my notes. This will be very helpful in checking my interpretation of the ROM.

It may also have already uncovered my problem. It may be a hardware issue and not a fault in my code. I am testing on a single laptop, with two USB to RS232 adaptors connected together by a null-modem cable, then running two instances of MEMU, each one using one of the adaptors. Logging both copies of MEMU showed that packets were getting from A to B OK, but being corrupted going from B to A. Testing with two copies of kermit on the serial adaptors showed the same issue.

I will have to consider how else I can test.