• Please review our updated Terms and Rules here

Honeywell 200 resurrection

Still digesting all this, but would it have been necessary to punch the deck in binary? From what I can tell, each 6-bit character value has a unique translation to/from Hollerith and so one could use either as long as they were consistent. If the equipment defaults to Hollerith, then in my mind that seems like the logical choice. Plus, if you were going to put some source code/line numbers in unused parts of the card, Hollerith seems like what you'd want (although, that's a weak argument unless you go and print the card later).
 
Are you confusing binary and Honeywell special code? If you look at the code set tables Hollerith and Honeywell special code were almost identical apart from maybe four specific characters for some daft reason. Punched cards could actually be punched in pure binary using every possible hole, which allowed 160 characters to be stored on one instead of 80. but as those cards had so many holes in them they were very fragile and could easily tear apart, so they weren't popular. Imagine a punched card with every possible hole location punched out; there'd be almost nothing left of it. I think we tried it once using a hand punch. Don't ask me why Honeywell didn't use Hollerith code; it was just weird but they may have had a historical reason from their earlier work with computers before the 200 series. All manufacturers try to be a little bit different with their products, don't they? The real problem was that if you used the wrong code set almost everything worked until you hit one of those four special characters in your data, so you could overlook the error for a long time. As the Honeywell supplied software always used their special code it made sense for us to use it for our data files as well. In fact all our card files from the earlier days when we had a tabulator machine with plugboards to do our printing never used any of the odd four characters, so they worked with either code set. I think the odd characters were things like "&" which we might have started using later in our data, so it made sense to for us to take a standard approach to match Honeywell's right from the start. It was bad enough with the currency symbols as ours was "£" but Honeywell's was of course "$", so we didn't want problems with things like "&" as well.
 
Ah, yes, there was "binary" as well as (what I call) two variations of Hollerith. I think the "Honeywell special code" sort of makes sense, related to the IBM 026 keypunch supporting only 48 characters and perhaps Honeywell expanded that to 64 slightly differently than the IBM 029 did. I forget, have some notes somewhere. Created this table to help visualize it all: http://honeywell2000.durgadas.com/h2000keypunch.html

Still, as long as the reader is set for the same codes as the punch used to create the deck, does it matter which is used? Seems like the default would be easiest to keep straight, especially if the BOOTSTRAP button selects the default. Unless the punch had a different default from the reader.
 
Yes one might get away with it everywhere but why take the risk? Anyway, that's what the self-loading card decks did as far as I recall and one can't argue with history if I'm right.
 
So my goal is to recreate the "Card Loader-Monitor B" and "Tape Loader-Monitor C" code - or at least something functionally equivalent. These monitors load programs that were saved in BRF and so don't need any of this special stuff needed for bootstrap. You just combine the BRF decks for the programs you want to run, in the order you want, and prefix them with the self-loading monitor. The instructions for the card monitor say to bootstrap (the first card) into 1620 (octal) and run it. The monitor itself occupies 100-1617 and uses additional space for card buffers up to 1748 (octal). The user programs must be orged at 1748 or above. The area below 100 is not touched, except for the monitor using X5 and X6, thus preserving all possible index registers for use by programs.

The cool thing about the tape monitor is that it can search forward or backward, by name, for specific programs and thus run them repeatedly and in any order. I have a minimal tape monitor working, and also a minimal card monitor. There are some advanced features, related to peripheral configuration, customization, and "exits", that are not yet implemented.

So, the bootstrap procedure makes sense in that the bootstrap code is loaded above the projected end of the monitor code, and from there it loads the monitor code into it's final place. What you've described can do that, at least more elegantly than my current brute-force method. My plan is to add another output type to the linker (it already does tape or card BRF, and can generate the punctuation instructions prefix needed) for the bootstrap you describe, and then take my existing monitor code and generate the self-loading deck from it and give it a try. But I'm not sure when I'll actually get to that.
 
The following from my friend Brian may be useful regarding the diagnostic tape.

