Just got back tonight from my travels this week. Now to play with the 1130 and related toys again.
PERTEC D3422 DRIVE RESTORATION
A fellow enthusiast who has past experience restoring and working with this disk drive has shared some materials and tips with me! I am just digesting what I found right now, after which I will likely have a few more questions. All that must wait until I have the power supply repaired.
For the power supply issue I am debugging, as far as I can see from the schematic there is just one path for the +20V raw power to get down to the circuitry for the -20V raw input, where parts are committing suicide. Everything else is separated by ground in the middle. Thus, unless some failed component has created a sneak path down to the op amp and transistors that are frying themselves, it can only be a small number of parts causing the problem.
The transistor replacements arrived today and I soldered the part in to replace the burned out Q30 in the power supply. I put a replacement op amp into the socket I had installed, to allow quicker replacement until I nail the core problem.
Friday, July 10, 2015
Monday, July 6, 2015
Holiday interruption but some progress on P390 and activity on Pertec
With the big holiday weekend here in the US, I have my daughter's family and their friends over for a belated barbecue which chewed up quite a bit of the day with prep work, shopping and cleanup, in addition to the time together. I didn't get anything done on Sunday.
I am off tomorrow on a business trip thus progress will be quite limited all week.
P390 SYSTEM CHECKOUT
I was successful using the standalone version of DMKFMT to format the DOS sysres pack, after which I began trying to run the standalone restore program to get the DOS image from virtual tape to the disk.
I had to modify the JCL to run the DOS install, forcing it to skip the initialization step and go right to the restore step. It worked, except for a minor JCL error I had to correct. That is, it worked until it tried to do IO to the virtual disk drive, then it once again failed with the 'invalid drive' error.
I did receive the new CMOS Battery for the server and installed it, now that the post office finally delivered it, several days late compared to when a first class package should have arrived. For several days it was listed as late, but then when it tagged in at my home post office this morning, it was magically adjusted back to 'on time' status. The stats will look really good to top management at the USPS, if they routinely erase evidence of failed service.
Next, I booted the ICKDSF standalone utility tape provided with the P390, which should definitely be able to initialize emulated 3350 packs. This too failed. The good news, however, is that it gave me more information about what is going wrong. It is an unrecoverable error on the alternate track 022B 0000 which is cylinder 555, right where alternate tracks would be if this were a physical 3350 volume.
I researched the error and discovered that the only way to initialize virtual volumes on the P390 is to tell ICKDSF that it is a minidisk, even when it is a full sized 3350. This parameter, MIMIC, will skip the check of the alternate tracks that is causing the problems. Next time I bring up the system, I should be able to initialize the pack properly and from there I should be able to restore DOS/VS.
I got the pack initialized properly as a DOS volume with the VTOC at the end, but the standalone restore program is still crashing with the error (invalid disk drive). I ran out of time to poke at this longer.
PERTEC DISK DRIVE RESTORATION
I finished the validation that my replaced components had full connectivity - installing a few bridge wires where that was necessary - and am now ready to start testing once again.
The testbed is the raw DC power into the servo board, the two external heatsinks with power transistors, and jumpers to return the -5V, +5V and ground sense returns. This should give me a safe subset to let me bring up the power and test each part of the regulation separately.
When I first brought it up, I saw the op amp smoking and the transistor it feeds. I had thought I had isolated the power sections and was only testing the +20V raw feed, which should have only driven the +10V output. The parts that smoked, however, are on the -20V raw feed side, which produces both -10V and -5V outputs. The last of the regulated supplies, the +5V one, is fed by a +10V raw feed.
I validated that it was not supplying -20V raw, only +20V. That should not be able to energize the circuitry on the negative side - there are just a few diodes and capacitors to ground and I don't see a legitimate path for the +20V to get down to the parts that smoked. This is a good clue even if a bit opaque at first.
I am off tomorrow on a business trip thus progress will be quite limited all week.
P390 SYSTEM CHECKOUT
I was successful using the standalone version of DMKFMT to format the DOS sysres pack, after which I began trying to run the standalone restore program to get the DOS image from virtual tape to the disk.
I had to modify the JCL to run the DOS install, forcing it to skip the initialization step and go right to the restore step. It worked, except for a minor JCL error I had to correct. That is, it worked until it tried to do IO to the virtual disk drive, then it once again failed with the 'invalid drive' error.
I did receive the new CMOS Battery for the server and installed it, now that the post office finally delivered it, several days late compared to when a first class package should have arrived. For several days it was listed as late, but then when it tagged in at my home post office this morning, it was magically adjusted back to 'on time' status. The stats will look really good to top management at the USPS, if they routinely erase evidence of failed service.
Next, I booted the ICKDSF standalone utility tape provided with the P390, which should definitely be able to initialize emulated 3350 packs. This too failed. The good news, however, is that it gave me more information about what is going wrong. It is an unrecoverable error on the alternate track 022B 0000 which is cylinder 555, right where alternate tracks would be if this were a physical 3350 volume.
I researched the error and discovered that the only way to initialize virtual volumes on the P390 is to tell ICKDSF that it is a minidisk, even when it is a full sized 3350. This parameter, MIMIC, will skip the check of the alternate tracks that is causing the problems. Next time I bring up the system, I should be able to initialize the pack properly and from there I should be able to restore DOS/VS.
I got the pack initialized properly as a DOS volume with the VTOC at the end, but the standalone restore program is still crashing with the error (invalid disk drive). I ran out of time to poke at this longer.
PERTEC DISK DRIVE RESTORATION
I finished the validation that my replaced components had full connectivity - installing a few bridge wires where that was necessary - and am now ready to start testing once again.
The testbed is the raw DC power into the servo board, the two external heatsinks with power transistors, and jumpers to return the -5V, +5V and ground sense returns. This should give me a safe subset to let me bring up the power and test each part of the regulation separately.
When I first brought it up, I saw the op amp smoking and the transistor it feeds. I had thought I had isolated the power sections and was only testing the +20V raw feed, which should have only driven the +10V output. The parts that smoked, however, are on the -20V raw feed side, which produces both -10V and -5V outputs. The last of the regulated supplies, the +5V one, is fed by a +10V raw feed.
I validated that it was not supplying -20V raw, only +20V. That should not be able to energize the circuitry on the negative side - there are just a few diodes and capacitors to ground and I don't see a legitimate path for the +20V to get down to the parts that smoked. This is a good clue even if a bit opaque at first.
Sunday, July 5, 2015
Desoldering station working, not so much the ztex board, and continued progress with the P390
P390 SYSTEM CHECKOUT
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.
PERTEC D3422 DRIVE RESTORATION
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.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
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.
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.
PERTEC D3422 DRIVE RESTORATION
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.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
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.
Saturday, July 4, 2015
This and that, mostly P390
P390 SYSTEM CHECKOUT
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.
1800 SYSTEM RESTORATION IN FINLAND
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.
PERTEC D3422 DRIVE RESTORATION
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.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
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.
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.
1800 SYSTEM RESTORATION IN FINLAND
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.
PERTEC D3422 DRIVE RESTORATION
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.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
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.
Friday, July 3, 2015
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.
P390 SYSTEM CHECKOUT
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.
PERTEC D3422 DRIVE RESTORATION
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.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
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.
P390 SYSTEM CHECKOUT
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.
PERTEC D3422 DRIVE RESTORATION
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.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
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.
Thursday, July 2, 2015
VM/370 up and running on P390, digging into the ztex fpga board issue for SAC Interface box
P390 SYSTEM CHECKOUT
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.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
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.
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.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
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.
Wednesday, July 1, 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.
1053 CONSOLE PRINTER RESTORATION
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.
P390 SYSTEM CHECKOUT
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.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
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.
1053 CONSOLE PRINTER RESTORATION
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.
P390 SYSTEM CHECKOUT
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.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
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.
GENRAD BUG HOUND ARRIVES
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.
GENRAD BUG HOUND ARRIVES
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.
Subscribe to:
Posts (Atom)