• Please review our updated Terms and Rules here

PDP SBC - J11 Hack

8

8008guy

Veteran Member
Joined
Jun 25, 2014
Messages
584
Location
Salt Lake City, Utah
Hi All,

I've been playing around with a J11 processor chip on a breadboard. Several years ago I ran upon the J11 hack website and have been intrigued ever since. For those of you not families with the site you can find it here:

http://www.cs.ubc.ca/~hilpert/e/pdp11hack/index.html

I found a J11 on ebay a month ago and thought I would see if the chip was functional. At the bottom of the J11 hack site is a link to a J11 hack built by Peter Schranz that incorporated all of the glue logic in a GAL. I am taking that approach.

To date I have the J11 running and interfaced to 128k words of Ram and a single serial port. I'm running it with a 12Mhz crystal, I'll pop in a faster xtal when I get time. For testing I have been using PDPGUI to drop in little test programs that I assemble using the GCC assembler built for the PDP11. I also have a working PDP11/83 that I can test against. So far have successfully run the simple test programs from the J11 Hack site. I've also written a small program that sets up and tests the MMU, that test worked.

My version also includes the power up register which can be used to configure boot from ROM at several locations.

I'm in the process of wiring up the second version that splits the GAL logic into two chips. One for memory addressing and the other for I/O. This next version decodes the upper 5 address bits and creates 32 blocks of 128k memory select, of which I am getting 6 select lines out of the GAL. The I/O GAL provides logic to partially decode 2 serial ports, parallel port space, and the boot ROM at 173000 in I/O space. I should have the wired by tonight and start testing again.

My immediate goal is to build a little SBC for a clock. You can see my previous projects at http://chronworks.com

In any case there has been others express interest in a J11 SBC that is more extensive and possibly capable of running RT11. I am planning to publish everything I'm doing and am open to incorporating additions. Once I get the ROM working and testing I'll post what I have, probably early next week. Overall I'm trying to keep the SBC reasonably simple. Input as to the HW base necessary to support RT11 would be helpful at this point. Please feel free to bring your thoughts and suggestions into this thread.

Cheers

len
 
Excellent!

I will be watching with great interest.
Thanks for the pointer to the original J-11 hack site. Your web site is pretty interesting, too!

smp
 
If your ultimate goal is to run RT-11 what would you do for mass storage? What would it take to build logic that is functionally compatible with something like an RXV21 controller at the register interface level, and use some sort of flash for storage?

I have two or three M8192 KDJ11-A modules which are functional enough to boot XXDP but fail some of the diagnostics. I wonder how likely it is that the J-11 chip itself has issues vs. other components on the module. Maybe someday I'll pull one of the J-11 chips and try experimenting with a single board J-11 hack.
 
Hi Len,

That's a very interesting project ad thanks for bringing the hacks site to our attention. I wasn't aware of it before.

Please keep posting updates.


Cheers,

Andy.
 
Hi

My original intentions were a bit simpler. The rt11 idea came from another user. Since I'm in the starting phase of the project I'm completely open to ideas.

Len


gslick said:
If your ultimate goal is to run RT-11 what would you do for mass storage? What would it take to build logic that is functionally compatible with something like an RXV21 controller at the register interface level, and use some sort of flash for storage?

I have two or three M8192 KDJ11-A modules which are functional enough to boot XXDP but fail some of the diagnostics. I wonder how likely it is that the J-11 chip itself has issues vs. other components on the module. Maybe someday I'll pull one of the J-11 chips and try experimenting with a single board J-11 hack.
Click to expand...
 
Nice 'little' project. I would be interested in helping out.

The first things that come to mind are:

The schematics currently address the RAM as WORDS. If you are writing your own embedded firmware - and don't plan to use the BYTE-based instructions - this is fine. If you plan to use (say) RT-11 - the memory will have to support both BYTE and WORD reads/writes. You will also have to get a bit more memory on the board... SRAM is fairly cheap and available in large byte-wide devices these days so this shouldn't be a problem.

Disk wise I would consider adding a simple parallel port to drive a compact flash (or similar) as an IDE interface. This will not be the same as any 'standard' DEC controller - but I am sure an RT-11 driver could be put together using the RT-11 distribution kit and SIMH. Thoughts anyone?

