Disassembly of IBM System/360 (attempt)

[voidstar78]

I understand there were various Models of the IBM System/360, so that alone makes it hard to do a general disassembly of S360 binary.

But suppose the binary below (starting at 0x200) is some kind of S360 machine code. I don't think it is the earliest Model 20, don't think it is a Model 40. I do think some floating pointing code might be in there.

The arrangement is below is HxD on a Wintel platform. My understanding is the S360 was big-endian -- but I'm not exactly sure what that means. Meaning, do I reverse the entire byte? Or do I just swap bytes within a word?

For example, the sequence below starts with "50 C0 D1 DC" (I understand not all S360 opcodes were 32-bit, but just examining the first "word" as an exercise)
How would that get interpreted by a S360?

Swap the nibbles:           "05 0C 1D CD"  ?
Swap the bytes:             "C0 50 DC D1"  ?
Swap the entire sequence:   "CD 1D 0C 05" ?
Or:                         "DC D1 C0 50"

Or maybe no adjustment is needed, if this binary was extracted in the same order the machine interprets it as? Under that premise, then are any of those even valid opcodes?

50 --> don't think this is a valid S360 opcode
05 --> Branch and Link (BALR)
C0 --> don't think this is a valid S360 opcode
CD --> don't think this is a valid S360 opcode
DC --> Translate (TR) [ gamble since who knows if the first instructions is a 32-bit word ]





It seems reasonable this code might start with a BALR:



Can anyone determine if the above might be a valid S360 machine code sequence?


Here is another section:



Then one more sample section: (I think the portion in the red box is data, an end of segment CRC since it falls right before the next segment of 0xA800)

 

[cruff]

You will need to swap the bytes in a 16-bit word or in a 32-bit word as appropriate. Thus your disassembler will probably need to be smart enough to detect the size of the instruction and its immediate data values.

 

[vwestlife]

Are you decoding it in EBCDIC?

 

[Chuck(G)]

I'm not going to go digging for my green card, yet. Byte ordering in the IBM world was strictly left-to-right; what may be confusing to some newer folks is that IBM numbered bits from 0 for the highest-order position. So a word was numbered bit 0 in the most significant position and 31 in the least one. Halfwords and bytes were similarly numbered 0-15 and 0-7.

The code in your example doesn't look like typical S/360 code, but then, that was more than 50 years ago.

 

[Bob-O-Rama]

Using your first image, I think you have code you just need to slog through the 360 disassembly.

50 = Store
C = Source: Register C
0D1DC = Target: Offset = 0, Base Register = D, Displacement = $1DC

05 = BALR
C0 = Registers C,0 Note that use of register 0 here mean do not branch and the address of the next instruction is stored in C

50 = Store
F = Source: Register F
0D1D8= Target: Offset = 0, Base Register = D, Displacement = $1D8

41 = Load Address
E = Target: Register E
E01A8= Target: Offset = E, Base 0, Disp = $1A8

41 6 00001 LDA R6 <-- 0:0:001

58 = Load
1 = Register
0:D:048 = Source address

12 = Load / Test Register
11 = R1,R1

etc...

Also telling are larger instructions: like at offset 220. D2 00 D0 23 D0 6F which is a multi byte move. The next instruction is a Load instruction. Even just ignoring what the code is "doing" and focusing on instruction length alone, you can see its an instruction stream with 370 instructions.

I mention this because you will note that while most instructions are 4 bytes, instructions which are 2 bytes or 6 bytes are followed by a valid opcode. So we are not just "disassembling gibberish." I haven't had to do 360 assembly in 35+ years, so above analysis can be taken as pseudo code. But from what I can tell, that first image is a valid instruction stream, without any messing around at all. Some of the opcodes ( like the MVC and op=0F CLCL is more recent like 370 ) so I don't know the provenance of the code but it may be newer than 1966, LOL.

https://en.wikibooks.org/wiki/360_Assembly/360_Instructions
http://www.bitsavers.org/pdf/ibm/36...To_IBM_System360_Assembler_Language_May66.pdf
https://slx-online.biz/hursley/s360-instructions.asp <-- Periodic Table Of the Opcodes LOL!

 

[voidstar78]

Pardon, having an ASCII text version (rather than image encoded) may be easier for anyone to manipulate and try to decipher.

NOTE: This code *should be* related to an APL parser for the S360. Anyone know which S360 models supported APL?
(the reason I don't think it is a Model 20 is because I think this code was late 1960s, and the reason I don't think it was a Model 40 is something gave me the impression that the Model 40 had a more limited instruction set -- but I could be wrong on both points)


