• Please review our updated Terms and Rules here

RL02/RL01 simulator project is finished

Hello,
a revised and improved version V3.03 of my RL02/RL01 simulator is available
and can be downloaded from my homepage. Simultaneously drive copy operation
is now possible. This meens you can copy any cartridges to the SD-Card. It
also works with other RL based operating systems like RSX, RSTS OS-8 or VMS.
More details in the Readme.pdf file.
Wish you all a happy Easter, Reinhard
 
Folks,

After many hours of troubleshooting, I finally have Reinhard's RL02 running properly. Of course, the problem was perhaps some bad luck on my part, but I did ultimately troubleshoot it and correct it. I will describe my problem here so that others can deal with it if they see it when they build theirs.....

There are six signals that are sent from the RL11/RLV11/RLV21/RL8A (RL11 for simplicity going forward) to the RL02 drive. They're received at the drive end with TI 75107B line receivers. These line receivers have TTL totem pole outputs. Reinhard's device also uses these same line receivers. However, the DE0 Nano is a modern device, and it uses 3.3V logic. It does not have 5V tolerant inputs, and so one must take care and reduce any standard 5V TTL logic highs to 3.3V logic compatible voltage. Reinhard does this with a simple voltage divider (680 ohm / 1K), one for each of the six received lines. Reinhard cautions that one should have good grounds in his writeup, and of course standard practice is to put a 0.1uF cap between Vcc and ground at each IC. I guess I didn't quite understand the good ground part well enough......

When I built my wire-wrap board, I put each of the voltage dividers right next to the corresponding 75107s. The ground side of the voltage divider was 1/2" of wire away from the ground on the 75107. This might have been ok for lower frequency signals, but there is a 4.1Mhz system clock on one of the lines. It is a very "nice" clock with sharp corners (I am a mechanical engineer, but I understand Fourier analysis.) The write data line is on the next IC over, with its ground about 1" of wire away. I had all these grounds bussed together. As you can guess, the system clock polluted the write data. This is why I could read fine, but never write without corrupting the disk image.

