• Please review our updated Terms and Rules here

MicroSD disk controller for PDP-11

SuperMax

Member
Joined
Jun 6, 2020
Messages
31
Location
Krasnoyarsk/Russia
Hi!

My colleague and I developed an original MicroSD controller for Russian PDP-11 clones.

The controller provides access to the images of RT11, which are physically represented as files on the MicroSD card.
This allows you to conveniently manipulate disk images.

The controller is also equipped with an Etherne network card, and a WEBDAV server. This allows you to manipulate disk images, as well as files in the image of RT11 from virtually directory in any external environment.

Recently, we tested the controller for PDP-11/73 . Everything works great.

Today I developed a printed circuit board for the original standard (the Russian standard of the PDP-11 boards has other sizes).

Ready to answer questions.
 
Interesting. What does it look like for the PDP-11? I would assume some known other disk controller? Which one? Or can be it configured to appear as different types based on some configuration?
Sounds like the ethernet controller is not visible to the PDP-11? Did you consider possibly making one that would be compatible with some DEC controller and also visible to the PDP-11 side?
And is it possible to disable the WEBDAV? While the idea works fine for RT-11, running RSX or Unix poses a problem, since parts of information in the file system might be cached in memory, and updating the file system in parallel with system operation in that case might cause serious file system brokenness...
 
Max,

Welcome to the VCF forum!

Allow me to introduce you to community. Gentlemen, SuperMax is quite famous (in narrow circles) authority on everything DEC related from the USSR. He is owner/maintainer of the domain pdp-11.ru, with a lot of resources on the subject, with a very wide collection of any DEC related resources at http://mirrors.pdp-11.ru/

I do not claim personal acquaintance, I was just using the resources provided by SuperMax, and I also procured from SuperMax the earlier version of aforementioned controller pcb through the russian forum https://zx-pk.com for the soviet pdp-11 clone ДВК, which I have not assembled yet (I mean both the clone computer and controller itself). I would vouch for quality and completeness of the set I received, it is just I have quite a backlog of hardware waiting for assembly.

I hope SuperMax will become an active member here and will promote a person to person distribution of enthusiast technologies that is quite common and works quite well in Russia these days
 
Interesting. What does it look like for the PDP-11?
Now in the testing phase for PDP-11 it looks like this


on the bus it takes up addresses:
177220 control register
177222 data register
177224 boot address 1
177226 boot address 2
(no any ROMs on the bus!)
driver for this configuration AZ.SYS

also the controller supports an alternative address 177200-177206
and it is possible to install two controllers simultaneously
driver for this configuration AY.SYS

to run you need to type
177226G
or
177224G

Code:
@177226G
AZ v1.2b Boot-I-Cold boot..

AZ (177220) disk driver  v1.2b 2020

RT-11FB  V05.07

.sh all

RT-11FB  V05.07
Booted from AZ4:RT11FB

USR     is set SWAP
EXIT    is set SWAP
KMON    is set NOIND
MODE    is set NOSJ
TT      is set NOQUIET
ERROR   is set ERROR
SL      is set OFF
EDIT    is set KED
FORTRAN is set FORTRA
KMON nesting depth is 3

CLI is set DCL, CCL, UCL, NO UCF

PDP 11/73A Processor
2048KB of memory
Floating Point Microcode
Extended Instruction Set (EIS)
Memory Management Unit
Parity Memory
Cache Memory
60 Hertz System Clock

FPU support

Device    Status                   CSR     Vector(s)
------    ------                   ---     ---------
  DW      Not installed           000000
  SP      Installed               000000   110
  XL      Installed               176500   300 304
  XC      Not installed           173300   210 214
  DL      Not installed           174400   160
  LP      Not installed           177514   200
  LD      Installed               000000   000
  VM      Installed               177572   250
  DX      Not installed           177170   264
  DY      Not installed           177170   264
  DZ      Not installed           000000
  RK      Not installed           177400   220
  DU      Not installed           172150   154
  DM      Not installed           177440   210
  MT      Not installed           172520   224
  MM      Not installed           172440   224
  MS      Not installed           172522   224 300
  MU      Not installed           174500   260
  LS      Installed               176500   470 474 300 304
  NL      Installed               000000   000
  SL      Installed               000000   000
  PI      Not installed           000000   000
  AZ      Resident                177220   000

TT  (Resident)
AZ  (Resident)
    AZ4 = DK , SY
MQ  (Resident)
LD
SL
VM
SP
XL
LS
NL
13 free slots

Job  Name  Console Level State    Low    High  Impure
---  ----  ------- ----- -----    ---    ----  ------
 0   RESORC   0      0   Run     000000 132742 134626

No multi-terminal support

Address   Module    Words
-------   ------    -----
160000    IOPAGE     4096.
157334    AZ          146.
133006    RMON       5227.
001000    ..BG..    23043.