--------------------------------------------------------------------------------------------
Your contact is quite correct it will be a 556bpi NRZI tape. It will be 7-track.
The tapes were called "Sadeh" tapes and you booted them into location zero via "Boot 40 000000" 40 being the tape trunk address. The diagnostic tapes were used to test various aspects of the H200 hardware. There were many programmes on the tapes; eg for testing the Control memory the programme was called "Conmem". I think the main memory prog was Memdex. To test the tape system we used "TapeB8", for more exhaustive testing we used a tape sort programme called Tesrt2 or for the bigger machines it was Tesrt4.

I have a "Sysfil" (residing in the cool garage) tape which was used to generate Sadeh tapes(s) if required. In the loft I have multiple Sadeh tapes, I did look but it was too hot to rummage around. The tapes were either 2400ft or 1200ft.

By chance very recently I came across a copy of booting a Sadeh tape using the H220-7 console. It also shows the octal characters which are loaded from the tape into location 000000 to start the boot process. I made and used this listing a lot when the Boot process failed.

You will note the first 2 -3 instructions are 22 ie SW Set Wordmark. These instructions are unique in that they are "Fixed Format" ie they do not require a word mark to terminate the op-code extraction cycles. The encircled characters are the word marked instructions as a result of the boot process. This may help your friend to determine if his tape id being read correctly. Regarding comparability if the IBM drive is a 7-track 556bpi NRZI drive it should read the tape(s).

Hope this helps
Best regards
Brian

sadeh loader.jpg
 
Well, here's an attempt to disassemble that loader. It's not in EZCoder, but hopefully those familiar with the H200 instruction set can grok it. The '.' means the current location counter in this assembler, so "pcb .,xxx" is a PCB instruction that loops to itself. The original printout is not totally legible, but I think I've got the right digits.

So the loader uses a simple header mechanism to locate a named record on the tape, and then execute the code in that record. So, sort of a first-stage boot loader, where the matched record contains more bootstrap code (the second stage) that completes the loading of the desired program. Not as sophisticated as BRT and the monitors, but at least you could choose by name what you want to run off the tape. It does appear to search forward and backward.

After BOOTSTRAP 00000 and RUN, it halts and allows the operator to modify (at least) the program name and revision/version strings. Then RUN again to start searching the tape for the desired record and runs it without operator intervention (no additional halt or checking of SENSE switch). There does appear to be some "junk" code in there, though, so perhaps there is more to it that I've missed on the first pass.

It does answer one question I had about the mag tape "backspace" control character for PDT. It appears that this actually backspaces TWO IRGs, as the loader only does one "backspace" then reads the record and if not the one then backspaces again. If the control only backspaced one IRG it would be stuck reading the same record over and over. As I recall, the Unix tape management was different, where you have to backspace twice in order to get to the previous record (once gets you to the beginning of the current record - to read that record again). I'll have to check whether I got that right in my simulator. Still, raises a question as to how the BRT monitor is able to work, as it does several backspaces in a row and must be able to land on odd or even records, so perhaps the control is "smart" and handles the IRGs differently on first backspace after a read vs. repeated backspaces.
 

Attachments

Regarding the tape drives, there was a control module for handling the reel motors, it wasn't as simple as letting the zone switches control them directly. The module has the switch (a kind of rocker switch) that Karl Malden uses to run the tape backwards in the movie, "checking the actuator" he says and pretending to back up the tape so he can overwrite the orders he's changing (effective visual, IMHO). If memory serves, there were 5 zone switches per column. The top and bottom were probably as you described and were for detecting error conditions. The next pair inwards were used by the control module to turn the reel motors on and off as well as their direction. Their motor/brake functions were swapped depending on which direction the tape was moving in (remember the drives could read backwards as well as rewind). From what I can see, I think the middle one was used during rewind and the controller basically tried to keep the tape somewhat near it (so between zones normally used for control). You didn't want the reels braking during rewind (unless there was a problem), and a control algorithm was used to accomplish this. These are the details I'm looking for in the theory of operation manual.

