Re: A little power circuit explanation please

[Don North via cctalk]

On 8/22/2017 4:30 PM, Adrian Graham via cctalk wrote:

Hi folks,

Failing Atari PSU aside I remembered a question I had ages ago but never posted 
about the power circuit of another 80s home micro, the Enterprise 64. This 
machine is powered by a 2A 9V unregulated PSU and internally there’s a pair of 
7805s and a 78L12 to smooth things out.

There’s also a small transformer coil in there too (L1 on the following 
schematic) and I’m not entirely sure what it’s for. Here’s the schematic of the 
original circuit, any enlightenment gratefully received since I have an 
Enterprise 64 with a dead coil :)

http://www.binarydinosaurs.co.uk/ep64PowerRegulators.png 


Cheers!

—
Adrian/Witchy
Binary Dinosaurs - Celebrating Computing History from 1972 onwards


It is part of a switching power supply to boost the 9VDC input to 13.7V or 
greater so that the 78L12 can regulate it down to 12V.


L1 is dual purpose; it provides feedback to the boost switching regulator 
oscillator (the tap) and is the main inductor for the boost supply generator.

Re: RX02 *.DSK convert to PDP11GUI Image format

[Don North via cctalk]

On 8/15/2017 2:10 AM, Jerry Weiss via cctalk wrote:

On Aug 14, 2017, at 11:49 PM, Glen Slick via cctalk  
wrote:

On Sun, Aug 13, 2017 at 9:00 AM, Ulrich Tagge via cctalk
 wrote:

Hi all,

maybe someone can help.
I would like to install TCP/IP on my RT-11 system.
After a short search I have found the following, which I would use:
http://www.classiccmp.org/PDP-11/RT-11/freeware/decus11/110939/rthtml/tcpget.htm
But the images are in DSK format, but I can't write them with PDP11GUI,
which is the only way I have at the moment.

I would take a quick look at those .DSK images to see what I can make
of them, but none of the download links on that page work for me.

For example, I can't download this .DSK image. Do these links work for
other people?
ftp://shop-pdp.kent.edu/du3:/tcpip.pkg/tcpipm.dsk

Glen - Try this link  ftp://shop-pdp.net/pub/tcpip/tcpip/tcpipm.dsk

As far as the DSK format, the files from at Alan’s site are logical
disk images.  Logical block 0,1,2,3 from from a DY sized volume starting at
Track 1.  In this case track 0 is ignored.

This is what RT-11 expects and uses for Logical Disks (LD:).
I’ve used Kermit and FTP to copy this file from my OSX disk to
a RT-11 DU type drive as a file. They mount and operate as
LD: drive without additional conversion.


SIMH on the other hand as I understand it, expects disk images to represent
the sectors of a disk.  I did a few checks and its appears faithful to the RX02 
format.
It expects 256 byte sectors for track 0 (qty 26) and 512 byte sectors
for the rest of the disk as Don pointed out.  You need to prepend 6556. bytes
of zero to the above file to get things started. But this is not the entire 
story.

 $  dd of=pad.dsk if=/dev/zero bs=256 count=26
 6656 bytes transferred in 0.000230 secs
 $  cat pad.dsk tcpipm.dsk >tcpipm_V2.dsk
  
When you attach tcpipm_V2.dsk in SIMH to an RY device (DY to RT-11), the expected

boot block is visible as (RT-11) Block #0.

 .dump/rad50/ascii/end:0 dy:/term
 DY:/X/E:0
 BLOCK NUMBER  00
 000/ 000240 05 000404 00 00 041420 116020 000400 * 
..C*
   D   E FT  J*HX82 FP
 020/ 004067 44 15 00 005000 041077 047517 026524 
*7.$...?BOOT-*
  ALW  6  M   AX JW9L$WGJD
 040/ 026525 067516 061040 067557 020164 067157 073040 066157 *U-No boot on 
vol*
  GJEQ2NO. Q3GEG.QZ1R6 QM9
 060/ 066565 006545 005012 000200 105737 177564 100375 112037 
*ume._.t.}…*

For an RT-11 Volume, the next logical block #1 should be the home block.  In 
this case,
its not. Instead it is found at block #7, but offset (early) -256. bytes from 
its normal location in the block.
The first directory block should start at block #6.  Here there directory 
blocks starting at block #3 and #4.

So the padding is not enough here.  The 6 sector skew and interleave 
implemented in the handler come
into play.  I haven’t looked at the code, but SIMH probably expects the disk to 
be sequential copies of
physical sectors for the floppy drives.  This makes sense, as the emulator 
presents them to the DY: handler
where it will de-skew the data.

Thus a DSK file representing logical blocks will not work for a floppy image in 
this case.
A small program can probably be written to skew/Interweave the data to make 
them usable directly in SIMH.

Images of most other DEC media probably don’t encounter the problem, as their 
device handler or driver doesn't
implement either skew or interleave directly.  Most of the ones I encounter 
leave that to the disk media formatting
and/or controller firmware.


Jerry
j...@ieee.org

Jerry's analysis is spot on. What Alan generated on his site were 988. block 
long logical container files, not RX02 device file images.


One could write a simple program that reads the binary ".DSK" file, and 
implements the track 0 prepend, 2:1 sector interlave, and +6 sector track to 
track offset to generate true ".RX2" disk images with the appropriate sector 
interleaves, as an exact image of the RX02 media. This .RX2 file would be 
mountable directly under SIMH (and presumably PDP11GUI) as an emulated RX02 device.


One simple (heh) way to do the conversion without having to do any programming 
would be to use SIMH running RT11. Boot RT11 from some media (say RL02) and then 
mount the .DSK file as an MSCP device image (MSCP supports variable sized 
physical disks using logical block order). Then mount an RX02 device under RT11; 
it will use the native SIMH .RX2 file format. Then under RT11 copy 988. blocks 
from the MSCP (DU) device to the RX02 (DY) device. RT11 thru its RX02 driver 
will handle all the low level details of skipping track 0, sector-sector 
interleave, and track-track sector skew.


Don

Re: RX02 *.DSK convert to PDP11GUI Image format

[Don North via cctalk]

On 8/13/2017 4:47 PM, Don North via cctalk wrote:

On 8/13/2017 11:34 AM, Jerry Weiss via cctalk wrote:

On Aug 13, 2017, at 12:59 PM, Ulrich Tagge <u.ta...@gmx.de> wrote:

Hi Jerry,

I have tried with PDP11GUI, but the first message says "The image contains 
only 505856 bytes, but disk has 512512 bytes".
I have written some disks, and have ignored this message, but none of them 
is readable under RT-11.

.dir dy0:
?DIR-F-Error reading directory

So I think the DSK format is different from the one PDP11GUI uses.
In the documentation I have seen, that the format is the same as SimH uses.
Image file format
Every DEC disk or tape is logically represented as a linear list of 
“blocks”. The block size differs between 128 byte and 1024 bytes. Reading 
and writing is based on block numbers.

The file format is that of SimH: a file image is just a stream of blocks.

Kermit would be a possibility, and I will try it later on.

Many Greetings
Ulrich
DEC OS’es typically do not do anything with track 0 on an RX02, and start 
with track 1.  I can only guess that PDP11GUI is trying to use the entire disk.


If there is an option to start at track 1 or skip the first 30 (?) blocks, 
that might work.


Note that ?DIR–F–Error reading directory is a hardware error.
Bad data would instead cause a ?DIR–F–Invalid directory.

Regards,
Jerry

The RX01 physical format is 77. tracks of 26. sectors (2002. total sectors) of 
128. bytes, or 256,256. bytes.
For RX02 track and sector counts are the same, but there are 256. bytes per 
sector, for a total of 512,512. bytes.


The .DSK images are (usually!) a pure physical image of the disk, in 
track/sector order, from track 0 sector 1 to track 76. sector 26.
The images include track 0 which is not used by any DEC O/S. The boot block / 
filesystem starts at track 1 sector 1.

Note that sectors are numbered 1. thru 26. There is no sector 0.

All the DEC operating systems use interleaving of logical to physical sectors 
on the RX device images, so they are unique
in the sense that the image file is not just a logical block 0. to block N-1. 
image of 512. byte blocks as most/all other image files are.


If your RX02 image file is only 505,856. bytes then this is 6656. bytes 
(exactly 26. * 256.) too short, so it would appear track 0 is skipped.
So when someone imaged the floppy they decided to skip over track 0 (how 
thoughtful of them).


You might try using unix dd to prepend 6656. bytes of zero as a header, and 
then copy the rest of the data to form a 512,512. byte file.
That may work on PDP11GUI (and should under SIMH as well) ***IF*** the person 
who imaged the disk just dropped track 0.
If they ALSO decided to de-interleave the physical sectors to logical blocks 
then the process just got a lot more complicated.
You will then need to undo the physical/logical conversion of the sectors to 
blocks to get back to a raw device image of the RX media.


Another thought ... if the disk image was taken as a logical filesystem dump (of 
blocks 0. thru 987. for the 505,856. byte image) then that image should be 
mountable under SIMH as an MSCP disk device image. MSCP will support arbitrary 
sized disk images of logical blocks.


So one could boot RT11 for example from an RK05 image, and then access the 
unknown image on an MSCP disk device to see if it has a valid RT11 filesystem on 
it (or using other bootable images like RSX, as necessary).


If the filesystem is valid and has meaningful files on it that would indicate it 
is a logical disk device image, as opposed to a physical sector by sector image 
of all tracks (or skipping track 0.) as one would normally expect for RX01/2 
media for the PDP-11.

Re: RX02 *.DSK convert to PDP11GUI Image format

[Don North via cctalk]

On 8/14/2017 12:40 AM, Ulrich Tagge via cctalk wrote:

Hi all,

I have tried to find a specification about the DSK Image format, but have only 
found the the following: http://www.cpctech.org.uk/docs/dsk.html , which looks 
like the focus is more on CPC related Disks.


Is there any detailed description somewhere in the www about the DSK format?

Many Greetings

Ulrich


I think you'll find many different '.DSK' formats on the web; there is not one 
universal definition. It depends on the program that wrote the .DSK files.

Re: RX02 *.DSK convert to PDP11GUI Image format

[Don North via cctalk]

On 8/13/2017 11:34 AM, Jerry Weiss via cctalk wrote:

On Aug 13, 2017, at 12:59 PM, Ulrich Tagge  wrote:

Hi Jerry,

I have tried with PDP11GUI, but the first message says "The image contains only 
505856 bytes, but disk has 512512 bytes".
I have written some disks, and have ignored this message, but none of them is 
readable under RT-11.
.dir dy0:
?DIR-F-Error reading directory

So I think the DSK format is different from the one PDP11GUI uses.
In the documentation I have seen, that the format is the same as SimH uses.
Image file format
Every DEC disk or tape is logically represented as a linear list of “blocks”. 
The block size differs between 128 byte and 1024 bytes. Reading and writing is 
based on block numbers.
The file format is that of SimH: a file image is just a stream of blocks.

Kermit would be a possibility, and I will try it later on.

Many Greetings
Ulrich

DEC OS’es typically do not do anything with track 0 on an RX02, and start with 
track 1.  I can only guess that PDP11GUI is trying to use the entire disk.

If there is an option to start at track 1 or skip the first 30 (?) blocks, that 
might work.

Note that ?DIR–F–Error reading directory is a hardware error.
Bad data would instead cause a ?DIR–F–Invalid directory.
  


Regards,
Jerry

The RX01 physical format is 77. tracks of 26. sectors (2002. total sectors) of 
128. bytes, or 256,256. bytes.
For RX02 track and sector counts are the same, but there are 256. bytes per 
sector, for a total of 512,512. bytes.


The .DSK images are (usually!) a pure physical image of the disk, in 
track/sector order, from track 0 sector 1 to track 76. sector 26.
The images include track 0 which is not used by any DEC O/S. The boot block / 
filesystem starts at track 1 sector 1.

Note that sectors are numbered 1. thru 26. There is no sector 0.

All the DEC operating systems use interleaving of logical to physical sectors on 
the RX device images, so they are unique
in the sense that the image file is not just a logical block 0. to block N-1. 
image of 512. byte blocks as most/all other image files are.


If your RX02 image file is only 505,856. bytes then this is 6656. bytes (exactly 
26. * 256.) too short, so it would appear track 0 is skipped.
So when someone imaged the floppy they decided to skip over track 0 (how 
thoughtful of them).


You might try using unix dd to prepend 6656. bytes of zero as a header, and then 
copy the rest of the data to form a 512,512. byte file.
That may work on PDP11GUI (and should under SIMH as well) ***IF*** the person 
who imaged the disk just dropped track 0.
If they ALSO decided to de-interleave the physical sectors to logical blocks 
then the process just got a lot more complicated.
You will then need to undo the physical/logical conversion of the sectors to 
blocks to get back to a raw device image of the RX media.

Re: PDP-11: DR11-C to FPGA or 1284?

[Don North via cctalk]

On 7/31/2017 2:52 PM, Ethan Dicks via cctalk wrote:

On Mon, Jul 31, 2017 at 1:52 PM, Fritz Mueller via cctalk
 wrote:

On Jul 31, 2017, at 8:19 AM, Jay Jaeger  wrote:
I have Ethernet shield for my Arduino Uno, and I use that and a simple
(in my case, perl,  program to talk to the final destination device.  I
have two cables, one for each direction, from the DR11-C (not using DMA)
to the Arduino.

Jay, does your Arduino support TTL-level signaling, or did you have to use some 
level-shifting chips?

"Arduino" covers a lot of hardware, but in the case of the Uno and
Mega (and many other models), the GPIO pins are CMOS-level (5V Vcc,
but CMOS thresholds, not TTL).  Not a massive fanout, but a few mA per
pin - at least one TTL load.  You can't drive 8 LEDs from one port,
but you can sink 1-2 LEDs on the same port (the specifics are well
covered in the Atmel datasheets for each processor).


I'm more familiar with FPGA platforms than Arduino, but this might give me a 
good excuse to finally play around with Arduino a bit!

I know there are people here who are not fond of them for various
reasons (some non-technical), but I do a lot of quick-and-dirty things
with them.  They are frequently overkill, but with clones at $6 (and
licensed ones under $30), they do a lot.  Where you can run into
complications is trying to use all the Arduino library function calls
to, say, read and write I/O pins at megahertz speeds (the MCU is
routinely clocke at 16MHz or 20MHz, and mostly
one-instruction-per-cycle).  digitalWrite() and digitalRead() end up
executing hundreds, if not thousand of machine cycles.  You can, of
course, write in AVR assembler, but mostly, just banging on the
relevant DDR and Data registers in C works plenty fast enough, much,
much faster than the Arduino library calls.

TL;DR - the chips are fine.  The libraries are heavy.  Someone coming
from another architecture can get up to speed pretty quickly to read
and write bits and bytes from GPIO pins.

-ethan

Totally agree with the above comments. As an example, my RX02 drive emulator 
(runs on an Arduino Mega2560 with a custom interface shield) code is available 
here: https://github.com/AK6DN/rx02_emulator  as an example. Uses the SDcard 
library, and does very high speed bit banging on GPIO ports thru optimized C 
routines to act as an RX02 drive connected to RX11/RX211/RXV11/RXV21/RX8E-28 
interfaces in a PDP system.

Re: PDP-11: DR11-C to FPGA or 1284?

[Don North via cctalk]

On 7/31/2017 10:52 AM, Fritz Mueller via cctalk wrote:

On Jul 31, 2017, at 8:19 AM, Jay Jaeger  wrote:

I have Ethernet shield for my Arduino Uno, and I use that and a simple
(in my case, perl,  program to talk to the final destination device.  I
have two cables, one for each direction, from the DR11-C (not using DMA)
to the Arduino.

Awesome -- it seemed likely somebody here would have done this sort of thing 
already :-)

Jay, does your Arduino support TTL-level signaling, or did you have to use some 
level-shifting chips?  How did you arrange the cabling/packaging?

I'm more familiar with FPGA platforms than Arduino, but this might give me a 
good excuse to finally play around with Arduino a bit!

--FritzM.


Arduino UNO (the 'original') and the Mega2560 big brother both use 5V I/O 
microprocessors, so all the I/O is directly 5V capable.


I happen to prefer the Mega2560 based design because it has a more capable CPU 
(lots more flash and RAM), 4 hardware serial ports, and lots of I/O (50+ pins) 
and it is not that much more expensive (based on Amazon clone suppliers; direct 
from Arduino .org suppliers it is priced way too high for the components it uses).


I used the Mega2560 in my RX01/02 emulator design, with a custom shield to 
interface to DEC standard RX11/211/8E 5V controllers using 5V logic. Works fine.


Arduino is pretty simple to program in more or less vanilla C if you want. The 
tools are freely downloadable from the web from www.arduino.cc

Re: PDP-11: DR11-C to FPGA or 1284?

[Don North via cctalk]

On 7/30/2017 7:47 PM, Fritz Mueller via cctalk wrote:

So, I have lately been using PDP11GUI to retrieve images of RK05 disk packs and 
to write images to these packs on a PDP-11.  This is awesome, but its a bit 
frustrating that it takes a couple hours to read or write an image this way.

I do, however, have a couple of DR11-C parallel interface cards.  It occurred 
to me that it might be pretty straightforward to interface one of these to an 
FPGA eval card, and this would give me a much higher-bandwidth way to move data 
on and off the PDP-11 (in fact, the RK11 could even be run in 
non-increment-address-mode pointed at the DR11-C, which would be pretty speedy.)

Another approach might be to interface the DR11 directly to a 1284-to-USB 
adapter.  This would only be eight bits wide, so you couldn't use the direct 
RK11/DR11 NPR hack, but it would still be a lot faster than 9600 baud serial.

Before I put too much thought into either of these, I thought I'd ping here to 
see if anybody else has already interfaced a DR11 in either of these two ways?

 cheers,
   --FritzM.


Or interface the DR11-C parallel port to an Arduino (I like the Mega2560 boards 
myself) that has an SDcard shield.


Then just write a bit of Arduino code to interface to the DR11-C port and write 
data to the SDcard using the SDfat library.


When done, just sneakernet the SDcard over to your PC and copy the files.

On the PDP-11 side just write a little macro11 program that reads all blocks of 
the disk and dumps them to the DR11-C, with appropriate handshaking, of course.


Don

Re: TU-58 in simh

[Don North via cctalk]

On 4/21/2017 6:55 PM, allison wrote:

On 04/21/2017 09:34 PM, Don North via cctalk wrote:

On 4/21/2017 4:25 PM, Brian L. Stuart via cctalk wrote:

I've seen suggestion that TU-58s are emulated in simh on
PDP-11s.  However, I'm not seeing it in a show dev and my
google-fu is failing me to find any info on how to use it.  Any
pointers on how to boot from a TU-58 image?

TIA,
BLS


Using simh v4.0 from github, in the PDP11 simh ini file:

*set tdc enable**
**attach tdc0 tu58.dsk*

then assuming tu58.dsk is a bootable image:

*boot tdc0*

Only two units 0,1 are supported (just like a real dual drive) and the
images must be 262,144 bytes in size (like a real tu58 cartridge).


I remember TDC was DECcassette (TU-60).

The boot for RT-11 would be BOOT DD:  the tape image should be built
with a DD driver or DDX for RT11XM.
Least that how it works for my physical PDP-11/23 RT11 system.
Generally all the files that should be on
a RT11 floppy needs to be on the tape.

For other OSs it first has to fit on the device and have a suitable
driver for TU58.

Allison

TU58 is really not much useful for running any real DEC OS other than XXDP, to 
run diagnostics; that is what I use it for on my 34 and 44 (real hardware). I 
don't use TU58 at all under SIMH (does not make much sense).


RT-11SJ works running from TU58, but just barely, and it is not really usable. 
RT11 is barely usable once you move up to a dual drive RX02.



test[991] pdp11

PDP-11 simulator V4.0-0 Betagit commit id: 17903827
sim> set tdc enable
sim> att tdc0 11xxdp.dsk
TDC: buffering file in memory
sim> boot tdc0

BOOTING UP XXDP-XM EXTENDED MONITOR

XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM DD0
124KW OF MEMORY
NON-UNIBUS SYSTEM

RESTART ADDRESS: 152000
TYPE "H" FOR HELP !

.DIR

ENTRY# FILNAM.EXTDATE  LENGTH  START VERSION

1  XXDPSM.SYS   1-MAR-89 2947 E.0
2  XXDPXM.SYS   1-MAR-89 39000104 F.0
3  DRSSM .SYS   1-MAR-89 24000153 G.2
4  DRSXM .SYS   1-MAR-89 48000203 C.0
5  DATE  .SYS   1-MAR-89  2000263 B.0
6  DB.SYS   1-MAR-89  2000265 C.0
7  DD.SYS   1-MAR-89  3000267 D.0
8  DIR   .SYS   1-MAR-89  7000272 D.0
9  DL.SYS   1-MAR-89  4000301 D.0
   10  DM.SYS   1-MAR-89  4000305 C.0
   11  DR.SYS   1-MAR-89  3000311 C.0
   12  DU.SYS   1-MAR-89  4000314 E.0
   13  DUSZ  .SYS   1-MAR-89  2000320 C.0
   14  DY.SYS   1-MAR-89  3000322 D.0
   15  LP.SYS   1-MAR-89  1000325 B.0
   16  MM.SYS   1-MAR-89  3000326 C.0
   17  MS.SYS   1-MAR-89  4000331 C.0
   18  MU.SYS   1-MAR-89  4000335 E.0
   19  HELP  .TXT   1-MAR-89 29000341
   20  PATCH .BIC   1-MAR-89 31000376
   21  SETUP .BIC   1-MAR-89 27000435
   22  UPDAT .BIC   1-MAR-89 29000470
   23  XTECO .BIC   1-MAR-89 26000525
   24  FLOAT .BIN   1-MAR-89 18000557

FREE BLOCKS:   126

.

Re: TU-58 in simh

[Don North via cctalk]

On 4/21/2017 6:34 PM, Don North via cctalk wrote:

On 4/21/2017 4:25 PM, Brian L. Stuart via cctalk wrote:

I've seen suggestion that TU-58s are emulated in simh on
PDP-11s.  However, I'm not seeing it in a show dev and my
google-fu is failing me to find any info on how to use it.  Any
pointers on how to boot from a TU-58 image?

TIA,
BLS


Using simh v4.0 from github, in the PDP11 simh ini file:

  set tdc enable
  attach tdc0 tu58.dsk

then assuming tu58.dsk is a bootable image:

  boot tdc0

Only two units 0,1 are supported (just like a real dual drive) and the images 
must be 262,144 bytes in size (like a real tu58 cartridge).



Removed the '*'s from the above simh commands (which were inserted because of 
thunderbird bolding the text ...)

Re: TU-58 in simh

[Don North via cctalk]

On 4/21/2017 4:25 PM, Brian L. Stuart via cctalk wrote:

I've seen suggestion that TU-58s are emulated in simh on
PDP-11s.  However, I'm not seeing it in a show dev and my
google-fu is failing me to find any info on how to use it.  Any
pointers on how to boot from a TU-58 image?

TIA,
BLS


Using simh v4.0 from github, in the PDP11 simh ini file:

*set tdc enable**
**attach tdc0 tu58.dsk*

then assuming tu58.dsk is a bootable image:

*boot tdc0*

Only two units 0,1 are supported (just like a real dual drive) and the images 
must be 262,144 bytes in size (like a real tu58 cartridge).

Re: booting os/8

[Don North via cctalk]

On 3/22/2017 5:03 PM, Don North wrote:

On 3/22/2017 4:25 PM, Bill Gunshannon wrote:
Look here: http://www.vcfed.org/forum/blog.php?12663-AK6DN   for info on my 
Arduino based RX02 emulator using a microSD card.
Works on RX11/RXV11/RX8E as RX01, RX211/RXV21/RX28 as RX02. Passes DEC 
hardware diagnostics.


Reinhard has done an FPGA based RL01/2 drive emulator, see: 
http://www.pdp11gy.com/indexE.html#file:///E:/homepage/indexE.html


Don
aka AK6DN
__

I saw that.  I ordered a set of boards from OSHPark today.  Once they come I 
will see about ordering the

parts and building at least one.  I may wish I had more controillers. :-)

I will take a look at the FPGA solution.  But I still have to ask, is there 
any reason why it could not be done
with an Arduimo like the RX emulator?  I haven't researched it deeply, but I 
never thought the RL drive

itnerface was all that complex.

bill



If you are still interested I still have blank PCBs for $10 each (either 2n7K 
or 8641 based), plus Sparkfun microSD adapters $5 ea, and then shipping.


OSHpark is good (I use them for proto) but it will cost you something like $75 
for three boards since they are 4 layer. Let me know if you are interested.


The RL0x interface is very different and requires some kind of high speed 
signal decoder to implement (Reinhard did it in an FPGA plus an embedded CPU).


The RX0x interface is driven by the drive as the master, so no high speed 
logic is required on the Arduino side, just bit banging I/O ports.


Don

Just checked my stock ... I have (5) 8641 based PCB, and (10) 2n7k based PCB 
left, and corresponding microSD adapters.


The 2n7K vs 8641 designs are functionally compatible (100% same software); the 
revised 2n7K design uses discrete transistor O.C. drivers and
HCT14 RCVRs in place of the 3x8641 (which are more or less unobtanium at this 
point, unless you have a well stocked DEC stockroom).


The two designs work the same, there is no discernible difference between them 
operationally.


As an aside I source Arduino Mega2560s from Amazon, you can get 100% a 100% 
compatible clone for $10-$12 vs $45 for a 'genuine' Arduino Mega2560.


Don

Re: booting os/8

[Don North via cctalk]

On 3/22/2017 4:25 PM, Bill Gunshannon wrote:

Look here:   http://www.vcfed.org/forum/blog.php?12663-AK6DN   for info on my 
Arduino based RX02 emulator using a microSD card.
Works on RX11/RXV11/RX8E as RX01, RX211/RXV21/RX28 as RX02. Passes DEC hardware 
diagnostics.

Reinhard has done an FPGA based RL01/2 drive emulator, see:   
http://www.pdp11gy.com/indexE.html#file:///E:/homepage/indexE.html

Don
aka AK6DN
__

I saw that.  I ordered a set of boards from OSHPark today.  Once they come I 
will see about ordering the
parts and building at least one.  I may wish I had more controillers. :-)

I will take a look at the FPGA solution.  But I still have to ask, is there any 
reason why it could not be done
with an Arduimo like the RX emulator?  I haven't researched it deeply, but I 
never thought the RL drive
itnerface was all that complex.

bill



If you are still interested I still have blank PCBs for $10 each (either 2n7K or 
8641 based), plus Sparkfun microSD adapters $5 ea, and then shipping.


OSHpark is good (I use them for proto) but it will cost you something like $75 
for three boards since they are 4 layer. Let me know if you are interested.


The RL0x interface is very different and requires some kind of high speed signal 
decoder to implement (Reinhard did it in an FPGA plus an embedded CPU).


The RX0x interface is driven by the drive as the master, so no high speed logic 
is required on the Arduino side, just bit banging I/O ports.


Don

Re: booting os/8

[Don North via cctalk]

On 3/22/2017 10:47 AM, Bill Gunshannon via cctalk wrote:


From: cctalk [cctalk-boun...@classiccmp.org] on behalf of W2HX via cctalk 
[cctalk@classiccmp.org]
Sent: Tuesday, March 21, 2017 11:49 PM
To: General Discussion: On-Topic and Off-Topic Posts (cctalk@classiccmp.org)
Subject: booting os/8

Hi folks,

I have a PDP-8/e that I've been working on. I have completed construction of AK6DN's 
RX01/02 emulator. I got to the step tonight where I was trying to boot an OS/8 disk image 
and nothing was happening. I realized that I do not have the bootstrap diode board in my 
8/e so begin the bootstrap triggered by the "SW" switch.

Does anyone have the program I can toggle in for the bootloader? What I found 
is somewhat confusing. Here is a discussion on this topic.

https://groups.google.com/forum/#!searchin/alt.sys.pdp8/RX01$20boot|sort:relevance/alt.sys.pdp8/9-GCoA0PCLA/370T3R-Ru_AJ

It seems one fellow was attempting to edit/improve the bootloader of another 
fellow. I was wondering if anyone has distilled this into something simple. At 
the moment, I care only about booting from RX01-Disk0.

Any pointers greatly appreciated. Thanks
Eugene W2HX
___

Well, I am sure glad someone posted this.  I had never heard of the work done 
by AK6DN and have considered
looking into such a project in the past.

So, has anyone looked at someting sililar for RL drives?

bill


Look here:   http://www.vcfed.org/forum/blog.php?12663-AK6DN   for info on my 
Arduino based RX02 emulator using a microSD card.
Works on RX11/RXV11/RX8E as RX01, RX211/RXV21/RX28 as RX02. Passes DEC hardware 
diagnostics.

Reinhard has done an FPGA based RL01/2 drive emulator, see:   
http://www.pdp11gy.com/indexE.html#file:///E:/homepage/indexE.html

Don
aka AK6DN

Re: quick omnibus question

[Don North]

I would also do a cleaning of your empty backplane with a good vacuum cleaner 
nozzle. It is not uncommon for bits of conductive detritus to fall into the 
backplane over time. Given that the pins are adjacent on the connector it might 
be a possible cause.


Vacuuming out any stuff that has accumulated over time will be beneficial in any 
event. I have had mysterious 'opens' occur on a card slot when an old sticky 
label that lost is stick fell into the slot, and got wedged between a card pin 
and the connector.


Don

On 1/22/2017 2:05 PM, W2HX wrote:

Thanks to several who have made suggestions. Noel, Tony, Jim, and Paul thank 
you. The system has been very thoroughly cleaned and the PS has been load 
tested. The front panel has had some bulbs replaced as well.

I took all my boards (except the front panel) to a friend's house with a 
working 8e and tested each board in succession. I found that most boards worked 
but M8310 was not. And 8K of 32K was working fine. Above 8K there was a stuck 
bit in the core. But with 8K working we were able to boot OS8 with all of my 
boards except M8310 (oh, and I borrowed his serial tty card).

I did know about these MA7-MD4 bits that seem stuck together in my machine. But 
we did not see this problem in my friend's machine. So I am concluding the 
problem could be in one of 3 possible places. The 8310 card, the front panel, 
the bus itself.  Because these are the three components that were not part of 
the test in my friend's machine.

Next step was to see if these two bus lines are shorted somehow. After wasting 
time looking at a document that was wrong, I checked the M8310 card for shorts 
between MA7 and MD4 and none existed.

I am waiting on a douglas electronics card extender in the mail to check the 
bus itself. This issue could still be in the front panel or in some logic 
further upstream. This will be interesting to troubleshoot.

FYI
That omnibus_legenda.pdf file on bitsavers is CLEARLY erroneous based on what 
you guys are telling me and I found another document that indeed indicates that 
file is wrong. Too bad that this file is stored on bitsavers when it is 
incorrect.

I hope this email can be found by the next guy searching for the omnibus 
details so they can avoid wasting time.
THIS FILE IS WRONG
http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp8/pdp8e/Omnibus_legenda.pdf

This file shows the Omnibus signal locations CORRECTLY (extracted from a larger 
document)
http://w2hx.com/x/VintageComp/PDP-8e/Docs/Omnibus_Card_Edge_Designations.pdf




-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of W2HX
Sent: Sunday, January 22, 2017 11:28 AM
To: General Discussion: On-Topic and Off-Topic Posts (cctalk@classiccmp.org)
Subject: quick omnibus question

Hi friends.
I am 100% new to my pdp8e and I am troubleshooting a problem.
The problem is that whenever address bit 7 I asserted, I also see MD bit 4 
asserted.

I am hoping there is a simple short somehow between these lines somewhere. I 
should mention that my setup has known working boards with the exception of 
M8310 does not work (all of my boards were tested in another machine one by 
one). So I am hoping the problem noted above might be occurring on the M8310 
board itself.

I found a document that describes the signals on the bus located here:
http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp8/pdp8e/Omnibus_legenda.pdf

I noticed that B1J (MA7) is directly adjacent to B1K (MD4). Could this be 
related?
So I decided to pull my 8310 and check the resistance between these signals on 
the edge of the board. However, I cannot seem to square the signals named in 
the PDF and what I see on the card edge connector on the board.

I am wondering if I am not understanding the PDF correctly. I have the board 
sitting on my table with the components facing up and the omnibus card edge is 
at the bottom of the card.  Going from left to right, do I have connectors ABCD 
or is it something else? Maybe DCBA?

Other than the reference PDF, is there another PDF that has a more detailed 
description of the bus and the signals?

Thanks
Eugene

Re: pdp-11 assembly standards

[Don North]

On 1/8/2017 9:10 PM, Brent Hilpert wrote:

OK, what was the standard (if there was one) number-base syntax for PDP-11 
assembler?

Despite all the PDP-11 assembly info on web sites, this seems to be a buried 
bit of info.
One assembler doc uses a prefix of "", another specifies octal as default and 
prefix of zero for decimal (opposite of the common C-derived standard . . great).

Is this for example standard?:

BIT #, @#  ; test 2^7 bit at address octal 
177564

(I'm just trying to make some written commentary consistent with common policy.)



MACRO11 Language Manual v5.5 section 6.4

All numbers are octal radix, unless the default radix is changed via the .RADIX 
N directive (N can be 2, 8, 10, or 16). N blank resets the radix to octal.


So 0100, 100 would be octal 100, decimal value 64.

Any number followed by a period (decimal point) is forced to be base 10.

So 100. would be decimal 100, octal 144.

Prefix operators ^B (binary), ^O (octal), ^D (decimal), ^X (hexadecimal) force 
the following digits/characters to the designated radix.


So ^B101000 == ^O50 == ^D40 == ^X28 all represent the same value (decimal 40.) 
irrespective of the current .RADIX N setting.

Re: MACRO11

[Don North]

And what about this one?

https://github.com/Rhialto/macro11   (forked from shattered/macro11 it 
appears...)

So which one of the three versions (at least, maybe more) is the 'preferred' ?

On 11/9/2016 7:52 AM, Jörg Hoppe wrote:

Hi,

I was notified that my fork of R. Krebiehls code was already put into GitHub 
without notifying me, apparently in 2009.


See github.com/shattered/macro11

"shattered" made a few changes too, to remove compiler warnings and improve 
commandline option check.


I merged the changes there back into my fork.

Joerg


Jörg Hoppe wrote:


Hi,

my version of the MACRO11 cross-assembler for PDP-11 is now on
https://github.com/j-hoppe/MACRO11 .

Among others it fixes the  "JMP Rn is illegal" error on "jmp (rx)" opcode.

Also I added the option "listhex" to produce a binary listing in hex
notation instead of octal.
I found this really necessary when analyzing test programs with a modern
logic analyzer.

Joerg

Thanks.

Could you possible change all the occurences of stricmp() wich is a
mikeysoft-only thing, to the more standard strcasecmp()?

Regards,

Holm

Re: [TUHS] Booting PDP-11's from RX02's

[Don North]

On 10/30/2016 5:47 AM, Noel Chiappa wrote:

 > From: Don North <no...@alum.mit.edu>

 > .. the hardware bootstrap reads track 1 sectors 1, 3, 5, 7

Ah, thanks for that. Starting to look at the code, I had missed the
interleave.

So does DEC do anything with track 0, or is it always just empty?

Noel


Track 0 is not used by standard DEC software, block zero of the device (boot 
block)
starts at track 1 sector 1. Track 0 is not even accessible thru the standard 
drivers.


Applies to both PDP-11 (eg, XXDP, RT11) and PDP-8 (OS8).

Maybe specific software that reads/writes disks in IBM exchange mode accesses
track 0, but I've never used such s/w and am only guessing.

Re: [TUHS] Booting PDP-11's from RX02's

[Don North]

On 10/29/2016 2:32 PM, Ron Natalie wrote:

I think just like everything else the boot rom just pulls in the first
sector of the disk.   I had RX02s on many of the BRL Gateways (my
implementation that replaced your MIT Gateway while you were in exile).
We put a V6 file system and I must have had a regular V6 boot block on it
with a RX02.   There might be someone still at BRL who might remember where
this stuff is.   I certainly don't have it.

BRL PDP-11 kernels had both V6 and V7 file systems in them but I'd have to
believe I was booting off a V6 one.


