Need help with TU58 emulator
geezer
pack for my RL02 equipped 11/44 so I decided to give the TU58 emulator
a try. I hacked together a cable to interface with the CIM module.
Firing up the emulator in debug mode I get the following:
C:\tu58>tu58em -d -p 1 -s 9600 -z xxdpd2d.tap
info: initialize tape on 'xxdpd2d.tap'
info: initialize XXDP directory on 'xxdpd2d.tap'
info: unit 0 rwcx file 'xxdpd2d.tap'
info: (C) 2007 Don North <ak...@mindspring.com>, (C) 1984 Dan Ts'o
<Rockefeller
University>
info: serial port 1 at 9600 baud
info: TU58 emulation start
info: R restart, S toggle send init, V toggle verbose, D toggle debug,
Q quit
info: emulator started
.......................info: flag=0x00 last=0xFF
info: <NULL> seen
info: flag=0x00 last=0x00
info: <NULL> seen
info: flag=0x04 last=0x00
info: <INIT> seen
info: flag=0x08 last=0x04
info: <BOOT> seen
and this is where it pretty much sits. The processor is running and no
further output to the console.
Brian.
geezer
My cut and paste missed a line.
After "info:<BOOT> seen" the next line reads
info:boot unit=0 blk=0X0000 cnt=0X0200
Don North
Well, since I wrote it maybe I should comment....
What are you running on the 11/44 side? You need to be running the 'DD'
bootstrap from the M9312 (which is actually integrated into the 11/44
Unibus module on that CPU). The TU58 emulator is just a dumb slave at the
end of the serial line. Your PDP-11 CPU has to issue read/write commands.
My assumption is you have either a toggle in boot or a DD device ROM as
the 11/44 CPU appears to have issued the 'boot' command.
Second, since you created an empty XXDP tape image using the -z command
it makes no sense to try and boot from it (the boot block is going to be
all zero) and there is no XXDP monitor on the device. You need to use
the -r command and pass it the name of an XXDP image file that has a
bootable image (all the tapes on my web page have bootable XXDP images).
The web page with a bunch of bootable TU58 images is at:
http://www.ak6dn.com/PDP-11/TU58
Don
geezer
Hi Don,
Thanks for your help on this. I downloaded the XXDP image and the
11/44 CIS diag image from your site, I used the -r switch and I
received the same exact response with both images. I also switched
from the laptop I was using to a dell desktop I had sitting around.
Same results. Both machines are running XP and I am using the DD ROM
in the 11/44. I am using the send, receive, and the ground pins in my
RS232 cable. The cable is going straight into the console board of
the /44.
Brian.
Don North
Since the behavior is the same using different PCs, I suspect there is
a h/w config issue. Are you sure the TU58 port on your 11/44 is setup
correctly for TU58 serial operation? Normally that port on an 11/44 will
be set to 38.4K baud, BREAK enabled, no parity, and EIGHT bit data. How
to do this on the M7096 multifunction module is detailed in the 11/44
tech ref manual pp.3-15 to 3-17. (Available at www.bitsavers.org). In
particular the data format MUST be set to 8 bit since the protocol is
binary.
Since your TU58 port is running at 9600 I suspect it may have been
used as a standard terminal port at some point in 7b mode.
The TU58 emulator program will setup all the serial port parameters on
your PC as required (baud rate, data format, etc) based on the command
line switch (-s BAUD).
Since you say you are seeing:
info: flag=0x00 last=0x00
info: flag=0x04 last=0x00
info: flag=0x08 last=0x04
info:boot unit=0 blk=0x0000 cnt=0x0200
this would indicate that the DD boot prom is sending the required
INIT codes (0x04) and BOOT code (0x08) bytes, and that tu58em is should
have sent the 512.byte boot block in BINARY mode.
I would check to see that some data has been loaded correctly into memory
starting at loc 0, this is where the boot block goes. Location 0 in memory
should have a NOP (octal 000240, hex 00A0) loaded in it.
Don
geezer
> particular the data format MUST be set to 8 bit since the protocol is
> binary.
>
> Since your TU58 port is running at 9600 I suspect it may have been
> used as a standard terminal port at some point in 7b mode.
>
> The TU58 emulator program will setup all the serial port parameters on
> your PC as required (baud rate, data format, etc) based on the command
> line switch (-s BAUD).
>
> Since you say you are seeing:
>
> info: flag=0x00 last=0x00
> info: flag=0x04 last=0x00
> info: flag=0x08 last=0x04
> info:boot unit=0 blk=0x0000 cnt=0x0200
>
> this would indicate that the DD boot prom is sending the required
> INIT codes (0x04) and BOOT code (0x08) bytes, and that tu58em is should
> have sent the 512.byte boot block in BINARY mode.
>
> I would check to see that some data has been loaded correctly into memory
> starting at loc 0, this is where the boot block goes. Location 0 in memory
> should have a NOP (octal 000240, hex 00A0) loaded in it.
>
> Don
Problem solved
I have two of the M7096 boards and they behave slightly different. The
one in the machine now I set to 9600 because it was giving comm errors
at 38.4. The other board I have is older but runs OK at 38.4. It gives
a slightly different output on the display. I checked both and they
are set to 8 bit, break enabled (W10 in), and no parity(W11 out).
I decided to check all the settings again on all of the installed
boards and found the CIM to be configured to RS-423. I replaced the
CIM with a spare and the M7096 with the one able to run at 38.4 and
was successfully able to boot xxdp.
Now I'll work on getting an OS onto at least an RL02, I can start
adding devices back in. I have a TE16 and a Systems Industries
controlled 160 Meg Fujitsu drive connected to this system.
Thanks again for the help,
Brian.
Don North
> Problem solved
>
> I have two of the M7096 boards and they behave slightly different. The
> one in the machine now I set to 9600 because it was giving comm errors
> at 38.4. The other board I have is older but runs OK at 38.4. It gives
> a slightly different output on the display. I checked both and they
> are set to 8 bit, break enabled (W10 in), and no parity(W11 out).
>
> I decided to check all the settings again on all of the installed
> boards and found the CIM to be configured to RS-423. I replaced the
> CIM with a spare and the M7096 with the one able to run at 38.4 and
> was successfully able to boot xxdp.
>
> Now I'll work on getting an OS onto at least an RL02, I can start
> adding devices back in. I have a TE16 and a Systems Industries
> controlled 160 Meg Fujitsu drive connected to this system.
>
> Thanks again for the help,
> Brian.
Glad to hear it, it had to be something 'simple' like that.
I use this mechanism all the time to load diagnostics down into my
11/44 and 11/34 boxes for running basic tests on the hardware.
I'm now working on an update to the 'xxdpdir/diagdir' program that
manipulates XXDP images on the PC side. I'm cloning the functionality
into a Perl module ('XXDP.pm') that understands TU58, RL02, RX02, RK05,
RA90, etc disk formats and directory structures. It is now at the point
of being able to do a 'dir' of all these device image files (RX02 was
the hardest since the DY.SYS driver on XXDP is doing sector interleaving
and I had to reverse engineer the algorithm). File insert/extract will
be next, followed eventually by being able to create bootable media.
I'll update my TU58 web page with these new programs when complete.
Don
geezer
With XXDP I tied to do an "init dlo:" and get a "RD ERR". I tried 4
different drives and two different sets of controllers and cables/
terminators. Drives load the heads come ready and ready light flashes
when spoken to. I am thinking this is why none of my packs booted.
Brian.
Tim Thompson
> different drives and two different sets of controllers and cables/
> terminators. Drives load the heads come ready and ready light flashes
> when spoken to. I am thinking this is why none of my packs booted.
This may sound odd, but. . .
Where is the RL02 physically installed?
i.e., what is above, and below it ?
Are all the drives in a rack, and slid all the way back into the rack?
The reason I mention this is that I had an odd problem like this many years
ago.
The problem proved to be operator error.
Since I was going to be frequently swapping packs,
I was operating the drive while it was halfway out of the rack.
(Just enough to allow the lid to open)
In the rack above it was an RX02. Below it, another RL02.
What I found was that magnetic fields from either of the adjacent drives
would cause errors during formatting (and during normal operations).
Just a thought. . . .
T
Bill Gunshannon
/|\
|
I hope that was a typo. :-)
> different drives and two different sets of controllers and cables/
> terminators. Drives load the heads come ready and ready light flashes
> when spoken to. I am thinking this is why none of my packs booted.
Got your terminator on the last RL drive? RL's are a lot touchier
than you would expect. Only thing worse was RA's. :-)
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Bill Gunshannon
Never saw that and I frequently ran them in various positions in the rack.
Most of them had a tendency to kinda drift out 6-9 inches anyway as I only
tied them in the rack when moving them. :-)
Johnny Billquist
> In article <lsuol.552$Hy7...@newsfe25.iad>,
> "Tim Thompson" <Tigge...@aol.com> writes:
>>> With XXDP I tied to do an "init dlo:" and get a "RD ERR". I tried 4
>>> different drives and two different sets of controllers and cables/
>>> terminators. Drives load the heads come ready and ready light flashes
>>> when spoken to. I am thinking this is why none of my packs booted.
>> This may sound odd, but. . .
>>
>> Where is the RL02 physically installed?
>>
>> i.e., what is above, and below it ?
>>
>> Are all the drives in a rack, and slid all the way back into the rack?
>>
>> The reason I mention this is that I had an odd problem like this many years
>> ago.
>>
>> The problem proved to be operator error.
>>
>> Since I was going to be frequently swapping packs,
>> I was operating the drive while it was halfway out of the rack.
>> (Just enough to allow the lid to open)
>>
>> In the rack above it was an RX02. Below it, another RL02.
>>
>> What I found was that magnetic fields from either of the adjacent drives
>> would cause errors during formatting (and during normal operations).
>>
>> Just a thought. . . .
>
> Never saw that and I frequently ran them in various positions in the rack.
> Most of them had a tendency to kinda drift out 6-9 inches anyway as I only
> tied them in the rack when moving them. :-)
I'll have to agree. I've had items places in all kinds of orders without
problems. Also, I think DEC designed them with this in mind. There are
shielding both to reduce output emissions, and reduce sensitivity to it.
And I think that DEC also did test for this.
It might be that there was something broken/damaged in the drive, or
perhaps people had partially disassembled hardware?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Johnny Billquist
Nitpick: The RA drives don't have a terminator. I suspect what you're
thinking of the power sequence cables of the RA60,80,81 and RA82.
Other RA drives don't have those.
RL drives are definitely picky on the terminator. But don't they signal
fault if the terminator isn't in place? (Check your lamps. Not uncommon
for RL drives to have broken lamps.)
Speaking of problems with RL drives. One problem that I've had was a
broken cable. The break was just enough to occasionally cause problems,
and it was affected when you slid the drive on the rails. That one was
annoying, and somewhat random. It was just one wire or two, and just by
the connector at the drive end.
geezer
I have three drives in the rack and when I am testing, I only use one
of them. I have tried three different terminators and two sets of
ribbon cable/drive cable setups. I have tested 4 of the six drives. I
just can't seem to get past this one. The drive ready light will
flicker when trying to boot and when using Init it flashes once. Since
the 44 only has one HEX SPC slot I can't move the controller around. I
haven't tried multiple drives yet though.
Johnny Billquist
You mean that nothing more happens?
You have checked that the fault lamp is ok, and isn't showing anything?
If I were to guess on something, it sounds like the drive is responding
to signals, but for some reason it don't play.
Here is a small checklist.
Check that you really get the disk spinning. That should be possible to
just listen to, or feel by having a hand on the drive. If not, then make
sure you've loaded the cartridge correctly, and that you've placed the
lid of the cartridge on top of the cartridge inside the drive.
Check that the transport safety is locked in the right position.
Check that the NPR signal jumper is removed from the backplane position
where you have the controller.
Bill Gunshannon
Johnny Billquist <b...@softjar.se> writes:
> Bill Gunshannon wrote:
>> In article <025fe019-eaa7-4597...@i38g2000yqd.googlegroups.com>,
>> geezer <abac...@yahoo.com> writes:
>
>>> different drives and two different sets of controllers and cables/
>>> terminators. Drives load the heads come ready and ready light flashes
>>> when spoken to. I am thinking this is why none of my packs booted.
>>
>> Got your terminator on the last RL drive? RL's are a lot touchier
>> than you would expect. Only thing worse was RA's. :-)
>
> Nitpick: The RA drives don't have a terminator. I suspect what you're
> thinking of the power sequence cables of the RA60,80,81 and RA82.
> Other RA drives don't have those.
I didn't mean with regards to a terminator. Al of them had their quirks.
For RA's it was the "odd number of connecting cables".
>
> RL drives are definitely picky on the terminator. But don't they signal
> fault if the terminator isn't in place? (Check your lamps. Not uncommon
> for RL drives to have broken lamps.)
I think you are right about the fault, but I also seem to remember
at least one time when that didn't happen and the drive just didn't
work.
>
> Speaking of problems with RL drives. One problem that I've had was a
> broken cable. The break was just enough to occasionally cause problems,
> and it was affected when you slid the drive on the rails. That one was
> annoying, and somewhat random. It was just one wire or two, and just by
> the connector at the drive end.
Yeah, look real close a the connectors. Those pins are really strange
and it doesn't take much to mess up the connector.
Johnny Billquist
More: I assume you have a unit button on the drive. Check that you
really have the right unit number. Check that you don't have two drives
connected using the same unit number.
Check that you have a correct terminator. The RK06/RK07 have a
terminator that looks identical. I believe the RK06/07 terminated will
work in an RL drive, but make sure. I know they are not identical.
Make sure the Unibus is correctly configured. You need bus grants in all
unused slots (this is not like Q-bus). Also, you need a correct
terminator for the Unibus. You also need to make sure the NPR-signal on
the Unibus backplane is ok. The jumper should be in (or you need an
extended bus grant card) for all slots where you don't have DMA-controllers.
When you insert the cardridge in the drive, the load lamp should be on.
When you press in the load button, the light should go off. About 10
seconds later, the Unit number lamp should go on, telling that the drive
is now online. If this don't happen, then there is something wrong.
geezer
>
> - Show quoted text -
Yes, all of the above has been done. I know the terminators are
correct, cables etc because this was all working on my 11/34 before
the power supply went south. When I get home tonight, I will recheck/
examine all the connectors again. I'll also check for the NPR jumper
config. The backplane on the 44 has (after all the processor cards) 4
slots for memory in which the first two are filled. The next two have
bus grants although I don't beleive they need them and then only one
slot left for the DL11. The last slot contains the terminator. It
seems to me that if any of this were wrong, I would not be able to
boot the machine and run XXDP. In the past, at least with the 34's I
have run, misconfigured NPR would not allow the processor to run.
Johnny Billquist
> In article <gnu7h0$dln$1...@tempo.update.uu.se>,
> Johnny Billquist <b...@softjar.se> writes:
>> Bill Gunshannon wrote:
>>> In article <025fe019-eaa7-4597...@i38g2000yqd.googlegroups.com>,
>>> geezer <abac...@yahoo.com> writes:
>>>> different drives and two different sets of controllers and cables/
>>>> terminators. Drives load the heads come ready and ready light flashes
>>>> when spoken to. I am thinking this is why none of my packs booted.
>>> Got your terminator on the last RL drive? RL's are a lot touchier
>>> than you would expect. Only thing worse was RA's. :-)
>> Nitpick: The RA drives don't have a terminator. I suspect what you're
>> thinking of the power sequence cables of the RA60,80,81 and RA82.
>> Other RA drives don't have those.
>
> I didn't mean with regards to a terminator. Al of them had their quirks.
> For RA's it was the "odd number of connecting cables".
Yeah, that's another exciting detail. :D
>> Speaking of problems with RL drives. One problem that I've had was a
>> broken cable. The break was just enough to occasionally cause problems,
>> and it was affected when you slid the drive on the rails. That one was
>> annoying, and somewhat random. It was just one wire or two, and just by
>> the connector at the drive end.
>
> Yeah, look real close a the connectors. Those pins are really strange
> and it doesn't take much to mess up the connector.
Good point! I had forgotten about that one! Look at the connector
itself. The pins are all a kind of springs. Make sure that none are
bent. That have happened to me a number of times (but more often on
massbus connectors). Spray some cleaning fluid perhaps. Something that
both cleans, and improves electrical connection.
Johnny Billquist
> Yes, all of the above has been done. I know the terminators are
> correct, cables etc because this was all working on my 11/34 before
> the power supply went south. When I get home tonight, I will recheck/
> examine all the connectors again. I'll also check for the NPR jumper
> config. The backplane on the 44 has (after all the processor cards) 4
> slots for memory in which the first two are filled. The next two have
> bus grants although I don't beleive they need them and then only one
> slot left for the DL11. The last slot contains the terminator. It
> seems to me that if any of this were wrong, I would not be able to
> boot the machine and run XXDP. In the past, at least with the 34's I
> have run, misconfigured NPR would not allow the processor to run.
Good.
Now, I must have missed something. I thought you couldn't boot from the
drive, but if you have XXDP running, then we can exclude a bunch of things.
Maybe I'm dense, or something. Could you please re-describe what the
problem is, and what you have observed, and what you have managed to do
successfully?
geezer
I am booting XXDP from a TU58 emulator. From there I am trying to make
a bootable RL02 pack. When I do the init DL0: , the ready light
flashes once and then I get a RD ERR. If I try and boot from same RL02
drive, the ready light pulsates but I am unable to boot from any of my
packs.
Johnny Billquist
Aha! Well, in that case I think most of my points are still valid.
The ones you can ignore are about the bus grants on the unibus, since
that must be whole for the machine to be happy.
However, the NPR signal can still be the problem. Go through the whole
list, please. :-)
The controller is accessing the drive, but the operations don't seem to
be completing. Could be NPR problem. Could be transport lock. Could be
cable problem.
I think my first pick might be NPR. But as usual, it's difficult to
diagnose remote. :-)
Bill Gunshannon
Johnny Billquist <b...@softjar.se> writes:
> geezer wrote:
>> Yes, all of the above has been done. I know the terminators are
>> correct, cables etc because this was all working on my 11/34 before
>> the power supply went south. When I get home tonight, I will recheck/
>> examine all the connectors again. I'll also check for the NPR jumper
>> config. The backplane on the 44 has (after all the processor cards) 4
>> slots for memory in which the first two are filled. The next two have
>> bus grants although I don't beleive they need them and then only one
>> slot left for the DL11. The last slot contains the terminator. It
>> seems to me that if any of this were wrong, I would not be able to
>> boot the machine and run XXDP. In the past, at least with the 34's I
>> have run, misconfigured NPR would not allow the processor to run.
>
> Good.
> Now, I must have missed something. I thought you couldn't boot from the
> drive, but if you have XXDP running, then we can exclude a bunch of things.
> Maybe I'm dense, or something. Could you please re-describe what the
> problem is, and what you have observed, and what you have managed to do
> successfully?
I think he booted XXDP from the TU58.
Tim Thompson
> I'll have to agree. I've had items places in all kinds of orders without
> problems. Also, I think DEC designed them with this in mind. There are
> shielding both to reduce output emissions, and reduce sensitivity to it.
> And I think that DEC also did test for this.
>
> It might be that there was something broken/damaged in the drive, or
> perhaps people had partially disassembled hardware?
>
Actually, it was my own machine at home. It had me stumped for at least an
hour.
At first I thought it was the pack, so I swapped that out; same problem.
Tried formatting the pack in the other drive, and it worked fine.
(Not thinking at the time that all the drives were now slid back into the
rack.)
At some point, I had turned off all the other drives, and recabled the drive
so that it was the only one on the controller, and it mysteriously started
working again.
(I had also swapped out the drive cable at some point, to no avail.)
Eventually, the little light bulb went on (inside my head, that is),
and I realized that my problems went away when other drives were powered
down,
or when the drive was all the way into the rack.
So, I tried an experiment. . . . I started a format with the drive in the
rack,
and SLOWLY started to slide the drive out of the rack.
As soon as the drive moved out far enough to where the little read/write
board for the RL02 heads was in proximity to the power supply of either the
adjacent RX02 or RL02, it returned an immediate error.
The drive would work when it was all the way out, or all the way in,
but not while it was out just far enough to be able to open the lid.
I was able to reproduce the results with my other RL02 in the rack,
so I don't think it was just one flaky drive causing the problem.
Weird, huh?
T
Don North
Have you tried running the RL02 diagnostics from a downloaded XXDP TU58
image? They might be able to tell you something about what is going on,
and give much more specific failure info than 'RD ERR' from the XXDP
monitor.
Don
geezer
Alright, Johnny gets the win. I removed the bottom cover and the NPG
jumper was removed as it should. The problem was that the slot next to
it was missing as well. I replaced the grant card with a G7273 and I
was able to create a bootable XXDP RL02 pack without a problem. Thanks
everyone for the help. Next step will be getting the TE16 to talk.
Thanks again,
Brian.
Johnny Billquist
> Alright, Johnny gets the win. I removed the bottom cover and the NPG
> jumper was removed as it should. The problem was that the slot next to
> it was missing as well. I replaced the grant card with a G7273 and I
> was able to create a bootable XXDP RL02 pack without a problem. Thanks
> everyone for the help. Next step will be getting the TE16 to talk.
Great! Always nice to see a problem solved.
The TU58 isn't using DMA at all, so you can get away with DMA not
working correctly when using that device.