As far as braking is concerned, they had brakes on the shafts of the reel motors. For the low-boys like the 204B-1, there was a metal pulley around 4-5inches diameter and around an inch wide on the back end of the motor shaft. There was a thin stainless steel strap shaped like an inverted letter "U" that wrapped half way around the pulley but not touching it normally. There was something like a thin strip of cork glued to the strap on the inside of the "U", so between the strap and the pulley. A vacuum actuator would pull one end of the strap (the other end was fixed), causing it and the cork to rub against the pulley and slow/stop the motor. Quite an elegant/simple solution.

For the high-boys like the 204B-8, they used disk brakes. There was a disk attached to the back end of the motor shaft and a second one parallel to it separated by a quarter inch or so and was fixed in place. A vacuum actuator pulled the fixed disk against the rotating one attached to the motor shaft for braking. Another elegant/simple solution, especially when compared the the IBM 729s. I was given access to the 729s and the rest of the 1401 system (for viewing only) at the CHM when I visited there several years ago and could not believe the amount of complexity in the tape drive compared to Honeywell's. The other things that struck me was that the reels were swapped compared to Honeywell's which puts the read/record surface of the tape against the walls of the loop chambers...why??? I read somewhere they forced air down between the walls and the tape to keep them from touching, which feels like a bit of a hack and makes me wonder why they just didn't swap the reels. Somewhere on Youtube there's a video about the follow-on series of tape drives (3420?) where they did just that and for that reason. Great job by the Honeywell engineers!

For the drawer fans, there were two mounted to the bottom of each drawer when the drawer is in it's normal position. They were the open frame style of fan (I think they were common shaded pole motors) and mounted inside of some black sheet metal with sloped sides and a metal grill on the face towards the PCBs. Each had an airflow detect switch (a momentary microswitch with an arm/paddle assembly in the air stream) that was probably wired in series with all of the others in a system and drove the red FAN light on the console (remember waiting for the light to go out before you could hit the DC ON switch?). Attached is the best picture I could find. They became detached in the middle but you can see the shape of one on the right and is half the width of a drawer. My guess is that they sucked air down through the cards, otherwise you would have hot air blowing out the top of the cabinet.
 

Attachments

  • 1751425657362.png
    1751425657362.png
    2.4 MB · Views: 6
The following from my friend Brian may be useful regarding the diagnostic tape.

--------------------------------------------------------------------------------------------
Your contact is quite correct it will be a 556bpi NRZI tape. It will be 7-track.
The tapes were called "Sadeh" tapes and you booted them into location zero via "Boot 40 000000" 40 being the tape trunk address. The diagnostic tapes were used to test various aspects of the H200 hardware. There were many programmes on the tapes; eg for testing the Control memory the programme was called "Conmem". I think the main memory prog was Memdex. To test the tape system we used "TapeB8", for more exhaustive testing we used a tape sort programme called Tesrt2 or for the bigger machines it was Tesrt4.

I have a "Sysfil" (residing in the cool garage) tape which was used to generate Sadeh tapes(s) if required. In the loft I have multiple Sadeh tapes, I did look but it was too hot to rummage around. The tapes were either 2400ft or 1200ft.

By chance very recently I came across a copy of booting a Sadeh tape using the H220-7 console. It also shows the octal characters which are loaded from the tape into location 000000 to start the boot process. I made and used this listing a lot when the Boot process failed.

You will note the first 2 -3 instructions are 22 ie SW Set Wordmark. These instructions are unique in that they are "Fixed Format" ie they do not require a word mark to terminate the op-code extraction cycles. The encircled characters are the word marked instructions as a result of the boot process. This may help your friend to determine if his tape id being read correctly. Regarding comparability if the IBM drive is a 7-track 556bpi NRZI drive it should read the tape(s).

Hope this helps
Best regards
Brian
Thanks Rob, and please thank Brian for us!

The reason I was unsure about an IBM drive reading a Honeywell tape is that Honeywell sold options for its tape drives to be able to handle IBM tapes (see attached), so there must be some kind of incompatibility (but may not be an issue for our purposes). I like Brian's idea of using the SADEH (pronounced "say dee" if memory serves) dump to at least give some idea if a dump is successful.

