Honeywell 200 resurrection

[BBtheEE]

Yeah, I've wanted to look into touch screen GUIs for most of my simulations, but don't have the means right now. I wrote it in JAVA so that it was "portable", but (most/all) tablets and smartphones won't run JAVA. I've not had the incentive to add a touch screen monitor to my PC as I sit pretty far back from the 37" TV I use right now. I need to read up on how the JAVA GUI handles touch screen and what needs to be done to support that. It may be fairly transparent, at least in some minimal set of features.

I've run your simulator on a touch screen laptop without issue. It kinda made it feel "normal" using my fingers instead of a mouse.

 

[durgadas311]

... I have a bunch of H200/H2000-series stuff that I've either kept since I was a kid or collected over the years since then.

...

Bill

Hi Bill, I've been working on a H2000 simulator and been hunting for any original H200/H2000 software to test it out. If you've got software, or listings, I'd be very interested in trying to run that. http://honeywell2000.durgadas.com/
Thanks,

 

[BBtheEE]

Hi Bill, I've been working on a H2000 simulator and been hunting for any original H200/H2000 software to test it out. If you've got software, or listings, I'd be very interested in trying to run that. http://honeywell2000.durgadas.com/
Thanks,

Hi Doug, very cool simulator! The only software I have is the diagnostic tape pictured earlier. I have a couple of 9-track tape drives (Overland Data desktop-sized, not sure if they are even fully functional), but no 7-track drives. Do you have any contacts that could xfer the tape to something you could use? I would think that the diagnostics would be useful for testing your sim out.

Regards,
Bill

 

[durgadas311]

... Do you have any contacts that could xfer the tape to something you could use? I would think that the diagnostics would be useful for testing your sim out.

Regards,
Bill