So first I lifted the ground of the system clock voltage divider and ran a separate dedicated ground to it from where ground connects to the power supply (about 3" away). This however was not enough. After some thinking, I added some filtering at the voltage divider. A 18pf cap (smallest value I had in the capacitor assortment) across the 1K resistor makes for a high frequency low-pass filter (in conjunction with the upstream 680 ohm resistor) with a cutoff a bit above the 4.1Mhz clock. That did the trick!!

Although this took me about 15 minutes to type, I spent about 15 hours at the bench looking at everything and four hours reading. At least it was eductational.

Reinhard, and a friend of his Jonny, put their voltage dividers far away from the line receiver ICs. They also had separate grounds. They did not seem to need the filtering though. Perhaps there was enough stray capacitance in their wiring to be sufficient.

I hope someone else finds this helpful. I especially thank Reinhard and Jonny for their encouragement during my troubleshooting.

The emulator does work quite well. I have it on the bench on an RLV21 at the moment. The next step will be to again try it on the RL8A.

Here is a view looking across the bench. http://www.vintage-computer.com/vcforum/album.php?albumid=184&attachmentid=13016 At the far right is the trusty 465, then moving left is the qbus repair fixture (backplane screwed to a board) which has an 11/23 and MXV11-B2. The RLV21 is in a card extender sticking out of the backplane. The RL02 emulator is in the chassis with the wood sides. At the far left are two VT420s. One is the console terminal for the 11/23 and the other is the debug terminal for the RL02 emulator.

Lou
 
Last edited:
Lou - N2MIY said:
Folks,

...
Here is a view looking across the bench. http://www.vintage-computer.com/vcforum/album.php?albumid=184&attachmentid=13016 At the far right is the trusty 465, then moving left is the qbus repair fixture (backplane screwed to a board) which has an 11/23 and MXV11-B2. The RLV21 is in a card extender sticking out of the backplane. The RL02 emulator is in the chassis with the wood sides. At the far left are two VT420s. One is the console terminal for the 11/23 and the other is the debug terminal for the RL02 emulator.

Lou
Click to expand...

That's an interesting bench-top setup! I didn't know that you could side-by-side the M8186 and M7195 in that manner in slot 1 -- you've got the CPU over in CD and the Mem/SLU in AB. Is that a standard 9-slot backplane block? Which?

Would the opposite setup (CPU = A/B and Mem/SLU == CD) in slot 1 be equally viable?

Also, really nice card-frame on the Qbus -- where did that come from?

And (finally) what's that under your PSU?

-----
paul
 
Paul,

That's a non-dec backplane. It says it was made by CTI, but I have no information on the backplane or the company. No prints at all unfortunately. It came out of a 19" rack mout enclosure that was in really bad shape. Everything was in the enclosure to be some kind of BA23 clone (sans PMI busing). I kept the guts and mounted them to the board. I did replace the linear open frame power supplies with the babyAT supply in the photo. The box under power supply was part of the original system. It just had a power entry, power switch, and solid state relay inside.

The cards shown are actually in the second slot. The first slot does not work as expected. For some reason, the processor has to go in this slot to work properly. I've never bothered to trace out the backplane to see what's going on. I use this setup for board repair, so I've never put any more time into it.

I also leave an RQDX3 in this backplane and an RX50 is vertically in the back left corner. I can then boot XXDP off floppy for running diagnostics on the board under test.

For the present work, I wanted to scope signals on the RLV21 as well as on the RL emulator, which is why I had it in this backplane.

Lou
 
Last edited:
Thanks Lou. Last day at work tomorrow, then a month or so of honey-do jobs, but at least there's a light at the end of the tunnel. Now to see how many projects I can get under my belt before my mind and/or body fails. This emulator is near the top of the list. Really appreciate the work you have done to prove this out, and of course Reinhard's tremendous contribution to us all.

Jack
 
I did successfully make a bootable OS/8 pack image with the RL02 emulator! This was on the RL8A in my 8/e. I had to use RL2FMT.SV to format the "pack", then build and transfer the system head the usual way (under BUILD), then copy the rest of the files over. This is quite exciting since at some point it will make bulk file transfers much faster than Kermit or RX01 sneakernet.

Lou

Additional question after the original post above: Should I have expected RT-11 "COPY /DEVICE" to have been able to copy an OS/8 RL02 pack? When I tried to do that, it did not work (and not because the source and destination packs did not contain the operating system. I booted RT-11 from RX50, had the source OS/8 RL02 pack in one drive and the emulator as the other.) I think it's because the OS/8 RL02 handlers run the RL02 in 12-bit mode, while RT-11 uses 8/16 bits. Thoughts?
 
Last edited:
Thanks Lou. I was wondering about the boot set-up too. Makes more sense now! What's a good way to get XXDP onto a RX50-formatted floppy, like what you use here? I'm pretty much at the "hoist by own bootstraps" stage.
 
Paul,

Back a few years ago when I had nothing, I used Will's TU58.EXE TU58 PC emulator to boot a machine into XXDP off of a bootable TU58 tape image. Will's program includes a utility for copying or removing files from XXDP and RT-11 tape images. I was able to set up the device handlers I wanted on the tape image, so that I could CREATE (xxdp update program command) a bootable system on other (real) media.

You see though, this is the beautiful thing about Reinhard's emulator. If you build one (and have the RL controller in your 11) I could simply e-mail or FTP to you an entire XXDP pack image that you could mount and run straight away!

Lou
 
Last edited:
Fully agree with utility! Has anyone started inventorying/sharing RL-images?

What I can glean regarding existing RL01/02 controllers are:

Unibus : M7762 - RL11
QBus : M8013/14 CD-combo [RL01 only] - RLV11; M8061 - RLV12
Omnibus : M8433 [RL01 only] - RL8A

Is that correct?

Looking for critical mass here :->. Also, has anyone done the equivalent for the RK05?
 
Sorry to hear that RT-11 COPY/DEVICE didn't work for your OS/8 pack since this would have been a nice way to read/write OS/8 packs between image and disk on the 11 where SCSI resources are available (and where I have multiple RL02s available). Wonder if dd under BSD would work?

Either way, just a minor inconvenience compared to the pre-emulator environment.

Jack
 
Lou - N2MIY said:
Paul,

You see though, this is the beautiful thing about Reinhard's emulator. If you build one (and have the RL controller in your 11) I could simply e-mail or FTP to you an entire XXDP pack image that you could mount and run straight away!

Lou
Click to expand...

OK, I'm in. Now working on the parts-list. I see that you used a linear +-5v supply -- that I guess that you happened to have on-hand. Reinhard seems to have used a switching regulator for his -5v supply. I see a potted black module on his layout-photo, but no identifying information. Could anyone clue me in on the component being used (circuit diagram, parts) for the -5v supply?

Any other gotchas as regards the circuitry components/layout?

Who else has succeeded here?

I've never worked with a FPGA before, so a bit "anxious" ...

THX!

(and if you'd like to send me that XXDP image, I'd appreciate that :->)
 
pbirkel@gmail.com said:
OK, I'm in. Now working on the parts-list. I see that you used a linear +-5v supply -- that I guess that you happened to have on-hand. Reinhard seems to have used a switching regulator for his -5v supply. I see a potted black module on his layout-photo, but no identifying information. Could anyone clue me in on the component being used (circuit diagram, parts) for the -5v supply?

Any other gotchas as regards the circuitry components/layout?

Who else has succeeded here?

I've never worked with a FPGA before, so a bit "anxious" ...

THX!

(and if you'd like to send me that XXDP image, I'd appreciate that :->)
Click to expand...

Paul,

Glad to hear that you're going to build one. I too have never played with an FPGA. I don't do this work for a living, so since being a teenager, it has all been 7400 or 8031/8051 microcontrollers for me. I too have been nervous, but the last couple weeks I have spent getting the hang of Quartus II and understanding the very basics of how the Nios II processor interacts with the logic that is laid out in Quartus.

I have had to do this because I found a problem when it comes to copying from a disk pack to the emulator. The emulator holds the drive ready bus line true even when it (its drive number) is not addressed. This screws up writes to any other drives on the bus, since the controller in the 11 (or 8 ) expects to see drive ready drop during writes. So, all writes to the non-emulated disk always fail. I did let Reinhard know about that. It's trivially easy to fix, and I was going to do it with external 74XX logic, but then I realized - it's time to stop being ignorant about this stuff and move on past the 1980s!

So, that exercise taught me a lot so far. Adding the extra gates in Quartus II is not hard. It reminds me of LabView. However, be advised that the editable code in Reinhard's distribution has a switch thrown in Qsys for the Nios II processor to boot from RAM rather than the EPCS (serial flash device). So, to run on the FPGA after editing, the code (.SOF for the FPGA and .ELF code run to run on the Nios processor) needs to be uploaded to RAM. After all bugs have been worked out, the last step should be to recompile a flashable version, but the switch has to be thrown in Qsys to then boot the Nios processor from the code in the EPCS rather than RAM.

So far, I envision what is going on in this FPGA this way: The FPGA is a huge programmable gate array. Quartus allows you to configure the gate array. That is stored in the .SOF file. The array is so huge, a microprocessor can be defined, and still leave lots of space for your logic. The microprocessor in this case is Altera's canned Nios II processor. The Nios II development environment runs on your PC and allows you to compile C/C++ code which ultimately will run on the Nios II processor in the FPGA. That code is in the .ELF file. Qsys is the bridge between the Nios II processor and the logic laid out in Quartus II. It configures the passing of signals between the two and sets the basic operation of the Nios II processor (for example, where it should look to find its bootstrap on startup). The DE0-Nano has a flash memory from which the configuration of the gate array and Nios II program are loaded on powerup. That information can also be loaded into RAM that exists on the FPGA also, but it is volatile. So, for troubleshooting on the bench, it's easiest to make tweaks and load into RAM, than it is to program the flash memory and reastart (there are extra steps to prepare the files for flashing.)

The heart of this project is in a big program that is running on the Nios II processor. The logic you will see in Quartus II handles other critical tasks in paralell with the processor, as well as providing the interface to the outside world. With this introduction, hopefully it's a little easier to digest now. If anyone else here can correct or elaborate on what I wrote above, it would be helpful. This is what I managed to come up with on my own.

As for your original power supply comments, well, for something this small, of course I made my own linear supply (again what I had done since being a teenager.) Since we only need +/-5V, I used a little RadioShack 6.3-0-6.3V center tapped transformer, little bridge rectifier, and 7805/7905 with filtering where appropriate. That's all cheaper and smaller than buying anything. The only thing I didn't already have on hand was the transformer. So if you go this route, the schematic is simple since the 7905 circuit (-5V) is largely a mirror image of the 7805 (+5V) side. If you've never used a 7905 before, do read the data sheet. The tab on the TO220 case is not ground (and so I have it insulated from my chassis) and the pinout is different.

Until I put this all back together and flash the EPCS with the corrected code, I won't be making that XXDP pack image. However I should have it before you're ready for it :).