For RX01 (and RX02) the hardware bootstrap reads track 1 sectors 1, 3, 5, 7
into memory. For RX01 with 128B sectors this yields 512B total (just like 
reading
one 512B block from most other disks). Their is a fixed 2:1 sector interleave.

For RX02 is does the same sector reads, but since the sectors are 256B the total
amount of data read is 1024B. In reality only sectors 1, 3 need be read, but the
bootstrap (M9312 anyway) just goes ahead and reads all four sectors always.
 

Re: DEC bus transceivers

[Don North]

On 10/24/2016 1:18 PM, David Bridgham wrote:

On 10/24/2016 01:37 PM, allison wrote:


The voltages are based on TTL levels.  What are the unique voltages?

The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the same):

Input low voltage (maximum): 1.3 V
Input high voltage (minimum): 1.7 V

And from the TI datasheet for the 74LS74:

Vil - low-level input voltage 0.8 V (maximum)
Vih - high-level input voltage 2 V (minimum)

So no, the DEC bus voltage levels are not TTL levels.  Yeah, TTL might
work on a smaller system but you can see that if you push it out to its
limits, TTL could start getting flaky.  That's the kind of bug I'm happy
to have DEC's engineers figure out and not have to track down myself.


FYI here is an I/O plot I did of the bus input receiver of an 8641 device (the 
blue line). A threshold of about 1.5V.
Also included is a plot of a 26S10 transceiver (which has a higher input voltage 
threshold) which I think is used

in later designs (SBI? IIRC).

http://www.ak6dn.com/stuff/26S10vs8641.jpg

Re: SCSI Tape Emulator

[Don North]

Something new: 
http://embedded-computing.com/news/launch-scsiflash-tape-replacement-obsolete-end-of-life-tape-drives/ 
but no price listed.

Not targeted at the classic computing hobbyist, so probably going to be 
expensive.

On 10/10/2016 3:34 PM, Al Kossow wrote:

"9-track tape emulator" brings up the usual suspects on G

they are ~10k dollar devices.

http://www.arraid.com/

et. al.


On 10/10/16 3:27 PM, Chuck Guzis wrote:

On 10/10/2016 02:02 PM, Dave G4UGM wrote:


Do you have any links, I couldn't turn any up? Are they affordable?


Only an echo of a name rattling around in my brainpan--AVAX.

Maybe a google search will turn up something.

--Chuck

Re: DEC TC11 maindec listings?

[Don North]

On 9/24/2016 8:32 PM, Al Kossow wrote:

I had it on fiche, which I scanned this afternoon.
It should be up on the bitsavers mirrors by morning PDT under pdp11/xxdp
along with rev E of the XXDP+ users guide.

I'll probably also do the RX02 diags if I can find them for Don, though
he may have them on fiche.


I was able to get ZRXDC0, ZRZEA0, and ZRXFB0 listings from the fiche images on
http://www.retrocmp.com/tools/pdp-11-diagnostic-database
so I am fine for RX02 diagnostics listings.

Don


The step and repeat fiche scanner isn't on line yet so I used the Canon
manual positioning one. It's tedious, and it gets out of focus easily, but
they are better than nothing.


On 9/21/16 12:38 PM, Mattis Lind wrote:

I have been looking for TC11 maindec listings in the usual places, but
didn't find any. I think they should be named ZTCA, ZTCB, ZTCC, ZTCD and
ZTCE.

Does anyone know of an online location or happen to have an offline paper
original?

/Mattis

Re: Short test programs for pdp 11/34

[Don North]

On 9/23/2016 6:15 PM, Paul Popelka wrote:

You might try looking at the M9312 proms that Don North has made available here:
http://www.ak6dn.com/PDP-11/M9312/

If you have an M9312 in your system it will have the basic console prom in it.
There are listings of the prom contents on that web page.

There is also a simple diagnostic prom that loops forever near the bottom of 
the page.
If you don't have an M9312 then you could probably key in a program from the 
rom listings provided.

I'd bet Don will be along shortly to provide a better explanation.


Basically correct. The 'ZZ' pseudo boot PROM I generated just runs the basic 
diagnostics contained

within the associated 248F1 11/04-34 console PROM in a continuous loop.

The diagnostics are very simple, and do a number of datapath and register 
checks, as well as a low memory

(0-28KW) write/read/check confidence test.

Not comprehensive by any means but having the diag in PROM and not reliant on 
any peripherals (except
the console TTY interface) is sometimes a very useful starting point for system 
debug.


If anyone wants one of the programmed console PROMs (a 256x4 82S129) programmed 
with the ZZ pattern
just ping me at the email address shown on the above mentioned website (or this 
post).


I can also provide programmed 82S129 devices for any of the other available DEC 
boot PROMs should anyone

need one.

Cost will be free for low quantities (ie one or two for personal use). Cost 
negotiated for larger quantities.


Don

Re: UNIBUS M9312 ROM type identification

[Don North]

On 9/6/2016 11:55 PM, Don North wrote:

On 9/6/2016 9:23 AM, JP Hindin wrote:


Greetings;

My googlefu is failing me and I was wondering if someone might be able to 
help me identify one of the boot ROMs present in an M9312 bootstrap/term 
board. The board has three ROMs, an RX01 (042130), an RX02 (042131) and then 
a mystery code - 043127.


The M9312 ROM identification table does not list this ROM code - I suspect it 
_might_ be for a DSD combined 8" drive and Winchester disk box, but I'm under 
the impression this would appear as a DU device, and attempting to boot from 
DU gets an ILL CMD, suggesting otherwise. I tried all of the other possible 
mnemonics listed in the M9312 manual, so it doesn't appear to piggy-backing 
on any of those either.


My thanks;

 - JP

Octal word 042130 decodes as ascii "DX", which is the M9312 boot mnemonic for 
the RX01 drive/RX11 controller combo.


Octal word 042131 decodes as ascii "DY", which is the M9312 boot mnemonic for 
the RX02 drive/RX211 controller combo.


Octal word 043127 decodes as ascii "FW", which is not a standard M9312 boot 
mnemonic. Probably a third party manufacturer custom boot prom.


FYI the above octal words are programmed in the first word of each boot PROM, 
so they are accessible at locations 773000,


You can find program listings and hex PROM images of all the known M9312 
devices here:  http://www.ak6dn.com/PDP-11/M9312/, including the DX and DY PROMs.


Don


Whoops I sent before finishing this line:

FYI the above octal words are programmed in the first word of each boot PROM, so 
they are accessible at locations 773000, 773200, 773400, 773600 as 18b UNIBUS 
address.


Don

Re: UNIBUS M9312 ROM type identification

[Don North]

On 9/6/2016 9:23 AM, JP Hindin wrote:


Greetings;

My googlefu is failing me and I was wondering if someone might be able to help 
me identify one of the boot ROMs present in an M9312 bootstrap/term board. The 
board has three ROMs, an RX01 (042130), an RX02 (042131) and then a mystery 
code - 043127.


The M9312 ROM identification table does not list this ROM code - I suspect it 
_might_ be for a DSD combined 8" drive and Winchester disk box, but I'm under 
the impression this would appear as a DU device, and attempting to boot from 
DU gets an ILL CMD, suggesting otherwise. I tried all of the other possible 
mnemonics listed in the M9312 manual, so it doesn't appear to piggy-backing on 
any of those either.


My thanks;

 - JP

Octal word 042130 decodes as ascii "DX", which is the M9312 boot mnemonic for 
the RX01 drive/RX11 controller combo.


Octal word 042131 decodes as ascii "DY", which is the M9312 boot mnemonic for 
the RX02 drive/RX211 controller combo.


Octal word 043127 decodes as ascii "FW", which is not a standard M9312 boot 
mnemonic. Probably a third party manufacturer custom boot prom.


FYI the above octal words are programmed in the first word of each boot PROM, so 
they are accessible at locations 773000,


You can find program listings and hex PROM images of all the known M9312 devices 
here:  http://www.ak6dn.com/PDP-11/M9312/, including the DX and DY PROMs.


Don

Re: PDP-8 diagnostic tests

[Don North]

On 8/24/2016 2:21 AM, Pontus Pihlgren wrote:

On Tue, Aug 23, 2016 at 12:31:42PM -0700, Scott Baker wrote:

Hi,
  
1) DEC documentation which more fully describes all the instruction set (in

more detail  than the PDP-8 handbook)

Not DEC documentation but a good resource:
http://homepage.cs.uiowa.edu/~jones/pdp8/man/

I've written an emulator purely from these pages and it passes the
MAINDEC-8E-D0AB-PB instruction tests.

Here is IAC described:
http://homepage.cs.uiowa.edu/~jones/pdp8/man/micro.html#iac


2) Some more instruction tests in assembler source code format. I have
found lots of binary files but I would prefer assembler source code format.
I am using a pal compatible cross assembler.

I don't have any of those. But I've used Krten's d8tape to dissasemble
BIN files with good result:

http://dustyoldcomputers.com/pdp-common/reference/host/index.html

That and the source code listings on bitsavers.

/P

Also I did not mention earlier my PDP-8 diagnostic page: 
http://www.ak6dn.com/PDP-8/MAINDEC/
has more or less what you asked for. It has all the base PDP-8e series CPU core 
diagnostics as listings
in PDF, binary tape images in BIN and RIM, and disassembled sources in PAL and 
assembled LST.


BTW my PDP-8 implementation in Verilog (not VHDL) passes all these diagnostics, 
as well as running

chess, focal, and other such images.

Don

Re: PDP-8 diagnostic tests

[Don North]

On 8/23/2016 12:31 PM, Scott Baker wrote:

Hi,

I have written a PDP-8 VHDL model and I have it running in an FPGA
https://github.com/scottlbaker/PDP8-SOC

At this time it has passed a basic DEC diagnostic instruction test but
I found some interesting things when getting that instruction test to pass.
For example:

The following segment of code implies that IAC instruction affects the Link
bit

  1797 /GROUP 1 OPERATE TEST 33
  1798 02626 7300  CLA CLL /AC= LINK=0
  1799 02627 1053  TAD K2525   /AC=2525
  1800 02630 7261  CLA CMA CML IAC /TEST COMBINATION
  1801 02631 7420  SNL
  1802 02632 7430  SZL
  1803 02633 7402  HLT /CLA CMA CML IAC FAILED, AC SHOULD
  1804 /BE , LINK SHOULD BE ZERO

but the PDP-8 Handbook  ; DEC copyright 1966; page 14
says nothing about the Link bit being affected by the IAC instruction.

The simh PDP-8 simulator also shows that L is affected by IAC.

If I change this test line from

  1800 02630 7261  CLA CMA CML IAC /TEST COMBINATION  << link=0

to:

  1800 02630 7261  CLA CMA CML  /TEST COMBINATION  << link=1

Can anyone point me to:

1) DEC documentation which more fully describes all the instruction set (in
more detail  than the PDP-8 handbook)

2) Some more instruction tests in assembler source code format. I have
found lots of binary files but I would prefer assembler source code format.
I am using a pal compatible cross assembler.

Thanks and Regards,
Scott


Both TAD and IAC effectively perform 13 bit additions on {L,AC}.

The PDP-8a Handbook 
http://bitsavers.trailing-edge.com/pdf/dec/pdp8/handbooks/MinicomputerHandbook_1976.pdf

describes TAD operation on p5-3, and IAC operation on p5-6.

The PDP-8 handbooks are probably the best / only definitive architectural 
specification.


The PDP-8e processor maintenance manual:

http://bitsavers.trailing-edge.com/pdf/dec/pdp8/pdp8e/DEC-8E-HMM1A-D-D_PDP-8e_Maintenance_Manual_Volume_1_Processor_Sep73.pdf

is a pretty detailed implementation reference. Chapter 3 section 2 is a very 
detailed reference on the instruction fetch/decode/execute flow.


Don

Re: Front Panel - Update. - PDP=8/i and PDP-8/l - Bezels - PDP-11

[Don North]

On 8/13/2016 6:20 AM, Christian Gauger-Cosgrove wrote:

On 13 August 2016 at 08:07, Noel Chiappa  wrote:

I can't recall any other models with front panels? (Well, the /74, but IIRC
there are none of those extant outside museums - although people might want
some for simulators.)


The whole list of PDP-11 models with any sort of front panel beyond
just an on/off switch is:

11/20 (11/15)
11/05 (11/10)
11/40 (11/35)
11/45 (11/50, 11/55)
11/70 (11/74)
11/34 (11/04, 11/34A) --- "Calculator" style panel (like an 8/A)
11/60 --- "Calculator" style panel.

I've put OEM machines, and machines that are otherwise identical, or
nearly so in parens. The '45 and '50 panels are the same except for
the number, while the '55 panel is painted completely differently. The
same goes for the '70 versus '74 panels: Same indicators and
everything, just completely different paint job.

The panel on the '74 is almost exactly like a standard '70 panel, just
its in "blue" (i.e. like the DECdatasystem-570 that Dave McGuire
owns). Compare:
11/74: 

11/70: 
The only other major difference between the '70 and '74 panels is that
the '74 uses the "chiclet" switches as on the '05/'10 instead of the
"normal" triangular plastic ones you find on a standard '70.

There's also different coloured versions for many of the panels too.
E.g. there's a brown-and-white '70 panel used in OEM typesetting
systems by CSI Systems (if I recall right). There's a blue-and-red '40
panel sold by DEC in their "INDUSTRIAL-11" version. A photo exists
showing an 11/20 and an 8/e in "labratory" green (i.e. the LAB-8/e
colour scheme).


With regards to the 11/74, last I heard there were no machines extant.
Apparently there's an 11/74 panel plexiglass "floating around", but I
don't recall who owns it.


Like this maybe:   http://www.ak6dn.com/stuff/1174.jpg

This is a 'true' 11/74 panel from the never-production variation of the 11/74, 
with CIS.
Not just a relabeled/recolored 11/70 panel. Note the additional LEDs on the 
right hand side.

AFAIK no front panel exists that mates with this plexiglass.

I also have a complete DEC DataSystem-570 panel (frame, plex, switches) which is 
just
a standard 11/70 panel, but recolored in light blue / dark  blue / gray color 
scheme.


Don



As an aside thought: I'd love to see a "blue" 11/70 or an 11/74 panel
running with either blue LEDs or white LEDs. That would probably look
very nice… hopefully Rob will do a one of those panels because that
sounds like a fun project.


Cheers,
Christian

Re: PDP-8 _Introduction_to_Programming_ & _Programming_Languages_(Scanned) Covers Needed

[Don North]

On 8/2/2016 9:18 PM, Cameron Kaiser wrote:

Does anyone have DEC's PDP-8 _Introduction_to_Programming_, Editions 3
and/or 4 and/or the PDP-8 _Programming_Languages_ handbooks?

I have a 4th edition PDP-8 Introduction to Programming. I'm not willing to
part with it and I don't currently have a scanner in easy reach, but the
program on the cover is '[unreadable]'S COMPLEMENT SINGLE PRECISION
MULTIPLY ROUTINE'.


Same for 5th Edition April 1975.

Routine is:  "TWO'S COMPLEMENT SINGLE PRECISION MULTIPLY ROUTINE"

Re: [SPAM key] - Re: memory map for RT-11 v 5

[Don North]

On 7/26/2016 7:17 PM, Jerome H. Fine wrote:

On Sunday, July 24th, 2016 at 14::29:59 -0700, Don North wrote:



>On 7/24/2016 8:06 AM, william degnan wrote:


>On Jul 24, 2016 8:58 AM, "Jerome H. Fine" <jhfined...@compsys.to> wrote:


>On Wednesday, July 20th, 2016 at 18:02:44 - 0400, william degnan wrote:
Is there a minimum memory requirement for RT-11 v5?  I was discussing with



Ray Fantini about it today, unsure...anyone know if 16K will work (from
00).

Bill


You need to be more specific!  Starting with V05.00 of RT-11 in 1983,
there were a total of 17 versions released up to V05.07 in 1998, including
sub-versions V05.01B, V05.01C, and V05.04A to V05.04G of RT-11.

Up until V05.05 of RT-11, RT11SJ.SYS required the least memory which
was replaced with RT11SB.SYS for V05.06 and V05.07 of RT-11.

Attempts to boot from RT11SJ.SYS under V05.00 of RT-11 with 24K
bytes of memory were successful.  Attempts to boot with 16K bytes of
memory were unsuccessful.  An RK05 was used as the disk drive since
it is close to the smallest device driver.  The answer to your question
about using 16K bytes of memory is NO for all versions of RT-11 starting with
V05.00 or RT-11.

Attempts to boot from RT11SJ.SYS under V04.00 of RT-11 with 24K
bytes of memory were successful.  Attempts to boot with 16K bytes of
memory were also successful.  An RK05 was used as the disk drive.  The
error message "Insufficient memory" is displayed, but some useful work
might be done with just 16K bytes of memory. However, you did not
ask if useful work being done was one of the criteria?

NOTE that I used the Ersatz-11 emulator to check the above details,
so there might be a difference with actual hardware.

If you have any more questions, please ask.

Jerome Fine


Thanks for the details.  I had been trying to boot rt-11 v5.3 on a 16k core
11/40 using RL11 (rl02) and it did not work.   The system was unable to
complete the initialization.  CPU diagnostics passed, I could load BASIC
papertape.  RL11 working correctly.  In this context I posted my question.

After I posted my message here I loaded up simh and emulated an 11 with
32k.  RT-11 v5.3 disk boots.  When I re-built the system and reduced to
16k, I could not boot, bombed.

One thing to remember is 16KW in a pdp11 is not the same thing that simh
refers to when one sets the CPU to 16K.  WWW do not all make this
distinction clearly.  I get it, just making this comment for future readers
of this thread.

Bill



RT-11 v5.03 single job monitor boots fine and runs in just 32KB (16KW) of 
memory.


You need to be more specific about how you specify the memory configuration 
(words vs bytes).


DEC routinely specified everything in KW (words) but most users and tools use 
KB (bytes) nowadays.


Note that to force RT11SJ (vs RT11FB) to boot on the below image I booted 
first using FB

in a larger memory configuration, did a:

COPY/BOOT DL1:RT11SJ.SYS DL1:

to force it to boot using the SJ monitor the next time.


