Standalone bootable ZRQC?? formatter

[RSX11M+]

It has come up a number of times here on the forums that members have a need to run XXDP ZRQC?? [the MSCP Disk formatter utility] to format a new hard drive, without the traditional media to run XXDP on. Making floppies for XXDP is becoming nearly impossible due to lack of PCs with compatible 5.25" drives. It's difficult to share XXDP on TK50 over the internet, although I have some thoughts about how this might be done someday.

In the past, I've made bootable task images on RSX, for both standard and special programs. The most recent [ha!... 18 years ago?] was a bootable diskette I made for one of our DEC service techs [Bob Gersky] to use with a UNIBUS trace module.

To make such an image, requires the sources to the program, and that it be "standalone" - requiring no other elements from an OS. Just like XXDP programs are.

Bob's was a rather lengthy program he was expected to "Toggle In" from the 11/70's front panel. As I recall it was more than 200 instructions. It took me less time to type in his program, compile it and make the boot image than for him to load it twice manually. It meant this would save about 2 hours each time he used the diskette, and turn a tedious job into an easy, direct one.
​

The sources are built and linked in a special manner [hopefully I can recall all the elements] to produce a task image compatible with VMR. Then VMR is used to "Save" it to the media of choice, making a bootable copy.

Once such a bootable task image exists, it can also be "Booted" directly from a running system, like RSX and possibly RT11.


Great. So what's the problem?

The problem here is that although we've combed the world for sources to ZRQC??, none have as yet been located.

This thread is my last ditch hope before deciding to disassemble a ZRQC task image to create sources to begin this process. That's a major ugly path, and will probably take more to complete and debug than I have time for these days. So it won't be available in time to help with the current need.

If the sources were to turn up [they should have been on one of our Microfiche sets] then the chain of events would look something like this.

1) Figure out how to build it as a bootable task.
2) Put together a "Kit" of source files, MACRO-11 and TKB building procedures for RSX and RT11.
3) Publish the "Kit" for download over the internet
4) Members would download the Kit, and using a terminal emulator - transfer the Kit files to the target system
5) Build the bootable ZRQC?? on the target system, and save it to media available to them - or simply run it from the build system by booting the image directly.
​

So... please comb your attics basements and garages for sources to ZRQC??. Any version would be more than we have now.

Thank You for your consideration.

 

[jackrubin]

Not the answer you're looking for, but the recent appearance of a number of reasonably priced qbus SCSI adapters on eBay allows another approach. It's pretty straight-forward to load the full XXDP package onto a bootable CD or ZIP drive to accomplish this and any number of other diagnostic tasks. People have also prepared bootable tape images with single XXDP programs and loaded them from PC-based TU58 emulators.

 

[RSX11M+]

Good point Jack... I didn't consider that. All true.

 

[Lou - N2MIY]

What I usually do is what Jack mentioned - I use a PC TU58 emulator with a bootable TU58 XXDP image. I use Will's TU58.EXE emulator and connect the PC serial port to a DL(V)11 set at the usual CSR and vector for dd:. Then you can toggle in a DD: bootstrap or run one from rom if you have this strap in rom.

Of course, I too really badly want to see the listing for ZRQC?? because I want to reduce to practice how to patch it to use ANY MFM HDD, not just RDxx drives.

Also, I am usually willing to put an XXDP RX01/2/50/33 in the mail for anyone who needs one (but the emulated PC TU58 method is preferred!!)

Lou

 

[RSX11M+]

What I usually do is what Jack mentioned - I use a PC TU58 emulator with a bootable TU58 XXDP image. I use Will's TU58.EXE emulator and connect the PC serial port to a DL(V)11 set at the usual CSR and vector for dd:. Then you can toggle in a DD: bootstrap or run one from rom if you have this strap in rom.

Of course, I too really badly want to see the listing for ZRQC?? because I want to reduce to practice how to patch it to use ANY MFM HDD, not just RDxx drives.