This weekend I wanted to spend some time in the workshop, so I made the front panel for the enclosure. Here is the photo so far (no labeling) : http://www.vintage-computer.com/vcforum/album.php?albumid=184&attachmentid=13697 . In Quartus II, there is a tool called the pin planner, where you assign signals to the FPGA pins. On the DE0-Nano, many of the FPGA pins are brought out to the two 40 pin header connectors. The GPIO1 header is largely unused, and so I will bring the front panel status leds, drive select switch, and reset button controls to unused pins on GPIO1 instead of the on-board leds and switches. I have not actually done it in the pin planner, but I see how and wanted to have the hardware prepared in advance. I also have my SD card slot affair also mounted to the front panel, along with a power switch.

So far, I know that Reinhard and his friend Jonny have built these and that theirs work (but they must have the same bug I mentioned above.) I too would really like to know who else has one or is working on one. So far, you and Jack are the only others I know of....

Lou
 
Last edited:
I have made some good progress. I was able to change the appropriate option in the CPU setting in Qsys and regenerate the Qsys file called by the Quartus II so that the Nios II processor would boot from the EPCS. I was also able to create additional outputs and map the pins to bring the status signals out to my front panel LEDs (I also left the existing ones on the DE0-Nano board to light also). Finally I flashed this (.SOF and .ELF) all in the EPCS and it worked!

At this point, I still need to test my logic for the drive ready problem (my first attempt is now flashed and ready to try). Then lastly I need to wire up my drive select switch and reset button. I was hesitant to do that last part until I was sure I could flash the updated pin planner data and have it stick. One has to be careful that input pins are set up properly to be inputs or else they will be destroyed. So I needed to be sure that the FPGA gets configured right away on power up to expect the voltages that will be present on the input pins. I can assure that now.