NOTE that while the above command is REQUIRED to perform a
hardware boot (from boot ROMs on real hardware or from
within the SimH emulator.  Starting at least with V04.00 of RT-11,
a software boot (which uses DUP.SAV) is supported from within
RT-11 from within any disk (with the files required to support being
a System Disk) to boot any specific monitor file (in this example
RT11SJ.SYS) using the RT-11 command:
BOOT  DL1:RT11SJ


Bill's original issue is he wanted to boot RT-11 v5 on a 16KW 11/40 system, so 
the only

option that would work would be to boot directly to RT11SJ. Booting into XM or 
FB
and then rebooting into SJ via executing the BOOT command is not possible in 
such
a memory configuration.


Thus even if there has been the RT-11 command to set up a
boot block on a specific disk for a specific RT-11 monitor
file, it is possible to override the boot block and use any
qualified RT-11 monitor file via an RT-11 software boot
(which uses DUP.SAV).

It is also possible from within RT-11 to force the use of the Primary
Boot Code (which is placed in block zero via the COPY/BOOT
command) via the RT-11 command:
BOOT/FOREIGN  DL1:
If the user includes a specific monitor in the command:
BOOT/FOREIGN  DL1:RT11FB
then the specified monitor file is ignored and the boot code in
block zero of DL1: (placed there via the COPY/BOOT command)
is used instead along with the actual monitor file that had been
specified during the COPY/BOOT command.



Don


PDP-11 simulator V4.0-0 Betagit commit id: 4065f47f


This portion of my reply contains many questions.  If possible,
answers to all of them would be appreciated, not just the first
question.

Is this the latest version of SimH?  Also, is is possible to support
a VT100 display.  I have heard that telnet can be used, but I have
never been able to do so.  Since I always use the RT-11 SL:
(Single Line Editor) device driver to support a command stack,
it is essential to support a VT100 display, 

Re: memory map for RT-11 v 5

[Don North]

On 7/24/2016 2:37 PM, Paul Koning wrote:

On Jul 24, 2016, at 11:06 AM, william degnan  wrote:


...
Attempts to boot from RT11SJ.SYS under V04.00 of RT-11 with 24K
bytes of memory were successful.  Attempts to boot with 16K bytes of
memory were also successful.  An RK05 was used as the disk drive.  The
error message "Insufficient memory" is displayed, but some useful work
might be done with just 16K bytes of memory. However, you did not
ask if useful work being done was one of the criteria?

FWIW, I used to run RT11SJ on an 11/20 with 8 kW (16 kB) of memory and RC11 
system disk, in college.  That fit with no trouble, enough room to run RT BASIC 
and a reasonably application program.

paul



And it still works today:

PDP-11 simulator V4.0-0 Betagit commit id: 4065f47f
sim> set cpu 11/05 16k
sim> sho cpu
CPU 11/05, idle disabled, autoconfiguration enabled
16KB
sim> att rk0 rt11.dsk
sim> boot rk0

RT-11SJV02C-02

.
.R PIP
*/L

DTMNSJ.SYS   46 27-NOV-75
DTMNFB.SYS   58 27-NOV-75
DP.SYS2 27-NOV-75
RK.SYS2 27-NOV-75
RF.SYS2 27-NOV-75
TT.SYS2 27-NOV-75
LP.SYS2 27-NOV-75
BA.SYS7 27-NOV-75
SYSMAC.SML   18 27-NOV-75
SYSMAC.8K25 27-NOV-75
BATCH .SAV   25 27-NOV-75
EDIT  .SAV   19 27-NOV-75
MACRO .SAV   31 27-NOV-75
ASEMBL.SAV   21 27-NOV-75
EXPAND.SAV   12 27-NOV-75
CREF  .SAV5 27-NOV-75
LINK  .SAV   25 27-NOV-75
PIP   .SAV   14 27-NOV-75
PATCH .SAV5 27-NOV-75
ODT   .OBJ9 27-NOV-75
VTHDLR.OBJ8 27-NOV-75
DEMOFG.MAC5 27-NOV-75
DEMOBG.MAC4 27-NOV-75
KB.MAC   33 27-NOV-75
LIBR  .SAV   15 27-NOV-75
MONITR.SYS   46 27-NOV-75
RKMNFB.SYS   58 27-NOV-75
RFMNSJ.SYS   46 27-NOV-75
RFMNFB.SYS   58 27-NOV-75
DPMNSJ.SYS   46 27-NOV-75
DPMNFB.SYS   58 27-NOV-75
DXMNSJ.SYS   46 27-NOV-75
DXMNFB.SYS   58 27-NOV-75
DT.SYS2 27-NOV-75
DX.SYS2 27-NOV-75
CR.SYS3 27-NOV-75
MT.SYS6 27-NOV-75
MM.SYS6 27-NOV-75
PR.SYS2 27-NOV-75
PP.SYS2 27-NOV-75
CT.SYS5 27-NOV-75
DS.SYS2 27-NOV-75
FILEX .SAV   11 27-NOV-75
SRCCOM.SAV   11 27-NOV-75
DUMP  .SAV5 27-NOV-75
PATCHO.SAV   33 27-NOV-75
VTMAC .MAC7 27-NOV-75
SYSF4 .OBJ   33 27-NOV-75
BASIC .SAV   36
BAS8K .SAV   34
DEMO  .BAS3
51 FILES, 1014 BLOCKS
3760 FREE BLOCKS
*
.
.R BAS8K

BASIC V01B-02
*

READY

OLD
OLD FILE NAME--DEMO

READY

LIST

DEMO   BASIC V01B-02

10 REM BASIC PROGRAM TO GENERATE N TERMS OF A FIBONACCI SERIES,
20 REM THE FIRST TWO TERMS OF WHICH ARE SPECIFIED BY THE USER.
30 REM
40 REM PRINT IDENTIFYING MESSAGE
50 PRINT "PROGRAM TO GENERATE A FIBONACCI SERIES"
60 REM
70 REM GET THE LENGTH AND FIRST TWO TERMS OF THE SERIES
80 PRINT "HOW MANY TERMS DO YOU WANT GENERATED";
90 INPUT L
100 IF L<>0 THEN 130
110 REM IF HE REQUESTS 0 TERMS,TERMINATE EXECUTION
120 STOP
130 PRINT "WHAT IS THE FIRST TERM";
140 INPUT T1
150 PRINT "WHAT IS THE SECOND TERM";
160 INPUT T2
170 REM MAKE SURE L IS NOT NEGATIVE OR TOO LARGE
180 IF L<3 THEN 200
190 IF L<50 THEN 220
200 PRINT L;"TERMS DOES NOT REALLY MAKE SENSE."
210 GO TO 80
220 REM PRINT THE FIRST TWO TERMS OF THE SERIES
230 PRINT "THE REQUESTED SERIES IS"
240 PRINT T1
250 PRINT T2
260 L=L-2
270 REM CALCULATE NEXT TERM AND PRINT IT
280 N=T1+T2
290 T1=T2
300 T2=N
310 PRINT N
320 REM DETERMINE IF SERIES IS FINISHED. IF SO,DO NEXT ONE.
330 L=L-1
340 IF L<=0 THEN 80
350 GO TO 280
360 END

READY

RUN

DEMO   BASIC V01B-02

PROGRAM TO GENERATE A FIBONACCI SERIES
HOW MANY TERMS DO YOU WANT GENERATED?4
WHAT IS THE FIRST TERM?12
WHAT IS THE SECOND TERM?5
THE REQUESTED SERIES IS
 12
 5
 17
 22
HOW MANY TERMS DO YOU WANT GENERATED?0

STOP AT LINE 120

READY

Re: re-initialize PDP 11 BASIC?

[Don North]

On 6/30/2016 10:29 AM, william degnan wrote:

I seem to remember there is an entry point that one can use to reinitialize
BASIC already loaded into core memory, with the intention of re-answering
the questions about MEMORY SIZE, Use SIN?, etc.  Is this correct?  I looked
in the docs I have b ut I could not find it.  If no one has this info I
will have to disassemble, IN a HEX editor I see the questions are all at
the end.

-- Bill


After loading the basic papertape, start it at 16104 to get to the config 
dialog.
Type a '?'  in response to the *O prompt to get the long form dialog.

Don


*Downloads[504] pdp11 basic.ini**
**
**PDP-11 simulator V4.0-0 Betagit commit id: d8aafde7**
**Disabling XQ**
**load basic.pt**
**run 16104**
**
**PDP-11 BASIC, VERSION 007A**
***O ?**
**DO YOU NEED THE EXTENDED FUNCTIONS?Y**
**HIGH-SPEED READER/PUNCH?N**
**SET UP THE EXTERNAL FUNCTION?N**
**MEMORY?**
**READY**
**100 FOR I = 1 TO 10**
**110 PRINT I,I*I,I*I*I**
**120 NEXT I**
**130 END**
**RUN**
** 1 1 1**
** 2 4 8**
** 3 9 27**
** 4 1664**
** 5 25125**
** 6 36216**
** 7 49343**
** 8 64512**
** 9 81729**
** 10100   1000**
**
**STOP AT LINE  130**
**READY**
*

Re: DL11 configuration for pdp11gui

[Don North]

On 6/26/2016 2:48 PM, Noel Chiappa wrote:

 > From: Fritz Mueller

 > So far I haven't seen any place in PDP11GUI to set anything other than
 > port and baud rate

You might have to use native OS tools to do that. On Unix, that will be
'stty'; on Windows, you'd have to use native Windows tools to do that; if you
go to the Device Manager, select your serial port, and click on 'Properties',
it has a tab ('Port Settings') for that (or, should I say, it used to - not
sure about the most recent versions, they're making it all smart-phone like
for brain-dead lusers).


 > From: Don North

 > Mostly PDP11GUI does not care, either 7b or 8b.

I'm kind of surprised to hear that; I assumed that PDP11GUI can download
binaries, and for that, 8-bit is kind of necessary?


PDP11GUI reads papertape files as 8b binary, but on download translates the 
output to console deposit commands, which are just 7b printable ascii; ie 'D 0' 
to send a binary 0x00 to the target system. So no 8b required here.


The PDP11GUI serial driver does binary block transfers as base64 uuencoded 
streams, which are also just plain ascii 7b text:


; high speed bufferaccess over serial port0
;
; Compression:
; like uuencode / base64
; Each serial char defines 6 bits, char is in range0x20 ..0x5f
; 8chars defines 3words
; Char #:  <.0..> <..1..> <..2..> <.3..> <.4..><..5..><..6..> 
<.7..>
; Char Bits:  543210 54 3210 5432 10 543210 54321054 32105432 
10543210
; bytes:  765432 10 7654 3210 76 543210 76543210 76543210 76
543210

; byte #:  <...0...> <...1...> <...2...> <..3> <...4...> <...5...>
; word #:  <...msb0lsb0..> <...msb1lsb1..> <..msb2.lsb2..>

Re: DL11 configuration for pdp11gui

[Don North]

On 6/26/2016 12:26 PM, Fritz Mueller wrote:

Hi folks,

I've started to look into hooking up pdp11gui to my 11/45 w/ M9301. Does 
anybody here know how the console DL11 should be configured for this wrt. data 
bits, parity, stop-bits?  I haven't seen this mentioned in the documentation 
or tutorials.


thanks,
   --FritzM.


Console DL11 configuration (baud, #data, #stop, parity) needs to match that of 
the PC (baud, #data,#stop,parity) that is running PDP11GUI, and vice versa. 
9600-8N2 on each end would be a good place to start (fastest baud rate, 8b, no 
parity) as it is very common.


Mostly PDP11GUI does not care, either 7b or 8b. Other characteristics (#stop, 
#parity, baud) need to match DL11 vs PC.

Re: options for replacing failed small ROMs in PDP-11

[Don North]

On 6/24/2016 4:36 PM, Fritz Mueller wrote:

Hi All,

In bringing up and debugging my PDP 11/45, I found that one of my GRA (M8101) 
spares has a failed ALU subsidiary ROM.  It's a pretty standard little 32x8 
ROM in a 16-pin DIP, and the truth table is in the 11/45 print set.


I wonder what the replacement options are for parts like these? In particular, 
given the 30ns micro-cycle on the KB11-A, and the fact that the propagation 
time for the ALU downstream of this is roughly 20ns on its own, I'd be worried 
that an off-the-shelf bipolar PROM might be too slow here.


I'm still a little slow on reading the microcode flows, so its not clear to me 
exactly how many micro-cycles there are on the critical path for the E-class 
instructions where this ROM is used.  Maybe its not an issue.


Anybody every try replacing one of these with a bipolar PROM?  Any other 
suggestions for how to repair parts like these?


cheers,
 --FritzM.

Almost 100% certainty the part already there is a small bipolar TTL PROM. What 
would you think it otherwise might be?


For a lot of these logic replacement applications DEC used the open collector 
version, but it might be tristate variation. Check schematic.


Also, the microcycle on the 11/45 (and 11/70 for that matter, basically the same 
design) is 150ns, not 30ns.


There are various clock timing pulses (tp1, tp2, etc) but the datapath / control 
unit microcycle is 150ns.


Don

Re: UNIBUS M9312 ROMS (Don North)

[Don North]

On 6/10/2016 4:56 AM, Michael Thompson wrote:

From: Don North <ak...@mindspring.com>
Subject: Re: UNIBUS M9312 ROMS

Actually the page listed below is a big out of date with respect to some
M9312
images (it is not an up to date mirror).
The up to date page is at:  http://ak6dn.dyndns.org/PDP-11/M9312/

--
Don North
AK6DN


RCS/RI has some PDP-11/34 systems that booted, I think using DDCMP, via a
COAX interface from a PDP-10 KL10. I think that it took four ROMs to hold
the boot loader. You might not have a copy of those ROMs.

There is a three PROM set 23-86[234]A9 for device code XM which is DDCMP boot 
over a DMC11/DMR11. Those PROMs are available and on my web page.


A two PROM set 23-E3[23]A9 has been found for etherNet DELUA/DEUNA boot (device 
code XE?) but it has not been reverse engineered. Hopefully soon the device 
patterns will be read and forwarded to me for processing.


I am not aware of the four PROM set you mention, but it could certainly be a 
custom one for that application.



(XM) DECnet DDCMP DMC11/DMR11 	23-862A9 
<http://ak6dn.dyndns.org/PDP-11/M9312/23-862A9/23-862A9-0625.hex> 	0x0625 	SRC 
<http://ak6dn.dyndns.org/PDP-11/M9312/23-862A9/23-862A9.mac>

LST <http://ak6dn.dyndns.org/PDP-11/M9312/23-862A9/23-862A9.lst>  (1,2)
23-863A9 <http://ak6dn.dyndns.org/PDP-11/M9312/23-863A9/23-863A9-063F.hex> 
0x063F 	SRC <http://ak6dn.dyndns.org/PDP-11/M9312/23-863A9/23-863A9.mac>

LST <http://ak6dn.dyndns.org/PDP-11/M9312/23-863A9/23-863A9.lst>
23-864A9 <http://ak6dn.dyndns.org/PDP-11/M9312/23-864A9/23-864A9-0551.hex> 
0x0551 	SRC <http://ak6dn.dyndns.org/PDP-11/M9312/23-864A9/23-864A9.mac>

LST <http://ak6dn.dyndns.org/PDP-11/M9312/23-864A9/23-864A9.lst>


--
Don North
AK6DN

Re: UNIBUS M9312 ROMS

[Don North]

On 6/8/2016 5:56 PM, Paul Koning wrote:

On Jun 8, 2016, at 6:46 PM, Jay West <jw...@classiccmp.org> wrote:

I wrote...
On Thu, Jun 9, 2016 at 6:34 AM, Jay West <jw...@classiccmp.org> wrote:

23-E39A9 is still lost to time, afaik. TMSCP - TU81

To which mike replied...

Could that not be reverse-engineered from the boot code in e.g. Emulex
UC17 ROMs? They could do TMSCP...

BTW what PROM blower would folks recommend for creating/imaging M9312 ROMs?

Possibly, but some (me) are sticklers for original code. Plus, I am not sure, 
but I think someone said this rom did something really bizarre to fit in the 
available rom space - self modifying code or something...

MSCP isn't all that hard.  The RSTS secondary loader fits in one block, and it 
contains not just code to speak MSCP but also enough room for a map of pointers 
to where the code to load lives (as opposed to the primary boot which just has 
to load one block from address zero).

paul


In an M9312 boot PROM there are 49. words of bootstrap space that are available 
for code and data. Getting an MSCP boot to fit in that space required playing 
some tricks like treating some specially crafted instructions as data values 
(and vice versa).



--
Don North
AK6DN

Re: UNIBUS M9312 ROMS

[Don North]

On 6/8/2016 5:56 PM, Mike Ross wrote:

On Thu, Jun 9, 2016 at 12:27 PM, John Robertson <j...@flippers.com> wrote:


No way the M9312 can self modify, it is a burn once PROM -

I kinda assumed it was a case of copying itself to RAM and
self-modifying as it runs there - if it ever happened.

Mike


As it happens the 23-760A9 TT/PR boot PROM does this copy by building a 
bootstrap
sequence in RAM, and then jumping to it. Once it is built it is not self 
modifying, however.


Ref:  http://ak6dn.dyndns.org/PDP-11/M9312/23-760A9/23-760A9.lst

--
Don North
AK6DN

Re: UNIBUS M9312 ROMS

[Don North]

On 6/8/2016 3:13 PM, Mike Ross wrote:

On Thu, Jun 9, 2016 at 6:34 AM, Jay West <jw...@classiccmp.org> wrote:

23-E39A9 is still lost to time, afaik. TMSCP - TU81

Could that not be reverse-engineered from the boot code in e.g. Emulex
UC17 ROMs? They could do TMSCP...

BTW what PROM blower would folks recommend for creating/imaging M9312 ROMs?

I have tried to compress/adapt the TMSCP boot in the PDP11 SIMH device driver, a 
bootstrap listing in a DEC tech manual, and using the programming concepts 
(hacks) in the MSCP DU M9312 boot prom 23-767A9, and have not been able to get a 
valid code image that fits in the PROM and has all the required functionality. 
So DEC must have taken some magic shortcut to get working TU boot code in the 
23-E39A9 PROM.


As to programming parts, I use an EETools TopMax programmer that I have had for 
years. It will do just about any of the older programmable devices. There are 
other programmers around (old DataIO's for example) that can do these bipolar 
PROMs.


Also, M9312 boot PROMs are typically 82S131 (or equiv) 512x4 tristate devices, 
but only half the device is used; the other half of the device is never accessed 
on the M9312 and is just blank filled.  An 82S129 (or equiv) 256x4 tristate 
device works just as well as a boot PROM as the upper address pin becomes an 
active low chip select, and this pin is pulled low on the M9312 board.


--
Don North
AK6DN

Actually the page listed below is a big out of date with respect to some M9312 
images (it is not an up to date mirror).

The up to date page is at:  http://ak6dn.dyndns.org/PDP-11/M9312/

Also note the 82S137/Am27S32/74S573 (1024x4-TS) device list applies to the 
CONSOLE PROMs, not the BOOT PROMs.


On 6/8/2016 5:27 PM, John Robertson wrote:


No way the M9312 can self modify, it is a burn once PROM - 
82S137/Am27S32/74S573 (1024x4-TS) and can easily be read and blown on a Data 
I/O 29B.


If you have a good copy of the original code it WILL replicate on a new PROM 
just fine.


Reference page of the files:

http://www.bluefeathertech.com/technoid/promfiles.html

John :-#)#




--
Don North
AK6DN

Re: UNIBUS M9312 ROMS

[Don North]

On 6/8/2016 3:13 PM, Mike Ross wrote:

On Thu, Jun 9, 2016 at 6:34 AM, Jay West <jw...@classiccmp.org> wrote:

23-E39A9 is still lost to time, afaik. TMSCP - TU81

Could that not be reverse-engineered from the boot code in e.g. Emulex
UC17 ROMs? They could do TMSCP...

BTW what PROM blower would folks recommend for creating/imaging M9312 ROMs?

I have tried to compress/adapt the TMSCP boot in the PDP11 SIMH device driver, a 
bootstrap listing in a DEC tech manual, and using the programming concepts 
(hacks) in the MSCP DU M9312 boot prom 23-767A9, and have not been able to get a 
valid code image that fits in the PROM and has all the required functionality. 
So DEC must have taken some magic shortcut to get working TU boot code in the 
23-E39A9 PROM.


As to programming parts, I use an EETools TopMax programmer that I have had for 
years. It will do just about any of the older programmable devices. There are 
other programmers around (old DataIO's for example) that can do these bipolar PROMs.


Also, M9312 boot PROMs are typically 82S131 (or equiv) 512x4 tristate devices, 
but only half the device is used; the other half of the device is never accessed 
on the M9312 and is just blank filled.  An 82S129 (or equiv) 256x4 tristate 
device works just as well as a boot PROM as the upper address pin becomes an 
active low chip select, and this pin is pulled low on the M9312 board.


--
Don North
AK6DN

Re: AT 3b2 vs SCSI2SD drive replacement

[Don North]

On 6/1/2016 10:19 PM, jwsmobile wrote:



On 6/1/2016 4:52 PM, Mike Ross wrote:

The advantages of the SCSI2SD over the ACard are as follows:
>
>1) It's open-source (hardware and firmware and software)
>2) The developer is extremely responsive to bug reports / feature requests
>3) It's very flexible -- you can make it look like any drive you want to
>(important for machines that expect to see only certain drives), it
>supports oddball sector sizes (for your lisp machines and AS/400s)

Wait - what? I'd never even thought of that. Has anyone got SCSI2SD
running successfully on AS/400?

I noticed that one vendor had the following note in their sale posting on Ebay.

** Please note
1) The card will be preconfigured for 8 gb storage only.
2) You will not be able to change the firmware as a little modifications have 
been done in PCB.


Vendor:  floppy_to_usb

Not nice sports fans.

SCSI2SD-50-Pin-SCSI-Hard-to-Micro-Sd-Converter-8-gb-micro-SD-for-Staubli-JC5

http://www.ebay.com/itm/301859438071

Any idea which vendor to buy from to get an "open" part, how to preserve the 
firmware / settings on what you get if you wish to modify it as an open 
product?  The above is pretty nasty for the vendor of an  open product, and I 
think I'll be buying from someone else.


Thanks
Jim


That price ($200) is about 3X the going rate.

The main page for SCSI2SD is here: 
http://www.codesrc.com/mediawiki/index.php?title=SCSI2SD


Scroll down to here: 
http://www.codesrc.com/mediawiki/index.php?title=SCSI2SD#Purchase to find links 
to vendors


Links to firmware updates and tools here: 
http://www.codesrc.com/mediawiki/index.php?title=SCSI2SD#News


I have no vested interest in SCSI2SD, other than being a very satisfied user.

Don



--
Don North
AK6DN

Re: General Question about UNIBUS backplanes

[Don North]

The M9312 can be setup to also act as a UNIBUS terminator card, and can reside 
in the

A-B position of the last UNIBUS backplane slot (ie, the 'UNIBUS out' slot).

Some of the jumpers on the card need to be configured to allow this, the M9312
technical manual gives the exact jumper configuration needed.

So on the 11/40, you can replace the M930 (or M9301) bus terminator card with 
the
M9312 with termination enabled.

On 5/22/2016 4:55 PM, Paul Anderson wrote:

An M930 terminator in the far left slot in A/B, where you have the RL11
(M7762). I don't remember if the G7273 is a unibus or q-bus grant card. I
always use the G727 , I think, the little 2 inch by 2 inch or so.

Try front panel funstions with the RL11 out.  You'll probably have to move
it to slot 3.

There is a trick to using a M9301 or m9312  in an 11/40, but I don't
remember it now.  It's been a while since since I've played with an 11/40.

On Sun, May 22, 2016 at 6:07 PM, william degnan 
wrote:


Paul,
What terminator card exactly?  As I had written originally, the system was
functional before I added the core planes.  I was thinking that I needed a
terminator now that I have more than just the cpu plus four slot plane, but
I did not have the space for it along with all of the cards I already have
installed.


http://vintagecomputer.net/digital/pdp11-40/card-layout_moved-plane_Pic2.JPG
(I removed the grant cards from the core planes per Tony's suggestion.)


--
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg 
Youtube: @billdeg 
Unauthorized Bio 

Re: General Question about UNIBUS backplanes

[Don North]

The M9312 can be setup to also act as a UNIBUS terminator card, and can reside 
in the

A-B position of the last UNIBUS backplane slot (ie, the 'UNIBUS out' slot).

Some of the jumpers on the card need to be configured to allow this, the M9312
technical manual gives the exact jumper configuration needed.

So on the 11/40, you can replace the M930 (or M9301) bus terminator card with 
the
M9312 with termination enabled.

On 5/22/2016 4:55 PM, Paul Anderson wrote:

An M930 terminator in the far left slot in A/B, where you have the RL11
(M7762). I don't remember if the G7273 is a unibus or q-bus grant card. I
always use the G727 , I think, the little 2 inch by 2 inch or so.

Try front panel funstions with the RL11 out.  You'll probably have to move
it to slot 3.

There is a trick to using a M9301 or m9312  in an 11/40, but I don't
remember it now.  It's been a while since since I've played with an 11/40.

On Sun, May 22, 2016 at 6:07 PM, william degnan <billdeg...@gmail.com>
wrote:


Paul,
What terminator card exactly?  As I had written originally, the system was
functional before I added the core planes.  I was thinking that I needed a
terminator now that I have more than just the cpu plus four slot plane, but
I did not have the space for it along with all of the cards I already have
installed.


http://vintagecomputer.net/digital/pdp11-40/card-layout_moved-plane_Pic2.JPG
(I removed the grant cards from the core planes per Tony's suggestion.)


--
@ BillDeg:
Web: vintagecomputer.net
Twitter: @billdeg <https://twitter.com/billdeg>
Youtube: @billdeg <https://www.youtube.com/user/billdeg>
Unauthorized Bio <http://www.vintagecomputer.net/readme.cfm>




--
Don North
AK6DN

Re: PDP-11/34a hung bus problem.

[Don North]

On 5/14/2016 2:41 PM, Noel Chiappa wrote:

 > From Ed Groenenberg

 > - insert both CPU cards, KY11-LB card & bootstrap card, 5 full grant
 > cards, DL11-W  and bus terminator card.
 > ...
 > - cntrl + boot shows register dump at printer.
 > ...
 > All looks ok

I'm surprised the bootstrap ran OK with no memory at all in the machine. I
vaguely STR that I had a machine that would not work like that, but maybe I'm
wrong. (DEC bootstaps tend to do things like set the NXM vector, in low
memory, so they can size memory; and when it gets the NXM (since there is no
memory) from trying to touch the NXM vector, and tries to push the old PS and
PC to service _that_, and gets _another_ NXM, that 'double bus fault' often
causes many -11 processors to do a cheap suit)


If the bootstrap card is an M9312 with the standard console PROM, it does NOT 
require any
memory to be present/accessible to get to the ODT prompt that prints out the 
registers and
waits for a command. Only until you execute a device bootstrap command with 
'diagnostics

enabled' (the default) does the memory sizing/test/diagnostic code get 
exectuted.

Listing:  http://ak6dn.dyndns.org/PDP-11/M9312/23-248F1/23-248F1.lst

So the system working to this level with no memory present is normal.



 > power down machine, add memory (M7981, 128KW)

What's an M7981? Did you mean an M7891 MS11-L?

 > - power up machine -> run light is on, does not get cleared by
 > cntrl + halt.

This is where a UA11 would really help. I had similar issues with an -11/04,
and the UA11 was a huge help in figuring out what's going on. One glance and
you can see if a bus line is wedged, or something.


Agreed, a bus probe would really be helpful in further debug. Given that the 
system does not
even get back to the ODT prompt (which would not yet access memory) indicates 
that logic
on the memory card is hanging the bus. Could be a bad bus driver interface chip 
(8641, etc).



 > - power down & replace memory with grand card -> run light is off.

Well, that's good sign - the memory card didn't fry anything, at least...

 > - tried a 2nd memory card (M8722, 128KW)

Ooops. The MS11-M needs +/-12V, which is _not_ standard in most
machines/backplanes). The EUB in the 11/24 and 11/44 (which this card is
intended for) does have it. The really bad part is that those same pins
usually carry +/-15V in most MUD backplanes. So hopefully you didn't fry it.
It does have standard UNIBUS as well as EUB, but there's a jumper, IIRC.


Bad idea to put this card in an 11/34. As indicated the +12V VDD rail on the 
memory chips
is wired directly to the UNIBUS +15V line in the 11/34 (which can be set to +12V 
in the 11/44).
So you placed +15V (or more likely up to +15.5V or so) onto the memory chip VDD 
lines.
Some 16K chips had a 15V max spec on this pin, others only 13.2V. So it is 
possible you
toasted so memory chips, or not, depending on manufacturer and their sensitivity 
to OV.


In any event, DO NOT use this card again in the 11/34. It is not compatible with 
the backplane.



 > So what could be the problem here? The bus works without the memory

Two possibilities off the top of my head. i) The first memory card is bad (or
configured incorrectly), or.. ii) The M7891 uses +/-15V as well as +5V? So
maybe one of the other voltages is not so good? But you said the console
worked, and I think that uses other voltages (at least, in EIA mode - not
sure about 20mA, I never touch the stuff).