Sample 1 starting at 0x0200:

50 C0 D1 DC 05 C0 50 F0 D1 D8 41 EE 01 A8 41 60
00 01 58 10 D0 48 12 11 0F 20 01 13 50 60 D0 4C
D2 00 D0 23 D0 6F 58 10 D0 68 12 11 0F 20 01 1D
50 60 D0 6C D2 00 D0 1F D0 4F 58 10 D0 6C 50 10
D0 24 59 10 D0 4C 0F 20 01 28 D2 03 D0 24 D0 4C
41 F0 00 04 58 60 D0 44 58 50 D0 64 50 60 D0 98
18 45 19 56 0F B0 01 35 18 46 41 A0 D1 EC 41 8A
40 08 41 78 40 08 41 37 40 08 19 3E 41 10 00 10

Sample 3 starting at 0xA730:

60 00 0F 80 51 E8 95 A4 60 00 0F 80 51 E8 12 77
0F 80 53 AA 95 9D 60 00 0F 70 54 14 45 F0 C4 10
0D 6A 53 8D 58 20 D0 90 5B 20 D0 84 45 F0 C2 62
41 20 00 1B 45 F0 C2 52 91 18 D1 52 0F 70 56 63
12 77 0F 80 56 67 0D 6A 52 F7 91 20 D1 52 0F 80
53 C5 41 20 00 03 0D 6A 54 16 45 F0 C4 10 95 9C
60 00 0F 70 54 02 91 01 D1 4E 0F 10 54 02 91 60
D1 52 0F 70 54 02 43 26 00 00 45 F0 C2 52 58 10
B0 B0 91 02 10 07 0F 80 53 E0 1F 77 0D 6A 53 AA
44 00 A4 FD 41 00 C8 9E 0A 01 44 00 A6 9F 92 99
D1 5E 92 01 D1 45 0D 6A 53 C5 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 26 D0 71
80 01 99 9D 95 9D 60 00 0F 80 53 BD 95 99 60 00
0F 70 54 14 46 70 C8 BA 0D 6A 53 AA 45 F0 C3 FA
95 99 60 00 0F 70 53 AA 43 26 00 00 45 F0 C2 52
0D 6A 53 73 92 18 60 00 18 16 1B 6B 0D 02 DA 87
41 16 B0 1A 95 99 10 00 0F 80 54 43 0D 02 DA EF
41 66 00 1A 1B 44 41 10 C9 B0 0D 02 DA 87 0D 6A
54 37 41 7B 60 00 95 99 70 00 0F 80 54 43 45 80
C9 8E 41 16 B0 00 43 41 00 00 41 64 60 01 0D 02
DA 87 0D 6A 54 31 58 60 D0 C8 58 7B 60 00 12 77

 

[voidstar78]

@Bob-O-Rama Thanks (and Thanks to all others!) - yes, I suspect this might be S370. I never worked on either system. The S370 itself came out in late '69 or '70?? Just from where the code came from, I didn't really think it would have been updated to take advantage of anything S370 specific. Maybe the S360 never had its own native implementation of APL?

And gosh, I was reading that S360 Principles of Operations and missed Store OpCode 50. Bit tired today :|

 

[voidstar78]

So nobody ever wrote an x86 compatible S360 disassembler? (something to run under Wintel?) I see references to disassemblers that run on the S360 system itself - which would make sense, you would know exactly what model you're working at least.

 

[voidstar78]

Ok, here is a dump of what should be slightly older version of the APL parser (I'm not sure if compiler is quite right, so for now I'll just refer to it as a parser).