You could 'borrow' the IDE disk interface from the PDP-8/E SBC6120 retrobrew project (see https://www.retrobrewcomputers.org/...-rbc-edition:sbc6120-rbc-edition-1.10-sch.pdf - in particular schematic 3 of 6, devices U18 and U24 and connector J2).

Dave
 
Last edited:
If you want to stick with DIP parts for now for breadboard work you can get AS6C4008-55PCN 512Kx8 SRAM parts in 32-pin DIP packages for less than $5 each new. With two of those you'd have 1MB of SRAM and should be able to run just about anything.
 
Perfect, both Digikey and Mouser has these for 4.57/4.56. THanks for the tip.

gslick said:
If you want to stick with DIP parts for now for breadboard work you can get AS6C4008-55PCN 512Kx8 SRAM parts in 32-pin DIP packages for less than $5 each new. With two of those you'd have 1MB of SRAM and should be able to run just about anything.
Click to expand...
 
Help me understand byte write.

In the J11 processor manual I can see that a AIO of 0011 is a byte write. Ok, no problem to decode that and spit the /WE signal. I'm just not understanding how the odd/even address correlate to the byte? (even address low byte, odd address high byte. ) I guess I need to spend some time with a schematic of a memory board.

I'll look at the 6120 Ide interface. I have a CF disk on my Z80 SBC that runs CPM. That was fairly simple, although I did not design the driver. I have parallel space set aside at 176160 where I was planning to throw in a couple 8255's.

I haven't looked at the source for the disk drivers. On my 11/83 I have a DU device. (RA82) I am using a UC07 with a SCSI2SD on the other end. Maybe I'm being naive, but I assume that the drive API provides stand calls and isolates the controller and drive. Writing code to replace anything lower than the API makes sense, at least here at 30,000ft. I assume that the drive needs dma to get the data into the memory direct from disk.

Those of higher knowledge please comment.

len




daver2 said:
Nice 'little' project. I would be interested in helping out.

The first things that come to mind are:

The schematics currently address the RAM as WORDS. If you are writing your own embedded firmware - and don't plan to use the BYTE-based instructions - this is fine. If you plan to use (say) RT-11 - the memory will have to support both BYTE and WORD reads/writes. You will also have to get a bit more memory on the board... SRAM is fairly cheap and available in large byte-wide devices these days so this shouldn't be a problem.

Disk wise I would consider adding a simple parallel port to drive a compact flash (or similar) as an IDE interface. This will not be the same as any 'standard' DEC controller - but I am sure an RT-11 driver could be put together using the RT-11 distribution kit and SIMH. Thoughts anyone?

You could 'borrow' the IDE disk interface from the PDP-8/E SBC6120 retrobrew project (see https://www.retrobrewcomputers.org/...-rbc-edition:sbc6120-rbc-edition-1.10-sch.pdf - in particular schematic 3 of 6, devices U18 and U24 and connector J2).

Dave
Click to expand...
 
8008guy said:
I haven't looked at the source for the disk drivers. On my 11/83 I have a DU device. (RA82) I am using a UC07 with a SCSI2SD on the other end. Maybe I'm being naive, but I assume that the drive API provides stand calls and isolates the controller and drive. Writing code to replace anything lower than the API makes sense, at least here at 30,000ft. I assume that the drive needs dma to get the data into the memory direct from disk.
Click to expand...

You have tradeoffs between hardware complexity, capability and software support. If you want existing disk device drivers to work on all DEC operating systems (e.g. RT-11, RSX) then you need to emulate the disk controller interface. Some disk devices are much simpler to interface with/emulate than others. The IMO nice disk controllers that support disk devices of arbitrary size (e.g. DU0: ) run MSCP (mass storage control protocol). This takes more intelligence in the controller than emulation of, say, an RH70. Think what you could do if you had an ARMv6 controller running Linux talking MSCP to your J11 system: you could use NFS, USB, SATA, SDHC, etc. But that would take a fairly serious software development effort to build a useful and flexible MSCP iimplementation for Linux. It might also be worthwhile to build a QBUS board for that controller once the software was proven to work.

The approach that daver2 suggested is much more modest: build an interface that will talk to an IDE disk that does not emulate any DEC standard controller, and write a new disk controller driver module for RT-11. You would need to write an additional device driver for RSX, and probably another different driver for RSTS. You would probably need to generate a system image for your hardware on standard DEC hardware (or SIMH), then write a bootable image to a disk that would work with your hardware.
 
Len,

This stuff is going back 10 or 15 years - so I would validate it before use!

If you look at your schematics you will see that you have wired LA1 to RAM A0, LA2 to RAM A1 and so forth. LA0 is unused. On a BYTE WRITE, LA0 is used to decide whether the write is to the EVEN byte (LA0='0') or to the ODD byte (LA0='1'). On a WORD WRITE, the state of LA0 is ignored. I suspect that your memory address decoding will need to be a little more complex than it currently is.

As Uniballer has already stated there are lots of tradeoffs here. You do not have to use DMA in a disk controller - although the use of it makes a high performance system and reduces the overhead on the CPU. You could use interrupts - when the disk controller is ready with the next data byte (or status change) it generates an interrupt which the device driver responds to. This is more CPU-intensive than the DMA case - but the CPU can get on and do something else whilst waiting for the next data byte. Or you could just use 'polled' mode - where the device driver sits and waits for the entire block transfer and performs the action all itself. This will not give you a high performance system at all. It all depends upon what you want to achieve. If the goal is a home-brew hacker that is cheap and cheerful with the smallest number of parts then I would look at the interrupt solution (avoiding DMA). To my way of thinking the polled solution just sounds really horrid - but it would result in the cheapest and easiest implementation.

Implementing a non-standard disk controller (or any hardware for that matter) will require a new device driver to be written. And (as has been stated) this can be done with either a 'real' O/S running on a 'real' machine or by the use of SIMH.

I think at some point you will be forced into looking at how interrupts work. For example, most Operating Systems require a clock and most Operating Systems will invariably switch from polled serial I/O to interrupt driven serial I/O the moment they are started. ODT is quite happy to work with polled I/O - but I would like to bet that RT-11 will not. Again - you want to perhaps look at the easiest and simplest method of implementing the limited interrupt functionality you require.

You're the nominated designer - which way do you want to go?

Hope this all makes sense.

Dave
 
Looking at the RQDX3 the hardware appears "relatively" simple. The T11 running at 7.5 Mhz. What about building the CPU facing API and then just supporting a CF card on the drive side. Eliminate the QBUS and just tie everything in directly to the J11/SBC. A fast 16 bit pic would easily handle the data. Maybe even a AVR running 20Mhz. Any takers?

It there a good description on the MSCP implementation, including call addresses and variables?

len


Uniballer said:
You have tradeoffs between hardware complexity, capability and software support. If you want existing disk device drivers to work on all DEC operating systems (e.g. RT-11, RSX) then you need to emulate the disk controller interface. Some disk devices are much simpler to interface with/emulate than others. The IMO nice disk controllers that support disk devices of arbitrary size (e.g. DU0: ) run MSCP (mass storage control protocol). This takes more intelligence in the controller than emulation of, say, an RH70. Think what you could do if you had an ARMv6 controller running Linux talking MSCP to your J11 system: you could use NFS, USB, SATA, SDHC, etc. But that would take a fairly serious software development effort to build a useful and flexible MSCP iimplementation for Linux. It might also be worthwhile to build a QBUS board for that controller once the software was proven to work.

The approach that daver2 suggested is much more modest: build an interface that will talk to an IDE disk that does not emulate any DEC standard controller, and write a new disk controller driver module for RT-11. You would need to write an additional device driver for RSX, and probably another different driver for RSTS. You would probably need to generate a system image for your hardware on standard DEC hardware (or SIMH), then write a bootable image to a disk that would work with your hardware.
Click to expand...
 
Dave,

Ahh, grasshopper moment here. I missed that "little" detail. That makes things really clear. I already decode the AIO lines, I can pick up the A0 line to handle the byte writes. I have minimal changes to split the /WE line to upper and lower byte. Thank you a million times!!!

On a possible disk controller I'm only thinking non-standard facing out. Interrupts and DMA don't bother me, unless the HW gets unreasonably complex. Unreasonably complex is still yet to be defined.

Based on today's thread I have ordered larger memory chips. Using either 2 or 4 of the 512k chips we could have 1 or 2MB's of memory. That is an effortless change. It will take a few hours and I will have the byte writes supported. The more complex I/O is mainly planning. I need the I/O map to pretty well be decided so I know how many address lines I need to decode. With the 22V10's at some point I run out of pins.

Keep the feedback coming. Again, if anyone wants to get involved please raise your hand.

len


daver2 said:
Len,

This stuff is going back 10 or 15 years - so I would validate it before use!

If you look at your schematics you will see that you have wired LA1 to RAM A0, LA2 to RAM A1 and so forth. LA0 is unused. On a BYTE WRITE, LA0 is used to decide whether the write is to the EVEN byte (LA0='0') or to the ODD byte (LA0='1'). On a WORD WRITE, the state of LA0 is ignored. I suspect that your memory address decoding will need to be a little more complex than it currently is.

As Uniballer has already stated there are lots of tradeoffs here. You do not have to use DMA in a disk controller - although the use of it makes a high performance system and reduces the overhead on the CPU. You could use interrupts - when the disk controller is ready with the next data byte (or status change) it generates an interrupt which the device driver responds to. This is more CPU-intensive than the DMA case - but the CPU can get on and do something else whilst waiting for the next data byte. Or you could just use 'polled' mode - where the device driver sits and waits for the entire block transfer and performs the action all itself. This will not give you a high performance system at all. It all depends upon what you want to achieve. If the goal is a home-brew hacker that is cheap and cheerful with the smallest number of parts then I would look at the interrupt solution (avoiding DMA). To my way of thinking the polled solution just sounds really horrid - but it would result in the cheapest and easiest implementation.

Implementing a non-standard disk controller (or any hardware for that matter) will require a new device driver to be written. And (as has been stated) this can be done with either a 'real' O/S running on a 'real' machine or by the use of SIMH.

I think at some point you will be forced into looking at how interrupts work. For example, most Operating Systems require a clock and most Operating Systems will invariably switch from polled serial I/O to interrupt driven serial I/O the moment they are started. ODT is quite happy to work with polled I/O - but I would like to bet that RT-11 will not. Again - you want to perhaps look at the easiest and simplest method of implementing the limited interrupt functionality you require.

You're the nominated designer - which way do you want to go?

Hope this all makes sense.

Dave
Click to expand...
 
Len,

>>> Ahh, grasshopper moment here. I missed that "little" detail.

Dead simple - easily overlooked...

I'm with Al on this one. If you're not careful - you will end up with more processing power on the disk interface than on the J11 side!

A couple of other things to mull over:

1) We will need some (EP)ROM to boot from. You could use PDP11GUI and ODT on the console of course.

2) One option is not to use a disk interface but a second high-speed serial port and a TU58 emulator running on a Pi (or similar). The Pi could double up as the console port as well (although we definitely have more power than the J11 on the Pi!)