Doug, pretty cool that you were able to disassemble that dump! Note at the top, barely visible (above B 40 000000), the operator ran a little clear-memory program.

I would have thought that the diagnostic to be run was an octal number entered into some address and not via the SENSE switches since some models only have 4 of them and my tape goes up to octal 00103, requiring 7 bits. The diagnostics would have to be able to run on a minimal system (thus the 556bpi density, the lowest common denominator that could be read by any drive). Maybe that's what the "P" entry is just before the "PRESS RUN" line? What is that command anyway?
 

Attachments

  • 1751426183852.png
    1751426183852.png
    55.2 KB · Views: 3
Last edited:
Regarding the Keytape, it was more than just a key-to-tape device. We had one connected to a printer and I could dump tapes to it. I was curious what was on all of these tapes we had acquired and it was common to find personal info like names and addresses (and presumably account numbers and such too). Luckily I was a good boy and never did anything nefarious with the data!

Something I was wondering about just the other day regarding the Honeywell keytape was why they even bothered with the vacuum columns? Typing in data didn't require much tape motion at all, so a simple idler pulley system like the paper tape reader/punch had would have sufficed. Even dumping to the printer and rewinding a tape was quite slow.
 
... Maybe that's what the "P" entry is just before the "PRESS RUN" line? What is that command anyway?
That command prints the contents of a control register, in this case looks like CR "00" which would be some R/W channel's CLC. Printing that (000400 here) out confirms that the full tape record was read in (256 bytes), or at least I'm guessing that's why it was done.
 
Thinking more about the SADEH code, I think that the CAM and B instructions at 0160 are the "program exit" entry point. Theoretically, a program could alter the program name and revision strings and then branch to 0160, at which point the loader would start searching again for the next program to run. The code right after that, though, is less obvious. It appears to just load a tape record into memory and run it directly/blindly. Not knowing how the tapes are organized, I guess it could be how the program runs beyond the first record. But it means that it must be careful not to run off the end of the program, or else it tries to execute the header portion of the next program. If all program names begin with 'P', that would be an invalid instruction.
 
Last edited:
I've always assumed that you just boot the diagnostic tape, enter the octal code from the NUM column in the listing to some address for the test you want to execute, and hit run. That would be much simpler than a string search for the name. One of them, possibly number 0000 (not listed) would probably read through the tape and print each program it finds in order to generate the list of programs taped to the...ummm...tape. :D 0000 could also just be the loader though. Just a best logical guess on my part but I can ask my dad the next time I talk to him and see if he remembers.
 

Attachments

  • 1751434142543.jpeg
    1751434142543.jpeg
    2 MB · Views: 4
  • 1751434158203.jpeg
    1751434158203.jpeg
    2 MB · Views: 4
BBtheEE - so the tape you have is the one known as "SYSFIL"? I see that one of the many components on it is called "SADEH1" - which I presume is what generates the SADEH LOADER we have. But I guess we don't know if SYSFIL uses the same loader and format as SADEH, or if it uses something different. I assume that each of these programs is (or could be) a different length, and so that this sequential number assigned is not the physical record number on tape but rather some logical "segment" number. But until we can see what gets booted off the SYSFIL tape we don't know if it is different. One interesting thing is that the SADEH loader seems to be using 5-char names while this tape label is using 6-char names. So, could be a newer version of SADEH, or it could be using a different loader. I really don't know how SADEH fits into SYSFIL. If SADEH is meant to be an ultra-simplified diagnostic framework, it might not be the same scheme as what is used to access programs on SYSFIL - which might be using a more full-featured monitor. It's hard to predict, not knowing the mindset that created both or what time period these are from. These monitors I've been studying come from 1965 time period, but I really don't know where they were deployed. On the one hand, if you've got a decent monitor it seems wasteful not to use it to enhance things like your diagnostics. But on the other hand, there might have been reasons you didn't want to use a complicated monitor if you were unsure of the hardware. Obviously, even SADEH depends on a fair amount of the hardware actually working.