I don't need full specifics on what it is doing, but I'm curious if anyone spots any S370 specific stuff in here? (I'll explain why later)

(assuming we've correctly established that no swapping of any bytes it actually necessary -- this stream was extracted directly off the ROS/ROMs, so I guess it should be in exactly the same format that system natively interprets it?)

Also is a ZIP attachment of that uncompresses the full ROS/ROM (96KB). Would be neat to get a full disassembly - if we could determine what Model it goes with.

I'm also curious if this binary stream is possibly mixed in with Data Tables of some sort (in particular, there is some "weird stuff" at the very end), it also possible not everything in there is S360/S370 machine code.

As far as EBCDIC stuff -- this is just a "raw binary stream" short handed into hex. So... we're viewing it in ASCII. I think EBCDIC would come into play if we found any kind of "print" code in here, or any sequences of data that are intended to be used as string outputs. I'm not sure how stuff was sent to a terminal or printer on S360 -- there is the SIO (Start IO) opcode 9C ? That would be super cool if anyone identified any strings in here (such as APL related error messages?).

(edit: wait - if we just re-parse all the hex values as EBCDIC, shouldn't some string literals appear? I'll see if I can code up a converter like that)





Text dump of the above:

50 C0 D1 DC 05 C0 50 F0 D1 D8 41 EE 01 A8 41 60
00 01 58 10 D0 48 12 11 47 20 C0 20 50 60 D0 4C
D2 00 D0 23 D0 6F 58 10 D0 68 12 11 47 20 C0 34
50 60 D0 6C D2 00 D0 1F D0 4F 58 10 D0 6C 50 10
D0 24 59 10 D0 4C 47 20 C0 4A D2 03 D0 24 D0 4C
41 F0 00 04 58 60 D0 44 58 50 D0 64 50 60 D0 98
18 45 19 56 47 B0 C0 64 18 46 41 A0 D1 EC 41 8A
40 08 41 78 40 08 41 37 40 08 19 3E 41 10 00 10
47 B0 C5 7E 12 55 47 80 C0 90 58 30 D0 60 41 33
B0 0C 44 50 C5 1A 12 66 47 80 C0 A6 58 30 D0 40
41 33 B0 0C 44 60 C5 20 44 60 C5 38 91 C0 D0 80
47 70 C0 B6 18 34 1B 3F 47 F0 C0 F0 47 10 C0 C2
58 30 D0 90 47 F0 C0 EC D2 07 D1 88 D0 84 68 00
D1 88 6A 00 C5 92 32 00 47 40 C5 7A 79 00 C5 A2
47 B0 C5 7A 6E 00 C5 9A 60 00 D1 88 58 30 D1 8C
1A 4F 8B 30 00 02 41 00 00 01 50 00 D1 CC 50 00
D1 D0 12 44 47 70 C1 0A 91 C0 D0 80 47 80 C1 EC
19 34 47 B0 C5 7A 12 33 47 40 C5 7A 91 C0 D0 80
47 10 C1 BE 19 56 47 80 C1 80 12 66 47 70 C1 38
44 50 C5 26 18 65 50 03 80 00 47 F0 C1 6C 12 55
47 70 C1 4C 44 60 C5 2C 18 56 50 03 A0 00 47 F0
C1 80 18 26 1B 25 19 2F 47 80 C1 78 49 20 C5 CE
47 70 C5 72 18 98 45 10 C3 4E 1B 8F 1B 7F 41 66
00 04 44 60 C5 38 50 60 D0 98 47 F0 C1 80 18 9A
45 10 C3 4E 1B AF 12 44 47 80 C1 EC 06 60 41 10
00 05 58 5A 30 00 58 28 30 00 50 1A 30 00 50 18
30 00 44 60 C5 6C 47 70 C5 7E 50 50 D1 D0 50 20
D1 CC 1A 52 50 57 30 00 47 E0 C2 0C 41 10 00 0B
47 F0 C5 7E 12 66 47 70 C1 D2 44 50 C5 26 44 50
C5 38 50 50 D0 98 18 65 06 60 12 55 47 80 C1 EC

 

[Chuck(G)]

There are a couple of disassemblers that run on Hercules.

 

[tradde]

I would have dug out my green card, but I no longer have one. I worked with 360 assembler long long ago.

 

[voidstar78]

What was your preference, SPS vs Autocoder?

 

[voidstar78]

So, no "very interesting" EBCDIC string sequences (in the older binary_APL_LROS.bin from IBM 5100), but a few things stood out.

Attached is the C++ code I used, if anyone interested or spots error in the approach. Which is basically:

- take each byte in the binary sequence
- interpret each byte as a value 0-255
- use the value as an index into a 255 character array that contains the EBCDIC values (e.g. array entry 129 is lower case 'a')
- buffer up groups of converted values longer than 3 characters, deem anything smaller as "trash"
- output these groups

hex
offset char hex / dec  EBCDIC

0x5eca    ‘ [91h / 145]    j
0x5ecb    ’ [92h / 146]    k
0x5ecc    “ [93h / 147]    l
0x5ecd    ” [94h / 148]    m
0x5ece    • [95h / 149]    n

0x8ccd    ‘ [91h / 145]    j
0x8cce    ’ [92h / 146]    k
0x8ccf    “ [93h / 147]    l
0x8cd0    ” [94h / 148]    m
0x8cd1    • [95h / 149]    n
0x8cd2    — [97h / 151]    p
0x8cd3    – [96h / 150]    o
0x8cd4    ˜ [98h / 152]    q

0x9ef2    ‘ [91h / 145]    j
0x9ef3    ’ [92h / 146]    k
0x9ef4    “ [93h / 147]    l
0x9ef5    ” [94h / 148]    m
0x9ef6    • [95h / 149]    n
0x9ef7    ˜ [98h / 152]    q
0x9ef8    – [96h / 150]    o

0xa250    ð [f0h / 240]    0
0xa251    ñ [f1h / 241]    1
0xa252    ò [f2h / 242]    2
0xa253    ó [f3h / 243]    3
0xa254    ô [f4h / 244]    4
0xa255    õ [f5h / 245]    5
0xa256    ö [f6h / 246]    6
0xa257    ÷ [f7h / 247]    7
0xa258    ø [f8h / 248]    8
0xa259    ù [f9h / 249]    9

0x106f7    ‘ [91h / 145]    j
0x106f8    ’ [92h / 146]    k
0x106f9    “ [93h / 147]    l
0x106fa    ” [94h / 148]    m
0x106fb    • [95h / 149]    n
0x106fc    — [97h / 151]    p
0x106fd    – [96h / 150]    o
0x106fe    ˜ [98h / 152]    q

0x12a20    ‘ [91h / 145]    j
0x12a21    ’ [92h / 146]    k
0x12a22    “ [93h / 147]    l
0x12a23    ” [94h / 148]    m
0x12a24    • [95h / 149]    n

0x12a91     [81h / 129]    a
0x12a92    ‚ [82h / 130]    b
0x12a93    ƒ [83h / 131]    c
0x12a94    „ [84h / 132]    d
0x12a95    … [85h / 133]    e
0x12a96    † [86h / 134]    f
0x12a97    ‡ [87h / 135]    g
0x12a98    ˆ [88h / 136]    h
0x12a99    ‰ [89h / 137]    i

0x12b71     [81h / 129]    a
0x12b72    ‚ [82h / 130]    b
0x12b73    ƒ [83h / 131]    c
0x12b74    „ [84h / 132]    d
0x12b75    … [85h / 133]    e
0x12b76    † [86h / 134]    f
0x12b77    ‡ [87h / 135]    g
0x12b78    ˆ [88h / 136]    h
0x12b79    ‰ [89h / 137]    i

0x12b81    ‘ [91h / 145]    j
0x12b82    ’ [92h / 146]    k
0x12b83    “ [93h / 147]    l
0x12b84    ” [94h / 148]    m
0x12b85    • [95h / 149]    n
0x12b86    – [96h / 150]    o
0x12b87    — [97h / 151]    p
0x12b88    ˜ [98h / 152]    q
0x12b89    ™ [99h / 153]    r

Curious sequences...

0x16e18    Ð [d0h / 208]    }
0x16e19    À [c0h / 192]    {
0x16e1a    Ð [d0h / 208]    }
0x16e1b    À [c0h / 192]    {

0x16f3c    Ð [d0h / 208]    }
0x16f3d    Ø [d8h / 216]    Q
0x16f3e    Ð [d0h / 208]    }
0x16f3f    Ø [d8h / 216]    Q

