• Please review our updated Terms and Rules here

Problems booting PDP-11 through tu58 emulator

RetroNewbie

RetroNewbie

Experienced Member
Joined
Dec 13, 2023
Messages
72
Location
Italy
Hi everyone. I've wanted to play around with a PDP-11 so I bought various cards and pieces to assemble one.
Right now I have a basic system up and booting into microODT. The next step would be to try and boot RT-11 with a tu58 emulator but I've been having some problems.
All the type-in bootstraps that I've found online and on the tu58 manual dont work, when I type "1000G" they just halt indefinitely without sending anything on the TRX line of the SLU (checking with a scope).

I was thinking of an addressing or SLU problem but this is the result of some testing if it helps (typed in through microODT):

Test #1:

MOV #1,R1
MOV R1,@#17776504

> This successfully puts a "HIGH" signal on the SLU TRX line.

Test #2:

@17775405/000200
@17776506/... 1111111

> The transmit ready bit is set and I can sucessfully send some data into the TRX line.

Test #3 (compiled with macro11):

.ASECT
.=1000
MOV #0,R2
10$:
BIT #200,@#17776504
BEQ 10$
MOV #111111,R2
MOV R2,@#17776506
BR 10$

> No data is sent through the TRX line, or sometime sent once.

This is the setup (cards are in order of placement in the backplane):

- H9275 backplane
- M8192 Cpu card
- M8028 SLU (used for the tu58)
- M7940 (used for micro ODT console)
- M8059 Ram

Thank you in advance, I'm really at a loss.
 
First of all, welcome to VCFED.

Have you tried removing the M7940 and reconfiguring the M8028 as the console to see if it works?

The H9275 is a quad backplane isn't it? Have you arranged the cards according to the manual (as each card you have specified is a dual height card in a quad height backplane). This shouldn't be your current problem though, but it could affect interrupt operation later.

Dave
 
Just looking at the code.

Should the BIT be a BITB and the MOV R2,@#... be a MOVB?

The address constants should be 16 bits also.

Probably not a problem...

Dave
 
daver2 said:
First of all, welcome to VCFED.

Have you tried removing the M7940 and reconfiguring the M8028 as the console to see if it works?

The H9275 is a quad backplane isn't it? Have you arranged the cards according to the manual (as each card you have specified is a dual height card in a quad height backplane). This shouldn't be your current problem though, but it could affect interrupt operation later.

Dave
Click to expand...
Thank you!

Yes the M8028 originally had the standard configuration for console operation. I changed the baud rate and it worked just fine as the console for the ODT then after changing the address and the interrupt vector options the only tests I was able to do are the ones that I wrote. I should probably mention that I also tried to use a DLV11-J without any luck.

Yes, the H9275 is a quad Q/Q backplane. And they are inserted as described in the manual, shouldnt change much though since I have 4 cards installed. The order for the interrupts is the one that I wrote for the cards.
 
daver2 said:
Just looking at the code.

Should the BIT be a BITB and the MOV R2,@#... be a MOVB?

The address constants should be 16 bits also.

Probably not a problem...

Dave
Click to expand...
You're right that would be better. But when testing with ODT that location contained just "000200" so unless there is an endian issue it shouldnt be a problem

The address costant are converted by the assembler to the normal instruction (17776506 become 176506) and in some tests it worked like that so it should be ok.
The only thing that I'm not sure of is that I'm taking the octal code from the listing file created with "macro11.exe" and not the bin file since it has some additional data that I dont think is needed while using it with ODT.
 
That's strange. I have always used a DLV11-J card with one of the ports configured as a console and generally had no problem.

Just thinking of things off the top of my head... Make sure all of the cards are configured for Q22 operation.

How is the CPU configured?

Dave
 
daver2 said:
That's strange. I have always used a DLV11-J card with one of the ports configured as a console and generally had no problem.

Just thinking of things off the top of my head... Make sure all of the cards are configured for Q22 operation.

How is the CPU configured?