Dave
 
Al Kossow said:
look in the SIMH source
this is a LOT of work. It would be bigger than your whole J11 kludge
Click to expand...

I linked a DEC document on MSCP above. Here it is again: Mass Storage Control Protocol ECO Controlled Version 2.4.0 11 June 1992

Hardware-wise, if the "controller" can read and write J11 memory at will, and get alerted when the PDP-11 writes to the CSR, amd interrupt the PDP-11 when needed, then the rest is software.

The MSCP details are published but an implementation from scratch is probably not for the faint of heart. I don't know how applicable it would be, but the SIMH MSCP code (module PDP11/pdp11_rq.c BTW) is apparently free for use.

I bet implementing this would be a lot of fun, but the time commitment is probably too much for most people (me included).
 
Last edited:
Yes, I think the SIMH soucre would be much easier to divine that the T11 assembly.

Actually... I disagree with the "kludge" sentiment. I actually think stripped from the overhead of the buss and a lot of generic support logic this can be done quite simply and elegantly. It's just a matter of finding the right solution. I have a "little" faith in my abilities. ;)

Now if we are talking Java based solutions, I'd agree. I'm an old fashion c and assembly embedded engineer. At one time we put men on the moon with incredibly simple "stuff".



Al Kossow said:
look in the SIMH source
this is a LOT of work. It would be bigger than your whole J11 kludge
Click to expand...
 
I've got the boot ROM at 177300 in the memory map currently. I've also anticipated more ROM space lower.

daver2 said:
Len,

>>> Ahh, grasshopper moment here. I missed that "little" detail.

Dead simple - easily overlooked...

I'm with Al on this one. If you're not careful - you will end up with more processing power on the disk interface than on the J11 side!

A couple of other things to mull over:

1) We will need some (EP)ROM to boot from. You could use PDP11GUI and ODT on the console of course.

2) One option is not to use a disk interface but a second high-speed serial port and a TU58 emulator running on a Pi (or similar). The Pi could double up as the console port as well (although we definitely have more power than the J11 on the Pi!)

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