0x17704    Ð [d0h / 208]    }
0x17705    Ä [c4h / 196]    D
0x17706    Ð [d0h / 208]    }
0x17707    Ä [c4h / 196]    D

0x17718    Ð [d0h / 208]    }
0x17719    Ô [d4h / 212]    M
0x1771a    Ð [d0h / 208]    }
0x1771b    Ô [d4h / 212]    M

 

[voidstar78]

OMG! I found strings in the other (newer) aplnx binary. You won't believe this, standby...
(have to adjust the format a bit to make it more readable)

 

[voidstar78]

And so here it is, found in the IBM 5110 APL ROS... (the one above is from the IBM 5100 APL ROS)

@stepleton

NOTE: WS == workspace

Too bad it doesn't also say who it's copyright by. That's a little suspect, Mr. IBM :D

aplnx.bin
hex
offset  EBCDIC "string" value
------- ----------------------
0xdf62    cdefghi
0xdf91    CDEFGHI
0xe056    ABCDEFGHIJKLMNOPQRSTUVWXYZ
0xe08c    0123456789
0xe0ba    abcdefghijklmnopqr
0x10902    jklmnqo
0x10d24    0123456789
0x10f0a    COPYRIGHT
0x10f18    1976
0x1201a    CLEAR
0x12027    LINE
0x12030    LONGNOT
0x12038    WITH
0x1203d    SYSTEM
0x12044    ERROREXCEEDED
0x12052    MAXIMUM
0x1205a    RECORD
0x12061    LENGTH100901
0x1210c    MARKOUTSSORTREWICLEA
0x13eda    CLEAR
0x13ee0    WSLOADEDRESUMEDNOT
0x13ef3    COPIED
0x13efe    FOUND
0x13f0c    WITH
0x13f11    OPEN
0x13f16    FILE
0x13f1b    INCORRECT
0x13f25    COMMAND
0x13f2d    INVALID
0x13f35    FILE
0x13f3a    NUMBER
0x13f44    LOCKED
0x13f52    FOUND
0x13f63    INVALID
0x13f6b    DEVICE
0x13f72    NUMBER
0x13f79    SYMBOL
0x13f80    TABLE
0x13f86    FULL
0x13f8b    INVALID
0x13f93    FILE
0x13f9c    WITH
0x13fa1    SUSPENDED
0x13fab    FUNCTIONS
0x13fb8    FULL
0x13fbd    FILE
0x13fc6    UNIQUE
0x13fcd    WRITE
0x13fd3    PROTECTED
0x13fdd    FILE
0x13fe6    FOUND
0x13fec    INVALID
0x13ff4    DISK
0x13ff9    FILENAME
0x15ae6    CLEAR
0x15af1    CHECKPOINTEDCONTINUEDSAVEDDROPPEDFREEDWAS
0x15b1f    WITH
0x15b24    OPEN
0x15b29    FILE
0x15b2e    INCORRECT
0x15b38    COMMAND
0x15b40    INVALID
0x15b48    FILE
0x15b4d    NUMBER
0x15b58    SAVED
0x15b5f    THIS
0x15b6e    LOCKED
0x15b7c    FOUND
0x15b8d    INVALID
0x15b95    DEVICE
0x15b9c    NUMBER
0x15ba3    INVALID
0x15bab    FILE
0x15bb0    LINE
0x15bb9    LONG
0x15bc2    WITH
0x15bc7    SUSPENDED
0x15bd1    FUNCTIONS
0x15bde    FULL
0x15be3    FILE
0x15bec    UNIQUE
0x15bf3    WRITE
0x15bf9    PROTECTED
0x15c03    FILE
0x15c0c    FOUND
0x15c12    INVALID
0x15c1a    DISK
0x15c1f    FILENAME
0x15c57    QOFF
0x15e36    COPYRIGHT
0x15e44    1976
0x166f2    ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
0x17694    INVALID
0x1769c    FILE
0x176a1    INVALID
0x176a9    DEVICE
0x176b0    INVALID
0x176b8    PARAMETER
0x176c6    WITH
0x176cb    OPEN
0x176d0    DEVICE
0x176db    WITH
0x176e0    OPEN
0x176e5    FILE
0x176ea    WSFULL
0x176f1    INVALID
0x176f9    DEVICE
0x17700    NUMBERALREADY
0x1770e    MARKEDLINE
0x1771d    LONG
0x1794f    LOAD
0x17955    SAVE
0x1795b    COPY
0x17961    CONTINUE
0x1796b    WSID
0x17977    OUTSEL
0x1797f    MARK
0x17997    VARS
0x179b9    SINL
0x17a00    SYSAREA
0x17a48    WRONG
0x17a4e    VOLUME
0x17aa4    ERROR
0x17aaa    0ERRORSET
0x17ab4    INVALID
0x17abc    DEVICE
0x17ac3    NUMBERALLOUTOFF
0x19d92    DEVICE
0x19d9d    OPEN
0x19da3    INVALID
0x19dab    DATA
0x19db0    TYPE
0x19db6    INVALID
0x19dbe    PARAMETER
0x19dcc    FULL
0x19dd2    INVALID
0x19dda    FILEDATA
0x19df1    EXCEEDED
0x19dfa    MAXIMUM
0x19e02    RECORD
0x19e09    LENGTH
0x19e15    WITH
0x19e1a    OPEN
0x19e1f    FILE
0x19e25    INVALID
0x19e2d    DEVICE
0x19e34    NUMBER
0x19e3c    INVALID
0x19e44    FILE
0x19e49    NUMBER
0x19e51    INVALID
0x19e59    DEVICE
0x19e61    INVALID
0x19e69    OPERATION
0x19e74    FILE
0x19e7d    FOUND
0x19e84    FILE
0x19e8d    UNIQUE
0x19e95    WRITE
0x19e9b    PROTECT
0x19ea8    DOMAIN
0x19eaf    ERROR
0x19eb6    INVALID
0x19ec3    INVALID
0x19ecb    DATA
0x19ede    PROGRAM
0x19ee6    CHECK
0x19eed    VALUE
0x19ef3    ERROR
0x19efa    WRONG
0x19f00    VOLUME
0x19f7b    STATUS

 

