Saturday, July 4, 2015

Desoldering station working, not so much the ztex board, and continued progress with the P390


I continued to fiddle with the DOS/VS boot-able utilities, to figure out why it didn't like the 3350 disk drive I was trying to initialize. I expended the card images in the hope that my problem was due to short card images. Same error. I am now left to believe that the lack of alternate tracks on the emulated disk is somehow flagged as a problem, or there is some other incompatibility between the dos standalone init program and the P390 emulated drive.

I am setting up a boot-able tape image of ICKDSF, the standalone format program, which will format the pack in the OS rather than DOS style. The only difference is that DOS does not use the type 5 record which records free space on the volume and therefore it flips on a 'DOS contamination' bit.

This change happens any time that DOS mounts a pack - the contamination bit is flipped on and the DSCB record is set to zero. If the pack is mounted by MVS, it recreates the format 5 record with an accurate free space count then resets the contamination bit. Therefore as soon as DOS restores the distribution image to the disk, overwriting the VTOC, it will have zero space and the contamination bit properly set.

I moved the P390 and monitor to a more convenient location inside the workshop, since my checkout (and playing around) is going on longer than I expected. I can now sit down with the monitor at tabletop height right behind the keyboard and mouse.

There are so many little details, commands and conditions to remember for each operating system - having to sweep aside four decades of mental cobwebs - but it is slowly coming back. I just remembered that I could 'punch' the standalone initialization program into the virtual card reader in a virtual machine, IPL that card reader to do the task. That means I wouldn't need to prepare the virtual tape image.


I poked around and found that the connections to the power supply transformer for low voltage for ICs were a bit intermittent. With a bit of manipulation I was able to restore the unit to operation and used it to remove my burnt op amp in the Pertec servo board.

With all the desoldering, the copper rings around the openings are gone and some of the traces arent close enough to take solder reliably. I put in an IC socket, to avoid this happening again, and then tested and restored connections as necessary to get this socket wired properly. It was tedious work but completed eventually.

While I am at it, I looked at all the other locations where I removed parts - all the tantalum replacements and the other fried op amp - to test every pin for full connectivity to the rest of the board. I was not done by the end of my worktime today.


I tried all the examples and demos in the SDK as a way of learning something about the problems I am having, but essentially all the demonstration programs load the bitstream to the fpga as the Java code on the PC starts, so that it doesn't matter if the fpga board won't boot up on its own. This masks the problem.

Friday, July 3, 2015

This and that, mostly P390


The PCOMOS2 3270 program used on this system is somehow not passing the PA2 or Clear key codes to the running OS (VM/370) but instead resetting the session in a way that forces the user off the terminal and makes them log back in. It displays a PROG775 message as well. Ideally this gets fixed so that I can hit the clear key to move forward when a terminal screen sites in the "More" state.

For the time being, I have overcome this problem by changing the timing of the 'more' function down to 5 seconds from the default of one minute. It is much more tolerable this way.

I set up a DOS virtual machine to do the DOS/VS 34 sysgen from the distribution tape. I had to fight the P390 system to produce output files from the spooled printing that everyone insists on doing - DOS to VM to P390 to OS2. I see an error message for the standalone disk initialization step saying that X'150' is not a valid disk drive. Progress.

This is typical of mainframe systems - it can take a while to figure out what is not working right; it is an environment with quite limited feedback. Sometimes you have to go to the source code, look up what causes a given message to be issued, and then step through the disk or memory to locate the trigger. Even then, it may take a bit of inspiration to figure out how to fix it, although usually the course of action is clear by this point.

I continue to have to reconfigure the settings each time I power on, because the CMOS battery is dead and the replacement is meandering through the lazy, unreliable USPS system - listed online as due for deliver yesterday but no sign of movement since it hit Dallas five days ago.

Went through a few tests, changing things, but still getting the error on the initialize disk utility. After I shut everything down, it occurred to me that this might be a very simple issue that the card images I am sending to the virtual card reader are not a full 80 columns long. I am not sure of the behavior of the spooled card readers - if they pad then everything is good, otherwise it might be looking at garbage on the remainder of the card buffer, causing the error message.

Frankly, since the error concerns the suitability of the disk drive, it might be an issue with the emulation of the drive - lack of CE tracks or something. At this point, I could initialize the pack with a known good program, then skip over the utility on the tape to run the restore job.