Also, I am usually willing to put an XXDP RX01/2/50/33 in the mail for anyone who needs one (but the emulated PC TU58 method is preferred!!)

Lou

I agree with all those points. The XXDP/PUTR method, if applicable to the console terminal would be the thing. Unfortunately there are still times that come up because there was no DLV shipped in these systems to be moved to the correct address for the standard TU58 boot. I already have another effort / thread going somewhere on getting this TU58 / Console terminal working. It's alluded to in the TU58 documentation, but not a demonstrated capability in our bag of tricks yet.

Having the ability to run diags - as BOOTABLE tasks - would add a powerful tool for systems that still have operable OS's on their drives without requiring anything else in terms of external hardware or software.

 

[RSX11M+]

Ok, so I got to thinking... what would be the most minimal solution to run ZRQC?

In the old days we'd toggle sizable programs into memory from the switch register for special hardware needs. It was tedious and laborious but it worked. Two guys working together, one operating the register and the other reading the code aloud could knock in a 1KB program before lunch.

Once MicroODT was included in the Micro-11's it's became much easier, although a bit less sexy.

Then I started thinking... could I load ZRQC onto a working system using only the console serial port and MicroODT? Just how big is ZRQC anyway?

This started me on a search to understand the file format of XXDP programs in general, and ZRQC in particular. My original thinking was to write a DOS program that would talk to a PDP-11 target via serial port connected to the console terminal. It would understand ODT and feed the necessary memory contents to the target automatically using ODT commands. [sort of like the method the TU58 tech manual referred to]

After sleeping on it, I decided a much simpler "brute force" approach might also work, and would require a lot less "understanding" on my part. Rather than working out all the file formats, why not use a Master/Slave approach to "transplant" the contents of memory from one system to another? So what if it was big, 64KB is nothing these days.

• Copy the entire loaded 54kb ram memory space from a halted XXDP/ZRQC session to a capture file via the console terminal. Vector table, stack, program space... everything.
• Then manipulate the contents of the dump file to turn it into the ODT commands to restore that "image" to another system - any system.
• All that would be required then would be to send the new file to a new target system and issue the command to re-start execution at the correct address. [this is known whenever an XXDP program is run]

I began looking [Google] for a suitable source for the XXDP image and eventually stumbled on the musings of someone else who had apparently been thinking the very same thing.

So, here is the file all ready to go. Just download it to your PC and re-transmit it to your halted target system using a PC terminal emulator. Windows Hyperterminal does nicely and has settings to throttle the send rate of ASCII transferrs. Be sure to send it slowly enough that no serial errors occur. Once it's complete, issue the ODT command: 145702G to restart ZRQC at it's original load address.

• Note: The transfer should take in the neighborhood of an hour, or you're probably going too fast.

If it worked you should see something like this output to the console terminal:

DRSSM-G2
ZRQC-H-0
RQDX3 Disk Formatter Utility
UNIT IS Formattable Winchester (RDnn) or Floppy (RX33) Drives
RSTRT ADR 145702
DR>

This method should work as well with other diagnostics too.

 

[Lou - N2MIY]

This technique will not only work on Micro-11s, but any unibus machine with M9301 or M9312 bootstrap / console emulators.

It is also inspires another project.... I am getting tired of typing bootstraps into ODT on the 11/04 and I don't have a programmer for the fuse proms for M9312. However, I could build a simple transmit-only RS232 box that blasts out the ODT encoded bootstraps (like a big long keyboard macro).

For a machine that has only one SLU, this is the way to go. However, if you do have the luxury of a second SLU, it is still a bit faster (10 minutes vs. one hour) to boot XXDP from an emulated TU58, then load ZRQC??.

Lou

 

[RSX11M+]

This technique will not only work on Micro-11s, but any unibus machine with M9301 or M9312 bootstrap / console emulators.

