MAINDECs, RIM and BIN

[jackrubin]

I'm working on a "new" 8/E that came to me a few months ago. Yesterday, I ran through the acceptance MAINDECs but with a twist.

I'm testing an automatic bootloader from Malcolm Macleod, so no more toggling. The board is set up to load the RIM loader every time I toggle the SW switch on the front panel, making manual loading obsolete.

I also chose to work with the resources from Don North's website - http://www.ak6dn.com/PDP-8/MAINDEC/ - where he has gathered all the needed diagnostics and presents them in PAL, BIN and RIM format, along with the matching doc files and assembly listings. If you have ever chased binaries and docs across the internet, trying to find matching versions, you'll realize how much work Don has done (and saved you from doing). He also provides SIMH .ini and log files, so you can run the diagnostics in simulation and compare your results on your hardware.

Since Don provides RIM versions of all the diagnostics I wanted to run, I simply flipped SW and used my terminal emulator (GTTY) to load the requisite RIM format file. My first surprise was to find that nearly all the diagnostics started automatically, as soon as the download finished.

The only exception was D0FC, which loaded "normally" and halted the machine. I then entered 0200 into the address register and started with CONTINUE.

QUESTIONS - How did Don create all the RIM versions of the diagnostics, and did he add some magic ingredient to give them autostart capability? Did he bake in the BINLOADER? Do these autoloaded files do error checking?

Normally, the BIN format is preferable to the RIM format because it does rudimentary error checking (checksum) while the RIM loader just proceeds blindly.

QUESTION - All the diagnostics ran successfully except for the Adder Test - D0CC.rim. I was able to run it once to completion - after about 35 minutes, it halted and output the expected results to the screen but in several successive attempts, it just ran forever ("forever" here defined as more than one hour). Any thoughts?

Thanks, Don, for a great resource!

 

[AK6DN]

I started with matching .bin and .pdf docs that I scrounged from around the net, and used Robert Krten's 'd8tape' program that disassembles .bin files into .pal source.

To make the .rim versions autostart, I added the following snippet of code at the end of each .pal file before assembling it into the .rim version:

*7751                       / align to RIMLDR location
    0200                    / addr of program start
    KCC                     / first instr in std RIMLDR
    TAD .-1                 / get KCC instr
    DCA .+2                 / restore into RIMLDR
    JMP I .-4               / start program
    JMP .-3                 / overlay first word of RIMLDR

so that when you use RIMLDR (or in my case the RIMLDR for TTY burned into the M847 bootloader card) it will, on loading, patch the RIMLDR in core to autostart the diagnostic at 200 and restore the standard tty RIMLDR back to its virgin state.

The .bin files don't need this autostart capability because .bin files have that facility to provide the start address in the protocol.

Don

For D0FC, I don't notice the HALT. What address does your panel show when it HALTed? It might indicate a failing test.

 

[AK6DN]

I was going to go back and edit my previous PS message, but it seems now that editing is disabled after 15 minutes? Is this something new, have not had this warning before.

So ... Is the HALT repeatable, even when you do a full reload of the .rim? It could have been a load glitch, as you indicate there is no error checking in the .rim format as there is in the .bin format (which uses a simple block checksum).

 

[jackrubin]

Don,

Thanks for the explanation - I saw the self modifying code you pointed out but didn't really grasp the full functionality. Very clever.

I won't be able to get back to the machine for another week or so but when I do I'll rerun the D0CC and D0FC tests as both .bin and .rim versions and let you know the details.