I am starting to realize how amazing these FPGAs are. I think I need to get another DE0-Nano for messing around with for my own designs.

Lou
 
Hello,
After 2 months, I'm back. There were personal reasons and I was not able to continue working on this project. Sorry.
Lou, thank you for all your information. I'm still a little surprised why the designes worked so different.
There are probably boundary conditions in the interface converting TTL to the FPGA world and grounding is still a very
important issue. I will work on the following 3 points and every note of you is very welcome.
1) Preformance problem : At this point PIO's are still used for data transfere from NIOSII to/from DPR. I changed already the
QSYS configuration to get direct access to the DPR using memcpy. Read works fine, but Write does not work at all. I still have
no idea what the reason is for this symtom. Looks like, I make a field test because I can't find any information/references.
2) Write MFM-Decoder: The schematics code will be replaced by verilog code which I did already in my MFM/SD-Disk simulator.
I have 2 working interface an one non-working interface from Jonny. He also used the TTL-converter chip instead my designed
resistor network but the signal edges will be changed and I hope to be able to implement signal-re-adjustment which is basically
very simple within verylog. 3) Clone-Mode: to be able to copy 1:1 every cartridges, a clone mode is required. The
necessary, optional signals are already available. The main effort here is to re-write the whole C-Program. Reinhard
 
Lou - N2MIY said:
I have had to do this because I found a problem when it comes to copying from a disk pack to the emulator. The emulator holds the drive ready bus line true even when it (its drive number) is not addressed. This screws up writes to any other drives on the bus, since the controller in the 11 (or 8 ) expects to see drive ready drop during writes. So, all writes to the non-emulated disk always fail. I did let Reinhard know about that. It's trivially easy to fix, and I was going to do it with external 74XX logic, but then I realized - it's time to stop being ignorant about this stuff and move on past the 1980s!
Lou
Click to expand...

Definitely would like to see the emulator able to live on the same string as a live-drive. I don't have one, but I'm working on it :->. I do have both Unibus and Qbus controllers, but no cabling.

Lou - N2MIY said:
As for your original power supply comments, well, for something this small, of course I made my own linear supply (again what I had done since being a teenager.) Since we only need +/-5V, I used a little RadioShack 6.3-0-6.3V center tapped transformer, little bridge rectifier, and 7805/7905 with filtering where appropriate. That's all cheaper and smaller than buying anything. The only thing I didn't already have on hand was the transformer. So if you go this route, the schematic is simple since the 7905 circuit (-5V) is largely a mirror image of the 7805 (+5V) side. If you've never used a 7905 before, do read the data sheet. The tab on the TO220 case is not ground (and so I have it insulated from my chassis) and the pinout is different.
Lou
Click to expand...

My use case is a bit different since I don't have a dead-RL02 to sacrifice for ZIF-cable-connectors in order to build an outboard box. Instead I'm thinking of mounting the assembly on a dual-height (and necessarily "dual-thickness" because of the piggybacked DE-0) card that I can plug into CD and then over-the-top a ribbon cable directly to the controller. Depending on what sort of Q-card I sacrifice I'll pull +5 either directly or via an additional cable. While the Qbus specifies AB2/BB2 as -12v (and I think also CB2/DB2), AFAIK DEC never powered that line. So I can't just use a 7905. I need to follow the approach apparently used by Reinhard -- which seems to be a RECOM Module, either the RB-0505D (+-5v, 100mA) or RD-0505D (+-5v, 200mA). The result would be a bit like your bench setup. Not convenient for changing the "disk pack", but I can live with that. I'll need to work out how to get it to simply power-up in the correct configuration for immediate use (e.g., boot). Or I could bring out some buttons via a header to an off-card control "head".