BRT defines a "segment record" that contains an expanded header with the program name, revision, visibility, and segment. It also contains a field which has the number of physical records you need to go backwards over to find the previous segment record - i.e. the number of backspace operations required. But I don't recall that even that monitor describes a way to just go to the "Nth program on tape". When searching forward, it just keeps reading records until it gets a segment header, then checks the program name (etc). When searching backwards, it issues the prescribed number of backspace commands and then reads the (previous) segment header and checks for a match.

I do notice that one of these components is called "PRTALL". I could interpret that to mean it is a program to print all names on the tape. Although, it could just as easily be a test program that tests all the printer features.
 
durgadas - In Easycoder the self-reference address is indicated by "*" rather than "." I don't think "." means anything at all as a symbol in Easycoder.

This morning I did just look through the code on that printout that Brian sent me but didn't work out in any detail what it was doing. However, I did wonder why it set a word mark on location 0133 halfway through the address in a PDT. That did not grok at all. There's no doubt that that address is clearly shown in a SW instruction on the printout and you have listed it in your version of the code as well as Brian circling that location on his printout. The word marks were set by the code in ascending address order so the address printed out must fall between 0131 and 0137, the actual end of the PDT, so obviously is 0133. At the moment I don't know whether a word mark halfway through an address would even have been detected during instruction extraction; it is possible that word marks were ignored during those cycles and only tested for where an end of the instruction could logically come. Even so, why was the word mark set there at all? To be faithful to the original machines any emulator, whether software or hardware based, should cope with these abnormalities just as the original did. I haven't got as far as testing for word marks in my hardware yet so don't currently need to know exactly where to do it in the logic. Maybe you know though.

Near the end of your code you have a truncated PCB with a note questioning whether it would have used the variants from the previous PDT but this format of the instruction just tested whether the read/write channel identified by the one C1 variant present was busy, indicating that any data transfer to or from main memory on that channel hadn't completed yet. It didn't even need to know what peripheral controller had last used that channel as it hadn't been told to communicate with it, only the R/W channel itself. Testing the state of the peripheral controller required a C2 variant in the PCB to identify it. Therefore that PCB only checked whether the data had been transferred, not whether any errors had occurred in the peripheral device while doing the transfer. That couldn't have been tested until after the data transfer was complete anyway. You need to fully understand these DMA data transfers and how access to main memory via the R/W channels was a separate consideration from access to the peripheral devices.

I'll have to ask Brian about the backspace issue.
 
BBtheEE - I know almost nothing about the workings of the tape drives and was only going on the workings of the ones in the Keytape machines. Brian told me that the Keytape machines were built around refurbished standard tape drives, which explains why they had the vacuum tape feed systems already in those, but it is likely that any components not essential to the Keytape operations were stripped out to make maintenance simpler. With the lower tape speeds and possibly lower rewind speeds as well braking would not have been essential, so the features that you mentioned could all have easily been removed. However, as my hub units and motors show no signs if having ever had the brake hardware that you describe attached it is possible that the original units were replaced with simpler custom units designed specifically for the Keytape machines. I have the schematics for several models of the Keytape machines and the vacuum switches and motors were definitely directly connected with no intermediate circuitry, so we may just be talking about quite different devices that happened to use the same basic drive technology. While looking at those schematics I also noticed that the Keytape drives only had one emergency stop sensor in each vacuum channel, so there clearly were simplifications made.

Regarding the attached printer, we had two Keytape machines with these, which were IBM Selectric golf ball typewriters with heavy duty screened cables attaching them to the Keytapes, which directly drove the solenoids in the typewriters. The Keytape machines had to have the K-717 printer adaptor unit in them, which consisted of an auxiliary forty slot backplane containing the extra logic boards. Of course I have all the logic boards from our two K-717 units plus one of the auxiliary backplanes, which I now use as a test bed for circuits before wiring them up on my main backplanes in my computer. The driver boards for the solenoids are easily identifiable because they needed heftier transistors than usual to handle the current surges involved.