[voidstar78]

Forgot HxD also offers EBCDIC encoding...

Not sure why the Common ROS contains the word "MICROPROCESSOR".

 

[stepleton]

Don't forget that the 5100 isn't EBCDIC, it uses its own encoding. PDF pages 336-337 of the 5100 MIM.

You can apply that transformation on the UNIX command line and filter for strings of text --- this does something very similar to your program:

tr '\0\1\2\3\4\5\6\7\10\11\12\13\14\15\16\17\20\21\22\23\24\25\26\27\30\31\32\33\34\35\36\37\40\41\42\43\44' ' ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789' < binary_APL_LROS.bin | strings

It's not quite the same because bytes that aren't in the alphanumeric characters get passed through `tr` unchanged, causing more noisy garbage text. But you can still find the strings you're looking for if you scan the output visually.

 

[voidstar78]

Exactly! All collectively confirmation that the 5100 series is emulating those mainframes (at least selectively or partially). As it more clearly shows PALM native vs non-PALM regions of the ROS. I guess another encoding using those native sequences might also give some insights.

It also explains the apparent “slowness” of the 5100 as it’s doing extra work to translate between these encodings ( between keyboard scan codes, emulator IO, and display output codes).

Wonder if the IBM line printers were generally more native EBCDIC devices?

 