I have heard from the owner of the 1800 system that he has been working on the 2311 disk drives as well as mastering the design of the 1800 processor itself. He just finished restoring a couple of ASR-33 teletypes and a Honeywell 316 minicomputer. His pictures of the cleaned up disk drive just sparkle - he has certainly cleaned it up superbly.


I can't find any manuals at all about the PP-8087/u rework station I have, which looks like it was built by Pace for the US military. I can't find a close enough equivalent Pace model to get the documentation. Unless I am lucky and find something that is causing it to fail to stay on, I may not be able to make use of this any more.


I have reloaded all the SDK code from scratch, used the files that worked properly at Richard's home, but they fail exactly the same here. This is quite frustrating.

P390, SAC Interface ztex board and other work

In the late afternoon, we heard a loud crack as the power went out in our area. A large tree had cracked, fallen across high voltage lines and snapped them. Through most of the evening we heard chain saws and cranes working, then slept in the dark until power came on in the wee hours. Needless to say, it cut sort my work on the 1130 and related projects.


I brought over a different DOS/VS tape image but still get the wait state when I try to IPL the tape, which doesn't start up when I 'ready' the JCL deck in the card reader. Not sure what is happening but will keep investigating. I can see that the P390 has an interrupt pending for the running code, but it isn't enabled for interrupts I suspect. On the other hand, it is not a disabled wait state either.

I can just do this all under my vm/370, which should at least give me more useful status if it doesn't work properly. That is, once I can power this up again.


I received some new desoldering tips for my Pace station today, which should make removal of the newly damaged replacement op amp easier. I put in the new tip, switched on the desoldering station, and . . . nothing. The fuses were all good but when I flipped on the main switch, nothing worked.

I opened it up to check for presence of voltage, including to the main rocker switch that powers it on and off. While manipulating the connections to the switch to test voltages, suddenly it would light up for a few seconds and then go off. The pump motor tried to work while the light was on, which means this is a true power issue and not just the bulb in the switch.

There are times I have to hang on tight to my rationality, lest I believe there are malevolent spirits just waiting to toy with me like this. Why would it fail right at this moment? Putting aside the yoyo of my emotions, I spent a few minutes but then closed it up and put it aside. I was already near the cutoff for fooling around with the Pertec drive and its power supply issues; this pushed me over the edge. For the time being, both the Pertec and this desoldering station will fester in the corner while I work on other things.


Richard Stofer and I are still battling the Ztex board and Xilinx toolchain, trying to figure out why I am having the problem getting the board to autoboot from the flash. Richard has some ideas which I will investigate, plus I will look at setting up a second Xilinx system at a different revision level to see what happens.

It is all a bit mysterious. A version of the bitfile that he produced and loads successfully on his end will configure the fpga to work but won't autoboot from flash on my system. My version of the bitfile loads and autoboots just fine on his end.

I was downloading the latest version of the Ztex SDK when the power went out.

Wednesday, July 1, 2015

VM/370 up and running on P390, digging into the ztex fpga board issue for SAC Interface box


I found a five pack VM system set up to run with the 4K protect key modification - loaded it up on P390 and brought it up successfully. While I was working on the system and remembering my CP and CMS commands, some very unusual raindrops began falling (unusual to have any rain at all in July). I had to move the monitor, keyboard and mouse inside, necessitating a shutdown.

I went back to the DOS/VS generation but continue to have a problem booting the distribution tape, which should have on it a disk init utility, then the disk restore program and finally the contents of the disk pack being restored. It just won't boot, which causes me to suspect that I don't have a good file of that distribution tape. I say this because I used a similar tape file for the VM process and it worked flawlessly.


I moved my fpga bitfile over to the home deskside computer, which also had the ztex software installed, and loaded the file to the ztex board flash. It reported successful loading but once again wouldn't boot from the saved image. The problem is clearly in the way that Xilinx ISE generates the file. May have to install a second instance of ISE on the deskside machine just to produce bitfiles that work with the Ztex board.

Richard Stofer is also investigating this using my project and bitfile, but on his end using his systems. We are exchanging some test files now to try to zero in on the problems I am having.

Tuesday, June 30, 2015

Working on install of VM/370 R6 and DOS/VS R34 on the P390 system, plus work on the ztex board problem