Quite true, any machine that can run ODT. However I can see the memory quantity mismatch quickly becoming a problem for this particular memory image.

It is also inspires another project.... I am getting tired of typing bootstraps into ODT on the 11/04 and I don't have a programmer for the fuse proms for M9312. However, I could build a simple transmit-only RS232 box that blasts out the ODT encoded bootstraps (like a big long keyboard macro).

If you send me the blank ROMs and specify the contents, I'll happily program them for you. I have a Proteus and it should be able to handle any of the older devices.

Also, the conversion of the bootstraps to this format is really pretty simple, and you could probably work it out yourself using only an old Windows Laptop and Hyperterminal.

For a machine that has only one SLU, this is the way to go. However, if you do have the luxury of a second SLU, it is still a bit faster (10 minutes vs. one hour) to boot XXDP from an emulated TU58, then load ZRQC??.

Lou

For a machine that has only one SLU, and no bootable media, this is the ONLY way to go. Many Micro-11s only shipped with 1 Console serial and a DHV, so there's no serial port easily capable of the DD [TU58]. Hence this method is ideal for that class of machine as has come up several times on this forum.

Transfer speed and Memory size are issues, which deserve more discussion.

• The reason it takes an hour is because we load the entire usable memory space below 64k. On J11 based machines, this method is really ideal as they almost always had more than 64k. Another customization would be to lessen the memory of the source system used to generate the image, and likewise a smaller/faster memory image file to transfer.
  
  In our case, trying to load ZRQC, what is the minimum memory required? I don't know, but guess it's probably 16KW. Maybe you know more specifically Lou. However, for other diags, I'm sure the reduced footprint option is an alternative.

• Yet another would be to download and run a small "precursor" program to fill memory with zeros '0" and then send only non-zero data to the target system when it would save time. From a quick scan of the file, this would also speed things along, but would require more of a conversion process after the original dump.

Of course, we're just re-inventing the storage format used in Console BOOTABLE TU58 tapes, which don't seem to exist any longer.

• A smarter device/program to send the data would also help. It could wait for the ODT response to each character and throttle itself accordingly, hence going as fast as the target system could actually accept the transfer. Using this, the bit rate of the console serial port could be turned all the way up. But then this becomes more than a simple terminal emulator program. I'm tempted to take a whack at this one myself, even though I personally wouldn't use it that often.

Instinctively a small solid state "Widget" does sound attractive though. A "Blivit" with two D-Sub serial connectors, to be inserted directly into the target system's serial port on one side, and accept the cable to the console terminal on the other.

It could:

• automatically send a pre-arranged bootstrap when it sees the target system start.
• provide interactive boot selection from the terminal side
• Interrogate the system CPU to select appropriate bootstrap options
• Carry a library of bootstraps, diagnostics and even complete "standalone" system images.
• it's own firmware and library could be updated via serial port from a PC
• WiFi accessible?

Is that what you were thinking?

 

[Lou - N2MIY]

The smallest memories I have are 32kW, so I don't have an easy way to identify the smallest amount of memory that XXDP/ZRQC?? will fit in and run. By now, most people would have at least 32kW anyway (one M8044), so that should not be a big deal.

As for programming roms for the M9312, I may take you up on that. I need to order some of those roms (74S571) - Jameco has them.