Dave
Click to expand...
When I installed It I had the console option on the DLV11-J disabled since I was using the M7940 for the console.

I checked for that on different manuals, the only card that required a jumper for 22bit system was the memory card. And I was able to use both the M7940 and M8028 for console operation so it should work.

The CPU configuration:
POWERUP option ==> Micro-ODT, PS=0
HALT option ==> Disabled
Wakeup ==> Enabled
BEVNT recognition ==> Enabled
 
daver2 said:
There are various MACRO-11 test programs over at:

Interfacing with a PDP-11/05: Test programs and "Hello, world!"

Joomla! - dynamische Portal-Engine und Content-Management-System
www.retrocmp.com www.retrocmp.com

You will need to tweak the I/O address based.

Dave
Click to expand...
Ok I changed the jumpers to 9600 bauds. Just tried running the "Hello world" example from the link you sent me. This is the result, it just halts, instead of printing on the console as you can see.

1702497130010.png
 
This may be a dumb question, but your RAM card is working isn't it?

I see you writing values into memory, but are the values really stored?

Dave
 
daver2 said:
This may be a dumb question, but your RAM card is working isn't it?

I see you writing values into memory, but are the values really stored?

Dave
Click to expand...
Unfortunately I dont know since I don't have a way to test it.
I noticed that at startup all the memory values are set to octal 1000 and I don't know if that's expect behavior.

When I change a memory value with ODT and I read it back the value is right, but I know that the M8192 has a cache so I don't know how it would behave in case of bad memory.
 
Download the program to 2000. Don't execute it, but open 2000 again and keep pressing the <LF> key to view the memory contents and see if the values are still correct.

Dave
 
daver2 said:
This may be a dumb question, but your RAM card is working isn't it?

I see you writing values into memory, but are the values really stored?

Dave
Click to expand...

PDP11GUI has a builtin memory test capability, so it might be worth your while to get it running. Also has a macro11 assembler and download capability built in.
 
Thank you for all of your suggestions. It's likely a RAM memory problem.
When testing by hand with ODT I think that the problems were hidden by the cache since the values were right. It always seemed a bit off the fact that all the memory was set to 1000.
I performed a full memory test as you suggested and this is the result. When it reaches the address 00400000 the diff mask becomes 1000. Hopefully (and probably) it's a problem of a logic IC and not of a memory IC.
1702575493862.png
 
You mean 10000 not 1000.

It does look like a stuck data bit though to me, although it could also be a data buffer.

What (and how many) RAM chips have you got on the card?

You will probably have multiple banks. If it is a RAM fault, you may find another bank is OK. That will rule out athe data buffer fault.

Dave
 
daver2 said:
You mean 10000 not 1000.

It does look like a stuck data bit though to me, although it could also be a data buffer.

What (and how many) RAM chips have you got on the card?

You will probably have multiple banks. If it is a RAM fault, you may find another bank is OK. That will rule out athe data buffer fault.

Dave
Click to expand...
Yes sorry you are right. But at address 00400000 the error does change.

1702579352760.png

The M8059 is populated with 36 Mostek MK4564N-15 ICs that should be 8KB each.
Some of them are for parity though but they should cover the address space from 0 to 760000 (I know I've got it wrong in the test and I did another test with the right upper memory bound later without any change).

What do you mean multiple banks? With the test I would get an error at all memory locations, wouldn't that suggest that the error is not related to the RAM ICs?
 
A 4564 DRAM is actually a bit-wide device, so it is 64K*1 bit not 8KB.

If there are 36 DRAM devices this will be 2 banks of 16 with 1 DRAM device for the parity for each byte making 36 devices in total (2*16 + 4 = 36).

So you have 2 banks of 64KW which should be 2 banks of 128KB = 256KB. Does this tally with the card numbering scheme?

It is just possible that you have two faults then - a different DRAM in each bank...

I have just done the maths, and I think what I have stated above is correct.

Dave
 
You must log in or register to reply here.
Back
Top