Prior to acquiring the Keytape machines our company used other earlier automated typewriter systems, some of which I also acquired. That is how I still have Flexowriter reader and punch components able to handle paper tape and a Dataplex machine central processor containing magnetic card drives. Of course the typewriters used by both those old systems virtually fell apart years ago. However, I did acquire two Wang daisy wheel printers in working order junked by the typing pool, so stripped one down to use for spare parts for the other one, which is still waiting for me to adapt it to use with my H200 one day. Of course the typing pool also gave me all their supply of printer ribbons as well and I bought a collection of compatible daisy wheels on eBay, so I have a good chance of getting the thing working if only I can lift it up as at my age getting something that heavy off the floor is probably beyond me.

Returning to the Keytape printers, our mainframe computer regularly produced tapes with large batches of prestige documents to be printed on them, so the keytape operators brought books or knitting to occupy their time while the Keytapes typed the documents. Of course the operators had to do all the other tasks involved in using a typewriter which didn't have automatic paper feeding or alignment, so they had to stay at their desks to keep the work flowing.

Brian just assumed that your "diagnostic tape" was a SADEH rather than a SYSFIL but now I know I can ask him whether they had similar boot records.

Regarding the necessity of a tape drive option to read IBM tapes, I had a subsequent email from Brian saying that he vaguely recalled IBM tapes using even parity while Honeywell ones used odd parity. If so then equally an IBM drive would need to have the option to read tapes having odd parity to read Honeywell tapes. Equally the longitudinal check characters at the ends of records created odd parity along each track on Honeywell tapes. He also stated that the tracks went from LSB to MSB then Parity across the tape with the LSB track nearest to you when mounted on a drive and the parity track furthest away. He also said that the first character on the tape would be the first 22 character in the boot record to be absolutely clear about what to expect.

The field engineers did regular preventative maintenance to catch developing errors before the users encountered them, so diagnostic tests would have pushed the systems to the limits compared to regular work. Therefore unless a machine had suffered a sudden serious malfunction rather than a weird intermittent one the diagnostics themselves had a pretty good chance of working and they were probably run in a set order that checked the machine functions with that in mind. I can remember Brian once telling me back in the 1960's that they had a test on the control memory that pushed up the chance of it overheating by hitting it with the fastest possible stresses that any program code could ever produce. Control memory burnout was a particular weakness of the H200 but the unusually high speed of the magnetic core control memory was also the machine's biggest selling point as it determined the machine's maximum speed.

Thanks for the info about the drawer fans. I was actually given a couple of the airflow detector switches to add to my collection by another engineer. You didn't mention the air filters though. Possibly the last working series 200 maintenance engineer in the world in Mechanicsburg PA disdainfully called them "rock catchers" because they didn't actually filter out fine dust. I had a similar one from a Keytape machine which was just layers of wire mesh which were regularly soaked in oil to catch particles in the air; at least that was the idea. These filter could be washed and re-oiled, so disposable filters weren't needed. I assume that these were at the bottom of the lowboy cabinets with the fans, so the fans must have blown the air upwards through the drawers, which would have been the natural direction for hot air to go. There was a gap all around the lowboy cabinets directly below the desktops, so the filters couldn't have been there and entirely unfiltered air would have gone in that way if the fans were sucking. They could also have sucked in papers left on top of the cabinets, which would have created an extra job for the engineers.

Brian said that the 2040 machines like the one at our science museum were slowed down versions of the 1250, which he reckoned had overheating problems because of the amount of logic packed into the lowboy cabinets. In contrast the basic model 200 didn't put out so much heat. He said that at some sites with 1250's running intensely active applications it was necessary to prop the tops of the cabinets open a couple of inches to keep the heat levels inside down. The 2040's were meant to last longer than the 1250's by running slower and cooler and the science museum machine has correspondingly slower peripherals, e.g. a 123 card reader instead of the usual 223 and a 122 printer instead of the usual 222. I can ask him which way the air went through the cabinets though as he spent very many years with it blowing around him. From my visits to the computer room I seem to remember the draught coming out at waist level through that gap.