Crushing day yesterday (Monday) with no free time other than work. Today I got a bit of time to go into the workshop.


I rerouted the last of the long cable, allowing the 1053 to sit properly in its cradle on the 1130. Things are buttoned up and ready to do final testing when I get the SAC Interface back online.


I found two virtual disk volumes that were corrupted, which explains why the OS/390 image doesn't boot up fully, triggering an abnormal end in the virtual disk driver code of the P390 software. Whether this is recoverable if I substitute a clean empty volume is still to be determined, since it depends on whether anything essential was on those volumes. Not a high priority.

I located and began transferring the public domain versions of DOS/VS, VM/370 and MVS 3.8, which would let me completely customize and install the systems as I want them. Some of the distributions are already in the right format for P390 (AWSTAPE format for tape reels and AWSCKD format for disk volumes), others are in formats that can be converted using utilities from the Hercules 370 simulator system on a PC.

At lunchtime I transferred over the DOS distribution tape images and began setting it up to begin generating my running dos image. I may have a problem if any of the software tries to use 2K storage protect keys, an option that went away on newer machines and is not emulated on the P390. It appears there are workarounds that have been developed by people that I can locate on the internet if necessary.

Having set up everything that should have allowed me to boot the DOS/VS distribution tape, format the virtual 3350 disk drive and then restore the disk volume from tape, I started up the P390 system and booted the tape drive but it just sat in "loading" or "stopped" status with a PSW of 000000 and no signs of life on the console. I am not sure what is wrong but will start investigating.

I brought over my VM/370 R6 distribution materials and started installing that. First step is to boot the disk dump restore program from tape, then restore the two disk volumes vmrel6 and cpr6l0. The restore job takes about two minutes on a PC running the Hercules 390 simulator, according to posts form those who have run it, but it is taking forever on my P390.

Finally, the two packs were restored and in the interim I had a clue as to why it was so slow. The x235 is a dual processor machine but OS/2 was only running with one of them online. This shortfall in capacity caused the CPU busy to pin at 99%, with the P390 processor mostly waiting for the x86 processors to do the IO emulation tasks and handle the virtual peripherals.

My CMOS battery is dead, which means it doesn't hold settings while powered down. I think the default configuration it is reaching does not activate the second processor. The new battery should be here in a couple of days, after which it won't suffer setting dementia, but I can take a bit of time to explore the configuration settings at first power-up to try to get both engines chugging away.

My attempt to boot the VM system lead to an invalid PSW loop, which I dimly remember being mentioned as a sign that VM is trying to use 2K storage protect keys, something not supported by P390. I think there is an easy fix for this - time to do some research.

It is indeed the issue of 2K keys and the solution is in how Control Register 0 is set by CP. There are source mods I can use to reassemble the CP supervisor but I have the 'bootstrap' problem right now. Either I temporarily bring over a VM system that already has the mods applied, or I create a new AWSTAPE image for the pack with the modified file included.


I am quite fortunate to have a fellow enthusiast, Richard Stofer, who also has a ztex board and has found a way to get his fpga files to load to the onboard flash and configure on powerup. I am exchanging settings and other information until we figure out what are the differences.

There seems to be some undocumented requirements where certain installs of Xilinx ISE set the parameters in a way that fails with ztex while others set parameters that allow success. Richard had one project that would fail and a different project under the same ISE that works, indicating that the conditions causing the problem are subtle.

Richard ran my project on his system and had a file that loaded to flash and booted automatically at power up time. Something different, but even more subtle than I thought. I have a different installation of the ztex software on the home PC, which I will try to see if that is able to load my fpga bitfile so that it configures at board power-on. I will have to try this tomorrow.


I found a GenRad Bug Hound on ebay for a very low price and bought it. It finally arrived and appears to be working fine. It is a tool to track down shorts, problems with wired-or buses and trace signals; it had been recommended by a reader of the blog, thus when the right price arose I added it to my arsenal of tools. 

Sunday, June 28, 2015

P390 System running several versions of MVS, OS/390 or Z/OS

I spent the day visiting with visitors from NY and Ireland - took everyone to Dim Sum at Rincon Center in SF. Travel was challenging, with a confluence of events today that overloaded transit.