Noel

Re: UNIBUS/QBUS interface chips Was: Re: MEM11 update

[Don North]

On 5/2/2016 7:04 AM, Mattis Lind wrote:

The following chips have been used by DEC to interface to the QBUS, and
I have seen many of the above chips (e.g. 8641's) used there too, so I
think chips seen on one bus could be used on the other:

Drivers:

7439 - Various - Quad NAND

Transceivers:

2908 - AMD - Quad latching transceiver with tri-state output

I _believe_ the following chips are also usable as UNIBUS/QBUS interface
chips, but I'm not sure if I've seen one used there:

Transceivers:

8836 - National Semi - Quad NOR
8838 - National Semi - Quad transceiver (aka Signetics N8T38)

Quite a zoo!


DEC also used the DEC DC005 for the data and address lines on QBUS cards.
The Signetics code is C2324N


DEC also used the DC005 (8 pcs) for address / data interface on the M8739 KLESI 
(Aztec/RC25)

UNIBUS interface card. DC013's were used for the NPR/NPG and BR/BG logic.

Don

Re: Which RT-11 for an 11/03

[Don North]

Ok, filed as: https://github.com/simh/simh/issues/285

On 3/12/2016 11:14 PM, Don North wrote:

Fixed!

sim> set cpu 11/34 256K fpp
sim> set tdc enable
sim> attach tdc0 tu58.dsk
sim> b tdc0

BOOTING UP XXDP-XM EXTENDED MONITOR

XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM DD0
124KW OF MEMORY
UNIBUS SYSTEM

RESTART ADDRESS: 152000
TYPE "H" FOR HELP !

In file pdp11_td.c, comment out/delete line 1023 (red) "ctlr->rx_buf = 
ctlr->obuf[ctlr->obptr++];   /* get first byte */"


This would seem to be priming the read routine, but in fact it is discarding 
the first byte of the block zero bootstrap.


Don


case TD_OPBOO:
if (ctlr->ibptr < 2) {  /* whole packet read? */
ctlr->ilen = 2;
ctlr->o_state = TD_GETDATA; /* get rest of packet */
return;
}
else {
int8 *fbuf;
int i;

sim_debug (TDDEB_TRC, ctlr->dptr, "td_process_packet(OPBOO) 
Unit=%d\n", ctlr->ibuf[4]);

ctlr->unitno = ctlr->ibuf[1];
fbuf = ctlr->uptr[ctlr->unitno].filebuf;
ctlr->block = 0;
ctlr->txsize = 0;
ctlr->p_state = TD_READ2;
ctlr->offset = 0;
ctlr->obptr = 0;

for (i=0; i < TD_NUMBY; i++)
ctlr->obuf[i] = fbuf[i];
ctlr->olen = TD_NUMBY;
//  ctlr->rx_buf = ctlr->obuf[ctlr->obptr++];   /* get first byte */
sim_data_trace(ctlr->dptr, >uptr[ctlr->unitno], ctlr->obuf, 
"Boot Block Data", ctlr->olen, "", TDDEB_DAT);

sim_activate (ctlr->uptr+ctlr->unitno, td_ctime);/* sched command */
}
break;

case TD_OPCNT:
break;







On 3/12/2016 10:19 PM, Don North wrote:

So I turned on full debug on the TDC device and I see the boot block is
being read correctly (bytes A0,00,20,01,...) but in the register reads
following that transfer the boot block to the PDP11 the first byte (A0)
is never seen, only bytes 00,20,01,...

So it appears to be a real bug in the TU58 SIMH implementation.

I'd cross post this info to the SIMH mailing list, but for some reason I
am unable to send to that mailing list, all my email gets rejected.

Don

DBG(930594)> TDC OWR: td_wr_o_buf()  o_state=GETDATA, ibptr=1, ilen=2
DBG(930594)> TDC OWR: TX_BUF: DAT=0x0
DBG(930594)> TDC TRC: td_process_packet() Opcode=OPBOO(8)
DBG(930594)> TDC TRC: td_process_packet(OPBOO) Unit=0
DBG(930594)> TDC DAT: TDC0  Boot Block Datalen: 0200
DBG(930594)> TDC DAT: A0 00 20 01 06 00 00 00 0A 00 00 00 00 00 00 00 .. 
.
DBG(930594)> TDC DAT: 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 


DBG(930594)> TDC DAT: 0020 thru 002F same as above
DBG(930594)> TDC DAT: 0030 00 00 00 00 00 00 00 00 02 0A 02 00 00 00 00 00 

DBG(930594)> TDC DAT: 0040 00 02 08 00 C6 15 00 60 05 00 C3 15 30 00 C2 15 
...`0...
DBG(930594)> TDC DAT: 0050 03 00 53 10 D1 0B C2 0A FC 02 E6 17 04 00 DF 15 
..S.
DBG(930594)> TDC DAT: 0060 6A 00 04 00 C9 0B 4B 10 03 01 CB 1D C4 FF 96 25 
j.K%
DBG(930594)> TDC DAT: 0070 9F 15 04 00 F7 15 08 00 C8 FF C4 15 00 02 37 10 
..7.
DBG(930594)> TDC DAT: 0080 BA FF E6 15 08 00 03 0A BF 0A A8 FF F7 09 E8 00 

DBG(930594)> TDC DAT: 0090 FF 0A A0 FF C3 15 04 04 FF 0B 96 FF F7 09 DC 00 

DBG(930594)> TDC DAT: 00A0 03 0A F7 09 EA 00 C3 00 C3 A5 10 00 04 03 CE 0A 

DBG(930594)> TDC DAT: 00B0 EA 02 D6 0B 58 01 D6 0B B7 0A 86 FF F7 25 28 00 
X%(.
DBG(930594)> TDC DAT: 00C0 80 FF 06 02 C2 1D 74 FF C1 1D 64 FF 5F 00 26 02 
..t...d._.&.
DBG(930594)> TDC DAT: 00D0 F7 09 96 00 02 0A C0 15 38 00 02 64 42 0B C1 8A 
8..dB...
DBG(930594)> TDC DAT: 00E0 FC 02 88 10 F7 09 82 00 C0 15 38 00 03 14 F7 09 
..8.
DBG(930594)> TDC DAT: 00F0 8A 00 C1 8A FB 80 F7 09 92 00 C3 A5 01 00 12 02 

DBG(930594)> TDC DAT: 0100 C2 10 C3 00 C1 90 C1 45 00 FF 81 0C F7 09 7C 00 
...E..|.
DBG(930594)> TDC DAT: 0110 D4 10 C2 60 42 0B C1 8A F9 02 F7 09 6E 00 C2 20 
...`B...n..
DBG(930594)> TDC DAT: 0120 EA 03 22 01 C3 A5 02 00 1E 02 C2 10 C3 00 C1 90 
..".
DBG(930594)> TDC DAT: 0130 C1 45 00 FF 81 8C F7 09 52 00 C3 A5 40 00 13 02 
.E..R...@...
DBG(930594)> TDC DAT: 0140 C3 0B 11 81 C2 60 42 0B C1 8A F7 09 3E 00 C2 60 
.`B.>..`
DBG(930594)> TDC DAT: 0150 42 0B C1 8A FA 02 C3 0B 06 81 F7 09 2E 00 C2 20 
B..
DBG(930594)> TDC DAT: 0160 03 02 77 00 52 FF 00 00 00 00 C1 9D CB FE C1 45 
..w.R..E
DBG(930594)> TDC DAT: 0170 00 FF 81 0C 81 0A 87 00 CF 09 CF 09 CF 09 FF 90 

DBG(93

Re: Which RT-11 for an 11/03

[Don North]

Fixed!

sim> set cpu 11/34 256K fpp
sim> set tdc enable
sim> attach tdc0 tu58.dsk
sim> b tdc0

BOOTING UP XXDP-XM EXTENDED MONITOR

XXDP-XM EXTENDED MONITOR - XXDP V2.5
REVISION: F0
BOOTED FROM DD0
124KW OF MEMORY
UNIBUS SYSTEM

RESTART ADDRESS: 152000
TYPE "H" FOR HELP !

In file pdp11_td.c, comment out/delete line 1023 (red) "ctlr->rx_buf = 
ctlr->obuf[ctlr->obptr++];   /* get first byte */"


This would seem to be priming the read routine, but in fact it is discarding the 
first byte of the block zero bootstrap.


Don


case TD_OPBOO:
if (ctlr->ibptr < 2) {  /* whole packet read? */
ctlr->ilen = 2;
ctlr->o_state = TD_GETDATA; /* get rest of packet */
return;
}
else {
int8 *fbuf;
int i;

sim_debug (TDDEB_TRC, ctlr->dptr, "td_process_packet(OPBOO) 
Unit=%d\n", ctlr->ibuf[4]);

ctlr->unitno = ctlr->ibuf[1];
fbuf = ctlr->uptr[ctlr->unitno].filebuf;
ctlr->block = 0;
ctlr->txsize = 0;
ctlr->p_state = TD_READ2;
ctlr->offset = 0;
ctlr->obptr = 0;

for (i=0; i < TD_NUMBY; i++)
ctlr->obuf[i] = fbuf[i];
ctlr->olen = TD_NUMBY;
//  ctlr->rx_buf = ctlr->obuf[ctlr->obptr++];   /* get first byte */
sim_data_trace(ctlr->dptr, >uptr[ctlr->unitno], ctlr->obuf, 
"Boot Block Data", ctlr->olen, "", TDDEB_DAT);

sim_activate (ctlr->uptr+ctlr->unitno, td_ctime);/* sched command */
}
break;

case TD_OPCNT:
break;







On 3/12/2016 10:19 PM, Don North wrote:

So I turned on full debug on the TDC device and I see the boot block is
being read correctly (bytes A0,00,20,01,...) but in the register reads
following that transfer the boot block to the PDP11 the first byte (A0)
is never seen, only bytes 00,20,01,...

So it appears to be a real bug in the TU58 SIMH implementation.

I'd cross post this info to the SIMH mailing list, but for some reason I
am unable to send to that mailing list, all my email gets rejected.

Don

DBG(930594)> TDC OWR: td_wr_o_buf()  o_state=GETDATA, ibptr=1, ilen=2
DBG(930594)> TDC OWR: TX_BUF: DAT=0x0
DBG(930594)> TDC TRC: td_process_packet() Opcode=OPBOO(8)
DBG(930594)> TDC TRC: td_process_packet(OPBOO) Unit=0
DBG(930594)> TDC DAT: TDC0  Boot Block Datalen: 0200
DBG(930594)> TDC DAT: A0 00 20 01 06 00 00 00 0A 00 00 00 00 00 00 00 .. 
.
DBG(930594)> TDC DAT: 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 


DBG(930594)> TDC DAT: 0020 thru 002F same as above
DBG(930594)> TDC DAT: 0030 00 00 00 00 00 00 00 00 02 0A 02 00 00 00 00 00 

DBG(930594)> TDC DAT: 0040 00 02 08 00 C6 15 00 60 05 00 C3 15 30 00 C2 15 
...`0...
DBG(930594)> TDC DAT: 0050 03 00 53 10 D1 0B C2 0A FC 02 E6 17 04 00 DF 15 
..S.
DBG(930594)> TDC DAT: 0060 6A 00 04 00 C9 0B 4B 10 03 01 CB 1D C4 FF 96 25 
j.K%
DBG(930594)> TDC DAT: 0070 9F 15 04 00 F7 15 08 00 C8 FF C4 15 00 02 37 10 
..7.
DBG(930594)> TDC DAT: 0080 BA FF E6 15 08 00 03 0A BF 0A A8 FF F7 09 E8 00 

DBG(930594)> TDC DAT: 0090 FF 0A A0 FF C3 15 04 04 FF 0B 96 FF F7 09 DC 00 

DBG(930594)> TDC DAT: 00A0 03 0A F7 09 EA 00 C3 00 C3 A5 10 00 04 03 CE 0A 

DBG(930594)> TDC DAT: 00B0 EA 02 D6 0B 58 01 D6 0B B7 0A 86 FF F7 25 28 00 
X%(.
DBG(930594)> TDC DAT: 00C0 80 FF 06 02 C2 1D 74 FF C1 1D 64 FF 5F 00 26 02 
..t...d._.&.
DBG(930594)> TDC DAT: 00D0 F7 09 96 00 02 0A C0 15 38 00 02 64 42 0B C1 8A 
8..dB...
DBG(930594)> TDC DAT: 00E0 FC 02 88 10 F7 09 82 00 C0 15 38 00 03 14 F7 09 
..8.
DBG(930594)> TDC DAT: 00F0 8A 00 C1 8A FB 80 F7 09 92 00 C3 A5 01 00 12 02 

DBG(930594)> TDC DAT: 0100 C2 10 C3 00 C1 90 C1 45 00 FF 81 0C F7 09 7C 00 
...E..|.
DBG(930594)> TDC DAT: 0110 D4 10 C2 60 42 0B C1 8A F9 02 F7 09 6E 00 C2 20 
...`B...n..
DBG(930594)> TDC DAT: 0120 EA 03 22 01 C3 A5 02 00 1E 02 C2 10 C3 00 C1 90 
..".
DBG(930594)> TDC DAT: 0130 C1 45 00 FF 81 8C F7 09 52 00 C3 A5 40 00 13 02 
.E..R...@...
DBG(930594)> TDC DAT: 0140 C3 0B 11 81 C2 60 42 0B C1 8A F7 09 3E 00 C2 60 
.`B.>..`
DBG(930594)> TDC DAT: 0150 42 0B C1 8A FA 02 C3 0B 06 81 F7 09 2E 00 C2 20 
B..
DBG(930594)> TDC DAT: 0160 03 02 77 00 52 FF 00 00 00 00 C1 9D CB FE C1 45 
..w.R..E
DBG(930594)> TDC DAT: 0170 00 FF 81 0C 81 0A 87 00 CF 09 CF 09 CF 09 FF 90 

DBG(930594)> TDC DAT: 0180 B4 FE C3 00 FF 8B AC FE FD 80 87 00 03 0A CF 09 

DBG

Re: Which RT-11 for an 11/03

[Don North]

So I turned on full debug on the TDC device and I see the boot block is
being read correctly (bytes A0,00,20,01,...) but in the register reads
following that transfer the boot block to the PDP11 the first byte (A0)
is never seen, only bytes 00,20,01,...

So it appears to be a real bug in the TU58 SIMH implementation.

I'd cross post this info to the SIMH mailing list, but for some reason I
am unable to send to that mailing list, all my email gets rejected.

Don

DBG(930594)> TDC OWR: td_wr_o_buf()  o_state=GETDATA, ibptr=1, ilen=2
DBG(930594)> TDC OWR: TX_BUF: DAT=0x0
DBG(930594)> TDC TRC: td_process_packet() Opcode=OPBOO(8)
DBG(930594)> TDC TRC: td_process_packet(OPBOO) Unit=0
DBG(930594)> TDC DAT: TDC0  Boot Block Datalen: 0200
DBG(930594)> TDC DAT: A0 00 20 01 06 00 00 00 0A 00 00 00 00 00 00 00 .. 
.
DBG(930594)> TDC DAT: 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 


DBG(930594)> TDC DAT: 0020 thru 002F same as above
DBG(930594)> TDC DAT: 0030 00 00 00 00 00 00 00 00 02 0A 02 00 00 00 00 00 

DBG(930594)> TDC DAT: 0040 00 02 08 00 C6 15 00 60 05 00 C3 15 30 00 C2 15 
...`0...
DBG(930594)> TDC DAT: 0050 03 00 53 10 D1 0B C2 0A FC 02 E6 17 04 00 DF 15 
..S.
DBG(930594)> TDC DAT: 0060 6A 00 04 00 C9 0B 4B 10 03 01 CB 1D C4 FF 96 25 
j.K%
DBG(930594)> TDC DAT: 0070 9F 15 04 00 F7 15 08 00 C8 FF C4 15 00 02 37 10 
..7.
DBG(930594)> TDC DAT: 0080 BA FF E6 15 08 00 03 0A BF 0A A8 FF F7 09 E8 00 

DBG(930594)> TDC DAT: 0090 FF 0A A0 FF C3 15 04 04 FF 0B 96 FF F7 09 DC 00 

DBG(930594)> TDC DAT: 00A0 03 0A F7 09 EA 00 C3 00 C3 A5 10 00 04 03 CE 0A 

DBG(930594)> TDC DAT: 00B0 EA 02 D6 0B 58 01 D6 0B B7 0A 86 FF F7 25 28 00 
X%(.
DBG(930594)> TDC DAT: 00C0 80 FF 06 02 C2 1D 74 FF C1 1D 64 FF 5F 00 26 02 
..t...d._.&.
DBG(930594)> TDC DAT: 00D0 F7 09 96 00 02 0A C0 15 38 00 02 64 42 0B C1 8A 
8..dB...
DBG(930594)> TDC DAT: 00E0 FC 02 88 10 F7 09 82 00 C0 15 38 00 03 14 F7 09 
..8.
DBG(930594)> TDC DAT: 00F0 8A 00 C1 8A FB 80 F7 09 92 00 C3 A5 01 00 12 02 

DBG(930594)> TDC DAT: 0100 C2 10 C3 00 C1 90 C1 45 00 FF 81 0C F7 09 7C 00 
...E..|.
DBG(930594)> TDC DAT: 0110 D4 10 C2 60 42 0B C1 8A F9 02 F7 09 6E 00 C2 20 
...`B...n..
DBG(930594)> TDC DAT: 0120 EA 03 22 01 C3 A5 02 00 1E 02 C2 10 C3 00 C1 90 
..".
DBG(930594)> TDC DAT: 0130 C1 45 00 FF 81 8C F7 09 52 00 C3 A5 40 00 13 02 
.E..R...@...
DBG(930594)> TDC DAT: 0140 C3 0B 11 81 C2 60 42 0B C1 8A F7 09 3E 00 C2 60 
.`B.>..`
DBG(930594)> TDC DAT: 0150 42 0B C1 8A FA 02 C3 0B 06 81 F7 09 2E 00 C2 20 
B..
DBG(930594)> TDC DAT: 0160 03 02 77 00 52 FF 00 00 00 00 C1 9D CB FE C1 45 
..w.R..E
DBG(930594)> TDC DAT: 0170 00 FF 81 0C 81 0A 87 00 CF 09 CF 09 CF 09 FF 90 

DBG(930594)> TDC DAT: 0180 B4 FE C3 00 FF 8B AC FE FD 80 87 00 03 0A CF 09 

DBG(930594)> TDC DAT: 0190 FF 8B 9C FE FD 80 C5 1F 98 FE E5 81 43 D1 C3 00 
C...
DBG(930594)> TDC DAT: 01A0 87 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

DBG(930594)> TDC DAT: 01B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 


DBG(930594)> TDC DAT: 01C0 thru 01FF same as above
DBG(930597)> TDC RRD: td_rd(PA=17776500(RX_CSR), access=0-Read)
DBG(930597)> TDC IRD: RX_CSR: DONE0 IE0
DBG(930599)> TDC RRD: td_rd(PA=17776500(RX_CSR), access=0-Read)
...
DBG(930763)> TDC IRD: RX_CSR: DONE1 IE0
DBG(930765)> TDC RRD: td_rd(PA=17776502(RX_BUF), access=0-Read)
DBG(930765)> TDC IRD: RX_BUF: ERR0 OVR0 RBRK0DAT=0x00 
<---DATA=00

DBG(930767)> TDC RRD: td_rd(PA=17776500(RX_CSR), access=0-Read)
...
DBG(930943)> TDC IRD: RX_CSR: DONE1 IE0
DBG(930945)> TDC RRD: td_rd(PA=17776502(RX_BUF), access=0-Read)
DBG(930945)> TDC IRD: RX_BUF: ERR0 OVR0 RBRK0 DAT=0x20 
<---DATA=20

DBG(930947)> TDC RRD: td_rd(PA=17776500(RX_CSR), access=0-Read)
DBG(930947)> TDC IRD: RX_CSR: DONE0 IE0
DBG(930949)> TDC RRD: td_rd(PA=17776500(RX_CSR), access=0-Read)
...



On 3/12/2016 9:47 PM, Don North wrote:
I've been doing some testing on the (new) SIMH TU58 device, and am finding 
that reading the boot block does not work.


I have TU58 bootable images, and when I try and boot from them in SIMH they 
halt/crash.


I adapted my PDP-11 M(312 TU58 boot code to a loadable SIMH image, and found 
that it appears that the TU58 boot command in SIMH (which should read block 
zero of the selected unit into memory locations 0-777(8)) is skipping over the 
first byte in the boot block (the 240(8) byte that is part of the NOP in the 
first word of every DEC bootstrap).


If I dump the first section of the bootable .dsk image I see:

local[505] od -

Re: Which RT-11 for an 11/03

[Don North]

I've been doing some testing on the (new) SIMH TU58 device, and am finding that 
reading the boot block does not work.


I have TU58 bootable images, and when I try and boot from them in SIMH they 
halt/crash.


I adapted my PDP-11 M(312 TU58 boot code to a loadable SIMH image, and found 
that it appears that the TU58 boot command in SIMH (which should read block zero 
of the selected unit into memory locations 0-777(8)) is skipping over the first 
byte in the boot block (the 240(8) byte that is part of the NOP in the first 
word of every DEC bootstrap).


If I dump the first section of the bootable .dks image I see:

local[505] od -b -N512 -v tu58.dsk
000 240 000 040 001 006 000 000 000 012 000 000 000 000 000 000 000
020 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
040 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
060 000 000 000 000 000 000 000 000 002 012 002 000 000 000 000 000
100 000 002 010 000 306 025 000 140 005 000 303 025 060 000 302 025
120 003 000 123 020 321 013 302 012 374 002 346 027 004 000 337 025

but when I give the 'boot' opcode to the emulated TU58 in SIMH it returns:

+:  000 040 001 006 000 000 000 012 000 000 000 000 000 000 000 000
+0020:  000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
+0040:  000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
+0060:  000 000 000 000 000 000 000 002 012 002 000 000 000 000 000 000
+0100:  002 010 000 306 025 000 140 005 000 303 025 060 000 302 025 003
+0120:  000 123 020 321 013 302 012 374 002 346 027 004 000 337 025 152

By inspection the bytes are the same, just shifted down one location from
where they should be, and the 240(8) byte in location zero is missing.

So this is why 'boot tdc0' fails in the current SIMH on github.

PDP-11 simulator V4.0-0 Betagit commit id: b304d7f4
Disabling XQ
TDC: buffering file in memory
Debug output to "tdc.log"
PDP-11 simulator V4.0-0 Beta
Simulator Framework Capabilities:
32b data
32b addresses
Ethernet Packet transports:PCAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
Asynchronous I/O support
FrontPanel API Version 2
Host Platform:
Compiler: GCC 5.3.0
Simulator Compiled: Mar 12 2016 at 16:36:37
Memory Access: Little Endian
Memory Pointer Size: 32 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
OS: CYGWIN_NT-6.1-WOW lenovoS30w7 2.4.1(0.293/5/3) 2016-01-24 
11:24 i686 Cygwin

git commit id: b304d7f4
PDP-11 simulator configuration



On 3/12/2016 3:58 PM, Don North wrote:
Whoops slight correction .. . the TU58 protocol supports a 16b block number, 
so it is 65536 blocks of 512B, or 32MB maximum.


On 3/12/2016 3:55 PM, Don North wrote:

Well looks like I have been living in the past ...

I have been using v3.9 SIMH from the SIMH website (the 'legacy' version) and 
have now gone an upgraded to the github v4.0 version. This one it appears has 
supported the serial virtual TU58 device since mid 2015 (at least by comment 
dates).


I have tried it, and it successfully boots my XXDP TU58 images, as one should 
expect.


However, I tried mounting a larger than 256KB physical TU58 image on the 
virtual TU58 (as one can do with a real TU58) but it does not appear to work 
as I expect. I should be able to mount a 10MB RL02 XXDP image on a TU58 and 
then do read-only accesses to the full image. The real TU58 protocol supports 
up to 32MB devices (512 blocks of 512 bytes) but it seems that the SIMH TU58 
only supports a physical TU58 tape image of 256KB. I'll have to do some more 
experiments and read some code to see what is going on.


If this restriction is in place it does rather significantly limit the 
utility of the TU58 virtual serial device, in not allowing one to build an 
(up to) 32MB disk image under SIMH, and then move it to a real TU58. Limiting 
simh to only 256KB sized images is being true to the physical limitation of 
TU58 cartridges, but not true to the actual capability of the TU58 serial 
line protocol.


Don

On 3/11/2016 11:19 AM, Richard Cini wrote:
I had a little time after lunch to try the below procedure and using the 
beta version of SIMH I am able to create a tape image that's bootable by 
SIMH without the below error.


I copied the following to the image, which I will try with TU58em when I get 
home tonight:


DD, TT, rt11sj, DU, SL, LD, pip, dir, swap, dup, and starts.com.

The size of the image is 504 blocks (264 free).

Rich

Sent from my iPhone

On Mar 11, 2016, at 1:26 PM, Mattis Lind <mattisl...@gmail.com> wrote:


SIMH has never

Re: Which RT-11 for an 11/03

[Don North]

Whoops slight correction .. . the TU58 protocol supports a 16b block number, so 
it is 65536 blocks of 512B, or 32MB maximum.


On 3/12/2016 3:55 PM, Don North wrote:

Well looks like I have been living in the past ...

I have been using v3.9 SIMH from the SIMH website (the 'legacy' version) and 
have now gone an upgraded to the github v4.0 version. This one it appears has 
supported the serial virtual TU58 device since mid 2015 (at least by comment 
dates).


I have tried it, and it successfully boots my XXDP TU58 images, as one should 
expect.


However, I tried mounting a larger than 256KB physical TU58 image on the 
virtual TU58 (as one can do with a real TU58) but it does not appear to work 
as I expect. I should be able to mount a 10MB RL02 XXDP image on a TU58 and 
then do read-only accesses to the full image. The real TU58 protocol supports 
up to 32MB devices (512 blocks of 512 bytes) but it seems that the SIMH TU58 
only supports a physical TU58 tape image of 256KB. I'll have to do some more 
experiments and read some code to see what is going on.


If this restriction is in place it does rather significantly limit the utility 
of the TU58 virtual serial device, in not allowing one to build an (up to) 
32MB disk image under SIMH, and then move it to a real TU58. Limiting simh to 
only 256KB sized images is being true to the physical limitation of TU58 
cartridges, but not true to the actual capability of the TU58 serial line 
protocol.


Don

On 3/11/2016 11:19 AM, Richard Cini wrote:
I had a little time after lunch to try the below procedure and using the beta 
version of SIMH I am able to create a tape image that's bootable by SIMH 
without the below error.


I copied the following to the image, which I will try with TU58em when I get 
home tonight:


DD, TT, rt11sj, DU, SL, LD, pip, dir, swap, dup, and starts.com.

The size of the image is 504 blocks (264 free).

Rich

Sent from my iPhone

On Mar 11, 2016, at 1:26 PM, Mattis Lind <mattisl...@gmail.com> wrote:


SIMH has never directly supported mounting/attaching virtual TU58 devices.
Altho the required serial interface
is emulated (ie, a plain DL11 at 776500/300) the TU58 drive behind the
serial interface has never been emulated.

I just tested the latest SimH from github and it is indeed possible to
enable tdc and attach an image file to the tdc0 device. I then booted into
RT11 from a DU-device and did INIT DD0: no problem.
Then I made a bootable DD image. I did even do a BOOT DD0: which gave me a
RT11-prompt. But booting from SimH failed on me. I am not sure why.

MattisMacBook:BIN mattis$ ./pdp11
PDP-11 simulator V4.0-0 Betagit commit id: 1b6f28a7
sim> set tdc enable
sim> attach tdc0 rt11-dd.dsk
TDC: creating new file
TDC: buffering file in memory
sim> attach rq0 rt11v53-games.dsk
sim> b rq0

RT-11SJ  V05.03

.init dd0:
DD0:/Initialize; Are you sure? Y

.copy dd.sys dd0:
Files copied:
DK:DD.SYS  to DD0:DD.SYS
 Copying some files *


.copy rt11sj.sys dd0:
Files copied:
DK:RT11SJ.SYS  to DD0:RT11SJ.SYS

.copy/boot rt11sj.sys dd0:
.boot dd0:

RT-11SJ  V05.03

.dir

DD.SYS 5P 20-Dec-85  TT.SYS 2P 20-Dec-85
SWAP  .SYS27P 20-Dec-85  STARTS.COM 1P 20-Dec-85
DIR   .SAV19P 20-Dec-85  DUP   .SAV47P 20-Dec-85
DU.SYS 8P 20-Dec-85  RT11SJ.SYS79P 20-Dec-85
8 Files, 188 Blocks
316 Free blocks

.boot du0:


RT-11SJ  V05.03

.

Simulation stopped, PC: 146414 (BCC 146446)
sim> exit
Goodbye
TDC: writing buffer to file

PDP-11 simulator V4.0-0 Betagit commit id: 1b6f28a7
sim> set tdc enable
sim> attach tdc0 rt11-dd.dsk
TDC: buffering file in memory
sim> b tdc0


Trap stack push abort, PC: 00 (WAIT)
sim>

I have no idea why SimH is not able to boot from the simulated DD0: device.
The steps to make a bootable dd0: was exactly the same steps as to make a
bootable RK0: which works just fine.


Ersatz-11 on the other hand works fine with the same image:

E11>assign tt1: dda:
E11>mount dda0: rt11v53_dd.dsk
E11>b tt1:

RT-11SJ  V05.03

.dir

TT.SYS 2P 20-Dec-85  DD.SYS 5P 20-Dec-85
RT11SJ.SYS79P 20-Dec-85  SWAP  .SYS27P 20-Dec-85
STARTS.COM 1P 20-Dec-85  DIR   .SAV19P 20-Dec-85
RESORC.SAV25P 20-Dec-85
7 Files, 158 Blocks
346 Free blocks

.


This is the image that boots in Ersatz-11 but not in SimH:
https://dl.dropboxusercontent.com/u/96935524/rt11v53_dd.dsk.gz
Since it boots on Ersatz-11 when set to 11/03 CPU it should work on the
real hardware.

BTW. It not so that the LTC interrupt is enabled in your system? I have had
problem with that one. In certain cases it need to be disabled. If I
remember correctly I had problems booting RT11 from MSCP devices with LTC
enabled.

/Mattis




Don

Re: Which RT-11 for an 11/03

[Don North]

Well looks like I have been living in the past ...

I have been using v3.9 SIMH from the SIMH website (the 'legacy' version) and 
have now gone an upgraded to the github v4.0 version. This one it appears has 
supported the serial virtual TU58 device since mid 2015 (at least by comment dates).


I have tried it, and it successfully boots my XXDP TU58 images, as one should 
expect.


However, I tried mounting a larger than 256KB physical TU58 image on the virtual 
TU58 (as one can do with a real TU58) but it does not appear to work as I 
expect. I should be able to mount a 10MB RL02 XXDP image on a TU58 and then do 
read-only accesses to the full image. The real TU58 protocol supports up to 32MB 
devices (512 blocks of 512 bytes) but it seems that the SIMH TU58 only supports 
a physical TU58 tape image of 256KB. I'll have to do some more experiments and 
read some code to see what is going on.


If this restriction is in place it does rather significantly limit the utility 
of the TU58 virtual serial device, in not allowing one to build an (up to) 32MB 
disk image under SIMH, and then move it to a real TU58. Limiting simh to only 
256KB sized images is being true to the physical limitation of TU58 cartridges, 
but not true to the actual capability of the TU58 serial line protocol.


Don

On 3/11/2016 11:19 AM, Richard Cini wrote:

I had a little time after lunch to try the below procedure and using the beta 
version of SIMH I am able to create a tape image that's bootable by SIMH 
without the below error.

I copied the following to the image, which I will try with TU58em when I get 
home tonight:

DD, TT, rt11sj, DU, SL, LD, pip, dir, swap, dup, and starts.com.

The size of the image is 504 blocks (264 free).

Rich

Sent from my iPhone

On Mar 11, 2016, at 1:26 PM, Mattis Lind  wrote:


SIMH has never directly supported mounting/attaching virtual TU58 devices.
Altho the required serial interface
is emulated (ie, a plain DL11 at 776500/300) the TU58 drive behind the
serial interface has never been emulated.

I just tested the latest SimH from github and it is indeed possible to
enable tdc and attach an image file to the tdc0 device. I then booted into
RT11 from a DU-device and did INIT DD0: no problem.
Then I made a bootable DD image. I did even do a BOOT DD0: which gave me a
RT11-prompt. But booting from SimH failed on me. I am not sure why.

MattisMacBook:BIN mattis$ ./pdp11
PDP-11 simulator V4.0-0 Betagit commit id: 1b6f28a7
sim> set tdc enable
sim> attach tdc0 rt11-dd.dsk
TDC: creating new file
TDC: buffering file in memory
sim> attach rq0 rt11v53-games.dsk
sim> b rq0

RT-11SJ  V05.03

.init dd0:
DD0:/Initialize; Are you sure? Y

.copy dd.sys dd0:
Files copied:
DK:DD.SYS  to DD0:DD.SYS
 Copying some files *


.copy rt11sj.sys dd0:
Files copied:
DK:RT11SJ.SYS  to DD0:RT11SJ.SYS

.copy/boot rt11sj.sys dd0:
.boot dd0:

RT-11SJ  V05.03

.dir

DD.SYS 5P 20-Dec-85  TT.SYS 2P 20-Dec-85
SWAP  .SYS27P 20-Dec-85  STARTS.COM 1P 20-Dec-85
DIR   .SAV19P 20-Dec-85  DUP   .SAV47P 20-Dec-85
DU.SYS 8P 20-Dec-85  RT11SJ.SYS79P 20-Dec-85
8 Files, 188 Blocks
316 Free blocks

.boot du0:


RT-11SJ  V05.03

.

Simulation stopped, PC: 146414 (BCC 146446)
sim> exit
Goodbye
TDC: writing buffer to file

PDP-11 simulator V4.0-0 Betagit commit id: 1b6f28a7
sim> set tdc enable
sim> attach tdc0 rt11-dd.dsk
TDC: buffering file in memory
sim> b tdc0


Trap stack push abort, PC: 00 (WAIT)
sim>

I have no idea why SimH is not able to boot from the simulated DD0: device.
The steps to make a bootable dd0: was exactly the same steps as to make a
bootable RK0: which works just fine.


Ersatz-11 on the other hand works fine with the same image:

E11>assign tt1: dda:
E11>mount dda0: rt11v53_dd.dsk
E11>b tt1:

RT-11SJ  V05.03

.dir

TT.SYS 2P 20-Dec-85  DD.SYS 5P 20-Dec-85
RT11SJ.SYS79P 20-Dec-85  SWAP  .SYS27P 20-Dec-85
STARTS.COM 1P 20-Dec-85  DIR   .SAV19P 20-Dec-85
RESORC.SAV25P 20-Dec-85
7 Files, 158 Blocks
346 Free blocks

.


This is the image that boots in Ersatz-11 but not in SimH:
https://dl.dropboxusercontent.com/u/96935524/rt11v53_dd.dsk.gz
Since it boots on Ersatz-11 when set to 11/03 CPU it should work on the
real hardware.

BTW. It not so that the LTC interrupt is enabled in your system? I have had
problem with that one. In certain cases it need to be disabled. If I
remember correctly I had problems booting RT11 from MSCP devices with LTC
enabled.

/Mattis




Don

Re: Which RT-11 for an 11/03

[Don North]

On 3/10/2016 7:02 PM, j...@cimmeri.com wrote:

On 3/10/2016 9:36 PM, Richard Cini wrote:
Separately… John — the SLUs are at what I think are the standard addresses 
and vectors (per the Heathkit and DLV11-J manuals) and the ODT and TU58EM 
work. I don’t know what RT-11 is looking for but the console @ 177560/60 and 
TU58 @ 176500/300 (Channel 3 and Channel 0 in DLV11-J parlance). I have not 
tried booting SIMH with the TU58 image (not sure how to do that; need to work 
on it). Regarding getting a real RX01 or RL02, the issue for me is space. 
It’s pretty convenient using a laptop and TU58EM (providing I can get 
something other than XXDPD2D to work). If someone has already built bootable 
TU58 RT-11 images, I haven’t found them yet.


I have doubts that taking an RK05 image, and copying the DD: bootstrap in like 
that, and then simply taking that modified RK05 image and attempting to boot 
it as a TU58... I'm not sure if that could work.  Just seems like there'd been 
some structural differences.  But I could be wrong.


I forget if either SIMH or Ersatz emulates a TU58.. but if they do, try making 
an empty tape container (I think TU58EM can do this) and then build up and 
RT11 system as outlined in the manual using one of the emulators.  Make sure 
it can boot in the emulator (if that's possible).


Do you know for sure if a real TU58 can even run RT-11?   Never tried it.

p.s.  you could also get yourself a qbus SCSI card, and have a much smaller 
disk subsystem.


- J.



Creating/running an RT-11 image on a TU58 tape, and then booting/running it 
under TU58EM has been
discussed in the past. I would suggest reading thru this thread, as it did 
succeed in building a bootable

TU58 RT-11 image:

http://www.vcfed.org/forum/showthread.php?39372-Wanted-RT-11-OS-as-a-TU-58-image/page2=tu58em

RT-11 can run from a TU58 disk (tape) as demonstrated above, on real PDP-11 
hardware.


SIMH has never directly supported mounting/attaching virtual TU58 devices. Altho 
the required serial interface
is emulated (ie, a plain DL11 at 776500/300) the TU58 drive behind the serial 
interface has never been emulated.


Theoretically one could attach the emulated serial port in SIMH to a real serial 
port that TU58EM is connected to
(or use something like comOcom on windows to wire together virtual serial ports) 
and run TU58EM with SIMH,
but I know of noone doing this (I never have, altho I believe it is technically 
possible to do).


I believe that ERSATZ-11 has integrated support for TU58 image support mounting, 
so that might be the way

to go to build a TU58 image under simulation.

I have seen rumblings that someone might be working on a virtual TU58 device for 
SIMH, but maybe it is just
an idea at this point for a rainy day. The code would be pretty straightforward 
I suspect.


Don

Re: Which RT-11 for an 11/03

[Don North]

On 3/10/2016 5:24 PM, Richard Cini wrote:

Gary, et. al.--

Ok, I spent some time trying this again, and here’s what I did. The system is 
very basic — LSI-11 CPU, 32kw of RAM and two SLU cards. Using PDP11GUI and 
TU58em emulator. XXDPD2D tape image loads and runs properly with this 
configuration and the standard boot loader.

Based on the instructions on Malcom Macleod’s site, I prepared an RT-11 
TU58-target tape image from the base RK05 image from the SIMH distribution. The 
key incantation is:

COPY/BOOT:DD RK0:RT11SJ.SYS RK0:

What this should do is make the disk image bootable as a TU58 image.

Next, I fired-up TU58em, loaded the boot loader into the H11 and ran it. Here’s 
the log from TU58:

D:\DEC>tu58em -v -p 3 -s 9600 -w rtv4_dd.dsk >>log.txt
info: unit 0 rw   file 'rtv4_dd.dsk'
info: serial port 3 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: boot unit=0 blk=0x cnt=0x0200
info: read unit=0 sw=0x00 mod=0x00 blk=0x0002 cnt=0x0800
info: read unit=0 sw=0x00 mod=0x00 blk=0x0006 cnt=0x0400
info: read unit=0 sw=0x00 mod=0x00 blk=0x0008 cnt=0x0400
info: read unit=0 sw=0x00 mod=0x00 blk=0x000A cnt=0x0400
info: read unit=0 sw=0x00 mod=0x00 blk=0x000C cnt=0x0400
info: read unit=0 sw=0x00 mod=0x00 blk=0x0134 cnt=0x0A00
info: read unit=0 sw=0x00 mod=0x00 blk=0x0085 cnt=0x0132 info: read unit=0 
sw=0x00 mod=0x00 blk=0x0086 cnt=0x3CC8 At this point, the RUN LED goes off and the system halts.  It looks like the boot loader is loading and running the second-level loader on the tape, but something happens after that. Not sure where to go from here.


These last two read commands look awful suspicious to me. A single logical 
device block is 512B (or 0x200) so the count
parameter is 0x200 for one block, 0x400 for two consecutive blocks, etc. 0xA00 
is five consecutive blocks.


However, 0x0132 (306. bytes) is a partial block read, and 0x3CC8 (15560.) is a 
read of 30.+ blocks. So I would speculate
that the code went south prior to these two read commands. Just a guess of 
course as I have never done this particular
task. But I would guess that the image you are using has been corrupted in the 
process.


Don

info: read unit=0 sw=0x00 mod=0x00 blk=0x0085 cnt=0x0132 info: read unit=0 
sw=0x00 mod=0x00 blk=0x0086 cnt=0x3CC8

Re: Imaging RX02 disks for simh (was: Re: MU-BASIC V2 and RT-11 V03B distribution disks.)

[Don North]

On 3/6/2016 8:56 AM, Brian Walenz wrote:

How the heck do you copy an RX02 disk for use in simh?

I've been trying to transfer RX02 images between simh and a real PDP11
(that has only two RX02's, console, and ethernet).  So far, I've only
attempted sending an RX02 image from the PDP to simh, but simh fails to
read it: "?DIR-F-Invalid directory".  Even after adding 13*512 bytes to the
start for the missing track, I still get invalid directory.

My process is to COPY/DEVICE/FILES DY1:/START:0/END:330 DY0:BLOCK1.DAT,
then FTP that off the PDP, delete the file, and do the remaining two thirds
of the disk.  Once all are transferred, "cat *DAT > floppy.dsk".

I can transfer RX50 images using the same recipe, though I haven't tried
sending an RX50 image created on simh back to the PDP.

For what it's worth, I'm having the same problem with Alan Baldwin's TCP/IP
disk images from http://shop-pdp.net/rthtml/tcpip.htm.  simh can't read the
individual DSK images, but could read the *.PKG with the disks inside, and
from that, I could (RT-11) MOUNT each disk to a logical device.

b


From the SIMH pdp11 RX driver (pdp11_rx.c) the disk size is computed as follows,
and the byte offset into the file is computed by CALC_DA(trk,sec) given the 
PHYSICAL
track (0..76) and sector (1..26) addresses used in accessing the controller.

So the SIMH disk image should be 77*26*128 = 256,256 bytes for an RX01 format.
RX02 format is same number of tracks and sectors, but has 256 byte sectors.

So if you image an RX disk using logical operating system 512B blocks there are
494 of them (76*26*128/512 = 494) numbered 0..493. Track 0 is skipped in the
filesystem (block 0 is at track=1 sector=1) for legacy compatibility reasons 
(with IBM).


However, since the SIMH file is in physical track/sector order, if you read the 
disk image
using logical device blocks, you have to know how the driver interleaves logical 
blocks

onto physical track/sectors, as you must de-interleave to build the SIMH file.

Or else you must run a program on the PDP-11 side that reads the RX drive as 
physical

tracks and sectors, not using file system access commands.

It's not pretty, but if you think about it enough it is the only way for SIMH to 
simulate the

RX/RY devices and be operating system agnostic.

Don

From PDP11/pdp11_rx.c:

#define RX_NUMTR77  /* tracks/disk */
#define RX_NUMSC26  /* sectors/track */
#define RX_NUMBY128 /* bytes/sector */
#define RX_SIZE (RX_NUMTR * RX_NUMSC * RX_NUMBY) /* bytes/disk */

#define CALC_DA(t,s) (((t) * RX_NUMSC) + ((s) - 1)) * RX_NUMBY

Re: PDP-8/e - Front panel switch reproductions and front panel PCB?

[Don North]

On 3/2/2016 11:16 AM, Anders Nelson wrote:

I found switch levers and a mounting frame design (
http://www.thingiverse.com/thing:360853) that I would like to have casted
with molded-in color, close to the originals as reasonable.

Has anyone already done this that I can simply buy from? If any injection
molds have been built I'd love to put those to work. Would it be better to
just paint a 3D print of these?

Also has anyone created the front panel PCB design? I use EAGLE and would
love to at least have a CAD outline from which to start as I build my
emulated PDP-8/e. Pretty much like the SBC6120 but emulated on a 32-bit
micro as opposed to the HD6120.

I await your thoughts!


Have you seen this: http://obsolescence.wix.com/obsolescence#!pidp-8/cbie

It might just satisfy your 'need' (and there are a lot more blinkin' lights on 
the 8i then on the 8e).


If this is not quite right, the basic design may make a good jumping off point 
to get to an 8e variation.


Oscar's design is a scaled (~2/3) configuration, so it is not an 'exact' replica 
per se. There is another
project in the works to create exact PDP-8e/f/m etc replica front panels (Rob 
Smallwood IIRC) but
I believe that is the acrylic panel only, nothing else. You need to supply all 
the other 8e parts yourself.


Don

Re: VAX 11/730 quickie

[Don North]

On 2/24/2016 1:11 PM, Mike Ross wrote:

Why are you using MRSP mode (-m switch)? Do you know that is absolutely
required?

For VAX-11/730 console yes it is absolutely required as far as I know;
everything I've read about people using emulation there says that it
is.

Mike


Yes it appears that is correct. Going back to this thread:
http://www.vcfed.org/forum/showthread.php?36113-Problems-using-tu58em-with-VAX-11-725-VAX-11-730/page13
there was a whole lot of discussion on bringing up a '730 with TU58EM, and the 
updates to it (to fix some time delays)

to support the TU58 device on the '730 with TU58EM.

I have since updated mainline TU58EM to version 1.4m to add Mark Blair's VAX 730 
timing and background mode changes
(enable via -x and -b switches). Source and cygwin executable here: 
https://github.com/AK6DN/tu58em

Functionally this should be the same as Mark's version 1.4j + his changes.

Don

Re: VAX 11/730 quickie

[Don North]

On 2/24/2016 3:43 AM, Mike Ross wrote:

On Tue, Feb 23, 2016 at 4:26 AM, Mike Ross <tmfdm...@gmail.com> wrote:

On Mon, Feb 22, 2016 at 10:14 AM, Mark J. Blair <n...@nf6x.net> wrote:

On Feb 21, 2016, at 23:09, Mike Ross <tmfdm...@gmail.com> wrote:
Actually I do have a Mac within easy range of the 730. Could you do me
a favour and throw a prebuilt OSX binary somewhere I can grab it? I
have flaky internet in the workshop and this Mac isn't set up with
Xcode or any other dev environment...

https://dl.dropboxusercontent.com/u/29876211/tu58em.zip

Thanks Mark... I played with this. I built a 3-wire cable; I'm sure I
have it wired right because traffic happens - and if I disconnect, or
switch Rx/Tx, it just sits there but this is as far as it gets:

MikeUpstairs:~ Imac$ ./tu58 -s 38400 -p /dev/tty.usbserial -d -v -m -x
-r vax73058
info: unit 0 rfile 'vax73058'
info: tu58 tape emulator v1.4j (NF6X fork)
info: (C) 2005-2014 Don North <ak...@mindspring.com>, (C) 1984 Dan
Ts'o 
info: serial port /dev/tty.usbserial at 38400 baud
info: MRSP mode enabled (NOT fully tested - use with caution)
info: TU58 emulation start
info: R restart, S toggle send init, V toggle verbose, D toggle debug, Q quit
info: emulator started

(I ctrl-c the VAX)

info: flag=0x00 last=0x00
info:  seen
info: flag=0x00 last=0x00
info:  seen
info: flag=0x04 last=0x00
info:  seen
info: flag=0x04 last=0x04
info:  seen
info:  seen, sending 

(?27 DEVICE ERROR on VAX)

(I ctrl-c the VAX again)

info: flag=0x00 last=0xFF
info:  seen
info: flag=0x00 last=0x00
info:  seen
info: flag=0x04 last=0x00
info:  seen
info: flag=0x04 last=0x04
info:  seen
info:  seen, sending 

(?27 DEVICE ERROR on VAX)

(repeat)

Can you spot me being stupid? Does my command line look sane re.
various options?

(I've trivially renamed the tape image file for faster typing
otherwise it's straight out of the box)

Just for giggles I decided to try Bela Torok's Arduino-based emulator:

http://www.torok.info/computing/pdp11/tu58/

I whipped that up from bits tonight and got it working surprisingly
quickly. But the VAX still doesn't want to play; from the behaviour
and messages it's falling over at exactly the same place. The Arduino
serial console displays:

Continue after 2 INIT flags. online!

And VAX shows the now-familiar ?27 DEVICE ERROR...

Which looks a HELL of a lot like how tu58em is ending. So I don't
think the problem is with tu58em...

Is there anything I should be looking at on the VAX end here? Any
configuration or cabling details that could be screwing things up
before I drag the RS232 analyser out? I've tried changing the 'delay'
parameter on the Arduino to various values between 0 and 255 to no
avail - and I've tried a couple of different tape images in case I got
a bad one...

Mike

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'



Why are you using MRSP mode (-m switch)? Do you know that is absolutely 
required?

Re: Need cheap source for anti-static chip tubes

[Don North]

On 1/16/2016 2:04 PM, Steven Hirsch wrote:
Title says it.  Perhaps I'm being stupid about search terms, but I'm not 
finding much of anything on eBay.  One seller has TSOP tubes, but I need 
plain, old 300mm DIP tubes.  End plugs and pins for them as well.


Plenty of companies offering them on the web, but all are oriented for 
production quantities.  I'd be happy with 20-25.






www.jameco.com

300mil tubes for 25c each for 10 or more. They sell the rubber end plugs as well 
7c each in 100s.


http://www.jameco.com/Jameco/catalogs/c152/P123.pdf  middle of the page

Re: Has Anyone Written PDP-8 .XOR. Code Using the MQ Register (Without the EAE)?

[Don North]

On 12/23/2015 10:50 PM, Don North wrote:

On 12/23/2015 7:14 PM, Christian Gauger-Cosgrove wrote:

On 23 December 2015 at 13:44, CLASystems <clasyst...@gmail.com> wrote:

Ironically, the shortest and fastest seems to be avoidance of the MQ
altogether [thus making it work on ANY model].

 TAD  ARGONE
 AND  ARGTWO
 CLL RAL
 CIA
 TAD  ARGONE
 DCA ARGTWO

This works because .XOR. is addition ignoring the carry bits. So, knowing
they will happen, just allow them at first, then remove them.


Hmm, I just tried that in SIMH, and that doesn't XOR at all.
I think there was just a bit of brain fade in the original listing. From 
DEC-08-FFAA-D PDP-8 Math Library circa 1968

the XOR routine is as follows, transcribed to SIMH:

sim> de 76 1234
sim> de 77 4321
sim> ie -m 100-107
100:CLA CLL
101:TAD 76
102:AND 77
103:CIA
104:CLL RAL
105:TAD 76
106:TAD 77
107:HLT
sim> go 100

HALT instruction, PC: 00110 (AND 0)
sim> ex ac
AC: 5115

Which produces the correct result in the AC. Locations 103/104 were swapped in 
order, and location 106 was left out.

And for completeness location 100 was added to initially clear the AC/Link.

Don



FYI here is a link to find the document: 
http://manx.classiccmp.org/details.php/1,3191

I can't find it under dec/pdp8 on bitsavers, maybe I'm just not seeing it.

Don

Re: Piggybacking 74LS logic chips to confirm a suspected fault

[Don North]

Or it is a mechanical fault due to a package/die bond wire becoming an open 
circuit.
This could happen to where the wire joins to either the package or the die pad, 
or
a wire that was fused due to excess current. Hard to tell unless you decap the 
package.


On 12/22/2015 1:32 PM, Alexandre Souza wrote:

Becaise they have diodes to gnd/vcc. And the common failure of a diode is a
rupture of the barrier and so, it gets shorted. So the gate is shorted to
ground or vcc

Enviado do meu Tele-Movel
Em 22/12/2015 19:29, "Chuck Guzis"  escreveu:


On 12/22/2015 01:10 PM, Alexandre Souza wrote:


It works if the gate is open. But if it is shorted to gnd/vcc, you're
in trouble :)


In my experience, this is the case with a lot of 4000-series CMOS. Don't
exactly understand why.

--Chuck

Re: KiCad Footprint ??

[Don North]

On 12/20/2015 5:02 AM, GerardCJAT wrote:

Speaking of KiCad 
Yesterday, I tried for the first time KiCad, and my first board design with it.
The very first part I was looking for  I was not able to locate it.
Is it because I am a newbe or because this part does not exist yet, beeing "too 
old"  ??
I was looking for :

Card edge connector ( fingers print ) , any contact count, BUT   pitch = 3.96 mm

Any help ?? Thanks !!

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus



That is pretty obscure, it is not like a standard IC footprint or connector.

Better to learn now how to create your own footprints in the KiCAD symbol 
editor.

Re: PDP2011 board

[Don North]

On 10/22/2015 10:09 PM, ben wrote:

On 10/22/2015 10:54 PM, Don North wrote:

For PDP2011 direct compatibility then the path of least resistance is
probably
the DE0-NANO with CycloneIV for $79. I have several; nice little boards
for experimentation.
You can get it from Adafruit ($99) or Digikey as well. Direct from
Terasic has high shipping cost.


A quick look at the PDP2011 site says that is it is too small
for the optional PDP 11 features.



Not sure what you mean by 'too small'. The boards have the same number of
header pins ((2x20)x2). You do need to wire up RS232 serial and SDcard to the
DE0-NANO (burning about 8 or so pins) since they are not on the baseboard.
And of course on the smaller board you don't get all the LEDs and switches.

The CycloneII part on the DE1 board has fewer logic elements than does the
CycloneIV part on the DE0-NANO, and has less embedded RAM blocks as well.

His source has configuration files for the DE0-NANO so it is probably just a 
matter
of recompiling.

Re: PiDP-11 plans...

[Don North]

On 10/22/2015 9:06 PM, ben wrote:

On 10/22/2015 8:45 PM, Mark Matlock wrote:

Oscar, I am very excited to hear about your PiDP-11 project. I also
would urge you to go to 1:1 scale for the PDP-11/70 panel and also
utilize the classic Purple and Pink color scheme.



One other comment I would make is that it would be great to modified
the SImh V4.0 to work with the PDP-11 front panel.Most of the
code supporting the panels are either V3.8 or V3.9. These front panel
reanimations should be part of the Simh development.



How about considering making a front panel for the
Altera DE1 (original) FPGA card.


Mark

Hi,

I suspect only a short time the orginal DE1 cards will be sold out
and the NEW version *DOES NOT HAVE THE SDCARD SLOT*
Ben.



Not to worry. The newer DE0-CV board (and others with CycloneV parts) have 
MicroSD.
Basically the same as SDcard, different physical form factor.

Re: PDP2011 board

[Don North]

On 10/22/2015 6:11 PM, jwsmobile wrote:


I'm not sure if the author of this nice bit of work is on here, but I'm 
looking at a board for this, the Altera DE-1. Unfortunately there are a 
plethora of Altera DE-1 boards and much puzzlement by me as to whether this is 
the right one.  The page with the info is deficient in details to tell.


The actual part which the author used is the key thing here, and not just the 
name of the board.  I'd appreciate opinions here as to whether these will run 
PDP2011 or whether it will be a nice learning board for my mistake pile.


http://pdp2011.sytse.net/wordpress/pdp-11/fpga-boards/de1/

There is currently what I think is a good specimen available if anyone is 
interested.


http://www.ebay.com/itm/131621388597

It includes the software and docs.  The current one I have was a student 
version sans the documents and software.


I hope to get the thing going to play with sometime soon.   There are so many 
small boards out there for very little money once I get this done and 
understand more about targeting this board and others I'd like to see how 
cheap a board this could be made to run with give the current boards.


There is currently an Arm/fpga Zilog chip board now made available that would 
be a nifty board to make into a PDP11 if it comes out as cheap as they promise 
it to be.


thanks
Jim


I have one of the DE1 CycloneII device boards and at this point that family 
(CycloneII) is a bit old.
If you can get it really cheap (<<$50) go for it, but the last Altera toolset 
that supports CycloneII is v13.0sp1 (v15.0 is current).
I have moved most all my new experimentation on to the CycloneIV and CycloneV 
family devices.


If you plan to use a board going forward for some time, the newer CycloneV based 
boards are a better choice:

http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English=13=Simple#Category167

In particular the DE0-CV has a lot of nice features for implementing a PDP-11 
($150):

http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English=167=921=1

Or if you want to go light on the hardware design and lean more on embedded 
software, the DE0-NANO-SOC  board ($99):

http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English=167=941

The DE0-NANO CycloneIV  board ($79) is also a good choice:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English=139=593

At this point I would stay away from CycloneIII or CycloneII boards (unless you 
can get one very cheap) as the tech is older.


Don

VAX 730 was Re: Self modifying code, lambda calculus - Re: ENIAC programming

[Don North]

On 9/18/2015 10:15 PM, tony duell wrote:

Simple answer. The control store functionality had to fit in the available space
on one hex
sized card, and 16K density DRAM was the only option. Allocating additional
space to use
4K or 1K SRAM would have pushed the CPU design to an additional board, which 
was not
a design option at the time.

The 11/730 was released in 1982 (according to Wikipedia which I don't take a 
gospel, but
I have no other source of information for this). The PERQ 1a was certainly out 
by then, it had
a control store using 16K*1 SRAM chips. OK 20 pin as against 16 pin packages, 
but I don't
think the 11/730 boards are that tighly packed (anyway, using SRAM would 
probably have
eliminated some support devices like address multiplexers).

-tony


Yes it was released in mid--1982 (that is correct) but the architecture started 
in 1977 and the first proto was built in 1979. By 1980 the design was finalized 
and multiple copies were being built and distributed to software development.


Documented here: 
http://bitsavers.trailing-edge.com/pdf/dec/vax/730/memos/730_Business_Plan_Phase_III_Oct82.pdf
Page 8 has a detailed timeline. So the 730 was implemented based on the 
technology available in late 79 or so.


The biggest risk I remember from the 730 design (I worked in the same hardware 
lab, different project: 11/74 CIS) was the extensive use of PALs. This was the 
first (I believe) project at DEC to use them, and they were basically buying all 
the devices MMI could produce. It was one of the limiting factors determining 
the number of prototypes that could be built.


Other projects (like the one I was working on) wanted to use PALs, but we 
couldn't because they were all allocated to the 730 project.

Re: Self modifying code, lambda calculus - Re: ENIAC programming

[Don North]

On 9/18/2015 9:51 PM, tony duell wrote:

The VAX-11/730 would have to have the microcode on TU58, as that is the
console media. Quite possible that it actually do load the microcode
from there at power up. I've heard that those machine were slow in so
many ways... :-)

The 11/730 has no microcode ROM as far as I can see. However part of the
instruction decoding is done in hardware, so implementing a totally different
instruction set would be inefficient

The craziest thing I have found in the 11/730 is that the control store is
dynamic RAM (lots of 16K*1 chips). Every few milliseconds the CPU is
halted while the control store is refreshed. There is space for 4K more
of control store (1K of that is fitted if you have the integrated disk
controller or floating point board) which is SRAM. Quite why the whole
lot isn't SRAM is beyond me.

-tony


Simple answer. The control store functionality had to fit in the available space 
on one hex
sized card, and 16K density DRAM was the only option. Allocating additional 
space to use

4K or 1K SRAM would have pushed the CPU design to an additional board, which 
was not
a design option at the time.

Don

Re: SIMH PDP-8 question

[Don North]

On 9/18/2015 7:08 AM, Vincent Slyngstad wrote:

From: Charles: Thursday, September 17, 2015 6:46 PM
Anyway, I'd like to do the same thing in SIMH (get the text file into Focal 
and then save it as a Focal program). Is there any way to do this with SIMH? 
Can I assign the text file to a paper tape reader, for example?


This should work fairly easily using the high speed paper tape peripherals of 
SIMH.  You can equip an output file for the punch, punch the "tape", then 
equip that file for the reader, and I believe the asterisk command or some 
such Focal feature will read it in.  Save to disk, and you'll have your text 
file converted.


Low speed paper tape on SIMH is more problematic, as you don't really have an 
8 bit channel, flow control isn't implemented, etc.  (At least on the console 
that is shared with the SIMH command prompt.)


   Vince


I have also used 'expect' to drive SIMH to have my 'expect' robot play 
tic-tac-toe vs the PDP-8 (endlessly ...) and to drive files into FOCAL and BASIC 
from the command line as typed text.


Don

Re: MAINDEX-11 CZKMA Diagnostic?

[Don North]

On 8/18/2015 7:36 PM, Ben Sinclair wrote:

I'm again trying to debug my PDP-11/23, and I believe I'm having
trouble with my M8067-LB/MSV-11 memory.

According to the manual, there is a diagnostic program called CZKMA
(for my 18-bit system), but I can't seem to find it.

I have all of the xxdp images from AK6DN, but this one doesn't appear
to be on any of those. Some searching shows references to it and even
a (poorly) scanned source listing, but does anyone know if I can get
it on a TU58 image or another format?

Thanks!



VMJAB0 is the MSV11-J memory test, on this TU58 disk image: 
https://ak6dn.dyndns.org/PDP-11/TU58/1123_1.dsk