I like the widget idea, and you listed way more than I could have imagined for it. The interactive boot selection is nice with bootstrap library. I have a half dozen boards (in nice enclosures) someone made in the early eighties with two 2732s, an AY-3-1015 uart w/ 1488/89, and some counters. Upon receipt of some particular ASCII codes, the counters dump regions of the roms to the uart. Like a keyboard macro. Although these are not interactive, I can use them to type out the bootstrap. (I just have to reverse engineer them first, I don't have the schematic!)

Lou

 

[RSX11M+]

...As for programming roms for the M9312, I may take you up on that. I need to order some of those roms (74S571) - Jameco has them.

I'll dust off the programmer and locate the software. It'll be ready to go when you are.

 

[RSX11M+]

The smallest memories I have are 32kW, so I don't have an easy way to identify the smallest amount of memory that XXDP/ZRQC?? will fit in and run. By now, most people would have at least 32kW anyway (one M8044), so that should not be a big deal.

I checked into it, and I think 32KW is the smallest ZRQC will run in, using the SM (small) XXDP monitor. ZRQCH0 itself is over +50kb as a binary image.

The only ways I see of speeding up the transfer [other than the pre-zero technique above] would be to transfer in some packed binary. This would be a little odd, because some systems would need it to work in 7-bit data mode, or require the console serial hardware to pass 8-bit characters.

A paper-tape loader sort of thing - which reminds me...

I have a half dozen boards (in nice enclosures) someone made in the early eighties with two 2732s, an AY-3-1015 uart w/ 1488/89, and some counters. Upon receipt of some particular ASCII codes, the counters dump regions of the roms to the uart. Like a keyboard macro. Although these are not interactive, I can use them to type out the bootstrap. (I just have to reverse engineer them first, I don't have the schematic!)

Could these devices be paper tape emulators? I seem to remember something like this in the late 70's / early 80s. Can't recall if it was home-brew, or a real product, or an "Escaped out the back door of DEC engineering" special.

 

[RSX11M+]

Settings load ZRQC over MicroODT session

Settings load ZRQC over MicroODT session

We've had success loading ZRQC** over a serial console terminal ODT session using this method and Windows Hyperterminal with these settings...

Comm settings:

• 9600
• 8
• N
• 1

ASCII Transfer Settings:

Sending:

• Send Line ends with line feeds - NO
• Echo typed characters locally - NO
• Line Delay - 0
• Character delay - 22 milliseconds

Receiving:

• Append Line Feeds to incoming line ends - NO
• Force incoming data to 7-bit ASCII - NO
• Wrap lines that exceed terminal width - NO

Procedure:

1. Be sure the target system is in ODT, but that the HALT button/switch is no longer engaged
2. Then hit enter a few times and commence the TEXT file transfer.
3. When it completes you should be ready to enter the 145702G command. [Hit enter a few times first.]

This is how it looks at the end when everything goes right [about 66minutes] ...

00157730/000000 5300
00157732/000000 1375
00157734/000000 12601
00157736/000000 12600
00157740/000000 207
00157742/000000 240
00157744/000000 407
00157746/000000 6
00157750/000000 0
00157752/000000 12
00157754/000000 0
00157756/000000 0
00157760/000000 0
00157762/000000 172150
00157764/000000 240
00157766/000000 514
00157770/000000 0
00157772/000000 0
00157774/000000 0
00157776/000000 0
00160000/052525
@145702G
DR>

Explanations:

The problem with the default HyperTerminal settings is that the ZRQC file contains LF (Line Feed - ASCII 0x0A) characters. If HT [or anything else] adds CR to these, it will screw things up and ODT will error. Also, after the LF, ODT should respond with something like: "<CR><LF>00000000/000000 " [like above]. This is ok, but takes a lot of time (~19ms@9600baud, 11bits per char) during which all characters ODT receives are ignored. HT apparently doesn't recognize LF as an EOL character, so we can't use the "Line Delay" setting to prevent a problem. Our workaround is to add the delay after every character. Yeah, it wastes time, but does work.
​

I've begun writing a specialized program to do it without all these unnecessary waits. It should be able to accomplish the same thing in 1/4 of the time, but until it's available this will do. Employing this understanding may allow others use different programs too.

**Note: To be certain the ZRQC file transfers correctly, verify it is 127566 bytes long, after download.

 

[PG31]

Thanks RSX11M+ I've successfully tried the beta ZRQC standalone formatter and used it to format an RD32. I found it straight forward to use.