Unibus has basically the same considerations, although I'd use a modified Unibus A/B slot. Although the DD11 holding the memory usually has a -15v rail, normal DD11 do not as that's not part of the spec, so the logical place to put this card would be A/B in/over modified Unibus slots (center two in a 4-row block). Omnibus generally in the same situation, but very different power-rail setup ... so the best solution is either design to draw power over-the-top, or set up a few jumpers for the correct +5/GND pins depending on bus and slot (and possibly some low-drop diodes to preclude mishaps; the RECON modules are spec'd to work down to 4.5v). But I don't actually have an Omnibus controller so supporting it isn't exactly a high priority ...

I haven't checked out form-factor issues but it looks like a double-width card should have ample real estate on it (~5" x 7.5"). The DE-2 appears to be only 2" x 3". Can you share some basic dimensional information for layout planning?

Finally, best would be to set up the board to work as the first device on the RL02 cable-string so that I could then attach the real RL02, or not (substituting a ribbon-based terminator), through normal cabling (ribbon, bulkhead, round-with-ZIF-connectors).

Anyone care to comment?
 
Last edited:
Reinhard,

My trouble with Item 2 was obviously my poor layout, but I resolved that. Item 3 sounds interesting, but unfortunately I did not include any spare line drivers so that the DE0-Nano could tell the real RL02 what to do. I didn't even leave room for them either.

Last night, I tried out my logic to solve the drive ready problem and it worked. I had both setups where the emulator was 0 and the RL02 was 1 and vice-versa. Both could be written to with no problem. So that is solved. It was trivially simple and involved two separate four input AND gates, whoose outputs were ORed to drive the drive ready line (one gate goes true when the emulator is drive 0 and ready, the other is true when the emulator is drive 1 and ready.) The four inputs were the emulator drive select switch, the drive bus select 0 line, drive bus select 1 line, and drive ready output from existing logic in the emulator. Inverters were used on the drive select switch and drive select 0 lines for one of the AND gates. I will make a sketch and post it later.

My last step will be to connect the front panel reset button and drive select switch and then we are done. The time required to copy the disk image to and from SD card is not an issue.

Paul,

Your desired setup will work fine. Although I have been using proper dec RL drive cables, there was a while that I was using 40 pin ribbon cable to go directly from the RLV12 to the line driver/line receiver board. That does work fine. I think Ray here actually uses such cable also between between his machine and his RL02 drives on one of his qbus systems.

Since I knew I would be using this device on various systems, I wanted something in it's own robust case. I do feel a bit guilty about stealing the drive interconnect connectors off the back of an old RL01, but until I find a new set of heads for that RL01, it's down. I had two RL01 drives and built one good one after stealing a head from the other.

The idea of fitting the whole works inside the card cage is a great one. It will make for a very compact system. The RECOM devices you speak of must be DC/DC converters. I think with some planning, the whole works could fit on a dual height, dual width card (don't remember the Douglas part number). It would be tight. If you can afford the space of a quad width card, it would certainly all fit.

Lou
 
Last edited:
Reinhard,

I am only noticing now for the first time the problem you described in item 1 in your last message. I was trying to copy a pack from a real drive to the simulator. The image on the simulator was the one you supplied with the distribution. When I do a bad block check on that image, after loading into ram, there are no bad blocks. However, if I shut the system down and write the image from ram back to the SD card, there are bad blocks created when I reload.

I tried another, simpler experiment. I used the emulator's utility to create a blank pack image and write it to the card. When I initialize that image in RT-11 and do a bad block check, there are no bad blocks. But again, if I shut the system down and write that image back to the SD card, there are also bad blocks created when I reload.

It is intersting that the utility that writes a blank pack image to the card does not write bad blocks, but the portion of the emulator that writes the image back to the SD card writes bad blocks.

To be sure that I did not cause this problem with my modifications to support the front panel and correct the drive ready problem, I reflashed with your V3.03 as released and still had the same trouble. I also tried a different SD card with no difference.

I suppose I should wait until V3.04 at this point.

Lou
 
RL02 .DEC Container file utilities for use with PUTR

RL02 .DEC Container file utilities for use with PUTR

Folks,

I have written two useful utilities for working with the .DEC RL02 container files for the emulator. One, that I called DEC2PUT.BAS takes the .DEC container file, and strips out only the block data and creates a file suitable for working with under PUTR. The second, PUT2DEC.BAS was a bit more work and takes a PUTR file and puts back all the important stuff to rebuild each sector as it appears in the .DEC file.

This second operation involves rebuilding the header preamble, address, checksum, and postamble as well as the data preamble, checksum,and postamble. Studying the RL11 prints, the checksum is CRC-16 as generated by a Fairchild 9401. I too used a lookup table based CRC-16 checksum generator. I also had to create a good replacement block table track for the last track on the disk. Most PUTR RL02 images don't include that.

I did this in M$ QBASIC. The one that came with DOS works fine under modern Windows. I did the development on my Hinote Ultra 2000 running Win95, and then later tried it under XP. Modern windows doesn't come with QBASIC anymore, so you'll have to copy it out of your old DOS machine. Lastly, please bear in mind that this code was written by a mechanical engineer. If you don't like it, then you can rewrite it in something else that will run faster and it will make us all happy. The PUT2DEC takes a few minutes on the Hinote, but took only about a minute on the modern Pentium 4.

This has been tested under RT-11 so far. My next test will be to take an XXDP RL02 PUTR image and make the .DEC. OS/8 testing will come after that. I have never seen an OS/8 RL02 pack image anywhere, let alone used with PUTR.

Needless to say, it has taken a good bit of research and debugging to get to what I thought was worth putting out there. I have been working on this in my spare time for about the last three weeks.

First DEC2PUT.BAS:

Code: 
10 REM *** DEC2PUT.BAS
15 REM *** LOU-N2MIY - JUNE 2013
20 REM
25 REM *** THIS PROGRAM READS IN RL02 PACK IMAGES FORMATTED FOR USE IN
30 REM *** REINHARD HEUBERGER'S RL02 SIMULATOR AND CONVERTS THEM TO
35 REM *** THE FORMAT USED BY THE PUTR PROGRAM.
40 REM
45 REM *** THE PUTR FORMAT IS BLOCK 0-39, HEAD 0-1, CYLINDER 0-511 ORDER
50 REM *** WITH 256 BYTE BLOCKS IN SEQUENCE (THE DATA PORTION OF AN RL02
55 REM *** PACK ONLY) WHILE .DEC IS SIMILAR TO THE BYTES ON A REAL PACK
60 REM *** INCLUDING FORMATTING AND CHECKSUMS)
65 REM
70 REM *** THIS PROGRAM STARTS WITH A .DEC IMAGE AND COPIES OUT THE BLOCK
75 REM *** DATA ONLY AND PASTES IT SEQUENTIALLY INTO A NEW FILE IN PUTR
80 REM *** FORMAT BLOCK ORDER. THE LAST TRACK ON AN RL02 IS USED FOR THE
85 REM *** BAD SECTOR FILE. PUTR IMAGES DO NOT USUALLY CONTAIN THIS TRACK.
90 REM *** BUT WE KEEP IT HERE BECAUSE THERE IS NO HARM IN DOING SO.
95 REM

100 REM *** VARIABLE DECLARATIONS
110 DIM BIN AS STRING * 288
120 DIM BOUT AS STRING * 256

200 REM *** MAIN PROGRAM
205 CLS
210 PRINT ".DEC RL02 IMAGE FILENAME TO BE CONVERTED? (XXXXXXXX.DEC)"
220 INPUT F$
230 OPEN F$ + ".DEC" FOR BINARY AS #1
240 OPEN F$ + ".RL2" FOR BINARY AS #2
250 PRINT "RUNNING"

300 REM *** READ BLOCKS FROM INPUT FILE
305 FOR CYLINDER = 1 TO 512
310 FOR HEAD = 1 TO 2
320 FOR BLOCK = 1 TO 40
330 LET RECORD& = (((CYLINDER - 1) * 80) + ((HEAD - 1) * 40) + BLOCK) * 288 - 287
340 GET #1, RECORD&, BIN

500 REM *** WRITE BLOCK TO OUTPUT FILE
510 LET BOUT = MID$(BIN, 19, 256)
520 LET RECORD& = (((CYLINDER - 1) * 80) + ((HEAD - 1) * 40) + BLOCK) * 256 - 255
530 PUT #2, RECORD&, BOUT
540 IF HEAD = 1 AND BLOCK = 1 THEN PRINT "PROCESSING CYLINDER:"; CYLINDER - 1

900 REM *** LOOP UNTIL EVERY BLOCK IS PROCESSED
910 NEXT BLOCK
930 NEXT HEAD
960 NEXT CYLINDER
990 CLOSE #1
995 CLOSE #2
999 PRINT "COMPLETE"
1000 END


Second PUT2DEC.BAS

Code: 
10 REM *** PUT2DEC.BAS
15 REM *** LOU-N2MIY - JUNE 2013
20 REM
25 REM *** THIS PROGRAM READS IN RL02 PACK IMAGES FORMATTED FOR USE IN
30 REM *** THE PUTR.EXE PROGRAM AND CONVERTS THEM TO REINHARD HEUBERGER'S
35 REM *** .DEC FORMAT USED BY HIS RL02 SIMULATOR.
40 REM
45 REM *** THE PUTR FORMAT IS BLOCK 0-39, HEAD 0-1, CYLINDER 0-511 ORDER
50 REM *** WITH 256 BYTE BLOCKS IN SEQUENCE (THE DATA PORTION OF AN RL02
55 REM *** PACK ONLY) WHILE .DEC IS SIMILAR TO A REAL RL02 PACK (INCLUDING
60 REM *** FORMATTING AND CHECKSUMS)
65 REM
70 REM *** THIS PROGRAM TAKES THE BLOCK DATA AND CREATES THE SECTOR HEADER
75 REM *** BEFORE THE DATA AND THE BLOCK DATA CHECKSUM FOR AFTER. THE LAST
77 REM *** TRACK (BAD BLOCK RECORD) IS A FAKE TO SATISFY THE RLO2 EMUATOR.
80 REM *** THE INPUT IS A .RL2 FILE AND THE OUTPUT IS A .DEC FILE. THE
85 REM *** INPUT FILENAME IS KEYED IN AT THE BEGINNING OF EXECUTION.
90 REM
95 REM

100 REM *** VARIABLE DECLARATIONS
110 DIM BIN AS STRING * 256
112 DIM BOUT AS STRING * 288
114 DIM LBL(0 TO 255)
116 DIM LBH(0 TO 255)
118 DIM SDCL AS STRING * 1
120 DIM SDCH AS STRING * 1
122 DIM SDC AS STRING * 2
124 DIM SLSA AS STRING * 1
126 DIM SMSA AS STRING * 1
128 DIM SA AS STRING * 4
130 DIM SHP AS STRING * 12
132 DIM SDP AS STRING * 276
134 DIM SHCL AS STRING * 1
136 DIM SHCH AS STRING * 1
138 DIM SHC AS STRING * 2
140 DIM ONES AS STRING * 256
144 LET ONES = CHR$(&H3) + CHR$(&H28) + CHR$(&H54) + CHR$(&H19) + STRING$(4, 0) + STRING$(248, 255)

150 REM *** LOAD CHECKSUM CALCULATION CONSTANTS
155 FOR L = 0 TO 255
160 READ LBL(L)
165 NEXT L
170 FOR L = 0 TO 255
175 READ LBH(L)
180 NEXT L

200 REM *** MAIN PROGRAM
210 PRINT "PUTR RL02 IMAGE FILENAME TO BE CONVERTED? (XXXXXXXX.RL2)"
220 INPUT F$
230 OPEN F$ + ".RL2" FOR BINARY AS #1
240 OPEN F$ + ".DEC" FOR BINARY AS #2
250 PRINT "RUNNING"

300 REM *** READ BLOCKS FROM INPUT FILE
305 FOR CYLINDER = 1 TO 512
310 FOR HEAD = 1 TO 2
320 FOR BLOCK = 1 TO 40
330 LET RECORD& = (((CYLINDER - 1) * 80) + ((HEAD - 1) * 40) + BLOCK) * 256 - 255
340 IF (CYLINDER + HEAD) = 514 THEN LET BIN = ONES ELSE GET #1, RECORD&, BIN

400 REM *** CALCULATE BLOCK DATA CHECKSUM (CRC-16 LUT METHOD)
405 LET DCL = 0
410 LET DCH = 0
420 FOR BN = 1 TO 256
430 LET BD = ASC(MID$(BIN, BN, 1))
440 LET BT = BD XOR DCL
450 LET DCL = LBL(BT) XOR DCH
460 LET DCH = LBH(BT)
470 NEXT BN
475 LET SDCL = CHR$(DCL)
480 LET SDCH = CHR$(DCH)
485 LET SDC = SDCL + SDCH

500 REM *** CALCULATE ADDRESS WORD
510 LET MSA = (CYLINDER - 1) \ 2
515 LET CYLSB = 128 * ((CYLINDER - 1) AND 1)
520 LET HB = (HEAD - 1) * 64
525 LET LSA = CYLSB + HB + (BLOCK - 1)
530 LET SMSA = CHR$(MSA)
535 LET SLSA = CHR$(LSA)
540 LET SA = SLSA + SMSA + CHR$(0) + CHR$(0)

600 REM *** CALCULATE ADDRESS CHECKSUM (CRC-16 LUT METHOD)
605 LET HCL = 0
610 LET HCH = 0
620 FOR BN = 1 TO 4
630 LET BD = ASC(MID$(SA, BN, 1))
640 LET BT = BD XOR HCL
650 LET HCL = LBL(BT) XOR HCH
660 LET HCH = LBH(BT)
670 NEXT BN
675 LET SHCL = CHR$(HCL)
680 LET SHCH = CHR$(HCH)
685 LET SHC = SHCL + SHCH

700 REM *** ASSEMBLE SECTOR HEADER PORTION (12 BYTES)
710 REM *** 00 00 00 80 [SA] [SHC] 00 00
720 LET SHP = CHR$(0) + CHR$(0) + CHR$(0) + CHR$(128) + SA + SHC + CHR$(0) + CHR$(0)

750 REM *** ASSEMBLE SECTOR DATA PORTION (276 BYTES)
760 REM *** 00 00 00 80 [BIN] [SDC] 00 00 00 00 00 00 00 00 00 00 00 00
770 LET SDP = CHR$(0) + CHR$(0) + CHR$(0) + CHR$(0) + CHR$(0) + CHR$(128) + BIN + SDC + CHR$(0) + CHR$(0) + CHR$(0) + CHR$(0) + CHR$(0) + CHR$(0) + CHR$(0) + CHR$(0) + CHR$(0) + CHR$(0) + CHR$(0) + CHR$(0)

800 REM *** ASSEMBLE AND WRITE COMPLETE SECTOR CONTENTS TO OUTPUT FILE
810 LET BOUT = SHP + SDP
830 LET RECORD& = (((CYLINDER - 1) * 80) + ((HEAD - 1) * 40) + BLOCK) * 288 - 287
840 PUT #2, RECORD&, BOUT
850 IF BLOCK = 1 AND HEAD = 1 THEN PRINT "PROCESSING CYLINDER: "; CYLINDER - 1

900 REM *** LOOP UNTIL EVERY BLOCK IS PROCESSED
910 NEXT BLOCK
930 NEXT HEAD
960 NEXT CYLINDER
990 CLOSE #1
995 CLOSE #2
999 PRINT "COMPLETE"
1000 END


20000 REM *** LOW BYTE DATA LOOKUP TABLE
20010 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20020 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20030 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20040 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20050 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20060 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20070 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20080 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20090 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20100 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20110 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20120 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20130 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20140 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20150 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20160 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20170 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20180 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20190 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20200 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20210 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20220 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20230 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20240 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20250 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20260 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20270 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20280 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20290 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40
20300 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20310 DATA &H00,&HC1,&H81,&H40,&H01,&HC0,&H80,&H41
20320 DATA &H01,&HC0,&H80,&H41,&H00,&HC1,&H81,&H40

20500 REM *** HIGH BYTE DATA LOOKUP TABLE
20510 DATA &H00,&HC0,&HC1,&H01,&HC3,&H03,&H02,&HC2
20520 DATA &HC6,&H06,&H07,&HC7,&H05,&HC5,&HC4,&H04
20530 DATA &HCC,&H0C,&H0D,&HCD,&H0F,&HCF,&HCE,&H0E
20540 DATA &H0A,&HCA,&HCB,&H0B,&HC9,&H09,&H08,&HC8
20550 DATA &HD8,&H18,&H19,&HD9,&H1B,&HDB,&HDA,&H1A
20560 DATA &H1E,&HDE,&HDF,&H1F,&HDD,&H1D,&H1C,&HDC
20570 DATA &H14,&HD4,&HD5,&H15,&HD7,&H17,&H16,&HD6
20580 DATA &HD2,&H12,&H13,&HD3,&H11,&HD1,&HD0,&H10
20590 DATA &HF0,&H30,&H31,&HF1,&H33,&HF3,&HF2,&H32
20600 DATA &H36,&HF6,&HF7,&H37,&HF5,&H35,&H34,&HF4
20610 DATA &H3C,&HFC,&HFD,&H3D,&HFF,&H3F,&H3E,&HFE
20620 DATA &HFA,&H3A,&H3B,&HFB,&H39,&HF9,&HF8,&H38
20630 DATA &H28,&HE8,&HE9,&H29,&HEB,&H2B,&H2A,&HEA
20640 DATA &HEE,&H2E,&H2F,&HEF,&H2D,&HED,&HEC,&H2C
20650 DATA &HE4,&H24,&H25,&HE5,&H27,&HE7,&HE6,&H26
20660 DATA &H22,&HE2,&HE3,&H23,&HE1,&H21,&H20,&HE0
20670 DATA &HA0,&H60,&H61,&HA1,&H63,&HA3,&HA2,&H62
20680 DATA &H66,&HA6,&HA7,&H67,&HA5,&H65,&H64,&HA4
20690 DATA &H6C,&HAC,&HAD,&H6D,&HAF,&H6F,&H6E,&HAE
20700 DATA &HAA,&H6A,&H6B,&HAB,&H69,&HA9,&HA8,&H68
20710 DATA &H78,&HB8,&HB9,&H79,&HBB,&H7B,&H7A,&HBA
20720 DATA &HBE,&H7E,&H7F,&HBF,&H7D,&HBD,&HBC,&H7C
20730 DATA &HB4,&H74,&H75,&HB5,&H77,&HB7,&HB6,&H76
20740 DATA &H72,&HB2,&HB3,&H73,&HB1,&H71,&H70,&HB0
20750 DATA &H50,&H90,&H91,&H51,&H93,&H53,&H52,&H92
20760 DATA &H96,&H56,&H57,&H97,&H55,&H95,&H94,&H54
20770 DATA &H9C,&H5C,&H5D,&H9D,&H5F,&H9F,&H9E,&H5E
20780 DATA &H5A,&H9A,&H9B,&H5B,&H99,&H59,&H58,&H98
20790 DATA &H88,&H48,&H49,&H89,&H4B,&H8B,&H8A,&H4A
20800 DATA &H4E,&H8E,&H8F,&H4F,&H8D,&H4D,&H4C,&H8C
20810 DATA &H44,&H84,&H85,&H45,&H87,&H47,&H46,&H86
20820 DATA &H82,&H42,&H43,&H83,&H41,&H81,&H80,&H40

More to come.....

Lou
 
Last edited:
Folks,

Good news. I took the XXDP V2.5 RL02 PUTR pack image, and used PUT2DEC and it booted right up and worked perfectly under the simulator!! This is what I really wanted when I heard about this simulator. I wanted to have a full RL02 XXDP pack. It would have taken forever to transfer the entire distribution via TU58 or RX01/50/33. Now it took only minutes. Paul, I'm ready to send you the XXDP .DEC file whenever you're ready!

I will spend some time working on the problem I mentioned a few posts back before I try OS/8.

Here are some photos of how the front panel turned out and of the finished unit:
http://www.vintage-computer.com/vcforum/album.php?albumid=184&attachmentid=14133
http://www.vintage-computer.com/vcforum/album.php?albumid=184&attachmentid=14132

The bottom left switch is the power. The switch on the right is drive select 0 or 1. The button is the reset button that triggers the write from ram back to SD or restarts. The six leds are (L to R) two yellow leds as the status bits, two green leds as unit selected and the sector pulse, two red leds as head move / read and write. This is the same L to R order as the status bits on the DE0 Nano, which still light. The SD card slot is obvious.


Lou
 
Last edited:
You must log in or register to reply here.
Back
Top