I'm looking around, but have not yet found the right search criteria - or else there really are no more computer media conversion shops anymore... I sent one email and am awaiting a reply. Can you confirm the width of the tape? I suspect it is 1/2", but if it is the older 3/4" I'm not sure what that does to our chances. From the labels, this tape might include the "tape monitor" code, so could be quite the goldmine (well, it's not a copy of OS/2000 but hey).

I thought some of the folks that hang out on this forum had tape conversion capability, but 7-track may be too obscure. The reel certainly looks like a 9-track, but I never saw a 7-track so don't know what differences there were. If both used 1/2" tape, it may be that they used the same reels as well (and it was only a matter of the magnetic pattern on the tape).

 

[Al Kossow]

I thought some of the folks that hang out on this forum had tape conversion capability, but 7-track may be too obscure.

Chuck Guzis / Sydex can read them.

 

[BBtheEE]

I'm looking around, but have not yet found the right search criteria - or else there really are no more computer media conversion shops anymore... I sent one email and am awaiting a reply. Can you confirm the width of the tape? I suspect it is 1/2", but if it is the older 3/4" I'm not sure what that does to our chances. From the labels, this tape might include the "tape monitor" code, so could be quite the goldmine (well, it's not a copy of OS/2000 but hey).

I thought some of the folks that hang out on this forum had tape conversion capability, but 7-track may be too obscure. The reel certainly looks like a 9-track, but I never saw a 7-track so don't know what differences there were. If both used 1/2" tape, it may be that they used the same reels as well (and it was only a matter of the magnetic pattern on the tape).

It's 1/2" tape and 7-tracks. Both 7- and 9-track drives commonly used 1/2" tape. I don't think 3/4" tape had much longevity and if memory serves, came before 1/2" in the Honeywell world. I think some of the older 3/4" tape drives were compatible with H200, which makes sense.

The diagnostic tapes were written at 556bpi too since all of the 7-track drives could read at the low density, a kind of common denominator thing...you wouldn't want to be stuck with a 1600bpi tape that you couldn't read. :D

Certainly no OS/2000 here! Those packs were scrapped decades ago for the aluminum. I bought a similar pack off of eBay a few years ago as decoration in my lab (I have my own business as an electrical engineering contractor). I don't know what all of the programs are, although my dad might remember. I asked him about the handwritten "hamfed" on the tape, and he said the tape came from Hamilton/Hamiltonian Federal, which was probably one of the banks he serviced.

 

[BBtheEE]

Speaking of OS/2000, here is the procedure I wrote up for booting it on my dad's H3200. He put together a nice system (512K!) as a backup site for his customers or for when they needed additional machine time. It mostly sat idle, so I got to play with it and learn more about computers (I was in my young teens back then) until I bought a TRS-80 model 1. I've run the little program at 8-J on Doug's simulator. All of the ADDRESS lights blink nicely when in address mode 4. I must admit that I used the console instead of the control panel, but with dad's help I was able to figure out how to enter and run it with the control panel. It makes for a nice little screensaver if you have a spare PC around! It does occasionally crash after a while though, maybe a memory leak in the sim, but I don't know Java.

Booting a Honeywell mainframe was certainly a process!

 

[durgadas311]

... It does occasionally crash after a while though, maybe a memory leak in the sim, but I don't know Java.

Booting a Honeywell mainframe was certainly a process!

I'll try it out to see if I can reproduce the crash. Did you capture the exception? You just ran that program for some number of hours?

 

[Chuck(G)]

Chuck Guzis / Sydex can read them.

Drop me a PM and we'll set something up. Have read dozens for NASA.

 

[BBtheEE]

I'll try it out to see if I can reproduce the crash. Did you capture the exception? You just ran that program for some number of hours?

I started a run before I went to bed last night, and I saw a "Run Fault Warning" dialog box this morning: Fault 1777776: FaultException: ran off end of memory 1777776. I assume this is a fault generated by code you wrote for the sim? That value looks suspiciously octal. 😁

 

[durgadas311]

I started a run before I went to bed last night, and I saw a "Run Fault Warning" dialog box this morning: Fault 1777776: FaultException: ran off end of memory 1777776. I assume this is a fault generated by code you wrote for the sim? That value looks suspiciously octal. 😁

Yes, the simulator traps on wrapping execution around at the end of memory. It also traps on illegal op codes.

I'm having trouble getting this program to run, but will follow up on PM (private message).

 

[durgadas311]

... I've run the little program at 8-J on Doug's simulator. ...

That's an interesting little "program" to analyze. The H3200 must have had different control register assignments, at least for AAR, but I was able to get this procedure to work:

A 00 0000000
115 115 015 015
A 77 0000000
A 67 0000003
A 70 0000002
A 00 0000000

And looking at what it does, I see that it never completes execution of the first instruction. It fetches the LCA opcode and starts executing with AAR and BAR as previously set. Because of the overlapping fields, 015 (LCA opcode without WM) keeps getting copied ahead of the AAR and so the instruction never sense a WM to terminate the copy. The CPU just keeps copying 015 over all of memory forever. You have to manually STOP the execution phase, at which point memory is filled with 015. If you were to RUN again at that point, you'd never complete the fetch phase since there are no WMs in memory anymore, which would explain the simulator exception.

 

[BBtheEE]

Sorry for the delay, I had a new client referred to me the other night that has a problem with boards blowing in their system (literally blowing copper traces off) and they are lines down and in a big hurry.

I never did know much about Honeywell architecture or programming. My dad taught me how to do data transfers between peripherals and read the sense switches (I made some programs that would've been great for The Billion Dollar Brain!), all of it in octal on the console. I haven't done any H200 programming for about 40 years now, until your simulator came along and I couldn't resist!

As I understood that program, it was basically a single instruction that never ends, as you mentioned. I remember hitting STOP and INITIALIZE simultaneously to get it to stop (or anytime something went awry). I thought it filled memory with all 0s though, so I checked the first 64 memory addresses in your simulator (starting at 0 and using +1 to increment), and they are all 0s (pic of what I ran attached). I should have mentioned that I'm running Build: Sat Mar 16 11:28:46 CDT 2019 of your simulator, and I should be on the latest version of Java (possibly one version older, I try to keep it up to date). One thing that doesn't appear to be implemented is the TYPE button. If memory serves, I used to be able to type A 00 0000000 and press type, and the console would dump memory contents until you released the button. Does that sound right? I couldn't get it to work on the sim, so I used the control panel instead (which, by the way, I learned to use using your sim...I only programmed on a console which was initially on an H2050A and then later the H3200 (I'll post a couple of pics sometime soon). I have some books that I've skimmed through, and I think the different models had different register sets (bigger ones had more kind of thing), but I could be wrong.

 

[durgadas311]

... I thought it filled memory with all 0s though, so I checked the first 64 memory addresses in your simulator (starting at 0 and using +1 to increment), and they are all 0s (pic of what I ran attached). ...

Ah, yes, you are setting CR 74=0000003 which is not a "valid" CR on this machine (it is not used by the CPU). I assumed that was meant to be AAR so I used 67 instead. If I run using 74 I also get memory filled with 00, but that is because AAR just happens to be 0000000 at the beginning and it quickly wraps around backward and, on the simulator, memory powers-up to 00 (but on a real H200/2000 that memory is core and will power up with whatever was last left in it) I thought about trying to emulate "real core memory", but have not thus far. So, I think the only way to get deterministic behavior on a "real" system is to make sure AAR is getting initialized (and memory is filled with 015). There's probably a way to re-do the "program" so that it fills with 000, too (perhaps as simple as "115 115 000 000").
It appears that some systems assigned AAR to CR 74 and others assigned it to CR 67. I haven't found any details on the 3200. The "Models 2040 through 2070" and "Models 200,1200,1250,2200,4200" documentation I have found show AAR at CR 67. At least as far as the variant character used in the LCR/SCR instructions. I have assumed that the front panel operates with the same codes/addresses as described for LCR/SCR.

 

[durgadas311]

I did sort out my confusion about CR 67 vs. 74. I read the table with the LCR/SCR instructions to mean that AAR was 67, but upon closer reading I see that 67 is a temporary register used to keep a copy of AAR during the LCR/SCR instructions. It would seem that AAR was 14 on very small H200 system (max CR 17), which seems to translated to 74 on larger systems (max CR 77).

I'm guessing Rob is building a smaller config, probably using CR 00-17. But given the likely 4-bit addressing, one could probably enter CR 74 on these smaller systems and get 14 when the control memory is actually accessed.

 

[RobS]

Hi folks! Pardon my absence but I haven't been receiving any notifications from the site so didn't know that you were chatting on my thread. I'll have to query that with the gods of VCFed.

First, my usual lack of progress report on my project. There's still no sign of my receiving that promised control panel from my contact in California, but this has been going on for many years now and I have difficulty even getting his attention as he seldom checks the email address which he gave me (much as I seldom check into this site to be fair). No doubt the tribulations of real life are still taking up all his time and this item is a long way down his list of things to do.

I will shortly reach my 78th birthday and now realistically I have to treat that original control panel as an essential component for my project. When I started the project I considered constructing a replica panel to be viable, so went ahead with work on the logic boards, but now I would not be able to devote the time and effort to that extra aspect of the construction work. I have always worked on the principle that I won't waste time working on the project if I am short of an essential component, so without the now essential control panel in my possession I have now stored away all the equipment involved and suspended work until I get it so that I have space to do other things in the meantime. There is however now a strong possibility that the project will never resume.

I need to read through the posts that appeared here during my absence carefully in case anything merits a response from me, but I immediately spotted mention of the notorious perpetually looping LCA instruction that can clear the entire memory. At the site where I worked it was part of the normal boot procedure for the operator to enter this instruction into memory from the control panel and run it. Apart from conveniently clearing memory it provided the valuable benefit of writing into every memory location, thereby eliminating any parity errors present before any jobs were run.

Honeywell did not guarantee what the state of memory would be at bootup even though core memory was theoretically retentive, probably because the memory driver circuits might perform spurious write operations as they powered down and up. In contrast a Honeywell series 16 engineer told me that that series was quite happy to shut down, restart and continue the work in progress before the shutdown, but this appears to have been the result of built-in power-failure provisions. As the series 16 machines were often used for process control this would have been important.

 

[durgadas311]

I am saddened to hear that this project may not be completed. As an alternative, I would really like to see the H200 CPU logic be written in some sort of VHDL so that it could be compiled into an FPGA or run on hardware simulators. I have started looking through the documentation, but must admit that my ability to "read" the diagrams is severely limited - I seem to be too well trained in 70s-80s logic diagrams.

Rob, would you be able to help get the CPU logic defined in either more-modern logic diagrams or translated into a VHDL? I'm envisioning that an FPGA to run the CPU logic, coupled with static RAM and a "service processor" like a Raspberry-Pi (peripheral controls and control panel) could do a reasonable job of bringing an H200 alive.

 

[RobS]

I am saddened to hear that this project may not be completed. As an alternative, I would really like to see the H200 CPU logic be written in some sort of VHDL so that it could be compiled into an FPGA or run on hardware simulators. I have started looking through the documentation, but must admit that my ability to "read" the diagrams is severely limited - I seem to be too well trained in 70s-80s logic diagrams.

Rob, would you be able to help get the CPU logic defined in either more-modern logic diagrams or translated into a VHDL? I'm envisioning that an FPGA to run the CPU logic, coupled with static RAM and a "service processor" like a Raspberry-Pi (peripheral controls and control panel) could do a reasonable job of bringing an H200 alive.

What documentation are you trying to read? I don't have any source of much of the detailed logic and am just designing my own to meet the H200 functional specification. If it looks like an H200 and quacks like an H200 then ... who cares about anything else?

The purpose of my project was to experience tackling the types of problems that the original designers had using only the types of components that they had available then. Therefore for example it was legitimate for me to use Honeywell flip-flop ICs from the 1960s in place of core memory in the design of my control memory but I couldn't have used later integrated memory ICs that they didn't have. My machine was intended to be one that they could have built in the 1960s even if it wasn't exactly like the H200 internally but only behaved like one. Any design that I do now will continue to follow that approach even if I decide not to follow through on the physical construction of the logic boards.

Even laying out logic diagrams is a tedious overhead for me and I tend just to transfer my designs straight to PCB layouts with no intervening steps apart from test runs of the more complicated static logic in a spreadsheet containing all possible states. That approach isn't appropriate for evaluating steps through time cells though and I tend to do that mentally.

By the way, this idea of mentally designing a computer intrigues me. If I conceive the design of a circuit in my mind and it seems to work there then in my experience there is a good chance that the real thing will work. Therefore once I have designed all the circuits in my mind then my brain will actually have stored somewhere within it a complete working virtual computer which it can theoretically use for its own purposes unbeknown to me.

That isn't the interesting part of this thought process though. Suppose I were to conceive within my mind a design for a time machine? If that conceptual time machine actually worked what would my brain do with it? Would I even have to conceive the design before my brain was able to use it, given that it was a time machine potentially capable of influencing the past behaviour of my brain? This might seem like pure speculation if I hadn't been having these problems with events in my future apparently affecting what I have done in the past for several years now ... I even have a website devoted to the subject but, much like my HoneyPi website, it hasn't been updated for years. Maybe I will get back to work on that in place of HoneyPi now. It is after all literally the future ... On this subject, is my avatar picture at all reminiscent of any character in the Back to The Future films?

Gosh, I'm appallingly off topic now. It's just as well that I don't visit this site more often.

 

[durgadas311]

Regarding tediousness, I would think that a language such as VHDL could also leverage building blocks, such that you simply use blocks to construct the machine.

I was envisioning a way to represent the original hardware logic, but using modern tools. I was looking at the "Series 200 Logic Training Manual" that I downloaded from bitsavers. That seems to describe the CPU logic in enough detail to (perhaps) reconstruct it, but the major diagrams are missing from the scan (or are part of a separate document bundle that is not available - or else I don't understand the references made).

I believe the same process (that you have been using) would be followed, except that instead of physical hardware one uses the language features of something like VHDL. (I keep using "VHDL" here because it is one hardware language I know of, but I suspect it is not the latest or best supported anymore).

 

[RobS]

I did sort out my confusion about CR 67 vs. 74. I read the table with the LCR/SCR instructions to mean that AAR was 67, but upon closer reading I see that 67 is a temporary register used to keep a copy of AAR during the LCR/SCR instructions. It would seem that AAR was 14 on very small H200 system (max CR 17), which seems to translated to 74 on larger systems (max CR 77).

I'm guessing Rob is building a smaller config, probably using CR 00-17. But given the likely 4-bit addressing, one could probably enter CR 74 on these smaller systems and get 14 when the control memory is actually accessed.

Yes, the basic H200 control registers only went up to 17. In fact if you look at the picture of the control panel HERE there were only four buttons to enter the control register address, so nothing above 17 was physically possible. The odd configuration of the variants in the SCR and LCR instructions was required for compatibility with the larger machines, but in the basic H200 the only i/o registers for the four available channels were 11, 12, 13, 15 for SLCs and 01, 02, 03, 05 for CLCs leaving 04, 06, 07, 10, 14, 16 and 17 for use by the CPU. Therefore, as you say, in the SCR and LCR instructions variant 77 was mapped to real register 17, the SR, variant 70 to register 10, the BAR, and variant 67 to register 07, one of the two work registers. Variant 74 would access the real AAR, register 14, but it would just return jumbled parts of the A address given in the instruction itself, bearing in mind that the contents would change as the instruction executed, so pointless.

Register 00 was strange on the basic configuration as the machine didn't use it at all when running, so the operator could store an address there and then use it to check the contents of that address again when the machine was stopped, so it was just an aid to debugging so far as I know. The control memory design contained sixteen registers anyway, so it made sense to make it accessible in this way rather than waste it. I have no idea whether variant 60 would have accessed it in run mode. I used to spend time with our resident field engineer experimenting with instruction configurations which gave "unspecified" results according to the official documentation to find out exactly what the machine did, but I don't recollect us trying that.