VERAULT
Veteran Member
Maybe one day Ill do something, anything with my 5120. I should start with making some disks.
Nice demo though. Good job!
Nice demo though. Good job!
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
IBM 5110 initial info
- Thread starter voidstar78
- Start date
voidstar78
Veteran Member
Thanks! I recently found that the system has an RNG function in the ROS (ROM), accessible from both APL and BASIC.
So with the ability to write anywhere onto the screen + poll the keyboard + RNG = can make an interactive game
BUT, suppose we made a 2000 byte program: even if had a tape deck or disk drive, I'm not sure how to write it in the proper format (from a modern PC or whatever was used to make said 2000 byte program). So you have to key it in at least one time, then write it to the native format of the system - except from the DCP (diagnostic) there is no load/save capability (unless you key that in as well, in PALM assembly). And from the built in BASIC, I'm not sure if they have a "run from this address" command (like SYS on the Commodore PET/C64), and there is no PEEK/POKE (as far as I could tell) in this BASIC.
What about external interfaces? Well, I don't have any BSCA (connect to special CCITT{?} terminals), Asynch (modem), or Parallel I/O cards.... (maybe there is enough tech detail to replicate the entire async serial I/O card - but finding a connector adapter itself would be a little hard, along with producing {and loading} whatever support software -- seems in the IBM manuals)
It still seems the disk drive portion could be emulated. The pinouts are all described in the manual, but the disk format (or file format) is a little daunting to me (the file format sort of describes its own format?) [also for this system, I think a printer could be daisy chained off the disk drive -- so the parallel I/O wasn't necessary for a printer? ]
I'm told the 5110 Model 2 can't support an external 5106 tape deck, since the ROS-portion to do so is just missing (implying the Model 2 was oriented more as a disk-only system). That may be true, and for the same reason perhaps an internal tape drive can be installed into a Model 2. Though I'm still curious to verify all that.
So the big question (to me) is: is the Executable ROS different between a Model 1 and Model 2 ? I don't see references to different part numbers (but only light digging on that). In otherwords, for the 5110 Model 2, did they remove from the Executable ROS whatever code supported read/write to the internal tape? OR, are just the Z2 tape connections just "not connected" ? Seems like I should be able to find this out by just coding in a BASIC program, and *trying* to save it. If it even attempts to save anything, then I can just probe the pins on the Z2 tape connector to see if it's trying to send signals, and that will give an answer? (alternatively I think someone extracted the Executable ROS into a binary for a 5100, we could do the same procedure for a 5110 Model 1 vs Model 2 -- but you either have to write down thousands of hex codes, or use a video OCR process -- though doing so would give a definitive answer on whether they were identical ROS code).
And for all those IBM manuals on the 5100-series, it describes the hardware and overall system - but I don't see sections about the Processor itself (down to PALM opcodes), neat that those got reverse engineered over time.
So with the ability to write anywhere onto the screen + poll the keyboard + RNG = can make an interactive game
BUT, suppose we made a 2000 byte program: even if had a tape deck or disk drive, I'm not sure how to write it in the proper format (from a modern PC or whatever was used to make said 2000 byte program). So you have to key it in at least one time, then write it to the native format of the system - except from the DCP (diagnostic) there is no load/save capability (unless you key that in as well, in PALM assembly). And from the built in BASIC, I'm not sure if they have a "run from this address" command (like SYS on the Commodore PET/C64), and there is no PEEK/POKE (as far as I could tell) in this BASIC.
What about external interfaces? Well, I don't have any BSCA (connect to special CCITT{?} terminals), Asynch (modem), or Parallel I/O cards.... (maybe there is enough tech detail to replicate the entire async serial I/O card - but finding a connector adapter itself would be a little hard, along with producing {and loading} whatever support software -- seems in the IBM manuals)
It still seems the disk drive portion could be emulated. The pinouts are all described in the manual, but the disk format (or file format) is a little daunting to me (the file format sort of describes its own format?) [also for this system, I think a printer could be daisy chained off the disk drive -- so the parallel I/O wasn't necessary for a printer? ]
I'm told the 5110 Model 2 can't support an external 5106 tape deck, since the ROS-portion to do so is just missing (implying the Model 2 was oriented more as a disk-only system). That may be true, and for the same reason perhaps an internal tape drive can be installed into a Model 2. Though I'm still curious to verify all that.
So the big question (to me) is: is the Executable ROS different between a Model 1 and Model 2 ? I don't see references to different part numbers (but only light digging on that). In otherwords, for the 5110 Model 2, did they remove from the Executable ROS whatever code supported read/write to the internal tape? OR, are just the Z2 tape connections just "not connected" ? Seems like I should be able to find this out by just coding in a BASIC program, and *trying* to save it. If it even attempts to save anything, then I can just probe the pins on the Z2 tape connector to see if it's trying to send signals, and that will give an answer? (alternatively I think someone extracted the Executable ROS into a binary for a 5100, we could do the same procedure for a 5110 Model 1 vs Model 2 -- but you either have to write down thousands of hex codes, or use a video OCR process -- though doing so would give a definitive answer on whether they were identical ROS code).
And for all those IBM manuals on the 5100-series, it describes the hardware and overall system - but I don't see sections about the Processor itself (down to PALM opcodes), neat that those got reverse engineered over time.
voidstar78
Veteran Member
For reference: on my 5110 model 2, when doing a MARK or SAVE (from BASIC), I get an error 013 with default device D80 (internal cassette). From the manuals:
This is as expected, but a "no status response" gives a little more hope than "device not supported" kind of error.
And yes, actually there are multiple "part numbers" for the Executive ROS. I think one difference is how extensive the built-in diagnostic program is. For example, when I run the DCP, the "0" and "1" options both only reference the disk drive I/O, and not cassette.
What I'm really getting at: is just "feels" like the 5110 model 2 Executive ROS does support the cassette I/O -- I say this, because you can inline a 5106 cassette with the disk drive. Whether it's device D40 or D80 (internal or external), the code to support doing MARK's, SAVE's, and LOAD's is in there.
But even if we retrofitted the internal cassette of a 5110 model 1 into a model 2, with the cable to the A1 board -- it's still possible some wires are missing from the other side of the Z2 plug and onto whichever corresponding spots on the A1 board (meaning it's just a cabling issue, not an actual ROS/ROM issue).
Specifically, like is D12-pin below connected on the other side to the rest of the system? And what is the nature of this "Cartridge in Place" signal, just a const 5v? (I'm still working through the manuals - I can't remember if this perimeter Z-pins are "always connected"??).
So it's either try to emulate this tape I/O or the disk I/O, pick your poison - at least the ROS code is there to do the "mark" (formatting), rather than trying to code up your own I/O code and media formats. What a curious thing to try to reverse engineer, for all 50 of these (still working) left ? :D
This is as expected, but a "no status response" gives a little more hope than "device not supported" kind of error.
And yes, actually there are multiple "part numbers" for the Executive ROS. I think one difference is how extensive the built-in diagnostic program is. For example, when I run the DCP, the "0" and "1" options both only reference the disk drive I/O, and not cassette.
What I'm really getting at: is just "feels" like the 5110 model 2 Executive ROS does support the cassette I/O -- I say this, because you can inline a 5106 cassette with the disk drive. Whether it's device D40 or D80 (internal or external), the code to support doing MARK's, SAVE's, and LOAD's is in there.
But even if we retrofitted the internal cassette of a 5110 model 1 into a model 2, with the cable to the A1 board -- it's still possible some wires are missing from the other side of the Z2 plug and onto whichever corresponding spots on the A1 board (meaning it's just a cabling issue, not an actual ROS/ROM issue).
Specifically, like is D12-pin below connected on the other side to the rest of the system? And what is the nature of this "Cartridge in Place" signal, just a const 5v? (I'm still working through the manuals - I can't remember if this perimeter Z-pins are "always connected"??).
So it's either try to emulate this tape I/O or the disk I/O, pick your poison - at least the ROS code is there to do the "mark" (formatting), rather than trying to code up your own I/O code and media formats. What a curious thing to try to reverse engineer, for all 50 of these (still working) left ? :D
stepleton
Veteran Member
The 5100 was me and you can find it here: https://archive.org/details/ibm_5100_ros
The 5110 ROS was extracted by Christian Corti a good while ago. I believe it is required for his emulator to work, and also for this javascript browser version. You can find the binaries and disassembly here: ftp://computermuseum.informatik.uni-stuttgart.de/ibm/ibm5110
voidstar78
Veteran Member
Thanks, that's really neat! I've tried to e-mail Christian, but am getting them bounced back - hope they're all ok over there. I've noticed several places seem to be rejecting gmail.com, I didn't try an alternate yet.
Did he do the OCR approach, or just transcribe it?
That's really neat, the 5110 Model 1 execros.asm is right there. Well, I could give this a shot -- or at least do an initial look to see if the Model 2 executive ROS (that I have) is different in anyway.
Couple questions:
(1) In rd_ros.lst, it mentions copying the APL stuff to RWS. Is getting the Executive ROS (or any other ROS) just a matter of changing the index in line 16? (i.e. offhand I didn't see an LST specifically to how he copied the executive ROS over to RWS - so I'm assuming the APL one is like a template on how to do all of them).
...
13/ B00 : org $0B00
14/ B00 :
15/ B00 : Start:
16/ B00 : 1104 CTRL 1, #$04 ; select APL ROS
17/ B02 : D301 000B LWI R3, #$000B ; address of low-byte of R5
18/ B06 : 8500 LBI R5, #0 ; source ROS address ...
(2) Any idea what "NX" is ? There is a README there that talks to aspects of compiling and building (and why the emptyX.dsk files are there - since the format disk command isn't supported, so the empty files are proxies), but no info about the ROS binaries:
aplros.bin (20K)
aplnx.bin (128K) (substantially larger than the aplros.bin above)
basicros.bin (16K) (assume this is the stock ROS for BASIC handling)
bas_ros.bin (48K) (???)
basicnx.bin (72K) (???)
comros.bin (16K) ("common"? or "communication"? slot F is labeled "Common and Language ROS", while slot D is "Async Comm Serial I/O")
execros.bin (32K) (all this in those "tin cans"? wild!)
Did he do the OCR approach, or just transcribe it?
That's really neat, the 5110 Model 1 execros.asm is right there. Well, I could give this a shot -- or at least do an initial look to see if the Model 2 executive ROS (that I have) is different in anyway.
Couple questions:
(1) In rd_ros.lst, it mentions copying the APL stuff to RWS. Is getting the Executive ROS (or any other ROS) just a matter of changing the index in line 16? (i.e. offhand I didn't see an LST specifically to how he copied the executive ROS over to RWS - so I'm assuming the APL one is like a template on how to do all of them).
...
13/ B00 : org $0B00
14/ B00 :
15/ B00 : Start:
16/ B00 : 1104 CTRL 1, #$04 ; select APL ROS
17/ B02 : D301 000B LWI R3, #$000B ; address of low-byte of R5
18/ B06 : 8500 LBI R5, #0 ; source ROS address ...
(2) Any idea what "NX" is ? There is a README there that talks to aspects of compiling and building (and why the emptyX.dsk files are there - since the format disk command isn't supported, so the empty files are proxies), but no info about the ROS binaries:
aplros.bin (20K)
aplnx.bin (128K) (substantially larger than the aplros.bin above)
basicros.bin (16K) (assume this is the stock ROS for BASIC handling)
bas_ros.bin (48K) (???)
basicnx.bin (72K) (???)
comros.bin (16K) ("common"? or "communication"? slot F is labeled "Common and Language ROS", while slot D is "Async Comm Serial I/O")
execros.bin (32K) (all this in those "tin cans"? wild!)
stepleton
Veteran Member
For question 1, I think it will help to refer to some of the documentation that Christian Corti wrote.
In particular, in the left frame, click on "Programming in machine language" and then read the materials relating to I/O. Some of the information in there pertains to accessing the non-executable ROS.
A careful read through all of the documentation at that website is well worth the time.
As for question 2, the sizes of the "nx" files are closer to the sizes of the ROS data I extracted from my 5100. My guess is that the emulator code depends on the 5110 executable and non-executable ROS being divided up into separate portions, and that these files correspond to those portions. Here is what I think is going on:
aplros.bin --
IBM System/360 emulator for running the APL interpreter. (I think this is part of the Language ROS, and is in the Executable ROS.)
aplnx.bin --
The actual System/360 machine code for the APL interpreter. (In the non-executable ROS.)
basicros.bin --
IBM System/3 emulator for running the BASIC interpreter (Also part of the Language ROS, I think, and so in the Exec. ROS)
bas_ros.bin --
I don't know.
basicnx.bin --
The actual System/3 machine code for the BASIC interpreter. (In the non-executable ROS.)
comros.bin --
Common ROS: various shared routines used by all executable ROS code (e.g. routines for accessing the tape). (In the executable ROS)
execros.bin --
Initial bootup and self-test code, diagnostic monitor. (In the executable ROS)
Remember, these are guesses. You may be able to improve on these guesses by
- reading the emulator source code and seeing where these files may be used
- examining the binary data inside these ROS files and seeing whether you see stuff that looks like System/3, System/360, or PALM binary code
A careful read through all of the documentation at that website is well worth the time.
As for question 2, the sizes of the "nx" files are closer to the sizes of the ROS data I extracted from my 5100. My guess is that the emulator code depends on the 5110 executable and non-executable ROS being divided up into separate portions, and that these files correspond to those portions. Here is what I think is going on:
aplros.bin --
IBM System/360 emulator for running the APL interpreter. (I think this is part of the Language ROS, and is in the Executable ROS.)
aplnx.bin --
The actual System/360 machine code for the APL interpreter. (In the non-executable ROS.)
basicros.bin --
IBM System/3 emulator for running the BASIC interpreter (Also part of the Language ROS, I think, and so in the Exec. ROS)
bas_ros.bin --
I don't know.
basicnx.bin --
The actual System/3 machine code for the BASIC interpreter. (In the non-executable ROS.)
comros.bin --
Common ROS: various shared routines used by all executable ROS code (e.g. routines for accessing the tape). (In the executable ROS)
execros.bin --
Initial bootup and self-test code, diagnostic monitor. (In the executable ROS)
Remember, these are guesses. You may be able to improve on these guesses by
- reading the emulator source code and seeing where these files may be used
- examining the binary data inside these ROS files and seeing whether you see stuff that looks like System/3, System/360, or PALM binary code
voidstar78
Veteran Member
Oh wow, so "NX" could mean non-executable - make sense. I'm not at all familiar with System/360 or System/3 native opcodes - but I'd imagine they weren't as extensive of instruction set as, say, an 8088 or 6502, so you needed more instructions to do whatever it is they are doing.
That's really neat how important backwards compatibility was so important even then -- they had all these applications already developed for the System/360 and System/3 (invoicing type software, or accounting stuff, I'd imagine) -- and neither of those systems (as far as I know) had a CRT or monitor, so the very idea of things like "clearing the screen" or "output to cell 10,8 on the screen" were foreign concepts to something that just had a line printer as its output. But all that existing software, they felt was worth keeping invested in.
So they invested in this emulator code - to help kind of "wrap" that legacy capability into a newer system that did have a CRT, tape, and disk drives - and so far I haven't found the story on who came up with PALM, what tools were developed for it (assemblers) and who coded to it (like who wrote the 5100 DCP stuff itself, and those emulators). I just imagine there was some internal IBM reference manual about it - or maybe some text files out in some System/360 installation somewhere, maybe even there was a PALM emulator? And THEN, this device also had the async. capabilities to remote back to their mainframe, to sync new data entries back up with main databases (with early CCITT v.24 protocols).
That might not all be entirely quite right -- but it makes me understand why the BASIC on the 5110 doesn't even have a CLRSCR command (even in sample programs, I noticed they "clear the screen" by doing a 16 line for loop to just-roll the screen -- it doesn't have a SYS to branch over to ROS system calls, or POKE to command some screen manager). It also shows how BASIC was well established well before the Altair 8080 version -- Bill and Davidoff likely borrowed the flow of how BASIC worked from their time probing around on their borrowed time in mainframes. But that's just how things are - the folks who lay the foundation aren't credited with building the house.
Yes, this helps point me in the right direction. Christian' emulator code isn't bad at all, pretty concise in just a few .c files, think I can handle making it runnable under Windows (just for the sake of being able to debug/step through and follow the sequence of things). Or, I'll just try compiling it under Cygwin first. May take a while to get enough free time on a weekend, but yes, I'd like to archive this Model 2 ROSs' while my system is still bootable - then compare them to the Model 1's.
Thanks!
That's really neat how important backwards compatibility was so important even then -- they had all these applications already developed for the System/360 and System/3 (invoicing type software, or accounting stuff, I'd imagine) -- and neither of those systems (as far as I know) had a CRT or monitor, so the very idea of things like "clearing the screen" or "output to cell 10,8 on the screen" were foreign concepts to something that just had a line printer as its output. But all that existing software, they felt was worth keeping invested in.
So they invested in this emulator code - to help kind of "wrap" that legacy capability into a newer system that did have a CRT, tape, and disk drives - and so far I haven't found the story on who came up with PALM, what tools were developed for it (assemblers) and who coded to it (like who wrote the 5100 DCP stuff itself, and those emulators). I just imagine there was some internal IBM reference manual about it - or maybe some text files out in some System/360 installation somewhere, maybe even there was a PALM emulator? And THEN, this device also had the async. capabilities to remote back to their mainframe, to sync new data entries back up with main databases (with early CCITT v.24 protocols).
That might not all be entirely quite right -- but it makes me understand why the BASIC on the 5110 doesn't even have a CLRSCR command (even in sample programs, I noticed they "clear the screen" by doing a 16 line for loop to just-roll the screen -- it doesn't have a SYS to branch over to ROS system calls, or POKE to command some screen manager). It also shows how BASIC was well established well before the Altair 8080 version -- Bill and Davidoff likely borrowed the flow of how BASIC worked from their time probing around on their borrowed time in mainframes. But that's just how things are - the folks who lay the foundation aren't credited with building the house.
Yes, this helps point me in the right direction. Christian' emulator code isn't bad at all, pretty concise in just a few .c files, think I can handle making it runnable under Windows (just for the sake of being able to debug/step through and follow the sequence of things). Or, I'll just try compiling it under Cygwin first. May take a while to get enough free time on a weekend, but yes, I'd like to archive this Model 2 ROSs' while my system is still bootable - then compare them to the Model 1's.
Thanks!
Last edited:
voidstar78
Veteran Member
@stepleton your exeros.bin is the one at the internet archive, right? For a 5100? But it's 64KB.
In the emu5110.tar, it has a execros.bin - do you know how Christian extracted this? (I mean, was it probably transcribed from the register display using the "512 bytes at a time" technique you described? but probably not the OCR way?) However, his execros.bin for the 5110 type 1 is only 32KB. [ not saying either is incorrect - they're different systems by about 3 years -- but still, 512bytes * 128, I'd expect 64KB? I can't see why the newer system would be a smaller ROS ]
I see his notes on how he extracted the non-executive ROS - he was able to export them to a file, had a working disk drive available, and was able to read the disk from a PC. Lucky guy :D (but still curious how he did the executive ROS)
I cracked open the case and did the run-switch deal to examine the first 512 bytes. That's so neat to have hardware switch to literally step through the CPU processing and watch register and memory values.
I spot checked the 64-byte offsets (start of each row), and the last byte - they all match exactly to what Christian put in the execros.asm he produced for his Type 1 (I have a 5110 type 2) - so that's a very good start, that our ROS code matches on this first 512 bytes. I'm still not exactly clear on how you guys manipulated the startup address lines (hardware isn't my strength).
But I think I'll study the emu source code first, as you suggested, before going down that route. One thing I'm trying to do is verify if a 5106 tape drive could be retrofitted into a 5110 Model 2 - and if so, maybe see about emulating one somehow. The key, I think, is seeing how much the ROS code of the model 2 and model 1 differ -- if they are in fact the same, then I don't see what prevents a model 2 from supporting an internal tape drive (other than you can't find any, anywhere! ).
In the emu5110.tar, it has a execros.bin - do you know how Christian extracted this? (I mean, was it probably transcribed from the register display using the "512 bytes at a time" technique you described? but probably not the OCR way?) However, his execros.bin for the 5110 type 1 is only 32KB. [ not saying either is incorrect - they're different systems by about 3 years -- but still, 512bytes * 128, I'd expect 64KB? I can't see why the newer system would be a smaller ROS ]
I see his notes on how he extracted the non-executive ROS - he was able to export them to a file, had a working disk drive available, and was able to read the disk from a PC. Lucky guy :D (but still curious how he did the executive ROS)
I cracked open the case and did the run-switch deal to examine the first 512 bytes. That's so neat to have hardware switch to literally step through the CPU processing and watch register and memory values.
I spot checked the 64-byte offsets (start of each row), and the last byte - they all match exactly to what Christian put in the execros.asm he produced for his Type 1 (I have a 5110 type 2) - so that's a very good start, that our ROS code matches on this first 512 bytes. I'm still not exactly clear on how you guys manipulated the startup address lines (hardware isn't my strength).
But I think I'll study the emu source code first, as you suggested, before going down that route. One thing I'm trying to do is verify if a 5106 tape drive could be retrofitted into a 5110 Model 2 - and if so, maybe see about emulating one somehow. The key, I think, is seeing how much the ROS code of the model 2 and model 1 differ -- if they are in fact the same, then I don't see what prevents a model 2 from supporting an internal tape drive (other than you can't find any, anywhere!
).stepleton
Veteran Member
I think Christian has split what I'm calling the "executable ROS" into multiple files. It's likely that the 16K comros.bin file is also part of what I call the executable ROS. There is also aplros.bin and basicros.bin, which I assume are also part of the executable ROS. It's clear that these files added together would consume more than 64K, which is a bit of a mystery --- the PALM only has a 16-bit program counter
Hopefully you'll figure it out from looking at the emulator source code
I don't know (or don't remember learning) how Christian extracted the executable ROS, but I don't think he used OCR. He may have taken photographs and copied them out by hand.
The single-step functionality of the 5100-series machines really is cool. As for manipulating the address bus --- it is a bit nerve-wracking to hook wires up to a computer that would be so hard to repair if you really messed something up, but at least the wire-wrap backplane pins make it very easy to do with regular dupont jumper wires. There is not much to it: if you want to change a bit on an address line from a 0 to a 1, you connect the corresponding backplane pin to ground through a suitably high-valued resistor. I can't remember what I used, maybe 10K or 50K?
Hopefully you'll figure it out from looking at the emulator source code
I don't know (or don't remember learning) how Christian extracted the executable ROS, but I don't think he used OCR. He may have taken photographs and copied them out by hand.
The single-step functionality of the 5100-series machines really is cool. As for manipulating the address bus --- it is a bit nerve-wracking to hook wires up to a computer that would be so hard to repair if you really messed something up, but at least the wire-wrap backplane pins make it very easy to do with regular dupont jumper wires. There is not much to it: if you want to change a bit on an address line from a 0 to a 1, you connect the corresponding backplane pin to ground through a suitably high-valued resistor. I can't remember what I used, maybe 10K or 50K?
krebizfan
Veteran Member
I am fairly certain that the 5100 series had some form of memory banking and would only have some of the ROS addressable at any time thus either BASIC or APL but never both at the same time. I have no idea if IBM removed the tape ROS cans from the board or if IBM expected no one would disconnect the floppy drives in order to insert a 5106 before the first 5114 and also forgo the chance of having a second 5114.
I spent more time than I should trying to find if anyone had archived any of the replacement 5110 disk systems. If someone 40 years ago reverse engineered the interface, having those documents would simplify doing something similar today. All I can find are short ads in Computerworld and the brochure for hard disks from Core International.
I spent more time than I should trying to find if anyone had archived any of the replacement 5110 disk systems. If someone 40 years ago reverse engineered the interface, having those documents would simplify doing something similar today. All I can find are short ads in Computerworld and the brochure for hard disks from Core International.
stepleton
Veteran Member
I think what you're describing is more the case for the non-executable ROS. This is accessed via I/O operations, prior to which you select which bank you want to read. On the 5100 at least, I am fairly certain that the Executable ROS is not banked.
I think that I/O code for talking to the tape and disk drives resides in the executable ROS as well, in the so-called "common ROS". Both the System/360 emulator and APL and the System/3 emulator and BASIC would have used it; it's probably the case that some service and diagnostic code that came on tapes would use that shared I/O code too.
I think that I/O code for talking to the tape and disk drives resides in the executable ROS as well, in the so-called "common ROS". Both the System/360 emulator and APL and the System/3 emulator and BASIC would have used it; it's probably the case that some service and diagnostic code that came on tapes would use that shared I/O code too.
voidstar78
Veteran Member
For my own context, and for those who may be passing by in the future...
Here is a comparison of the A1 boards and ROS arrangements between the systems. I think the 5100 "RWS" (RAM) were in 8K cards, while the 5110 had 1 less RWS slot, but used 16K cards.
I was excited when I read the 5110 supported IEEE-488 - means you can just hook up CBM IEEE-488 disk drives, right??? :D No, not that simple. And in any case, it was an add-on feature via the Parallel I/O card, and tethered its way through a small slot on the back of the machine (I think).
IBM 5100 was released in 1975. As far as I know, it did not have support for any kind of disk drive. They all came standard with a built-in cassette tape deck (but not a standard audio-tape-deck; I'm not sure what to call it, but it was a more digital-data oriented kind of tape, with some I/O control logic in this tape-deck itself). The 5100 could support an additional external 5106 tape drive, connected in the back through this "Y-shaped-serial-port" looking connector (again, not sure what it is more officially called). My understanding is the tape and its formatting supported a somewhat more "random access" to the data on the tape than what you'd see from a more linear audio-tape-deck (e.g. the machine could command the tape drive to rewind, etc.). The IBM MIM (maintenance information manual) 2-59 section gives a diagram and pinout info about this interface. Mechanically I think the internal and external tape decks were identical, but I'm not sure how the interfaces differed (the "Z2" connector versus using the I/O Cable Driver on "A").
IBM 5110 was released in 1978 (maybe '77?). The BSCA stuff was related to some v.24 CCITT things, even the manual described communicate with some world-trade systems? An early tape program for the IBM 5150 included an asynch. I/O that was used to communicate with the DOW exchange. Wild to think these systems were the terminal used by the whales in big finance and business. The Async Comm I/O was used for some sort of modem - I'm not sure how the BSCA stuff really differs from a modem (maybe BSCA had a tad more security, if just by virtue of how you connected to it? maybe interfacing with things that aren't 8-bit or EBCDIC? The info is probably in the IBM manuals, but I don't have these cards anyway - and even found these cards, I'm not sure if the ROS's as-is support using them {but I've wondered if studying the Async I/O might be an easier way to get information in and out of this system - a WiModem for the 5100 perhaps, tethered to that Z1 connector?).
The 5110 model 1 could use a disk drive, and included a built in tape (like the 5100) or have a 5106 external tape deck added. So all the ROS code to support all that should be there.
The 5110 model 2 saved some cost by not having a built in tape drive. If you weren't working "in the field", then it would make sense to use this model in an office and plop it on top of the disk drive 'fridge (or table next to it). There are actually different part numbers to the Executive ROS in the IBM manuals - but the question remains: did they actually remove all tape deck support from these Model 2's? Business was cut-throat back then (I mean, you had Commodore smashing out empty RAM sockets to prevent people from upgrading!), maybe IBM was keen on "only giving what was paid for" - but the other hand, that's another build of the ROS to maintain. My hope is the different part numbers of the Executive ROS are just for different external support (BSCA and async I/O handling; I think there was also some special-kind-of-printer support as well - a graphics printer, as an option?). I could see for the Model 2 builds, maybe IBM just didn't wire up the "Z2" pins - so the ROS code might be there, but won't work till you connect up those pins.
NOTE: I don't think this "Y" connector pin-outs changed between the 5100 and 5120 - in which case, if you could write the PALM assembly to do it, technically couldn't a disk drive be retrofitted onto the 5100? (you couldn't stick a 5110 ROS card into the 5100 - for other reasons)
But you're right, without working hardware to refer to, it's pretty rough to reverse engineer a disk or tape emulator for this system from the existing manuals.
The emulator code does have some limited disk support (at least for reading, maybe not complete for formatting/marking and creating new files). I can't help but feeling that an Arduino could replicate all the electrical responses of that disk drive system.
It's just - if you invest in figuring out the disk drive support, that helps 5110's (well, and probably 5120's). If you figure out the tape support, that helps both 5100's and 5110's (I think).
Here is a comparison of the A1 boards and ROS arrangements between the systems. I think the 5100 "RWS" (RAM) were in 8K cards, while the 5110 had 1 less RWS slot, but used 16K cards.
I was excited when I read the 5110 supported IEEE-488 - means you can just hook up CBM IEEE-488 disk drives, right??? :D No, not that simple. And in any case, it was an add-on feature via the Parallel I/O card, and tethered its way through a small slot on the back of the machine (I think).
IBM 5100 was released in 1975. As far as I know, it did not have support for any kind of disk drive. They all came standard with a built-in cassette tape deck (but not a standard audio-tape-deck; I'm not sure what to call it, but it was a more digital-data oriented kind of tape, with some I/O control logic in this tape-deck itself). The 5100 could support an additional external 5106 tape drive, connected in the back through this "Y-shaped-serial-port" looking connector (again, not sure what it is more officially called). My understanding is the tape and its formatting supported a somewhat more "random access" to the data on the tape than what you'd see from a more linear audio-tape-deck (e.g. the machine could command the tape drive to rewind, etc.). The IBM MIM (maintenance information manual) 2-59 section gives a diagram and pinout info about this interface. Mechanically I think the internal and external tape decks were identical, but I'm not sure how the interfaces differed (the "Z2" connector versus using the I/O Cable Driver on "A").
IBM 5110 was released in 1978 (maybe '77?). The BSCA stuff was related to some v.24 CCITT things, even the manual described communicate with some world-trade systems? An early tape program for the IBM 5150 included an asynch. I/O that was used to communicate with the DOW exchange. Wild to think these systems were the terminal used by the whales in big finance and business. The Async Comm I/O was used for some sort of modem - I'm not sure how the BSCA stuff really differs from a modem (maybe BSCA had a tad more security, if just by virtue of how you connected to it? maybe interfacing with things that aren't 8-bit or EBCDIC? The info is probably in the IBM manuals, but I don't have these cards anyway - and even found these cards, I'm not sure if the ROS's as-is support using them {but I've wondered if studying the Async I/O might be an easier way to get information in and out of this system - a WiModem for the 5100 perhaps, tethered to that Z1 connector?).
The 5110 model 1 could use a disk drive, and included a built in tape (like the 5100) or have a 5106 external tape deck added. So all the ROS code to support all that should be there.
The 5110 model 2 saved some cost by not having a built in tape drive. If you weren't working "in the field", then it would make sense to use this model in an office and plop it on top of the disk drive 'fridge (or table next to it). There are actually different part numbers to the Executive ROS in the IBM manuals - but the question remains: did they actually remove all tape deck support from these Model 2's? Business was cut-throat back then (I mean, you had Commodore smashing out empty RAM sockets to prevent people from upgrading!), maybe IBM was keen on "only giving what was paid for" - but the other hand, that's another build of the ROS to maintain. My hope is the different part numbers of the Executive ROS are just for different external support (BSCA and async I/O handling; I think there was also some special-kind-of-printer support as well - a graphics printer, as an option?). I could see for the Model 2 builds, maybe IBM just didn't wire up the "Z2" pins - so the ROS code might be there, but won't work till you connect up those pins.
NOTE: I don't think this "Y" connector pin-outs changed between the 5100 and 5120 - in which case, if you could write the PALM assembly to do it, technically couldn't a disk drive be retrofitted onto the 5100? (you couldn't stick a 5110 ROS card into the 5100 - for other reasons)
But you're right, without working hardware to refer to, it's pretty rough to reverse engineer a disk or tape emulator for this system from the existing manuals.
The emulator code does have some limited disk support (at least for reading, maybe not complete for formatting/marking and creating new files). I can't help but feeling that an Arduino could replicate all the electrical responses of that disk drive system.
It's just - if you invest in figuring out the disk drive support, that helps 5110's (well, and probably 5120's). If you figure out the tape support, that helps both 5100's and 5110's (I think).
Attachments
Last edited:
voidstar78
Veteran Member
And a note, confirmed: the rear side Y-connector pinouts the same between 5100 and 5110.
Seems like a PALM program could be written to read the non-executable ROS content, and bang it out on the #3 signal connector? ("bus out 0-7" pins?).
Still tedious for the executable ROS portions - the OCR approach may not work for me, since the center of my screen has some debris in the way that may make "training" not really work (I'm not familiar with the history of that debris - maybe it's degraded/missing phosphorus on the glass? it's a scattered mess, but the system is overall still usable)
Seems like a PALM program could be written to read the non-executable ROS content, and bang it out on the #3 signal connector? ("bus out 0-7" pins?).
Still tedious for the executable ROS portions - the OCR approach may not work for me, since the center of my screen has some debris in the way that may make "training" not really work (I'm not familiar with the history of that debris - maybe it's degraded/missing phosphorus on the glass? it's a scattered mess, but the system is overall still usable)
Last edited:
stepleton
Veteran Member
Thanks for sharing your notes. I didn't realise that the 5110 had IEEE 488 support.
You are correct to guess that the "Controller" card in the 5110 is the processor, or at least a major part of it. Some things we might think of as part of the CPU might also be on other cards --- perhaps "Base I/O" contains some circuitry that helps implement the I/O instructions. But I don't know for certain.
Tapes
You are correct that the tape drive is not like a cassette-tape deck (although SCAMP, the experimental machine that lead to the 5100 series, did use an ordinary tape recorder.) The tapes are cartridges about the size of three decks of cards laid side-by-side. The tape mechanism can and does go back and forth over the tape as it reads and writes. Here is a video of the tape mechanism in my 5100 at work loading an APL workspace:
photos.app.goo.gl
(The loud fan noise is from the apparatus I use to convert power from 50 Hz 230 VAC to 60 Hz 120 VAC; my thumb is on the tape because the cartridge positioning/guide rollers inside the tape drive need servicing, and until they get it I need to hold the tape against the heads and capstan manually.)
Most systems that used tapes like this would have you "partition" (not the word they used) the tape into a series of "chunks" (also not the word they used), a bit like chapters in a book. In some cases you would read the entire chunk into memory, do some work, and then write the whole chunk back onto tape. (This is how APL workspaces worked.) In other cases you would read and write smaller records within a chunk. When you're loading a whole chunk, you usually just say which one you want to load: the computer then figures out where it is on the tape, rewinds or advances the tape to the chunk, then loads it.
You can find out more about tape usage in BASIC and APL by reading the IBM 5100 and 5110 manuals for both languages.
Disk drives for the 5100
With PALM assembly speaking to the I/O interface port on the back of the IBM 5100, you can talk to whatever you want so long as you have sorted out the hardware interfacing . Floppy drive, flash drive, ethernet, why not.
I don't think IBM ever supported disk drives for the 5100, although some of its designers wanted to do it --- there just wasn't enough time to get it ready by the ship date. There was a third-party option by a company called Sykes Datatronics Inc., and you can find a brochure about it on bitsavers: http://www.bitsavers.org/pdf/sykes/brochures/Sykes_Comm-Stor_5100_Brochure.pdf . It looks like this was a device that simply attaches to the optional serial I/O adapter on equipped 5100s (not the Y-shaped connector), so I guess you could probably have used it with other machines that had a serial port. Regrettably my 5100 doesn't have the serial adapter fitted; I wish it did!
Miscellaneous
BSCA: Not a 5100 thing, so I don't know about it I think you're correct that many of the questions you have about the communications options will be in the IBM manuals. I don't think any of the 5100-series speaks ASCII "natively" (i.e. without translator software or hardware); the 5110 might do an EBCDIC of some kind, but I think the 5100 has an internal character map that's proprietary to itself. Also, apparently a Katakana option was available for the 5100, although I've never seen it anywhere except the manuals.
Tape drive emulator for the I/O port connector: it does sound like the most useful option for all 5100-series users. Please go for it! You can count on having at least one customer...
What's wrong with your 5110's display? It looks to me like at one point the scan circuitry in your 5110's display failed, meaning that all of the video was collapsed into one very bright dot in the centre of your CRT. It doesn't take long for that to leave a permanent mark. If this happened, someone repaired the circuitry later, but by then the phosphor damage was done.
Send the non-executable ROS out of the I/O port? I think this is a great idea, and in fact I'd hoped to do it that way on my 5100. But my limited experiments to wiggle bits on the I/O connector were unsuccessful, and at the time I didn't have my assembler, so writing hex code was tedious (and typing it in was tedious too). I don't think I have the patience for this that you have! So instead I did an elaborate neural network approach. This was more fun than practical.
You are correct to guess that the "Controller" card in the 5110 is the processor, or at least a major part of it. Some things we might think of as part of the CPU might also be on other cards --- perhaps "Base I/O" contains some circuitry that helps implement the I/O instructions. But I don't know for certain.
Tapes
You are correct that the tape drive is not like a cassette-tape deck (although SCAMP, the experimental machine that lead to the 5100 series, did use an ordinary tape recorder.) The tapes are cartridges about the size of three decks of cards laid side-by-side. The tape mechanism can and does go back and forth over the tape as it reads and writes. Here is a video of the tape mechanism in my 5100 at work loading an APL workspace:
New video by Tom Stepleton
photos.app.goo.gl
(The loud fan noise is from the apparatus I use to convert power from 50 Hz 230 VAC to 60 Hz 120 VAC; my thumb is on the tape because the cartridge positioning/guide rollers inside the tape drive need servicing, and until they get it I need to hold the tape against the heads and capstan manually.)
Most systems that used tapes like this would have you "partition" (not the word they used) the tape into a series of "chunks" (also not the word they used), a bit like chapters in a book. In some cases you would read the entire chunk into memory, do some work, and then write the whole chunk back onto tape. (This is how APL workspaces worked.) In other cases you would read and write smaller records within a chunk. When you're loading a whole chunk, you usually just say which one you want to load: the computer then figures out where it is on the tape, rewinds or advances the tape to the chunk, then loads it.
You can find out more about tape usage in BASIC and APL by reading the IBM 5100 and 5110 manuals for both languages.
Disk drives for the 5100
With PALM assembly speaking to the I/O interface port on the back of the IBM 5100, you can talk to whatever you want so long as you have sorted out the hardware interfacing
. Floppy drive, flash drive, ethernet, why not.I don't think IBM ever supported disk drives for the 5100, although some of its designers wanted to do it --- there just wasn't enough time to get it ready by the ship date. There was a third-party option by a company called Sykes Datatronics Inc., and you can find a brochure about it on bitsavers: http://www.bitsavers.org/pdf/sykes/brochures/Sykes_Comm-Stor_5100_Brochure.pdf . It looks like this was a device that simply attaches to the optional serial I/O adapter on equipped 5100s (not the Y-shaped connector), so I guess you could probably have used it with other machines that had a serial port. Regrettably my 5100 doesn't have the serial adapter fitted; I wish it did!
Miscellaneous
BSCA: Not a 5100 thing, so I don't know about it
I think you're correct that many of the questions you have about the communications options will be in the IBM manuals. I don't think any of the 5100-series speaks ASCII "natively" (i.e. without translator software or hardware); the 5110 might do an EBCDIC of some kind, but I think the 5100 has an internal character map that's proprietary to itself. Also, apparently a Katakana option was available for the 5100, although I've never seen it anywhere except the manuals.Tape drive emulator for the I/O port connector: it does sound like the most useful option for all 5100-series users. Please go for it! You can count on having at least one customer...
What's wrong with your 5110's display? It looks to me like at one point the scan circuitry in your 5110's display failed, meaning that all of the video was collapsed into one very bright dot in the centre of your CRT. It doesn't take long for that to leave a permanent mark. If this happened, someone repaired the circuitry later, but by then the phosphor damage was done.
Send the non-executable ROS out of the I/O port? I think this is a great idea, and in fact I'd hoped to do it that way on my 5100. But my limited experiments to wiggle bits on the I/O connector were unsuccessful, and at the time I didn't have my assembler, so writing hex code was tedious (and typing it in was tedious too). I don't think I have the patience for this that you have! So instead I did an elaborate neural network approach. This was more fun than practical.
stepleton
Veteran Member
Another approach I had considered for exfiltrating the ROS was writing a machine-code program that would blink the entire screen on and off (that is, fill the screen either with empty spaces or some dense character like '@') to read out ROS bits, perhaps using manchester encoding for self-clocking. I could also have used the top half of the screen to blink out a clock signal and the bottom half to blink out the data, bit-by-bit.
You could then take a movie of the display and use dead simple image processing to recover the bits.
Another option I opted not to take for the same reasons I mentioned before.
You could then take a movie of the display and use dead simple image processing to recover the bits.
Another option I opted not to take for the same reasons I mentioned before.
voidstar78
Veteran Member
Here's the "screen damage" I have for comparison (in regular and reverse modes; this is just the register-display to get something to fill the screen easily). Even for a human it may be a little difficult to determine some hex codes around the center. But I'm mostly just after if the 5110 Model 2 is any different executable ROS than what was already captured for the Model 1 - so I probably just need to spot check a few addresses near the beginning, middle, and end.
These screens (inside) are in a vacuum, right? So just adding some phosphorus probably isn't a realistic option.
The 5110 has a speaker - we could use morse code to bang out the ROS ?
These screens (inside) are in a vacuum, right? So just adding some phosphorus probably isn't a realistic option.
The 5110 has a speaker - we could use morse code to bang out the ROS ?
Attachments
stepleton
Veteran Member
Unfortunately there is likely no easy way to fix your CRT --- you are right that there is a vacuum inside, among other challenges. If you are willing to make a trip up to Columbus, Ohio, perhaps you can interest the folks at the Early Television Museum in trying to carry out a repair with equipment they have on hand. I think they may have taken some of the machines in this video back to their museum:
But that's probably not very realistic. It will probably be easier to try to find a replacement CRT. The tube may be one of the closer things to a commodity part inside the machine, so you may not need to find a junk 5100-series machine in order to replace it.
Here's another idea of what to do next for the mystery about whether the executable ROS is different:
I notice in the 5110 Maintenance Information Manual that the bring-up diagnostic (that thing that prints ABCDEF... when you power on or reset the system) includes two steps called "Executable ROS Check" (see page 232). These two steps print the letters K and M to the screen when they run.
I don't know what these steps are checking. There would seem to be limited options in general: so far as I know, the processor cannot read the executable ROS in any other way besides putting an address into the program counter and executing the corresponding instruction from the Executable ROS.
But maybe we will be lucky and there is more to it. If the Executable ROS Checks are doing a checksum or a CRC of some kind, then potentially all you might need to do to tell whether the ROSs are different is to compare the checksum or CRC values from the Model 1 and Model 2 ROS.
To see whether this is realistic, the most important thing would be to find out what the Executable ROS Checks are doing. The best way to do that is probably to open Christian Corti's disassembly of the 5110 Executable ROS and see if you can find and understand the code.
But that's probably not very realistic. It will probably be easier to try to find a replacement CRT. The tube may be one of the closer things to a commodity part inside the machine, so you may not need to find a junk 5100-series machine in order to replace it.
Here's another idea of what to do next for the mystery about whether the executable ROS is different:
I notice in the 5110 Maintenance Information Manual that the bring-up diagnostic (that thing that prints ABCDEF... when you power on or reset the system) includes two steps called "Executable ROS Check" (see page 232). These two steps print the letters K and M to the screen when they run.
I don't know what these steps are checking. There would seem to be limited options in general: so far as I know, the processor cannot read the executable ROS in any other way besides putting an address into the program counter and executing the corresponding instruction from the Executable ROS.
But maybe we will be lucky and there is more to it. If the Executable ROS Checks are doing a checksum or a CRC of some kind, then potentially all you might need to do to tell whether the ROSs are different is to compare the checksum or CRC values from the Model 1 and Model 2 ROS.
To see whether this is realistic, the most important thing would be to find out what the Executable ROS Checks are doing. The best way to do that is probably to open Christian Corti's disassembly of the 5110 Executable ROS and see if you can find and understand the code.
Last edited:
voidstar78
Veteran Member
I was reading about that Comm-Store/5100 device you mentioned - funny thing I noticed in the manual and the C code emulator, and in the comm-Store brochure: the file format header has an "expiration date" field. I suppose back then, when disk/storage/archive was limited, folks were motivated to think about indicating when such-and-such data was expired or no longer relevant.
Under modern file systems, we have Date Created, Date Last Modified, and a photo might have Date Acquired/Taken. But "Expiration Date" seems to have fallen by the wayside.
BTW - the BNC external monitor connector works fine. Duh, I can video/OCR off of that :D That motivates me to try that address-pull technique. Just point me to the right pins. Have 5v source + set of resisters.... In fact, I could inline-record it, and not have to setup a camera (because a BNC to HDMI adapter).
ITEM 1
5110 MIM 3-20: "Each R/W storage card consists of eighteen 8K storage modules. These 8K modules are further broken down into eight 1K storage chips." I'm confused by that, maybe it is a typo. This is from the 1978 manual, maybe it changed in 1979? But... 18 * 8K = 144K... Maybe it meant eight instead of eighteen? I'm not brave enough to actually take any of my cards out of their slots, but here's the best angle I can get on the RWS card that I have. However it works, this single card is giving me 32K.
ITEM 2
As we know, flipping the REGISTER switch shows the first 512 bytes of RWS - with the first 128 bytes being used as registers right on the processor.
But from the manual, address 008F (byte 143) is the "tape status". Might be neat to see if we can manipulate signals on that Y-connector to change this status.
BOT talks about needing "5 holes" in the tape, and EOT is "3 holes"....
ITEM 3
From the manual, it says the DCP (built in executable ROS), has these commands...
“A xxxx“: alter address xxxx
“BE xxxx yyyy” BRANCH to Executable ROS (halt on yyyy)
“BR xxxx yyyy” BRANCH to read/write storage (halt on yyyy)
“BX xxxx yyyy” BRANCH to extended ROS (halt on yyyy)
Type “C” to enter a diagnostic menu (test I/O, OP codes, ROS, DCP I/O)
Type “D xxxx“: display address xxxx (use arrow keys to cycle addresses)
Well..... BE, branch into Executable ROS?? Maybe I can set some register values (A xxxx), and execute some known code in the executable ROS, and see if I get matching results (as running the Model 1 ROS in the emulator)?
And, what's "BX" extended ROS? I didn't yet come across more details about that.
ITEM 4
5110 MIM 4-70: Machine Check Jumper
"Jumper connects K2-S07 to the A1 board. Removing this jumper allows the controller to continue functioning when an error occurs on the machine check line."
Well good to know - if CRCs fail to check or something like this, there may be a way to "force continue."
Under modern file systems, we have Date Created, Date Last Modified, and a photo might have Date Acquired/Taken. But "Expiration Date" seems to have fallen by the wayside.
BTW - the BNC external monitor connector works fine. Duh, I can video/OCR off of that :D That motivates me to try that address-pull technique. Just point me to the right pins. Have 5v source + set of resisters.... In fact, I could inline-record it, and not have to setup a camera (because a BNC to HDMI adapter).
ITEM 1
5110 MIM 3-20: "Each R/W storage card consists of eighteen 8K storage modules. These 8K modules are further broken down into eight 1K storage chips." I'm confused by that, maybe it is a typo. This is from the 1978 manual, maybe it changed in 1979? But... 18 * 8K = 144K... Maybe it meant eight instead of eighteen? I'm not brave enough to actually take any of my cards out of their slots, but here's the best angle I can get on the RWS card that I have. However it works, this single card is giving me 32K.
ITEM 2
As we know, flipping the REGISTER switch shows the first 512 bytes of RWS - with the first 128 bytes being used as registers right on the processor.
But from the manual, address 008F (byte 143) is the "tape status". Might be neat to see if we can manipulate signals on that Y-connector to change this status.
BOT talks about needing "5 holes" in the tape, and EOT is "3 holes"....
ITEM 3
From the manual, it says the DCP (built in executable ROS), has these commands...
“A xxxx“: alter address xxxx
“BE xxxx yyyy” BRANCH to Executable ROS (halt on yyyy)
“BR xxxx yyyy” BRANCH to read/write storage (halt on yyyy)
“BX xxxx yyyy” BRANCH to extended ROS (halt on yyyy)
Type “C” to enter a diagnostic menu (test I/O, OP codes, ROS, DCP I/O)
Type “D xxxx“: display address xxxx (use arrow keys to cycle addresses)
Well..... BE, branch into Executable ROS?? Maybe I can set some register values (A xxxx), and execute some known code in the executable ROS, and see if I get matching results (as running the Model 1 ROS in the emulator)?
And, what's "BX" extended ROS? I didn't yet come across more details about that.
ITEM 4
5110 MIM 4-70: Machine Check Jumper
"Jumper connects K2-S07 to the A1 board. Removing this jumper allows the controller to continue functioning when an error occurs on the machine check line."
Well good to know - if CRCs fail to check or something like this, there may be a way to "force continue."
voidstar78
Veteran Member
So, I tried that "ROS to RWS" sample at Christian Corti's page (I still haven't been able to contact him). This is a small program placed at $0B00 that copies $4000 "words" from a selected ROS over to RWS. I think Christian had a 64K machine, mines only 32K - which is fine, I just get to preview 12K sections at a time instead of 16K.
A couple interesting findings...
At $0B00 the first instruction is "1104" == CTRL 1, #$04
You just change the "04" to a selected set of devices (well, the opcode says "devices" but I'm not sure if that's what it really means). So I walked through all of them, 0 - F ....
For that first instruction, I'll call it "11XX". With XX replaced as follows, here were the results:
00 all zero's in the RWS result
01 all zero's in the RWS result
02 Common ROS! It matches the comros.bin that Corti' produced (and provided with the emulator)
EXCEPT... One byte at 0xEF is different (mine has "14" hex, his is "00" -- since he used an actual floppy disk, I'm suspect maybe there was a read/write error in that process )
Then there is a bunch of differences after 0x2DE0
Both do end their content at 0x2FFF (so this is 543 bytes of differences at the end - can do a lot of damage with 500+ assembly instructions I may just transcribe these out, since it's not that many, and see what they disassemble into )
(his comros.bin file is 16K, but the last 4K are all zero's)
03 (repeat of common ROS)
04 all zero's (as expected; this should be the APL ROS that I do not have)
05 all zero's
06 (repeat of common ROS)
07 (repeat of common ROS)
08 BASIC! Yes, it matches the "basicnx.bin" file (well, at least the first 12K match, I didn't check the rest yet)
09 (repeat of BASIC)
0A What's this!? Starts with: 0A 32 97 F1 DC 16 14 F1 12 BB 33 D6 B1 80 37 F6 ...
0B (same as 0A)
0C (repeat of BASIC)
0D (repeat of BASIC)
0E (same as 0A) i.e. 0A 32 97 F1 DC 16 14 F1 12 BB 33 D6 B1 80 37 F6 ...
0F (same as 0A)
I assume 0A is probably the "Feature ROS" ? I guess one way to confirm that might be to remove the Feature ROS card, but I'm not that curious about it (and don't want to risk removing any cards).
I tried some other permutations of this CTRL opcode. Just feels there ought to be a way to sneak a peek at the executable ROS. Christian has some notes about a transfer bit being set to write an executable ROS, which he proposed was a way to avoid wasting/burning a lot of ROM while they were R&D that code. In Christians' "I/O functions with IOCB" (at the bottom) it refers to "switching between RWS/ROS" (via an I/O Supervisor, which I think I recall seeing more clearly marked on the 5100).. And I kind of follow that example of using an IOCB to make the system beep.
Anyhow, wanted to try the "ROS to RWS", see if got lucky and some value happened to hit the executable ROS. Will hit the emulator code next to see if some other trick stands out.
A couple interesting findings...
At $0B00 the first instruction is "1104" == CTRL 1, #$04
You just change the "04" to a selected set of devices (well, the opcode says "devices" but I'm not sure if that's what it really means). So I walked through all of them, 0 - F ....
For that first instruction, I'll call it "11XX". With XX replaced as follows, here were the results:
00 all zero's in the RWS result
01 all zero's in the RWS result
02 Common ROS! It matches the comros.bin that Corti' produced (and provided with the emulator)
EXCEPT... One byte at 0xEF is different (mine has "14" hex, his is "00" -- since he used an actual floppy disk, I'm suspect maybe there was a read/write error in that process
)Then there is a bunch of differences after 0x2DE0
Both do end their content at 0x2FFF (so this is 543 bytes of differences at the end - can do a lot of damage with 500+ assembly instructions
I may just transcribe these out, since it's not that many, and see what they disassemble into )(his comros.bin file is 16K, but the last 4K are all zero's)
03 (repeat of common ROS)
04 all zero's (as expected; this should be the APL ROS that I do not have)
05 all zero's
06 (repeat of common ROS)
07 (repeat of common ROS)
08 BASIC! Yes, it matches the "basicnx.bin" file (well, at least the first 12K match, I didn't check the rest yet)
09 (repeat of BASIC)
0A What's this!? Starts with: 0A 32 97 F1 DC 16 14 F1 12 BB 33 D6 B1 80 37 F6 ...
0B (same as 0A)
0C (repeat of BASIC)
0D (repeat of BASIC)
0E (same as 0A) i.e. 0A 32 97 F1 DC 16 14 F1 12 BB 33 D6 B1 80 37 F6 ...
0F (same as 0A)
I assume 0A is probably the "Feature ROS" ? I guess one way to confirm that might be to remove the Feature ROS card, but I'm not that curious about it (and don't want to risk removing any cards).
I tried some other permutations of this CTRL opcode. Just feels there ought to be a way to sneak a peek at the executable ROS. Christian has some notes about a transfer bit being set to write an executable ROS, which he proposed was a way to avoid wasting/burning a lot of ROM while they were R&D that code. In Christians' "I/O functions with IOCB" (at the bottom) it refers to "switching between RWS/ROS" (via an I/O Supervisor, which I think I recall seeing more clearly marked on the 5100).. And I kind of follow that example of using an IOCB to make the system beep.
Anyhow, wanted to try the "ROS to RWS", see if got lucky and some value happened to hit the executable ROS. Will hit the emulator code next to see if some other trick stands out.