IBM 5100 ROS arrangement

[voidstar78]

Greetings! I'm trying to figure out the arrangement of ROS code in the IBM 5100.

@stepleton extracted these ROS' a while back with a very clever process (and did it twice to ensure accuracy!).

I'm not quite old enough to have worked on these systems first hand in their heyday, so I am just going by what I can read from the IBM manuals. But I am fairly familiar with the 5110 emulator and the extracted ROS binaries from that system (see 5110VEMU). From what I've read, the PALM processor was unchanged between the IBM 5100 and 5110 (in terms of opcodes and what they do). Keyboard scancodes and video characterset codes were changed, but it's the same 16-bit PALM (16x16-bit registers across 4 interrupt levels -- well, 3 plus a main processing tier).

Let me begin with the 5110, as an initial frame of reference. Based on my understanding, it has a ROS arrangement like this:



What was extracted (by Christian Corti, who I've tried to contract but so far unable to reach) were 6 binaries files: executive ros, common ROS, BASIC ROS, BASIC NX ROS, APL ROS, and APL NX ROS.

These are in two categories: basically native PALM instruction binaries, and then non-PALM binaries (which my understanding those were essentially binaries extracted from System/370 and System/3 -- or variants thereof -- or at least existing BASIC and APL interpreted programs from those corresponding systems). This is partly why these IBMs were "slow" - they were emulating the running of interpreters! But to me it's also very clever -- software is hard/expensive to produce, difficult to debug/perfect (especially at a time when you didn't have interactive debuggers, and had to wait for printers, etc.).