When I had a much needed shower, it having been so appallingly hot here over the last few days, earlier today I found out that our shower has a serious problem that needs urgent attention, so that looks like my task for tomorrow. Back to real life then.
 
Rob, I had not focused on that stray WM in the middle of the PDT instruction. That is certainly surprising, and I can't see any logical reason for it. Perhaps it is just a mistake. But, assuming this code actually runs then the CPU must have handled that. Looking at the H2000 programmers and ETM200 201CP Logic documentation, it is quite vague. My simulator does not handle that, it scans for the next WM and only looks at the characters between as the instruction. I'll have to fix that, under the assumption that address extraction has a "blond spot" to WMs.

Looking at other WMs being set raises more questions. It seems to set WMs in the tape buffer for an expected pattern of instructions to be executed. That says to me that the first part of each record must have the same instruction pattern in it. I also see WMs being set in the buffer used by the code at 0165 (which partially overlaps the tape buffer), which implies a fixed code pattern there as well. That makes me wonder what the code in those records looks like, and what rules are required. It also raises the question about re-use of that buffer space. I had assumed that this buffer was used multiple times for loading additional code, but that could not be the case if the code varies at all. And if that code is self-punctuating, that punctuation remains to foul up any later use of the buffer. Will have to re-think how that is being used.

There is also a RM set at 1137, which is also puzzling. Assuming all tape records are the same size (0400 octal), then that area would overlap the tape buffers. So, these second-stage loaders must be copying the tape records into some other memory location, I guess. But, they must also be responsible for wiping all existing punctuation before they can call back to the SADEH loader to run another program. Puzzling.

Here's the most recent listing for the loader code. Note, this is not EasyCoder, it is a Unix V6 assembler which uses '*' for multiplication and traditionally uses '.' as the current location counter. I use this assembler just because it is easier for me than trying to write EasyCoder without a keypunch machine (can use tabs and generic whitespace).
 

Attachments

As I was thinking about this "WM in the middle of a PDT" issue, I realize that some instructions don't ignore WMs in the address fields - or at least at the start of an address field - because the address fields can be optional. But the PDT instruction always must have an A address (and two variants). So I don't think I can simply ignore the WM, but must check for whether the address is required or optional. I'll have to do my scanning for WM during extraction in a more complicated way, but I think I have all the flags already setup for that. It may be the case that WM in an address field is ignored everywhere but at the start (of the field), and then it is ignored if the address is required. And then extract variants until the next WM.

In this case, the WM is not at the start of the address field. But I don't know if the CPU would do some sort of instruction format halt/exception if it did find a WM at the start of a required address field.
 
As I'm reviewing my instruction extraction, I ran across something in the Programmer's Manual sections on the instructions. For the most part, the FORMATs are showing both the Easycoder input format as well as the physical layout of characters in the object code (in memory when running). But there are some instructions like MAT and MIT that have this:
1751545750672.png
where (I now believe) "format b" does NOT have anything to do with the instruction as it lives in memory - that is purely an input style for Easycoder. I was previously assuming that this indicated how the instruction might look in memory and was doing some odd things to extract through it, but I now suspect that Easycoder just converted "format b" into "format a" when generating the object code and only "format a" ever exists in memory. Maybe this is a "duh" response for everyone else, but I had been taking these FORMATs too literally.

I'm pretty sure most other instructions are showing the memory layout, even if that's not the intention of these diagrams - at least based on running and examining Rob's MACHIN code. But cleaning this up will remove some ambiguity from my extraction code, at least for these two instructions. There are still some special cases during extraction, such as SVI and of course SW/SI, but I'll be reviewing all of that. And I'll need to update my Easycoder and Unix v6 assemblers to do the conversion. That's a bit trickier for my Unix v6 cross-assembler as it will want to store a relocatable address for the "C ADDRESS" field, and so I may have to do the conversion during link time - which is abnormal. It will take some thought.
 

Attachments

  • 1751545028211.png
    1751545028211.png
    37.1 KB · Views: 0
Back
Top