• Please review our updated Terms and Rules here

Problems booting PDP-11 through tu58 emulator

daver2 said:
I have found out that Don's website doesn't have them.

Dave
Click to expand...
It does, but they are contained within TU58 (or RX02) XXDP .DSK images files.
One could use my xxdpdir.pl program to extract all the files from an XXDP image (available here: https://github.com/AK6DN/xxdpdir
I use that program to extract all the files from the RL02 distribution media and then to build them into custom XXDP TU58 bootable disk images.
For reference I have attached a .zip of all the individual files on the DEC XXDP_v25 RL02 disk distribution images. Basically a whole lot of .BIN/.BIC file images.
It is from these files I build the various .DSK image files on my website.

You might also want to look here: http://www.bitsavers.org/pdf/dec/pdp11/xxdp/
And in particular grab this file: http://www.bitsavers.org/pdf/dec/pdp11/xxdp/PDP11_DiagnosticHandbook_1988.pdf
if you don't already have it.
 

Attachments

  • XXDP_v25_rl02.zip
    4.1 MB · Views: 3
Last edited:
AK6DN said:
It does, but they are contained within TU58 (or RX02) XXDP .DSK images files.
One could use my xxdpdir.pl program to extract all the files from an XXDP image (available here: https://github.com/AK6DN/xxdpdir
I use that program to extract all the files from the RL02 distribution media and then to build them into custom XXDP TU58 bootable disk images.
For reference I have attached a .zip of all the individual files on the DEC XXDP_v25 RL02 disk distribution images. Basically a whole lot of .BIN/.BIC file images.
Click to expand...
Thank you so much, this will be of much help
 
So unfortunately I havent been able to load binary files from pdp11gui since using the memory loader program just crashes the application. But I've done some more testing to rule out potential breakpoints.
  • Tried diane's bootloader with an halt instead of the final jump to have a chance to lookup at memory and the errors were in the exact same spot.
  • Tried switching back to the M8043 for the SLU but exactly same behaviour.
  • Tried disabling the cache with no difference
  • Tried switching usb to rs232 adapter but the errors are the same.
Then I tried loading some different test files through the tu58 emulator instead of a real image
  • An empty file (only 000000) and that loaded without any bit flips (as far as I can tell)
  • A 'full' file (only 177777) and that loaded without any bit flips (as far as I can tell)
This is even more confusing -_-
 
>>> This is even more confusing

Well, not really, you are (after all) using one (1) test pattern, either all '0's or all '1's...

Try 512 bytes of 'randomish' data to boot.

If the problem is an address line fault, then writing the same pattern into all of the memory addresses will tell you nothing. Writing 0 into the first byte, 1 into the second byte and so one would corrupt an earlier byte.

This happened on an 11/83 of mine. One of the address lines from the CPU to the backplane was damaged. Fortunately, the 11/83 POST spotted the RAM error. The clincher was when I replaced the large memory board with a small one, and a MAP resulted in two distinct memory areas found that were the same physical memory. This pointed me at the address line that was faulty and to the broken track (that was subsequently repaired).

Try writing unique word values to powers of 2 addresses: 0=0, 2=2, 4=4, 10=10, 20=20, ...

Obviously, all of the values are in octal...

Then look at what is now stored in the memory addresses that you originally wrote to, to see if the value is the same or has changed. If the value has changed, does it match a later value that was written or not?

Beware about bytes and words though...

Dave
 
daver2 said:
>>> This is even more confusing

Well, not really, you are (after all) using one (1) test pattern, either all '0's or all '1's...

Try 512 bytes of 'randomish' data to boot.

If the problem is an address line fault, then writing the same pattern into all of the memory addresses will tell you nothing. Writing 0 into the first byte, 1 into the second byte and so one would corrupt an earlier byte.

This happened on an 11/83 of mine. One of the address lines from the CPU to the backplane was damaged. Fortunately, the 11/83 POST spotted the RAM error. The clincher was when I replaced the large memory board with a small one, and a MAP resulted in two distinct memory areas found that were the same physical memory. This pointed me at the address line that was faulty and to the broken track (that was subsequently repaired).

Try writing unique word values to powers of 2 addresses: 0=0, 2=2, 4=4, 10=10, 20=20, ...

Obviously, all of the values are in octal...

Then look at what is now stored in the memory addresses that you originally wrote to, to see if the value is the same or has changed. If the value has changed, does it match a later value that was written or not?

Beware about bytes and words though...

Dave
Click to expand...
Thank you I'll check for that, I'll find a way to make a file like that, I just need the first 512 bytes anyway.
To rule out some more things I tried switching the initial memory pointer from 0000 to 0002 and the errors (at least the initial ones) moved with the pointer. So for example when I used the starting addres 0000 I had a 0004 at address 0030 when I was supposed to have 0000 and moving the starting address the error moved to 0032. Wouldnt this rule out a bad address line?
 
>>> Wouldnt this rule out a bad address line?

Nope. It reinforces some sort of address fault.

Just use ODT to write the values and then read them back. Go simple...

Dave
 
daver2 said:
>>> Wouldnt this rule out a bad address line?

Nope. It reinforces some sort of address fault.

Just use ODT to write the values and then read them back. Go simple...

Dave
Click to expand...
Oh I see. Tried changing the same addresses where the error occurred but I was able to write the correct value (with caching disabled in theory)
 
Yes, but you need to write unique data values to ALL of the 512 bytes that could be affected.

And then dump the values back again to see what has changed (if anything).

Dave
 
daver2 said:
Yes, but you need to write unique data values to ALL of the 512 bytes that could be affected.

And then dump the values back again to see what has changed (if anything).

Dave
Click to expand...

Just did that, this is the result. Looks like everything is correct

1708347328518.png
 
daver2 said:
Ok, so that doesn't look like the problem...

More thinking required...

Dave
Click to expand...
Yeah, that's unfortunate... Tried doing some more tests skipping some memory cells but it worked just as fine

Ok so the errors in the memory locations changes depending on the data that is transmitted after it. I've tried sending the disk image setting to 0x00 increasingly more values at the start of the file and errors in the first couple of bytes changes with these modifications...

For example:
1708349815379.png
1708349826979.png
 
Last edited:
Another update, I'm kinda understanding this error now. I tried doing some testing with a python script and I finally tracked down when a bit flip would occur.
Basically when you write a value in ram at address (1XX) the third bit of the value gets written to (0XX) too (and vice versa). This also happens with addresses such as (3xx) <--> (2XX) and (13XX) <--> (12XX). But for some reason it wont work with (2XX) <--> (1XX). I was able to reproduce this behaviour through ODT with caching disabled so It's not an algorithmic problem (nor a cpu problem in my opinion).

I think there are two possibilities:
  • A failure in the control circuitry of the RAM board
  • A failure of the RAM IC itself
To me the second one would make more sense since it's basically ignoring the 7th bit of the address and writing/reading the same value disregarding that address bit.

I was setting up a logic analyzer to settle down the doubt but while I was doing that some smoke got out of the machine... I couldnt trace down where the smoke came from but when I briefly turned on the machine back again the correct LED on the cpu board light up but I didnt get an ODT propmt, I hope it's just a failure in the SLU card, I'll setup the 4 lines SLU next and use that for console operation once and for all.

One step forward and two backwards...
 
1709142660395.png

It's finally done! After something like two months and a half since getting all the parts together (and starting this thread) I can finally boot into a tape!!! I want to thank you everyone from this forum that helped me with this repair and journey getting to know the pdp-11. A special thanks to @daver2 who was always ready to help me and was of invaluable help!

In the end I had the idea to test if the bit flip would also occur in the upper memory bank, and it didnt, pinning it down to the RAM IC. I decided to disable the upper memory bank and borrow one of the ICs from there in order not to wait for delivery, installed a socket and get it running. Unfortunately neither the tu58 manual's bootstrap nor mine worked, but diane's bootstrap code worked perfectly and produced the output that you can see in the attached image.

I still have some work to do, I plan on creating a bootable RT11 tape to try out and other projects, such as restoring and connecting this paper tape reader (and a puncher in the future) to my pdp11, as well as a custom made rack mounted case, front panel, etc.

GHWlR39XEAAl1LP


Thank you again to everyone that helped!
 
You must log in or register to reply here.
Back
Top