Ok, back to the question: I have reason to believe the "ROS" (ROM) code can only be 32 Kbytes (because in the emulator they shift a bit when addressing the ROS, which means the ROS' end up only 15-bit addressed, or 32K). Or maybe that was just a side effect of having extracted the ROS' into individual files - I'm not 100% sure.

The "NX" code can be up to 128KB, as they seem to be 16-bit addressed and 16-bits wide (the core emulator code reserves up to this space, but most of these NX ROS's don't actually use that much). And the ROS PALM code has to do a lot of bit twiddling to feed things in and out of that "NX" code.

NOTE, for this exercise I'm ignoring the Feature ROS. We can access it and could extract it, but it's a component of (apparently) very little interest -- related to disk sorting (I think maybe sorting content that's on a disk? which yes by itself is useful, but not relevant until you get to a working disk setup).

Both APL and BASIC have both a "ROS" and an "NX" (non-executive) binary. The "ROS" is the PALM-native code that coordinates the corresponding emulated code (the BASIC interpreter, or the APL interpreter). The PALM by itself seems to be a fairly capable processor, so it's a shame its raw capabilities were so hidden. I'm not sure if any "pure-assembly" (machine-code) programs were ever commercially developed for it (although I've read about some IMF code that could be latched in from the DCP, maybe those were in PALM opcodes?)

Anyhow, there is quite a bit of content/code in the "Common ROS", but frankly I haven't been able to quite determine if it is PALM instructions or a mix of System/370 and System/3 content?? Somewhere i've read that the Common ROS stores "common tables" between the emulated code (I suspect maybe conversion codes for maybe effectively scancodes and characterset codes of those emulated systems, and the native ones of the IBM5100/5110? so the "code" in the common ROS could just be lookup tables -- but it's 12K of "something", the remaining 4K is all blank/zeros -- and remember the Common ROS is read-only, ROS/ROM, not a scratch pad space).

If you removed both BASIC and APL - you still have a functional machine: you have the Executive ROS, that can run PALM instructions from the RWS/RAM. BUT, if you want to load or save content, you have to be be savvy and send proper IOCB control codes and branch to the proper executive microcode (so the Executive ROS is exactly like an early BIOS. But imagine you're in BASIC or APL and do a "SAVE" or ")SAVE" command, something has to interpet what the emulator would do, and communicate that back as suitable IOCB control codes -- I'm not sure if the "Common ROS" handles that, or parts of that, or not (which is why possibly it could be a mix of "all of the above" PALM and System/370/3 code, or either).

From my emulator, "between" each BASIC or APL statement (after pressing ENTER/ATTN), control temporarily goes back to the Executive ROS - to do maintenance things like scroll the screen, update the RWS available RAM count, blink the cursor, check for interrupts, etc. This applies when running code also - run a statement, swap back to Executive, check status, repeat next line, etc.

NOTE, in the above Card F is marked "ROS Control" or also cited as "Common and Language ROS" - the 5110 was offered in an "A" version that (allegedly) didn't have BASIC. So I'd expect the BASIC ROS and BASIC NX portions of that slot to just be missing, the Common ROS should still be there, and the language switch just hard-wired to an APL startup. Not sure. Also don't quote me on the arrangement of those ROS across Card F - I just guessed. I don't know which "side" is 0 address (if that even makes any sense). Remember as 16-bit words (or maybe 18-bit w/ parity?), the BASIC NX should be "36K" addressed (2 bytes each, total 72K).

This is just the setup to the question, which is the next post...

 

[voidstar78]

Ok, previously I talked about the 5110 - it might not be exactly correct, but the emulator works and I think we have all the ROS's account for (except for the Async ROS, which we'll hold off on that for now).

So, similarly the ROS binaries for the 5100 were extracted, but it ends up with 3 files instead of 6. So I have to assume those 3 files are mingled/double-dipped with several ROS's.

Let's take a look. Here is how I think the arrangement should be:




NOTE the IBM 5100 has a "mainboard" (A1) with "expansion slots" - but they're not exactly interchangeable. It's not an ISA bus. The slots are specific purpose - they are modular in that you can remove memory, or maybe remove just BASIC. But the overall arrangement is fairly rigid. And aside from the memory being at the "end", the arrangement is fairly different than the 5110. So as some highlights:


- APL Supervisor? (is that called APL ROS in the 5110?)
- Where is the Common ROS? Slot E is ROS Control, but Slot H also indicates some aspect of "BASIC" in there.
- for the Executable ROS, there is *something* different at the halfway (32KB) mark. And the last 20K (B000-FFFF) is all 0xFF values.
- as extracted, the BASIC NX and Common ROS were apparently across a seamless set of addresses (i.e. the resulting binary was 36+18 = 54KB in length), so should the Common ROS be addressed as such? Which then implies it is part of Slot C (and not E or H!)
- Previously I said I had reason to believe that the ROS (non-NX) PALM code was limited to 32K. So if that's the case, how is the 5100 executive ROS a total of 64K? It could be that the Executive ROS for the 5100 is really two separate portions of ROS's? Or I'm just wrong about that - but note the Executive ROS portion of my 5100 emulator is working (and it has the >>1 bit shift when addressing the executive ROS; if I remove that shift, the whole thing blows up and doesn't work - at least for BUP and initial startup, right on up to the language ROS handoff)

So now it's finding where the APL ROS and BASIC ROS equivalent are addressed from (which might be in the Executive ROS itself?), or what the APL Supervisor is all about. Also note that the BASIC NX and APL NX are quite a bit smaller than the 5110 versions -- I know for BASIC NX on the 5110, they added quite a bit of "FORM" keyword capability. I'm not sure on the APL capability differences (I suppose one obvious addition in the disk drive support -- which, did they basically use the same "file" format on tape or disk? you have to guess how much size you want to mark for a file -- kind of like guessing allocation-units on modern FAT drives?? just difference is with the disk, you don't have to issue a REWIND...).


I'm not sure what the "Expansion Feature" of the 5100 was (Slot B) -- I'd assume serial or modem related, some kind of comm. But the 5100 was light on external I/O and didn't have the Features ROS (no disk support). Whatever ROS it was, we don't have that yet.


Was the 5100 ever offered WITHOUT BASIC ? (i.e. did it have A/B/C variants like the 5110?)


I'll plug away at some trial and error. But I'm curious if anyone has insights or suggestions here


Also, in the MIM manual I found a reference that listed some "keyboard compositions" for some APL keys. I didn't see a corresponding composition on the BASIC side - but I do know (now!) that you can compose an "!" with a couple of keys ( ' and . ). If anyone knows of a document of other compositions, I'd be interested in that. (although the code to support that ought to be in the Executive ROS itself, we'll find em )

 

[krebizfan]

For contacting Christian Corti, you may want to join the CCTALK mailing list. There was a post last Friday from that person regarding the 5100. http://www.classiccmp.org/mailman/listinfo/cctalk

There is a picture of a card that was in the Expansion Feature slot at https://www.oldcomputr.com/ibm-5100-1975/ It does not look to be doing any I/O since there are no visible ports but I haven't a clue as to what it might do. Pages 5-16 and 5-17 of the maintenance have diagrams that make it seem to be a serial port controller.

 

[voidstar78]

Although there are no apparent external pins on that Expansion Feature card, I suspect the base connector on that is routed to that Z1 connector on the top left (Comm/Serial IO), which is then in turn has a cable routed to the open slot on the back (facing the back side, there is the "Y"-shaped set of connectors, but to the left of that is a smaller panel for the externals - that panel is typically just covered entirely if the unit has no comm/serial devices). This one:




The IO Cable Driver is the one in Slot A with more obvious cables routed to that "Y"-shape set of connectors on the back.

Excellent photos. The number of "tin cans" on each card is a helpful clue.

To talk to these cards, the PALM has a CTL OpCode (Appendix C of the IBM 5100 MIM manual about PALM opcodes, an appendix that is apparently omitted on the 5110 manuals). From that, it looks like the expansion could be "either" a comm or serial I/O (similar but different protocols?). Although the slot on the back panel provisions for having two expansion options.





I hadn't read through the 5100 MIM as much as the 5110. In the Oct1979 5100 MIM, a few pages of interest:

6-2 list the BASIC IOCB addresses.

4-22 lists some subroutines in the Executive ROS (it lists $8000 as just "APL microprogram routines").

4-19 answers one of my questions: Common and Language ROS is in E2

4-21 I don't fully get the "Select ROS" diagram here, but I recall there being a SAR and SAB registers (?) used to designate

4-4 answers another question: there were A/B/C models of the 5100 (like the 5110). Although, this manual is from '79, I'm not sure if that was the case also in '75 on launch.

And 4-20 has this: (which to me confirms that the BASIC ROS and Common ROS should correctly be a single 54KB binary, where the offset/address into that is shared - but then I'm still not exactly sure the APL ROS is located, which should a be thing at sets up IOCB instructions to talk to the APL NX stuff)

 

[stepleton]

Thanks for kicking off this thread on the 5100. At the rate you're going now, I have high hopes that you'll crack open all of these mysteries fairly quickly. I wish I had more time to participate in the discussion here, but there is a lot going on!

One of the questions that is coming up a lot seems to be around finding out what parts of the code are native PALM software, what's System/3 software for the BASIC interpreter, and what's System/360 software for the APL interpreter. I think this is something you could probably unravel using a bit of brute force

The tools I would use for this are disassemblers. I don't know if there's a System/3 disassembler out there, but you have made a PALM disassembler, and for System/360 code, it seems possible to me that the GNU binutils tools for s390 could do the job.

What I would do is break the firmware data into chunks and run them through the disassemblers. If the disassembly for a chunk looks like real System/360 assembly code, for example, then that's probably what that chunk was, but if there are lots of weird opcodes and unrecognised data, then it was probably for a different architecture, or maybe data tables.

One interesting thing to look at:



This funky picture is what you get when you take all the non-executable ROS data and concatenate it together, then turn it into a raw 256-pixel-wide RGB image. (Note that the image here has been "blown up" by 200%.)

It doesn't really make sense to make a picture like this, except, remarkably, you can still see structure! See how the top third looks different from the bottom two thirds? That's because the top third is the BASIC ROS and the bottom two thirds is the APL ROS. Your eyes and brain can see the statistical differences between the way System/3 code looks and the way System/360 code looks.

 

[voidstar78]

all of these mysteries fairly quickly

I appreciate your confidence :D I think the existing PALM core emulator is close. But I've tried a few variations without luck yet.

As mentioned, it is running your executive ROS - at least I can "read" what it is doing and display the results. I can't yet interact with it (I can't type things to command the DCP). I've adjusted for the different keyboard scan codes of the 5110, the interrupt 3 is firing -- and the cursor is blinking, so the code is running. But the "A"/alter, "D"/display, or "C"/test list inputs aren't registering yet, so that's a bit of a mystery still.

And then the executive to language handoff is still not working. This is going on the assumption that the "language ROS" as extracted are corrected. And since the executive ROS was done so well, I'm confidence the language ROS ones are also. Although - the "endianness" aspect comes to mind. I wouldn't think the language ROS files were written in any different way than the executive ROS was -- but it's possible maybe the language ROS' are byte-swapped from what the emulator is expecting?

It'll take some time to unravel

I noticed the old Wang 2200 has an emulator, so it's well-past time that there is a proper emulator for the IBM 5100 as well Both being derived from early 1970s work, and having "book-sized" processors.

 

[stepleton]

The non-executable (language) ROS is the one I'm the most confident about, since I was able to use IBM's own 16-bit CRC to check the integrity of the recovered data. There's a chance that there's a problem with the data that eludes the CRC-based verification, but I don't think it's too likely.

 

[voidstar78]

Well, I finally found a sample of System/370 machine code (or what it calls object code) in the 1969 book "Assembler Language Programming: the IBM System/370 Family" (looks like it was revised or reprinted in 1984?)

It's just a for-fun reference, but it highlights that the OPcodes (object code) are indeed 32-bit/4 bytes. The full opcodes are listed near the end of the book, but the other 400+ pages are samples of a particular assembler for that system (including a random number generator sample! and sections about virtual memory and working sets - pretty neat).




But this did lead me to coming up with another way to determine what's native PALM and not: I disassembled the binary_BCOM.bin file (with the PALM disassembler) and I noticed the resulting .asm had a bunch of CTRL opcodes that aren't valid for the IBM 5100. CTRL is opcode 1, and the next nibble is a device reference. Only about half of those devices are defined:

$0 yes controller
$1 yes non-executive ROS (which one? can select APL or select "BASIC or common")
CTRL $2 no (not assigned)
CTRL $3 no (not assigned)
$4 yes keyboard and control panel switches
$5 yes printer
CTRL $6 no (not assigned)
CTRL $7 no (not assigned)
$8 yes expansion feature (can select TX mode or RX mode)
CTRL $9 no (not assigned)
CTRL $A no (not assigned)
CTRL $B no (not assigned)
CTRL $C no (not assigned)
CTRL $D no (not assigned)
$E yes tape unit
$F yes all I/O


Sooo... if I disassemble a binary, and it issues CTRL wrt devices for any of the ones not-assigned, then it is probably not PALM code. i.e. technically the opcode that uses unassigned devices are valid, it just there would be no reason for any ROS code to issue that.

And sure enough, such "invalid" CTRL opcodes (for unassigned devices) are all throughout the binary_BCOM.bin file (near beginning, middle, to near the end). So that suggest to me, as suspected, that entire file isn't native PALM content (combined with other parts of the MIM saying the Common and BASIC NX share the same addressing). [ it occurs in the APL_LROS.bin as well -- which by the way, why does that filename have "L" before ROS? was always curious about that ]


So, for the 5110 is has BASIC ROS, BASIC NX ROS and APL ROS and APL NX ROS. I do think in the 5100, the (equivalent of) "BASIC ROS" and "APL ROS" are in the Executive ROS binary (what I think the 5100 calls APL Supervisor and the "BASIC" within Card H). I shouldn't really have to care where in that address space they exist - the executive ROS code should just point accordingly. But maybe I'm wrong -- I recall the MIM saying there are "two" Executive ROSs (and they don't necessarily have to be split at the 32K mid-section of that 64K binary).

Meaning, in the way you extracted that Executive ROS - it's a valid 64K linear set of code (and as you mentioned, the startup CRC check might only apply to a portion of that). But parts of the ROS software might reference different relative offsets within that ROS when executing (which is all native PALM instructions, not to be confused with the "language ROS" that are NX/non-executable since they aren't native PALM instructions, those reside on different cards and have their own address space). So still TBD is that 64K execros still needs to be split up or not.

All that said, I'm still not clear on exactly what resides on the Slot E "ROS Control" card for the 5100. Which incidentally, the startup error I am getting is "18 07" which my understanding is 18 is referring to E2 ROS Control card (per 3-16 of the Oct1979 5100 MIM, page 98 of the PDF). Maybe we have a 4th missing ROS ? (I assumed CTRL $0, which goes to "Controller" -- I assumed that meant the "main controller" in Slot G, where the CTRL can do things like halt the CRT and turn on the processing light -- but maybe the logic to do that stuff is actually in the ROS Controller card E?)
NOTE: that same 5100 MIM from Oct1979, diagram on 4-6 says "E2" is Common and Language ROS, which I think should be the 18K portion of the binary_BCOM.bin file, but still not sure (or even if so, how it's addressed)

 

[stepleton]

The meaning of this error code (according to the MIM page you referenced) is that the computer wanted to read ROS module 18 but encountered what it thinks is ROS module 07 instead.

ROS modules are 6144-byte ($1800-byte in hex) chunks of data in the non-executable ROS. Each one is identified by a number --- that's the number that shows up on the second line of the display when the 5100 is undergoing its "I" test.

ROS module 18 does exist in the data that I dumped --- and it passes the 5100's CRC verification. I don't think there is still unrecovered ROS data in the machine.*

...

What all this tells me is that the combo of the 5100 executable ROS and the emulator are looking for module 18 in a different part of memory than where your work-in-progress code is placing it now. Wherever the ROS+emulator is looking to find module 18, it's instead finding some other data in memory that has a "07" value in the place where the module identifier goes. You'll probably need to put the data for module 18 in that location, wherever it is.

There is no such thing as a module "07" in the 5100 non-executable ROS. However, I think you can find the module 18 data in the last 6144 bytes of the file binary_BCom.bin.

Consider reviewing https://github.com/stepleton/5100NonExecutableROSDecode/blob/main/DATA.md carefully --- there may be hints in there that help you deduce the memory arrangement that the 5100 requires. I did find certain aspects of the non-executable ROS addressing to be unusual. (Note that this document uses the word "segment" instead of "module").

Good luck! I think you are close.



(* well, there are the PALM microcode ROMs that we discussed many weeks ago, but that's a very different thing! not needed if we already have a PALM emulator.)

 

[voidstar78]

Ah, YY = Module ID *read*. The "007" below that distracted me (where ZZZ meant it should be 3-digits, not 2). (do later models of the 5100 show the actual letters "ROS" before the numbers? the 5110 does this; the MIM was updated in 1979, and I recall reading somewhere both the 5100/5110 weren't discontinued until '81 ? i.e. not sure if the executive ROS of early 5100's differed from later 5100's)



And noticed this nice startup sequence description in that MIM 3-10. I've stepped through the "RWS test" it mentions in line 2, I'll see if I can find the address table setup it is talking about in line 3.




EDIT: There is a GETB instruction (opcode E), it is invoked shortly after the "H" entry. And related to processing that GETB in the emulator, it has two constants. While the code says it is related to "keyboard", remember the switches on the front panel are essentially part of the keyboard as well. So I think it is monitoring the state of the language switch, and then one of these two constants are returned back. Perhaps it is these two constants that are throwing off the 5100 emulator (the value of the constants may be different for the 5100 than the 5110). Maybe these constants are the starting address of a Module ID ????

.....
case 4: /* Keyboard */
if(REGLO(n2) == 0x80)
{
/* Read status */
if(language_ros == BASROS) // set earlier based on monitoring state of the language switch
REGLO(n2) = 0x76; // 0111 0110 works for 5110, valid for 5100 ????
else
REGLO(n2) = 0x36; // 0011 0110 works for 5110, valid for 5100 ???

if(kbdcode) // <-- does not apply during startup, no actual key is being pressed
REGLO(n2) |= 0x08;
}
....

 

[stepleton]

Good questions all --- I don't know about versioning of the various 5100 ROSs, though I've often wondered if there had been multiple revisions. I'm not certain when my 5100 was built, although I find that it has the "old style" AC box (see MIM PDF page 29), which may mean that it's an earlier unit. Of course, whether it is or not, that doesn't mean that the ROS cards are original to my machine --- they could have been replaced at some point.

I don't know if this is relevant to this mystery, but I remember reading in the MIM that if an IBM tech were fitting a language ROS to a 5100 that did not have that language before (e.g. adding APL to a machine that had only ever had BASIC), then they also had to connect a jumper between some of the pins on the backplane.

If you ever find that you'd like me to run some short programs on my 5100 under DCP, then I'm happy to type them in and try them out. You might be able to use the information to check for differences between what the emulator does and what the real hardware does.

 

[larryw]

That code is really a blast from the past. That listing is IBM (360/370) Basic Assembler Language (aka BAL) and the compiler converted that into machine code. The IBM "Bible" for assembler was the "IBM Principles of Operation" I think I still have a copy of that well-used brownish orange book somewhere along with the "yellow card" and (I think) it was an older edition "green card" reference. The "Opcodes" are the numbers at the start of each line the readable text are the Mnemonics so for example the mnemonic "LA R7,X and LA R8,Y and LA R9,Z" all begin with the opcode "41" followed by the register folllwed by the address where the data to be loaded is stored so 4170, 4180 or 4190 and an address e.g abcd. If there was a value OTHER than where I showed zero then that would be indirect addressing and the number would represent a register which had an address which would be used as the base address (pointer) and the 4 digits following would then be added to that base addres value the final address. When I was taught assembler we HAD to learn and program for the first month in JUST opcodes (i.e long strings of numbers) the instructor only introduced the mnemonics after the first month. This of course meant that graduates of the class could read system and program abnormal ends (ABENDS) or dumps which are of course nothing but pages of numbers without even thinking about it (kind of like learning CW now I think about it)

 

[voidstar78]

Just a quick note:

IBM 5100 MIM Logics 5-33 (Oct 1979) has some hardware diagrams of each card...

( the IO Controller has a little bit of memory, I think related to an 8-bit counter - didn't show that one )

But for the main ROS's - the arrangement seems to be:

(it's just whats the relative address of each of these - they all start at 0? or are accessed as a continuation of another ROS's address space? )


BASIC ROS = 32K (the binary binary_BCom.bin is 54K - subtract 18K for common, that's 36K -- so there's 4K of "something" still in this ROS binary)
Executive ROS = 16K + 16K (should be 32K, so the exeros.bin has 32K of "something" - must be the APL Supervisor stuff, not sure how that upper 32K is addressed {unless it's 0-offset from "something")
APL ROS 1/2/3 = 32K + 32K + 32K = 96K total (that's consistent with the APL_LROS.bin that is 96K)
ROS Control = 18K (manual says this is somehow addressed "as part of" the BASIC ROS)


I noticed in the binary_BCom.bin the *first* 18K has a clear cut right around that offset (i.e. I thought maybe the CommonROS was the last 18K of that 54K file, maybe it's actually the first 18K?)

Right now I'm just trying to get the BASIC ROS up and going. But down the road, for the APL ROS - I wonder which one is "first" (ROS3? or does it go ROS1/2/3). From the controller perspective, it should be a seamless 0 to 96K address, but it might matter in the order of the binary file. TBD.


Agreed that first 32K of the executive ROS is solid and confirmed. And I suspect the reason I can't "interact" with it (type stuff) is that fires off interrupt 3, and part of that handling might either be in the ROS Control or the Common ROS (which I don't have sorted out yet) - I could be wrong about that, since somewhere in the MIM it says executive ROS $5B00 is the interrupt 3 handler (but in there it has some CTRL opcodes that may involve that ROS Controller?)

 

[voidstar78]

@larryw Yeah, I didn't want to full up learn System/370 And yes, assembly is subjective (in that it is up to the assembler software to decide what the mnemonics are).

Section 1.3: "Since the IBM System/360 was announced in 1964, there have been many different models. System/370 models had some improved capabilities, and some of these were the first IBM computers to implement virtual storage.... there is a set of 16 general-purpose registers, each one word (4 bytes) long... Their addresses are 0 to 15 Still another set of four registers is used in floating-point arithmetic.... In models newer than System/360, there is a set of 16 control registers... These registers are used almost exclusively by the operating system"
...
"Addresses in System/370 are usually 24-bit numbers, though in some modes in newer models 31-bit addresses can be used." (goes on to explain byte order, each address is a word of 32-bit, and the 88 characters of EBCDIC, followed by "zoned decimal" as related to punch cards).

And thought you might appreciate this from the Appendix C (that's nuts! Appendix C is also used in the IBM 5100 MIM manual for its OpCodes -- a completely different reference -- was that an industry insiders convention, to have appendix C be for opcodes? haha):



The book reader I have doesn't let me rotate the pages, so it's a pin of a pain to examine these. But Im really curious what tools they used to make these diagrams back in 1969. Like one of these, how would it have been expressed and sent to a printer back in those days? Some software on a System/360 itself?




There are many parallels to the PALM processor here -- it has 16 registers, each of 16-bit, and they start from address 0. And I noticed R1 (register 1) is often used as an index/offset from R0 (like R0 is a base address, and R1 used to jump around relative to that base)

 

[larryw]

The 360 series in production environments were a little before my time but I had quite a run consulting as an IBM VM systems programmer (yes Virtual Machines originated on the mainframe) on the 370 and 4300's before moving to UNIX and then PC's. Anyway as I said thanks for posting that listing it was fun seeing that old code again I may have to lookup whatever happened to the, I think it was Hercules, mainframe emulator and get an MVS system running on a Raspberry Pi or sometbingm

 

[voidstar78]

So, these are notes/ramblings just for future prosperity I've examined each of the 5100 ROS's available, and see some interesting trends. I'll start with the Executive ROS:

For each of these, I basically scanned through them in a hex editor, and itemized out sections that were separated by at least 10-30 blanks (0x00).

The PALM (Executive ROS) one is fairly straightforward...

1) the machine starts at whatever offset the first byte says. "00 04" in this case means start at the 00 01 02 03 04th offset, which is "1F FF" in this case (a CTRL $F,$FF instruction that "resets everything" {all the devices}). And things proceed from there

2) the MIM manual has a page that gives a sort of "memory map" of the Executive ROS - and the addresses I found line up with that (see descriptions in Column F).

3) at $3000 and $B000 are a bunch of 0xFF, I'm not sure why. The first one is 8K in length, the second one is 20K in length. They don't hurt or mask anything, it's just how the ROS was setup. Maybe it helped to clearly indicate "space available for future ROS expansions", as opposed to having 0x00 zeros.

4) The Executive ROS (Card 2x16KBx18 bits, 2 bits for parity). So each address is 2-bytes, which should explain why it is 64KB bytes total. (contrast to the ROS Control E2 card, that is 18Kx8-bit, which I'm still not exactly sure where that is located or how it is addressed - yet).

 

[voidstar78]

Ok, now the "BASIC ROS"... Which should be System/3 instructions. All 54K of it?

So, I found a System/3 manual (great, another 500 page manual!). There were many models (the manual I found is model 8, 10, 12, and 15). I'm not sure if we know for certain which model the 5100 emulated.

Tentatively, it looks like: if System/370 was akin to RISC, then System/3 seems to be CISC !!!! That might not be quite accurate (and I know those two terms came years/decades after these IBM systems) -- but I say this because it seems the System/370 had memory alignment and kept things mostly at 32-bit words. But the System/3 opcodes are dynamic - sometimes 2, 3, or 4 bytes (maybe more). And yes, the System/370 had some exceptions where an addressed continued into the next word - but I don't think it had any "odd-numbered" opcodes (in terms of number of bits).

Anyway, at the end of the System/3 book is Appendix A with a nice summary chart of opcodes. And the gist of it seems to be: anything starting with
00, 01, 02, 03, 05, 09 (hex)
10, 11, 12, 13, 15, 19 (hex)
(... and so on, all the "blank" entries in the table...)
Those are invalid opcodes. At least for the models discussed in this System/3 manual.

(see chart below first, may help clarify the following)
So when exploring binary-as-instructions, it's hard to know what is Data and what is Instruction. Like in the earlier PALM example, the first two bytes are actually Data (what offset to start at).

Anyway, if I assume this "BASIC_COM.bin" binary is System/3 opcodes (as viewed in the hex editor, and not having to byte swap anything -- Intel systems have to byte swap in memory, but the file as streamed should be ok)...... That binary file starts with "16" which actually is a valid System/3 opcode: "AZ". But the weird thing is, the entire first 512 bytes of this binary is full of "1x YY" instructions (see blue boxes below for the first 8 - but all 255 of them seem to be valid "1x" instructions). So maybe it's just initializing stuff - the first nibble ("0001") sets the address/indexing mode, the second nibble decides the action.

At offset 0x0200 (not shown) then you have a bunch of 0xF0 instructions (about 25 of them). I'm not System/3 expert, but it looks like "F0" is a halt instruction, followed by two operands that basically control what letters show up on some status LED of System/3 (what operands map to what letters are listed out in the manual). There are two operands since it is a LEFT and RIGHT set of segmented LEDs. So maybe it doesn't really halt but cycles through a bunch of letters?

So then the first "real instruction" isn't until 0x233, which is 0xCE... which, according to the little System/3 opcode chart -- is an invalid opcode Sad. So maybe I'm wrong, maybe all the stuff at these early addresses is actually data, cross-reference tables. But if it is code, then it starts at 0x233 and goes up for about 6K. Then something interesting happens.. a pattern!

@stepleton There is where I may need your help, you mentioned 1800h earlier (something I wasn't aware of till I dug into this binary)... well... see below

Starting at 0x17FC, I see this pattern of a 4-byte "code" followed by 6K of "instruction." And there is a pattern to the code:
00 10
00 11
00 12
..13, 14, 15, ...
01 16
01 17
I'm not sure if the two bytes after these codes is CRC values? Well, the section at the beginning is also 6K -- but there is no "00 09" or "00 01" or "00 00" marker, so where is the CRC code for that starting section?

Ok, but here's another interesting thing: all these 6K sections (except the first section @ 0x0000 and the last section 17 @ C000), they all contain that "F0" instruction.

Each section has a different number of F0 instructions -- and again, the manual suggest these are a HALT instruction (as in, go into an infinite loop), but also does talk about updating a LEFT/RIGHT LED display with the operand code (maybe it doesn't halt, or maybe these are branch targets in case some error conditions are encountered?).

Anyway, if I assume these are either branch targets, data, or just flicker the LEDs in a sequence -- if I skip the "F0" instructions, column G list the "code" that follows that sections F0 sequence. Each of the F0 entries are followed by two bytes. Then the end of the entire sequence is followed by "00 00". It could be System/3 by default "ignores" invalid OpCodes and just keeps incrementing the program counter? Not sure, which means from Column G I'm not sure what is exactly the first instruction executed. (e.g. "05" seems like an invalid instruction in the System/3 manual reference I have, but maybe it is a different model/etc).


So finding this "pattern of 6K stuff" is neat - but... I still can't answer these questions:
1) is this BASIC_COM.bin file entirely System/3 instructions? (or is any portion of it actually table-data stuff? but it looks like 9x6K sections of something = 54K total)
2) where is the 18K of "ROS Control" content? (maybe there is no ROS Control, maybe it is just a buffer to funnel up to 18K between PALM and these emulated systems? don't think so, it is called "Control"... manual calls it as a "common and language ROS")
3) was System/3 byte, 2-byte, or word (4-byte) addressable? I'm still not 100% clear on that. It matters in trying to explain why the file is 54K (BASIC ROS is given 32K). If it is 2-byte addressed, then ok it's only 27K addresses and fits. [whatever it is, i'm not sure why it would be different on the IBM 5110 -- i.e. that the emulator is running for the 5110 ok]
[ although with a missing or broken ROS control, maybe results of the BASIC ROS binary aren't getting communicated back properly? ]

 

[voidstar78]

And for completeness, here is an examination of the 96K APL binary (which should System/370 code).

The registers are word (32-bit). I'm not 100% sure if the addressing is also 32-bit - although I think it makes sense, as it explains how the APL ROS binary can be 96K (even though the APL ROS cards only have 32K -- well if each address can hold up to 4 bytes, they only needed 3 sections to hold up to 96K).

Nothing too exciting, things look like valid opcodes. The two exceptions are in RED below at 0x2FFC and towards the very end is a bunch of "83 6E" repeated starting at 0x17DFC. I'd assume those two sections are data tables of some sort (address offsets, ASCII/scancode conversions, etc?). But the repeat "83 6E" is curious, does that ring a bell with anyone in the context of System/370 ?

Then at 0xCE68 is something odd, a bunch of "0x80" repeated. Not sure what's going on there. (0x80 is also a valid opcode for that system, just not sure why it is repeated about 50 times).

But things like "50", "41", "05" ,"90", "91", "58", "5A", etc... all valid opcodes.

Again, I was marking any address that was preceded with about 10-30 null (0x00) characters. Typically, that represents major "breaks" between sections of instructions.

I was looking for "transitions" at the 32K and 64K mark, to see if anything was suspect about the ordering of of these sections -- the IBM 5100 slots are ROS 1 (D2) ROS 2 (D4) ROS 3 (C2). It doesn't really matter which sections (addresses) corresponds to which physical slot, just a curiosity.

But as stepleton mentioned about colors, it is interesting to get kind of 3 different "cultures" of instruction-code observed here, between PALM, System/3, and System/370.

 

[stepleton]

I hear my name! I'm happy to help you out, but I'm not sure if there's something specific you had in mind?

I really appreciate your writing out the reverse-engineering thought process here --- I think I will learn from it for sure. I wish things weren't so busy at work these days!

I have only one quick hint. Looking back at my old code for verifying the ROS module CRC values, I see a note that the third byte from the end in each $1800-byte module is the byte that identifies the module itself (the 18 20 21 etc. that gets printed under ABCDEFGHI). This will surely mean that the last 16 bits in the module are the CRC value, in a manner of speaking.

(What this really means is this. The code that calculates a module's CRC starts with $FFFF: that is, the CRC of "no data" is $FFFF. Every time the code gets a new byte, it updates that value to a new and very different CRC value. So, if the code iterates next over values $01, $02, $03, the CRC value changes from $FFFF to $F1D1, then $0E7C, then $ADAD. The final two bytes in a module are whatever bytes you need to use so that after the CRC code runs over all of the data leading up to those two bytes, running over those last two bytes will cause the CRC to be $0000. The CRC test for a module passes if the whole module's actual CRC value is zero. But it's really the last two bytes in the module that are a signature of the rest of the module's data.)

It is inevitable that some of the data in the ROS modules (my bet is the BASIC+Common ROS) will be tables. Note that PALM can't even multiply integers natively, much less do arithmetic with floating point numbers. APL and BASIC meanwhile support all of those things as well as trigonometric functions, exponents, and logarithms. The data that supports these computations, as well as many other features, will be in the ROS somewhere.

 

[voidstar78]

Thanks, that clarifies a couple questions actually. Thoses CRC's appear at the end of sections, not the beginning - makes more sense (I didn't even notice 18 at the end!!)

And I see the "00 20" etc in the APL ROS.

I still think 18K of ROS is missing still That ROS Controller. But yep, busy times too at work, just a mystery puzzle to work in the evenings a little bit at a time :D

i.e. in the machine code in your writeup for reading ROS's

CTRL 1, #$04 ; select APL ROS

I think there is another ROS besides #$04 and #$08. This is what I found on my 5110, trying all values in that instruction from #$00 to #$FF (I forget the exact number, but I think a number corresponded to the Feature ROS/Disk Sorting of the 5110 -- I'm suspecting for the 5100, some other number besides #$04 and #$08 will get a new sequence of code that might be the ROS Controller)