• Please review our updated Terms and Rules here

Help decoding some System/3 machine code

voidstar78

Veteran Member
Joined
May 25, 2021
Messages
698
Location
Texas
So, this is similar to my System/360 thread.

But System/3 appears to be a little more obscure. My understanding is the main feature of System/3 was the RPG II programming language. I'm not at all familiar with that, but I suspect many people maybe didn't code in raw machine code on System/3 - so in general less people may be familiar with its instruction set? Also like the S360 problem, there were a variety of S/3 Models. Something has led me to believe I'm dealing with Model 6 code here, but I'm not 100% certain.

Here is the sample of the binary stream, which should be some System/3 machine code:

1683780951277.png

The classic challenge here is we don't know what sections are Data vs Code. One thing I noticed here is that each "section" of code (content separated by "islands" of empty 00 space), they all start with "F0 xx xx 00 F0 xx xx 00 F0 xx xx 00" and so on. Something runs in my mind is that the System/3 did have an "error code" display - and you could HALT the system and show two codes (on an LED or some part of the system). Can't recall where I read that, somewhere in here probably (site also has an inventory of remaining 1401 and S3's): http://www.ibmsystem3.nl/

In that case, it could mean these "F0" sequences are kind of Data - in that they are offset addresses to use when certain error conditions happen (then Halt the system and display). Here is an example of what the LED looked like:
1683783467579.png



Here's what I'm using as the assembly reference:

I recall reading the System/3 is "famous" for not having any actual registers - it has a "base-register displacement addressing", but it's still in-memory.

Which this is what it says about the F0 opcode instruction (pg68): (i.e. it should be 3-bytes, so what is the "00" doing in between the F0's in the sample above? maybe just a separate to make it easier to read, since HPL is going to halt the system anyway)

Halt Program Level
1683781146299.png


Starting at 0x8F80
Code:
F0 47 35 00 F0 47 0D 00 F0 46 FC 00 F0 46 E4 00 
F0 46 8C 00 F0 46 54 00 F0 46 38 00 F0 46 1E 00 
F0 46 19 00 F0 45 86 00 F0 45 41 00 F0 44 C4 00 
F0 43 D5 00 F0 43 C6 00 F0 43 C0 00 F0 42 D2 00 
F0 42 29 00 F0 40 73 00 F0 40 65 00 F0 3F E3 00 
F0 3F DC 00 F0 3F D4 00 F0 3C 00 00 04 15 B0 70 
FB 50 10 FB 60 20 FB 70 80 D5 00 02 C0 01 48 0B 
49 01 02 00 FF FE 7C 00 0C 75 20 00 B3 20 01 F7 
20 00 F6 20 00 33 00 00 44 F8 00 20 C0 A0 4B 1D 
D4 00 02 08 4B 1D 89 43 00 00 00 9C 01 00 04 9C 
01 1A 06 9C 01 1C 0A 33 30 00 C4 F8 30 20 C0 A0 
4B 1D D4 30 02 08 4B 1D B3 00 44 B4 00 04 89 10 
29 00 40 D5 10 08 C0 81 48 37 9C 10 29 00 BC 00 
02 E9 04 00 4B 38 E3 00 00 FE E5 00 0C C0 01 4B
3C B5 10 04 9C 07 3A 04 FB 10 50 79 08 10 48 74 
33 10 0B 3C 73 40 18 FE 73 30 02 D5 10 00 C0 81 
48 6F FA 20 10 20 48 6F 6D 01 00 00 28 48 6F 78 
08 14 48 6F B8 40 03 48 5F FE 7A 40 15 FE E5 00 
1A C0 81 48 68 6D 01 1A 1A 28 48 6C F0 4B 34 FE 
6D 10 29 29 20 4B 34 FE B8 10 10 4B 6C FE FB 10 
30 FA 10 40 10 48 4C FE FB 10 50 B9 20 10 48 7D 
78 04 10 48 7D FE 7B 80 10 FE 78 80 10 48 85 FE 
B8 80 10 4B 38 FE BA 80 14 FE 78 40 10 48 8D FE 
B8 40 10 4B 38 FE BA 40 14 FE 78 C0 10 48 93 FE 
B8 80 11 4B 34 FE 33 30 00 45 F8 30 20 C0 A0 4B

Still not sure where the code starts after that.
 
Hi,

I have seen allot of IBM System/3 machine code over the years, but this code makes no sense to me.
Where did you get it ?

Regards Henk
 
This'll be from the BASIC and common ROS from an IBM 5100 or 5110 portable. The 51[012]0 emulated a System/3 to run a BASIC interpreter that targeted that system.

However, the BASIC and common ROS supposedly has two kinds of machine code: the System/3 BASIC code plus some native PALM (=processor in the 5100) routines as well (that's the common ROS bit). There's a chance that what's shown above is PALM code, or maybe it's just a data table of some kind.

What are some byte sequences that you would expect to be really common in System/3 machine code? We should be able to spot them in this ROS dump.
 
Mark Waterbury and I have sorted this out some years ago.
There is no IBM System/3 machine code emulator in the IBM 51x0. The S/3 model 6 had a BASIC (5703-XM1)
See http://www.bitsavers.org/pdf/ibm/sy..._System3_Model_6_BASIC_Logic_Manual_Jan72.pdf

The compiler generates a Pseudo Machine Language (PML) see page 2-9 and 3-227 which is interpreted during run time.

The IBM 51x0 has an interpreter for this PML writing in PALM native code.
Below an example of a BASIC program and the compiled PML.


System/3 simulator V3.11-0

5703-XM1 COPYRIGHT IBM CORP. 1970
ENTER CONFIGURE COMMAND OR PRESS PROG START KEY
CONFIGURE 16CK,16K,NOCRT,2D200
ENTER DATE - MM/DD/YY
01/17/22

READY
ASSIGN-WORKAREA R1

FILE ALLOCATION COMPLETED

READY
EDIT DEMO
WORK FILE HAS BEEN CLEARED AND NAMED DEMO

READY
0100 REM DEMO / TEST PROGRAM.
0110 LET N = 10
0120 REM
0130 PRINT '*** PRINT POWER AND SQR BETWEEN 10 & 25 ***'
0140 REM
0150 PRINT N ' POWER = ' N*N ' SQR = ' SQR(N)
0160 N=N+1
0170 IF N<26 GOTO 150
0180 PRINT '*** END OF LISTING. ***'
0900 STOP
0990 END
RUN

*** PRINT POWER AND SQR BETWEEN 10 & 25 ***
10 POWER = 100 SQR = 3.16228
11 POWER = 121 SQR = 3.31662
12 POWER = 144 SQR = 3.4641
13 POWER = 169 SQR = 3.60555
14 POWER = 196 SQR = 3.74166
15 POWER = 225 SQR = 3.87298
16 POWER = 256 SQR = 4
17 POWER = 289 SQR = 4.12311
18 POWER = 324 SQR = 4.24264
19 POWER = 361 SQR = 4.3589
20 POWER = 400 SQR = 4.47214
21 POWER = 441 SQR = 4.58258
22 POWER = 484 SQR = 4.69042
23 POWER = 529 SQR = 4.79583
24 POWER = 576 SQR = 4.89898
25 POWER = 625 SQR = 5
*** END OF LISTING. ***

READY

sim> r (STOP)
Simulation stopped, IAR: 12BE (TBN 03C3,10)
sim> g (START)


> CD,DD,VM,CP,DP,DC,DW, H,R,T,M... VM
ENTER FIRST LINE #.......... 0100
ENTER LAST LINE #........... 0990
0100 5600 STH 0064 640064
0110 5603 STH 006E 64006E
5606 STA F536 34F536
5609 STF F4FB 20F4FB
560C USF 26
0120 560D STH 0078 640078
0130 5610 STH 0082 640082
5613 STC F4E8 28F4E8
5616 PRS 01 6001
5618 STC F4D5 28F4D5
561B PRS 01 6001
561D STC F4C2 28F4C2
5620 PRS 04 6004
0140 5622 STH 008C 64008C
0150 5625 STH 0096 640096
5628 STF F536 20F536
562B PRS 01 6001
562D STC F4AF 28F4AF
5630 PRS 01 6001
5632 STF F536 20F536
5635 STF F536 20F536
5638 MPY 0A
5639 PRS 01 6001
563B STC F49C 28F49C
563E PRS 01 6001
5640 STF F536 20F536
5643 FN1 0900 140900
5646 PRS 04 6004
0160 5648 STH 00A0 6400A0
564B STA F536 34F536
564E STF F536 20F536
5651 STF F497 20F497
5654 ADD 06
5655 USF 26
0170 5656 STH 00AA 6400AA
5659 STF F536 20F536
565C STF F492 20F492
565F CMF 40
5660 BRC 5625 82 44562582
0180 5664 STH 00B4 6400B4
5667 STC F47F 28F47F
566A PRS 01 6001
566C STC F46C 28F46C
566F PRS 04 6004
0900 5671 STH 0384 640384
5674 SVC 02
0990 5675 STH 03DE 6403DE
5678 SVC 02
5679 EOF 70

> CD,DD,VM,CP,DP,DC,DW, H,R,T,M... R


READY
 
Wow, this is huge news to me!

To check if I understand: BASIC for the System/3 used a virtual machine described in the references you cited. It compiled BASIC programs to this virtual architecture and executed the resulting machine code. The 5100 didn't implement any System/3 emulator, it just implements this virtual machine. This would have to mean that the 5100's BASIC interpreter(compiler) is also written in "pseudo-machine code" (i.e. machine code for the virtual machine) or in PALM machine code directly, not in System/3 machine code. Is this correct?

Do you have any writeup or other collection of your findings? How did you make your discovery?
 
Last edited:
I don't mean to doubt, but the virtual machine opcode for an unconditional branch (0x46) appears only 56 times in the entire (54K) dump of the 5100 BASIC and common ROS. This seems low? Anyway, I'm really eager to know more. Mods, please approve this person's posts right away :)
 
Page 93 of the S3 assemble refrence has this Model 10 example: (which I think should work on a Model 6 as well?)

Just as a reference to what "normal" System/3 assembly and object code looks like (including this example uses the F0 op-code -- which as we're learning is not the same F0 in the IBM 5100 ROS BASIC).


1683842087589.png


From the S/3 BASIC Logic Manual, referenced earlier: Way cool - recently Usagi demo'd his working Centurion where I saw a similar thing: the BASIC was compiled and then executed.

1683842526391.png


EDIT: Also wanted to remind/point out, the BASIC here on the IBM 5100 had some more extensive MAT (matrix) features. And the System/3 itself had no native floating point support - despite this, a website by Glenn (apparently one of the BASIC developers of the System/3) mentions how it's a pretty horrible instruction set, but they did manage to implement BASIC on that system with full floating point support.


I've always wondered why the IBM 5100 just didn't also use a BASIC that was on the IBM System/360 -- tentatively it looks like no one really ever made a BASIC for the S/360 (understandable - since why? it had plenty of other better high level languages already). [ IMO: the subsequent appeal of BASIC in the 1977-onward microcomputers was it could fit in a 2K - 8K ROM, whereas any other higher level language almost immediately requires much more substantial resources that couldn't yet be afforded in the early microcomputers with a price target of under $1000 ]... Anyway, it looks like this decent implemention of BASIC was made on the System/3 in Boca Raton, Florida - the same place making the PALM processor for the IBM 5100 - so they just went with what was available to them at the time (~1974).


And I agree with stepleton's question: the IBM 5100 BASIC ROS *should be* "raw" PMC? I'm still not yet seeing what the PMC native opcodes would be (i.e. how anyone would know how to implement that). Or it's still a little confusing: the Compiler/Loader itself would have to be in this PMC?
 
Last edited:
Page 41 of the following elaborates about the F0 opcode and the two character LED display (and confirms that yes, each character requires a full byte, hence the need for the two operands - the bits related to individual segments of the LED, so the two full bytes offer about 22 symbols):

(this document is also in the Symulator/3 code repo)

It also talks about difference behavior on "dual programming feature" systems versus those without dual programming feature.

Without dual programming feature, you can press a START key to acknowledge the HALT and resume on to the next instruction.


Anyway, based on that: I don't think the above F0 sequences are this HPL opcode (native S3) because the bits don't correspond to any sensible lettering (and because bit 0 is set, which is a reserved/unused portion of the LED segment).
 
And don't think the sequence is native PALM...

Attempting to take it literally as PALM, "F0" would be a SUBI (subtract immediate) instruction - so F0 would be subtracting from Register0 (which is the program counter).

When arranging them out, I noticed these F0's decrement in order (for awhile)... F0 47, F0 46, etc... to F0 3F. That seems suspect for a series of instructions (that would be implementing a BASIC interpreter).

Then skipping past all the initial F0's, the first code is "04 15" then "B0 70" (since all PALM instructions are 16-bit, with one exception - there is a JUMP that uses the next 16-bit as the target, making that one a 32-bit instruction). All tentative, but so far it's just not adding up to me as being PALM instructions.

If it is PMC/PML... I guess we are assuming that's all big-endian as well ?


Code:
F0 47 35 00     
F0 47 0D 00

F0 46 FC 00
F0 46 E4 00
F0 46 8C 00
F0 46 54 00
F0 46 38 00
F0 46 1E 00
F0 46 19 00

F0 45 86 00
F0 45 41 00

F0 44 C4 00

F0 43 D5 00
F0 43 C6 00
F0 43 C0 00

F0 42 D2 00
F0 42 29 00

(F0 41?)

F0 40 73 00
F0 40 65 00

F0 3F E3 00
F0 3F DC 00

F0 3F D4 00

(F0 3E?)
(F0 3D?)

F0 3C 00 00

04 15   AND  R4, R1
B0 70   SETI R0, 70  (R0 = 70)
 
I don't mean to doubt, but the virtual machine opcode for an unconditional branch (0x46) appears only 56 times in the entire (54K) dump of the 5100 BASIC and common ROS. This seems low? Anyway, I'm really eager to know more. Mods, please approve this person's posts right away :)

Ah, page 3-227 Pseudo Instruction Set - I see that now, thanks.
 
Last edited:
@snhstq

If you get time, is there anything in the attached binary that looks like System/3 instructions? Specifically I was looking at offset C000 (and also the very beginning, 0000).

This attachment is from the IBM 5100 BASIC, which you may not have explored before (stepleton only recently extracted it a couple years ago, per my understanding).

Another interesting observation in the binary in this 5100 version is that it also has the "F0" pattern shown above (which was from the 5110). Except there is no "extra 00" inbetween the groups of F0, and they "count up" (whereas in the 5110, these F0 subsequent byte counted down). For example, at 0x1800 there is: (going 18h to 2Dh)

Code:
F0 18 3B
F0 1A 9A
F0 1C 39
F0 1C 57
F0 1E 17
F0 1E 50
F0 1E C6
F0 21 39
F0 23 2B
F0 24 8F
F0 25 2B
F0 27 12
F0 27 20
F0 29 21
F0 2A 65
F0 2A E4
F0 2A FD
F0 2B B8
F0 2D 3F
00 00 05 0D 0E C5 1C

Then there is a "pause" of 0000 and some non-F0 sequence begins. Curious if this kind of pattern stands out to anyone.



EDIT: Just curious we have some sections started with F0's and a couple not. Unlike in the 5110 BASIC binary, I think every section in there started with an "F0" sequence.
I'm still learning towards this binary_Bcom.bin is all non-PALM, but could be wrong.
 

Attachments

  • binary_BCom.zip
    32.2 KB · Views: 1
Ok, there is still some misunderstanding how it works.

The virtual memory implemented on the model 6 only increased the 'available' memory from 8/16k to 64kbyte.
IBM did a very nice job doing this, although it has nothing to do with our BASIC question.

Model 6:
BASIC statements are compiled to Pseudo Machine Language (PML)
The compiler runs IBM S/3 machine code.
After compiling the generated PML is interpreted by the interpreter which runs (again) IBM S/3 machine code.

IBM 51x0:
BASIC statements are compiled to Pseudo Machine Language (PML)
The compiler runs PALM code
PML is interpreted by the interpreter which runs (again) PALM code
IBM -only- reused in the IBM 5100 design the definition of the PML as described in the S/3 BASIC logic manual op page 3-227. No more no less :)

I hope it is now clear.

Henk
 
@snhstq

If you get time, is there anything in the attached binary that looks like System/3 instructions? Specifically I was looking at offset C000 (and also the very beginning, 0000).

This attachment is from the IBM 5100 BASIC, which you may not have explored before (stepleton only recently extracted it a couple years ago, per my understanding).

Another interesting observation in the binary in this 5100 version is that it also has the "F0" pattern shown above (which was from the 5110). Except there is no "extra 00" inbetween the groups of F0, and they "count up" (whereas in the 5110, these F0 subsequent byte counted down). For example, at 0x1800 there is: (going 18h to 2Dh)

Code:
F0 18 3B
F0 1A 9A
F0 1C 39
F0 1C 57
F0 1E 17
F0 1E 50
F0 1E C6
F0 21 39
F0 23 2B
F0 24 8F
F0 25 2B
F0 27 12
F0 27 20
F0 29 21
F0 2A 65
F0 2A E4
F0 2A FD
F0 2B B8
F0 2D 3F
00 00 05 0D 0E C5 1C

Then there is a "pause" of 0000 and some non-F0 sequence begins. Curious if this kind of pattern stands out to anyone.



EDIT: Just curious we have some sections started with F0's and a couple not. Unlike in the 5110 BASIC binary, I think every section in there started with an "F0" sequence.
I'm still learning towards this binary_Bcom.bin is all non-PALM, but could be wrong.
It doesn't look like S/3 code. Most used S/3 instruction is C0 87 xxxx (Uncond branch)
I have attached all 5100 related files I have. Originally from Christian Corti.
 

Attachments

  • emu5110.zip
    377.7 KB · Views: 1
All does makes sense: on the IBM 5100-series, you can't "store" an invalid BASIC command line. If there is an error, the executive beeps or flashes and shows an arrow where the arrow is - and this is because it is compiling that line of BASIC as soon as you press EXECUTE to complete the line. You have to syntaxically correct the error before that line can be stored.

In addition, after the compile/parsing of that line, the resulting format of your BASIC line might be altered. For example, it removes unnecessary spaces. When you re-LIST the BASIC, you will see these changes applied automatically. (maybe this was just an automated memory-savings feature, but maybe it relates more to the formality of the PML)

Now I wonder if the compiled version of the line is stored in memory (so the BASIC is stored twice -- the original string sequence, along with the already-compiled version), or if it is re-compiled again as you RUN the program.


About 3/4th (75%) into the Christmas Star video, you see the BASIC version of the program taking substantially more "work" (instructions) to run. Enabling the TRACE is exceptionally slow for the display - maybe a better approach is to dump the TRACE to a file instead of actively to the screen window.


Might it be fair to say this pseudo machine code is even more to the concept of Java JVM byte code?

I'd still like to figure out what these F0 sequences are. It's just millions of instructions at runtime to wade through, to see the interaction between the Exec, Language ROS, Common ROS, and the BASIC NX stuff.


I think the S/3 was viewed as an ancestor to the AS/400 ? So was this PMC/PML used on subsequent systems besides the S/3 ? Did the FORTRAN, RPG II, etc. compilers on the S/3 also compile to PMC ?
 
> I think the S/3 was viewed as an ancestor to the AS/400 ?
Correct
>> So was this PMC/PML used on subsequent systems besides the S/3 ?
I only know of the IBM5100
>> Did the FORTRAN, RPG II, etc. compilers on the S/3 also compile to PMC ?
No, the compiled output of the RPG, Fortran and COBOL compilers where all S/3 executable object files.
COBOL does use a sort of PMC (A-text, B-text, C-text & L-text) which is used between all phases during compilation.
At the end the output is a still S/3 executable object file.
 
Still haven't cracked this yet - as far as definitively finding any "pseudo machine code" (PMC) as defined in the System/3 manual (and what those F0 sequences might be). Not saying that isn't happening - maybe in the IBM 5100-series in particular they used a different set of codes.

What I have found is that it appears for each BASIC statement you enter, the tokenized version of it is stored starting around RWS address $120F.
If you do a simple line like "10 A = 255", you see an appropriate tokenized version of that appear starting at that address (and can change the value that A is set to, and see the memory adjust accordingly). For values larger than FFFF then you see multiple tokenized sequences. The BASIC here seems to support arithmetic up to 17 or 18 characters long, before it then auto-converts the type over to scientific notation.

As you adjust the program and insert lines and such, the tokenization becomes "weird" - the end of the token sequences seem to have pointers to connect things, so as a program is modified its not always in the linear sequence stored in memory. This gets "corrected" as soon as you RUN the program ("garbage collection" is applied) -- I think I recall there is another manual command you run invoke to do this cleanup without actually running.

All that makes sense to a typical BASIC implementation. But as far as I could tell, these tokens didn't seem to be compiled PMC (not that they needed to be, but just wondered if maybe it did that compiling upfront).


Here is a picture to show what I mean. In the simple BASIC line "10 A=55", the variable "A" becomes the "C1" in memory (where the red line points) and "55" decimal is stored as 37h.
If you change line to something like "Z=12", only those two values in memory are adjusted - until you change the line to be more complicated (like A = 5+B or A = 5* &PI, etc).

1683992021003.png


The only other thing I noticed is that when you do a RUN, so many cycles are spent upfront as the BASIC ROS clears out memory. That's funny since when I upgraded my 5110 to a full 64KB, I noticed a "lag" after doing RUN -- and this might be why: the more memory you have, the more it has to clear upfront (every time you do RUN). It's still "blink of an eye" fast in normal runtime - but in line debugging, it's a painful sequence to iterate through.

I've updated the emulator to more clear when it is disassembling on whether the context is currently ExecutiveROS vs a LanguageROS. And I've also realized I can add hooks on when the "NX" ROS (BASIC NX, APL NX) are being accessed - which means I can log when addresses in those it is using. So from that, I determined that the first address used in the BASIC NX is at 0x0922.

Anyway, I still couldn't make heads or tails from the following content in the BASIC NX (non-executive) sequence starting at offset 0x0922, where it *should be* either System/3 code or this PMC code - but have "run out of daylight" (and energy) for now.

Code:
0920: C3 00
0922: 0B 22 C8 20 0B 2A 05 C4 CA 0F 0B 2A 23 EE
    : 3B 10 0B 6C 38 80 0B A1 04 9F 31 00 0B A8 3C 40
    : 05 C0 3C 00 0B 57 09 01 0B 58 00 00 3B 10 0B 6D
    : 3B 08 0B A4 33 40 01 3F 3C FF 10 CE 04 40 10 CF
    : 10 CE 3B 04 0B 6D 35 40 0B 63 33 50 00 03 F8 40
    : 50 C0 A0 04 D5 C4 40 0B 61 08 04 D5 34 40 0B AC
    : 3B 03 0B AD 0C 01 0B AA 0D B0 3B 03 0B AB 33 40


I understand the PALM GETB (it is getting a byte from the Language ROS "device") -- the language ROS is doing this, a loop to buffer in some NX content, to then parse what to do. But later it does a PUTB, so I'm not following how/why the language ROS does a PUTB to that device (we can't write a byte to the ROS??) with no intermediate CTRL (to change devices).
 
But later it does a PUTB, so I'm not following how/why the language ROS does a PUTB to that device (we can't write a byte to the ROS??) with no intermediate CTRL (to change devices).
PUTB is how you tell the non-executable ROS the address you want to start reading from. Remember that the non-executable ROS is a streaming device: you tell it where to start reading from with PUTBs, and then you pull bytes out with repeated GETBs. See info about Device 1 on this page by Christian Corti.
 
Makes sense, forgot this was in Corti's examples with annotated comments. Not exactly sure where the address ends up being stored - there is a "SAR" register that I think manages reading from the 128 byte register file vs RWS.
 
Update: I've been able to determine that for the IBM 5110 BASIC NX (non-executable) it contains a jump table at the very beginning (0x0000). Sometime during startup, when BASIC language is selected, that jump table is copied to RWS 0x0800.

Thereafter, when the BASIC NX ROS is consulted to get the next opcode, there is explicit PALM code in the BASIC ROS to add the GETB result to 0x0800. That code looks like this:
1685513847318.png

Which should mean:
- R3 = next byte from device $1 (BASIC NX ROS)
- R2 = 0x0800 (address $0106 is initialized to the address of this jump table during startup, so constant $0800 in the case of the language switch set to BASIC)
- R2 = R2 + R3
- RE (or R14 = next byte from BASIC NX ROS (device $1), presumable to prepare for the next byte that is a Q-code or operand
- R2 = R2 + R3 (the jump able is a 16-bit address, so the target addressed is 2*TheOpCodeValue, e.g. opcode C8 jump table offset becomes 0800 + 2*C8 = 0x0990
- JUMP to the address in BASIC ROS that implemented the given OpCode from BASIC NX


So re-arranging the table a bit -- whatever OpCodes are being emulated, they range from 00 to FF and the corresponding BASIC ROS PALM target address implementation is as follows:

1685514970710.png

(again, the table is defined in the BASIC NX and copied to RWS -- while these addresses are defined in the non-executable ROS, the target is into a address of the BASIC ROS; the APL side of things does exactly the same thing but with a different set of opcodes and the target addresses are into the APL ROS)

This still doesn't yet directly correspond to System/3 or PMC. But some interesting notes:

#1) All the colored cells in row 2 to 12, obviously you see groupings of the same target address. But for each of those groupings, the target corresponds redundantly to the same PALM instructions: (using 0830 as an example, but 1406/1470/1000/etc all correspond to the same byte code repeated at their respective target addresses)
Code:
0830    0203        INC2 R2, R0
0832    2091        JMP ($0122)

Basically, R2 = R0+2 (i.e. let R2 be stored to the next -- or really, "the current", PALM instruction), then JMP.

#2) The darker brown cells between rows 14 and 17, they all correspond to the same target address which has this: (which I interpret as basically do some cleanup and then HALT, implying to me something like "unsupported opcode")...
Code:
0268    E11F        STAT R1, $1
026A    011D        MLH R1, R1
026C    E11F        STAT R1, $1
026E    1077        CTRL $0, #$77
0270    0000        HALT

#3) for all the other cells (white), they are target addresses to a "clean" sequence of code -- that does something, then JMP or BRA somewhere for subsequent processing. i.e. they look to be implementing the opcode, then branching for the next additional work to do (increment PC and process the next instruction).


#4) In the System/3 "table" of opcodes -- it has groups of "3 blanks" (empty cells), but then the "3-series" and "7-series" rows are mostly full of some unique opcodes. That same general pattern is in the table above.



The System/3 Assembler Reference mentions there are "extended mnemonic codes" - it list some of those mnemonics, but it not clear what their opcodes are. Somewhere in the manual it suggested these extended mnemonics do things like operate on half-words instead of full-words - so perhaps there are some "undocumented" extended opcodes (which is why it appears there isn't System/3 instructions here, when actually maybe they are -- just not a Model we're yet familiar with).


Out of time for today, but maybe something here stands out to someone or jogs some thinking.
 
Last edited:
Back
Top