[stepleton]

There's really little doubt about the emulation of other systems: the code is pretty clearly System/3x0 and System/3 code. You don't need a complete disassembly to become pretty certain of this: instead, one quick and easy way is to look for really common words and check that they correspond to sensible opcodes. To get the ten most common words in the APL LROS, do:

xxd -c 2 -p binary_APL_LROS.bin | sort | uniq -c | sort -n -r | head -n 10

This gives us:

Occurences   Word   S360 instruction
      5618   0000     <not an instruction, just empty bytes>
      1070   47f0   Unconditional branch
       884   4780   Branch if equal to zero
       645   0002     <not an instruction>
       576   b000     <not an instruction>
       535   4770   Branch if not equal to zero
       479   58f0   Load into register F
       422   0004     <not an instruction>
       416   0001     <not an instruction>
       371   05ff   Branch to address in register F, return address into register F

We shouldn't be surprised at the frequency of common constant values like 0000, 0001, 0002, and 0004, and most of the rest are really sensible "popular" instructions for the 360 and its successors. I suspect that 1,070 separate occurrences of an unconditional branch instruction is a pretty big clue all by itself!

I couldn't find a convenient hex-to-opcodes table for System/3, so I'll have to leave the analysis of the BASIC and common ROS as an exercise. But I bet you could do basically the same thing there.

Regarding the different types of code, here's a visualisation of all the 5100 non-executable ROS: just turn the bytes into raw RGB and see what you get.



Looks like static, right? But examine closely: you can see the texture of the static change between the top third and the bottom two thirds. That's the boundary between the System/3 code and the System/3x0 code.


Meanwhile: translating between character encodings isn't too resource-intensive: you only need to do a lookup in a 256-byte table.

 

[voidstar78]

Yep, I hadn’t seen an S3 analysis yet, so I was gearing up with practice on what we knew so far on the S370 side. Actually I wasn’t certain on S360 vs S370 content - and was wondering if we could narrow it down to a more specific model ( and maybe find the original source that it came from ).

So if it’s S370 based then it’s some model 150 series? Also weird to think of a “weaker system” emulating a more powerful system ( ie 16bit PALM emulating 32bit mainframe ), but maybe that just shows how arbitrary categorizing the “bit-ness” of a system is. ( I think we talked before how the 1-bit Datapoint could still do a good amount of general purpose stuff )