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. 

No comments:

Post a Comment