No LD units mounted


I would assume some known other disk controller?
Which one? Or can be it configured to appear as different types based on some configuration?

Initially, the idea of ​​making a convenient controller arose due to problems with a single MFM hard drive controller.
there were practically no other hard drive controllers for Russian clones. and this one itself was not reliable and the MFM drives are already quite old.
we did not copy any ideas. we made a new hardware and driver under RT11.

comparison of the board for the Russian clone and the board of the original format



Sounds like the ethernet controller is not visible to the PDP-11?
Did you consider possibly making one that would be compatible with some DEC controller and also visible to the PDP-11 side?
the ethernet controller is not visible in the PDP-11 because we have not yet decided how to do it better, although we already have the API for TCP/UDP/IP/NTP/DNS/DHCP/SNMP.


And is it possible to disable the WEBDAV? While the idea works fine for RT-11, running RSX or Unix poses a problem, since parts of information in the file system might be cached in memory, and updating the file system in parallel with system operation in that case might cause serious file system brokenness...
WEBDAV is focused on RT11 since it is very common on Russian clones of PDP11. Most of the clones do not have the resources to run RSX and Unix. (most clones have 56kb of RAM and don't have MMU)
however, there are clones with MMU. and we are interested in developing RSX and UNIX for these clones.

I implemented WEBDAV because it is quite simple to do and this allows you to mount a disk to Windows using regular tools.
for samle I opened the RT11 image via webdav and you can access RT11 files directly:

(DSKs open recursively too)

For working with RSX and UNIX, this approach is dangerous and I will not "disclose" the contents of the file system.

also at the moment we do not have competencies to develop drivers for RSX and UNIX - here we are looking for a comrade in the development team

the current version of the "AZ" controller is simple and cheap and does not know how to work in DMA.
we are now developing "AZ V2" which will contain FPGAs and 4MB of memory on board, a 100Mbit network card and of course DMA will be able to.
 
also at the moment we do not have competencies to develop drivers for RSX and UNIX - here we are looking for a comrade in the development team.

That's exactly why I built a SD-Card interface which emulates a RLV12 controller. I know it's just 4 x 10Mbyte but I still hope to find the time to turn this into a MSCP device. At least the same hardware is capable of doing that with only small changes to the CPLD configuration. I have more problems with undertanding the MSCP protocol and the implementations in SIMH and the Unibone.
 
That's exactly why I built a SD-Card interface which emulates a RLV12 controller. I know it's just 4 x 10Mbyte but I still hope to find the time to turn this into a MSCP device. At least the same hardware is capable of doing that with only small changes to the CPLD configuration.
I have more problems with undertanding the MSCP protocol and the implementations in SIMH and the Unibone.

we plan to deliver a relatively large FPGA, so we will have the resources to implement the MSCP protocol.

Now I am planning to order printed circuit boards under the PDP 11 standard for the production of the current version of AZ.
We plan to complete the development of the printed circuit board for the second version in the summer. and then we can do programming FPGAs and STM32.
 
the ethernet controller is not visible in the PDP-11 because we have not yet decided how to do it better, although we already have the API for TCP/UDP/IP/NTP/DNS/DHCP/SNMP.



WEBDAV is focused on RT11 since it is very common on Russian clones of PDP11. Most of the clones do not have the resources to run RSX and Unix. (most clones have 56kb of RAM and don't have MMU)
however, there are clones with MMU. and we are interested in developing RSX and UNIX for these clones.

I implemented WEBDAV because it is quite simple to do and this allows you to mount a disk to Windows using regular tools.
for samle I opened the RT11 image via webdav and you can access RT11 files directly:

(DSKs open recursively too)

For working with RSX and UNIX, this approach is dangerous and I will not "disclose" the contents of the file system.

also at the moment we do not have competencies to develop drivers for RSX and UNIX - here we are looking for a comrade in the development team

the current version of the "AZ" controller is simple and cheap and does not know how to work in DMA.
we are now developing "AZ V2" which will contain FPGAs and 4MB of memory on board, a 100Mbit network card and of course DMA will be able to.

It would be rather nice with an ethernet in addition to the disk. However, unless you make something that looks like a DEQNA or DELQA, it's going to be quite some effort to make use of it.

As for the disk controller, if you could provide some details, and ideally, an implementation on simh that simulates your hardware, then I could write an RSX driver for it. Probably fairly straight forward. The biggest question might be booting, but there might be some ways around that...

But since I don't have a russian machine, and don't really have room for more stuff, I will not be able to test anything on a physical machine, so an implementation of the controller for simh would be the obvious thing. You could test that yourself, using RT-11 to confirm that it works the same as your actual hardware before handing it over.

Given more time, I could probably do the 2.11BSD driver as well, but that would probably take a bit more of an effort.

Oh, and if it don't do DMA, you mean that you are doing polled I/O? That might be a headache for anything more fancy than RT-11...
 
It would be rather nice with an ethernet in addition to the disk. However, unless you make something that looks like a DEQNA or DELQA, it's going to be quite some effort to make use of it.
in the current version there are no resources (no FPGA) for emulating DEQNA, however, I already wrote that we are developing the second version of the controller.

As for the disk controller, if you could provide some details, and ideally, an implementation on simh that simulates your hardware, then I could write an RSX driver for it. Probably fairly straight forward. The biggest question might be booting, but there might be some ways around that...
there is no ready emulation in simh yet. we did not deal with this issue.
however, there will soon be a hardware controller.
Are you comfortable with the controller for QBUS? (free of course)

Given more time, I could probably do the 2.11BSD driver as well, but that would probably take a bit more of an effort.

Oh, and if it don't do DMA, you mean that you are doing polled I/O? That might be a headache for anything more fancy than RT-11...
We don’t have DMA now, but there is the possibility of working in IRQ, which will solve the problem when working with something more complicated than RT 11

full documentation for the controller and driver sources are available. it will take some time to translate it into English.
and just the printed circuit boards will be made.
 
It would be rather nice with an ethernet in addition to the disk. However, unless you make something that looks like a DEQNA or DELQA, it's going to be quite some effort to make use of it.

As for the disk controller, if you could provide some details, and ideally, an implementation on simh that simulates your hardware, then I could write an RSX driver for it. Probably fairly straight forward. The biggest question might be booting, but there might be some ways around that...

But since I don't have a russian machine, and don't really have room for more stuff, I will not be able to test anything on a physical machine, so an implementation of the controller for simh would be the obvious thing. You could test that yourself, using RT-11 to confirm that it works the same as your actual hardware before handing it over.

Given more time, I could probably do the 2.11BSD driver as well, but that would probably take a bit more of an effort.

Oh, and if it don't do DMA, you mean that you are doing polled I/O? That might be a headache for anything more fancy than RT-11...


Missing DMA is not really an issue. Charles Dickman has built a simple Q-Bus Adapter for IDE disks that does not support DMA either and has written a driver for BSD 2.11. As well for RSX-11M this is not a major issue and might not even have an impact on the performance. It all depends how a block is transferred in software. On the other side, the hardware required to implement DMA is very simple for a Q-Bus Adapter, if you are using a large FPGA this only requires additional registers and drivers. My RLV12 only requires a CPLD with 128 macro cells to implement almost all IO functions.

A DELQA Emulation would be a very nice addition, however it must be compatible with the real hardware. https://pdp2011.sytse.net/wordpress/pdp-11/ shows how to do that in a FPGA (and everything else to build a full PDP-11/70 as well)
 
Missing DMA is not really an issue. Charles Dickman has built a simple Q-Bus Adapter for IDE disks that does not support DMA either and has written a driver for BSD 2.11. As well for RSX-11M this is not a major issue and might not even have an impact on the performance. It all depends how a block is transferred in software. On the other side, the hardware required to implement DMA is very simple for a Q-Bus Adapter, if you are using a large FPGA this only requires additional registers and drivers. My RLV12 only requires a CPLD with 128 macro cells to implement almost all IO functions.

A DELQA Emulation would be a very nice addition, however it must be compatible with the real hardware. https://pdp2011.sytse.net/wordpress/pdp-11/ shows how to do that in a FPGA (and everything else to build a full PDP-11/70 as well)

Well, without DMA, you are sitting in the kernel for longer times. Not really the most desireable thing. Yes, it works. But it has an impact. Of course it does. The slower the machine, the worse it is.
A block is transferred in software through a loop doing MOVs and counting.
 
in the current version there are no resources (no FPGA) for emulating DEQNA, however, I already wrote that we are developing the second version of the controller.


there is no ready emulation in simh yet. we did not deal with this issue.
however, there will soon be a hardware controller.
Are you comfortable with the controller for QBUS? (free of course)


We don’t have DMA now, but there is the possibility of working in IRQ, which will solve the problem when working with something more complicated than RT 11

full documentation for the controller and driver sources are available. it will take some time to translate it into English.
and just the printed circuit boards will be made.

I could deal with a real Qbus controller, yes. Simulation would be easier. It's always better with something where it is easy and fast to reboot and examine the state of things all over the place.
But sure, there is also always the risk that there are some issues with the simulation not matching the real hardware, so at some point you want to run it with real hardware anyway.

And yes, you definitely need at least some interrupt to signal when things are ready for transfer. You don't want to ever sit inside a driver, interrupt level or not, waiting for something.
 
Well, without DMA, you are sitting in the kernel for longer times. Not really the most desireable thing. Yes, it works. But it has an impact. Of course it does. The slower the machine, the worse it is.
A block is transferred in software through a loop doing MOVs and counting.

The loop is only an issue on CPUs without cache and you should of course have more than one MOV per loop as done in the kernel block move routine. DMA overhead is quite high on a Q Bus and this overhead is like being in kernel doing nothing. Sitting in the kernel is only an issue with interrupts disabled. Charles Dickman has done some performance tests and did not find a large difference in performance against a real RQDX3 controller. Still as I said the logic to support DMA is simple and should be added.
 
The loop is only an issue on CPUs without cache and you should of course have more than one MOV per loop as done in the kernel block move routine. DMA overhead is quite high on a Q Bus and this overhead is like being in kernel doing nothing. Sitting in the kernel is only an issue with interrupts disabled. Charles Dickman has done some performance tests and did not find a large difference in performance against a real RQDX3 controller. Still as I said the logic to support DMA is simple and should be added.

The loop is always an issue. It's not for free, ever. Yes, with cache you have the loop itself in the cache, but it still reads from the device, and it writes to memory, or the other way around. Which means you are spending quite some time in the loop. Not to mention it actually messing up your cache, if you have one.
Loop unrolling of course makes it faster, at the expense of some more code memory used, but it is still a bunch of code being executed. Time which otherwise would have been spent elsewhere.

But sure, if the CPU is just idle anyhow, then it matters little.

DMA overhead on the Qbus is less than on the Unibus. And both are less than CPU execution.

(And the RQDX3 is close to the worst things to compare against. :) It's not that fast to start with, not to mention the slow disks it uses...)
 
Greetings!

the board AZ for QBUS was ordered at the beginning of June, but it cannot cross the Chinese border ...
The delivery of parcels due to the coronavirus has become very difficult :(



however, at this time my colleague and I were developing AZ 2020 - with FPGA, memory and STM32.
here is the first estimate of the printed circuit board for the MPI (Russian version of QBUS)



after a fundamental check for operability - a version for QBUS
 
Tough time, but put together a trial batch - everything works fine, no modifications are required.

Assembled AZ QBUS


For those interested in the development of the project, I can send AZ QBUS in a complete set:
- AZ QBUS controller
- MicroSD card 16GB with RT11
- ST-LINK V2 programmer
- LAN card
- wire for network card
- a box for a network card [cut the holes yourself]

Of interest is the development of a driver for UNIX
 
Do you intend to sell it? What would be the price and shipping cost to US? Would you sell an unassembled kit and what would be pricefor that?
 
Do you intend to sell it? What would be the price and shipping cost to US? Would you sell an unassembled kit and what would be pricefor that?

Yes, if you are interested, the controllers will be available as a DIY Kits.

I also plan to release assembled controllers.
at the moment, the orientation will be as follows - $ 100 full set, plus shipping costs

at the moment 3 controllers are ready, and I am ready to send them to those who undertake to develop a driver for RSX-11 or UNIX.

I would have developed a driver for UNIX myself, but I do not have UNIX installed for PDP-11 due to the lack of a SCSI controller


now I am expecting components to build controllers.

Detailed controller description
https://forum.maxiol.com/index.php?showtopic=5541

Due to the fact that the used GAL16V8 is discontinued, we are planning to modify the controller: we will use a small FPGA

development of new firmware for the controller continues - this is an evolving product.

Accordingly, I will designate an approximate set of functionality for development:

-Firmware update via SD card image
-Firmware update via the Internet
-Managing network settings via ini file [this is already under testing]
-Development of the functionality of mounting images through an ini file
-Mounting images via SET AZ command
-Expanding Supported Disks for RSX-11 Operation
-External loader, those user code that is downloaded into the machine and launched (convenient for developing your extensions based on AZ - for example, the boot menu)
[under testing]
-Clock [under development]
 
at the moment, the orientation will be as follows - $ 100 full set, plus shipping costs

If that is price for a kit, it would be somewhat steep for me at the moment. Maybe just bare PCB would be an option for me then.

I would have developed a driver for UNIX myself, but I do not have UNIX installed for PDP-11 due to the lack of a SCSI controller

What I would do in this situation, I would rather write an emulator of the board for some existing pdp-11 emulator that supports booting unix, such as simh, and then develop driver on that platform.
 
If that is price for a kit, it would be somewhat steep for me at the moment. Maybe just bare PCB would be an option for me then.
this is the price for a ready assembled and tested controller

small DYI kit - $ 20, plus shipping costs
- printed circuit board
- flashed GAL microcircuits

big DYI kit - $ 50, plus shipping costs
- printed circuit board
- all details, including flashed GAL microcircuits
- ST-LINK V2

not included ( it is freely sold in many places)
- network card based on ENC28J60
- wire to the network card
- MicroSD card

What I would do in this situation, I would rather write an emulator of the board for some existing pdp-11 emulator that supports booting unix, such as simh, and then develop driver on that platform.
I'll try
 
Back
Top