The annual Gay Pride parade, a Grateful Dead concert, and an SF Giants game meant that the Caltrain was so jammed that people could only board at the first 4 or 5 stations, the next 20+ had huge frustrated crowds trying to push onto a train with zero room.

The roads were even worse,  which is why we didn't try to drive in. Originally we were going to head up to arrive 2.5 or 3 hours before our meal reservation, but we switched to mass transit plus a 25 minute walk from the train station to our restaurant.

Finally got back home in the early evening, so not much accomplished in the workshop.


I was able to fire up several versions of the OS, validating that this system is in great shape. MVS 5.2.2 came up fine, as did Z/OS 1.4, but I had a failure during IPL on the OS/390 2.10 system.

My problem with the OS/390 boot was in the OS/2 driver that handles the virtual disk drives (AWSCKD for count-key-data type disks); it failed and disabled all disk access. That is undoubtedly due to an integrity or corruption issue on one of the virtual disk packs. I expect that once I know how to use the utilities to load and examine those PC virtual disk pack files, I can fix this somehow.

I own a couple of cards that would act as a 370 channel, allowing any physical peripheral for MVS mainframes to be hooked to the P390 system. However, these cards are designed to fit into the older IBM style PCs - the Microchannel Architecture bus (MCA) - and not into the x235 or any modern PCI bus oriented machine.

If I can find a card for the PCI machines that acts as a mainframe channel, I would put in into the system. I don't have any devices that require bus and tag channel connections, which makes this a bit theoretical.

The P390 system does provide SCSI connections which might allow my IBM 9 track tape drive to be attached (as a 3420 tape drive as far as MVS is concerned). That wouldn't require the channel card, it could be connected and tested much sooner.

Saturday, June 27, 2015

P390 checks out and runs MVS, replacement op amp commits suicide, 1442 card reader news of the world


While I haven't made any progress on repairing or replacing the punch feed wheels for my card reader/punch, the National Museum of Computing in the UK, which has a restored 1130 system, has had great success in clearing up a problem they have been experiencing for months on their 1442. Congratulations to Peter Vaughan of TNMOC.

The team at the Techworks museum in Binghamton NY are engaged in battle with their 1442 reader/punch, although this one is attached to their IBM 1440 computer rather than an 1130 system. I wish them success as well.


I ran out and bought a new op amp and a few 10uf and 22uf tantalum capacitors, allowing the completion of the replacement of the failing capacitors on the servo board and an attempt to restore the regulated power supplies.

After putting everything back, swapping the suspect op amp and swapping out the 22uf tantalums, I fired up the bench test and saw an essentially perfect -4.98V level. Time to move back to using the main power supply, delivering -20, +20 and +10 raw power, plus hooking in the logic board and both heat-sink mounted sets of power transistors. If I find all four regulated voltages are good and the fuses hold, it will then be time to proceed forward.

Moving forward means that I have to re-install the three crowbar SCRs which will blow a fuse if the regulated voltages go too high. Unfortunately, the +5V crowbar SCR was bad and the replacement SCR I bought on ebay was also bad, so I left that circuit unprotected. Then, I hook up all the cables and boards and repeat the power testing to ensure I now will hold power at the proper levels and the fuse-blowing is far in the past.

Alas, when I fired it up, watching the +5V supply, I saw it soar to about 8V and saw a small wisp of smoke as my replaced op amp committed suicide. Something is still not right. This is not making me happy. I am putting far too much labor into this, given that this was an opportunistic buy and not something that is mainstream for the 1130 project.


My suspicion that the MVS wait state was due to a simple operational issue was confirmed - the wait state I received means that no console was available for the IPL to continue. I took a bit of time today to fire up the system again and try to figure out what I have to do to set up a virtual console terminal that MVS will find during IPL. This will involve starting at least one 3270 session.

When I started a TN3270 session as the P390 was booting, I  had a main console and was able to do a cold start boot and see MVS come fully up. I did some minor operator commands to poke around and convince myself I had a workable system, then quiesced for the day.

This P390 system is a normal PCI based x86 system plus the PCI card for the processor. Unfortunately, that means the parallel channel card I own, which is designed for the IBM MCA bus, can't be used to allow this to hook up via bus and tag cables to physical peripherals. I would need to find a PCI version of the parallel channel board in order to achieve that added functionality.