15 May
2014
15 May
'14
1:04 a.m.
The SCSI2SD project
(http://www.codesrc.com/mediawiki/index.php?title=SCSI2SD) was brought
up here a few months back -- it's effectively a SCSI disk emulator,
using Micro-SD cards as the backing store. I ordered a couple and I
started chatting with the creator (Michael) about supporting
non-standard sector sizes (for example, the 1280 byte/sectors that the
Symbolics XL400, XL1200, and XL1201 demand...) SCSI drives that support
sector sizes other than 512 bytes are getting more and more hard to
find, and having a modern replacement would be awesome.
Michael was extremely receptive to the idea (he was already working on
256 byte/sector support) and added non-standard sector size support
(from 64 to 2048 bytes/sector) and I tried it out with my XL1200. It
didn't work initially, but over the last month we've iterated over a few
potential fixes, with me gathering logs and diagnostics and him doing
all the hard work of fixing the firmware. And finally this morning the
last bug was squashed -- I have my XL1200 booting Genera entirely from
a Micro-SD card. It actually seems to be a little bit faster than the
Seagate drive I've been using (and I'm still running a debug version of
the firmware) :).
If anyone's looking for a replacement for oddball SCSI devices like
this, the SCSI2SD seems to be a pretty good option. Michael has been
very receptive to bug reports and suggestions (and of course, the source
is open to anyone who wants to hack away at it...)
Just thought there might be a few people on this list interested in this
news...
- Josh
15 May
15 May
4:37 a.m.
I for one appreciate the information.
Very similar innovations have have transpired in the Commodore / C-64
world, though over there it's known as "SD2IEC" or something to that
effect.
Same or similar situation though. It uses an SD card as the storage
backend for a custom hardware that emulates the Commodore 1540 / 1541 etc.
drives.
7:34 a.m.
On 2014-05-15 02:04, Josh Dersch wrote:
The SCSI2SD project
Just thought there might be a few people on this list interested in this
news...
Anybody out here tried it with a MicroVAX, VAXStation etc?
That's where most other SCSI emulators fail, so I would be very
interested. (So I can finally stop making my owns ;-) )
Cheers
4:23 p.m.
New subject: Homebrew SCSI/ATA controllers for DEC - Re: Singing the praises of the SCSI2SD project...
On 15/05/14 10:34 AM, emanuel stiebler wrote:
On 2014-05-15 02:04, Josh Dersch wrote:
Wait - are you making your own scsi adapters for vax/pdp? If so, can you
publish specifications?
thanks
--Toby
The SCSI2SD project
Just thought there might be a few people on this list interested in this
news...
Anybody out here tried it with a MicroVAX, VAXStation etc?
That's where most other SCSI emulators fail, so I would be very
interested. (So I can finally stop making my owns ;-) )
Cheers
5:10 p.m.
New subject: Homebrew SCSI/ATA controllers for DEC - Re: Singing the praises of the SCSI2SD project...
On 2014-05-15 17:23, Toby Thain wrote:
Wait - are you making your own scsi adapters for
vax/pdp? If so, can you
publish specifications?
No, sorry. I gave up on this side (qbus & unibus) as I got enough for
myself, and there simply is not enough interest in them, as the prices
really dropped on ebay. One day, I probably make a qbus to sd-flash
version, but my day job is really in the way of things like that.
Anyway, what I was looking for are SCSI<->SDFlash controller,
as they would make my desktop machines quieter, and the rotating rust
things ae not getting more reliable. And how nice that is, to just
replace a sd-flash, and boot something completely different ;-)
Cheers
5:48 p.m.
New subject: Homebrew SCSI/ATA controllers for DEC - Re: Singing the praises of the SCSI2SD project...
On 05/15/2014 04:23 PM, Toby Thain wrote:
On 15/05/14 10:34 AM, emanuel stiebler wrote:
Not strictly related, but this reminded me of the IDE adapter plans for
Qbus and UNIBUS that were floating around some years back.
Mirror: http://www.telegraphics.com.au/pdp11/dsu
I haven't unpacked any of the files there, so I couldn't say how
complete a solution it is. But there are circuit diagrams, and the
original authors claim to have gone the extra mile, and include patches
to get several DEC OSes running.
Then there was Brad Parker's thread on the same topic, which I'd
forgotten about:
https://groups.google.com/d/msg/alt.sys.pdp11/iJp5R8uqBOQ/1Pd0xGmm-R8J
I lost track of this as I moved cross country a couple months later. But
judging from this thread in late 2012, it moved forward considerably -
but I haven't found a final outcome yet:
http://www.classiccmp.org/pipermail/cctech/2012-October/098178.html
Either way an IDE interface should give you a path to using Compact
Flash, in terms of moving beyond rotating media...
--Steve.
Anybody out here tried it with a MicroVAX, VAXStation etc?
That's where most other SCSI emulators fail, so I would be very
interested. (So I can finally stop making my owns ;-) )
Wait - are you making your own scsi adapters for vax/pdp? If so, can
you publish specifications? 
6:23 p.m.
New subject: Homebrew SCSI/ATA controllers for DEC - Re: Singing the praises of the SCSI2SD project...
On 5/15/2014 6:48 PM, Steven M Jones wrote:
Either way an IDE interface should give you a path to using Compact
Flash, in terms of moving beyond rotating media...
But if you plan to go that way, stock up on the NEW MEDIA now
while you can get smallish parts.
--Steve.
Ben.
16 May
16 May
8:37 a.m.
New subject: Homebrew SCSI/ATA controllers for DEC - Re: Singing the praises of the SCSI2SD project...
Not strictly related, but this reminded me of the IDE
adapter plans
for Qbus and UNIBUS that were floating around some years back.
I was helping with one, once upon a time. What evidence I can find
says this was around February 2002, but I'm not sure whether that's
when I was working on it or a timestamp corresponding to something
else, like when I last copied the files.
I never saw the hardware. The person who was working on the hardware
gave me remote console (and network) access to the machine; I was
trying to write a driver for it for NetBSD/vax. I never got it
working. The project - from my point of view - kinda fell apart while
I was still struggling with, based on fuzzy memory, some kind of
addressing issue.
I still appear to have all the code I wrote, in case that matters.
Mouse
17 May
17 May
8:41 a.m.
New subject: Homebrew SCSI/ATA controllers for DEC - Re: Singing the praises of the SCSI2SD project...
I did finish an 2.11BSD and RT11 driver for the hardware years later,
but never went back at NetBSD.
http://www.chdickman.com/qbus_ide/
On Fri, May 16, 2014 at 11:37 AM, Mouse <mouse at rodents-montreal.org> wrote:
I never saw the hardware. The person who was working on the hardware
gave me remote console (and network) access to the machine; I was
trying to write a driver for it for NetBSD/vax. I never got it
working. The project - from my point of view - kinda fell apart while
I was still struggling with, based on fuzzy memory, some kind of
addressing issue.
I had the I/O address space kind of scrambled from the normal ATA
order. There was a problem with interrupt handling logic too.
I still appear to have all the code I wrote, in case that matters.
Mouse
-chuck
15 May
15 May
8:44 a.m.
On May 15, 2014, at 01:04 , Josh Dersch <derschjo at gmail.com> wrote:
The SCSI2SD project
(http://www.codesrc.com/mediawiki/index.php?title=SCSI2SD) was brought up here a few
months back -- it's effectively a SCSI disk emulator, using Micro-SD cards as the
backing store.
I'm glad to hear that the project is still being improved! It was recommended to me
just this week by another collector as a good option for adding an emulated hard drive to
my PDP-11/03 (along with a SCSI card; I chose an Emulex UC07 from eBay). Sadly, it was
listed as being out of stock when I tried to order a couple of them. I hope they'll
reappear soon. I also want to try one in my Amiga 3000, where the Aztec Monster CF adapter
that I tried didn't make the computer happy. I ended up with another card reader meant
for 3.5" floppy bays just sitting loosely in the system's hard drive bay, since
the mounting screws didn't line up. If the SCSI2SD will work with my A3000, it should
install more neatly.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
9:24 a.m.
On May 15, 2014, at 8:44 AM, "Mark J. Blair" <nf6x at nf6x.net> wrote:
On May 15, 2014, at 01:04 , Josh Dersch <derschjo at gmail.com> wrote:
Can a PDP-11/03 handle a SCSI Adapter? Something like this might be fun for my PDP-11/73.
It's already practically silent since I moved it to 3.5" SCSI drives. :-)
The SCSI2SD project
(http://www.codesrc.com/mediawiki/index.php?title=SCSI2SD) was brought up here a few
months back -- it's effectively a SCSI disk emulator, using Micro-SD cards as the
backing store.
I'm glad to hear that the project is still being improved! It was recommended to me
just this week by another collector as a good option for adding an emulated hard drive to
my PDP-11/03 (along with a SCSI card; I chose an Emulex UC07 from eBay). Sadly, it was listed as being out of stock when I
tried to order a couple of them. I hope they'll reappear soon. I also want to try one
in my Amiga 3000, where the Aztec Monster CF adapter that I tried didn't make the
computer happy. I ended up with another card reader meant for 3.5" floppy bays just
sitting loosely in the system's hard drive bay, since the mounting screws didn't
line up. If the SCSI2SD will work with my A3000, it should install more neatly.
The A3000 is a system that this seems perfect for, I for one will be interested in hearing
your results.
Zane
--
healyzh at aracnet.com
http://blog.zanesphotography.com
http://www.flickr.com/photos/zanes-photography/
10:08 a.m.
Sent from mobile device that advertises itself for no good reason
On 15 May 2014, at 12:24, Zane Healy <healyzh at
aracnet.com> wrote:
> On May 15, 2014, at 8:44 AM, "Mark J. Blair" <nf6x at nf6x.net>
wrote:
>
>
>> On May 15, 2014, at 01:04 , Josh Dersch <derschjo at gmail.com> wrote:
>> The SCSI2SD project (http://www.codesrc.com/mediawiki/index.php?title=SCSI2SD)
was brought up here a few months back -- it's effectively a SCSI disk emulator, using
Micro-SD cards as the backing store.
>
> I'm glad to hear that the project is still being improved! It was recommended to
me just this week by another collector as a good option for adding an emulated hard drive
to my PDP-11/03 (along with a SCSI card; I chose an Emulex UC07 from eBay).
The /03 is 18-bit right? The SCSI adapter I have has an option for 18-bit addressing.
Can a PDP-11/03 handle a SCSI Adapter? Something like this might be fun for my
PDP-11/73. It's already practically silent since I moved it to 3.5" SCSI drives.
:-)
Sadly, it was listed as being out of stock when I
tried to order a couple of them. I hope they'll reappear soon. I also want to try one
in my Amiga 3000, where the Aztec Monster CF adapter that I tried didn't make the
computer happy. I ended up with another card reader meant for 3.5" floppy bays just
sitting loosely in the system's hard drive bay, since the mounting screws didn't
line up. If the SCSI2SD will work with my A3000, it should install more neatly.
The A3000 is a system that this seems perfect for, I for one will be interested in
hearing your results.
Zane
--
healyzh at aracnet.com
http://blog.zanesphotography.com
http://www.flickr.com/photos/zanes-photography/
10:26 a.m.
On 15 May 2014 13:08, Cory Smelosky <b4 at gewt.net> wrote:
The /03 is 18-bit right? The SCSI adapter I have has
an option for 18-bit addressing.
The LSI-11 and LSI-11/2 (PDP-11/03, in other words) processors are
only 16-bit addressing, actually. If my recollection is correct.
--
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.
2:12 p.m.
On May 15, 2014, at 10:26 , Christian Gauger-Cosgrove <captainkirk359 at gmail.com>
wrote:
On 15 May 2014 13:08, Cory Smelosky <b4 at
gewt.net> wrote:
I believe that my system's backplane is the 18-bit variety, as opposed to the 22-bit
variety. I think that the UC07 card will support both 18 and 22 bit busses. If I
understand correctly, the processor directly addresses 16 bits but uses some sort of bank
mapping register(s) to address additional bits, but I'm not positive about that.
In any case, I'll find out for sure whether it works when I try it. My SCSI card is
still in transit, but hopefully I'll know in a couple weeks or so.
My system's bootstrap ROMs don't include code for MSCP-compatible controllers, but
the UC07 is supposed to have its own built-in bootstrap. I don't know if I'll
still have access to the original bootstrap ROMs after I jumper everything for the UC07
bootstrap. Maybe I'll need to route one or more jumpers out to some external
switch(es) to let me boot from the RX02 when desired?
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
The /03 is 18-bit right? The SCSI adapter I have
has an option for 18-bit addressing.
The LSI-11 and LSI-11/2 (PDP-11/03, in other words) processors are
only 16-bit addressing, actually. If my recollection is correct. 
2:52 p.m.
On Thu, May 15, 2014 at 3:12 PM, Mark J. Blair <nf6x at nf6x.net> wrote:
On May 15, 2014, at 10:26 , Christian Gauger-Cosgrove <
captainkirk359 at gmail.com> wrote:
The LSI-11 and LSI-11/2 (PDP-11/03, in other words) processors are
only 16-bit addressing, actually. If my recollection is correct.
I believe that my system's backplane is the 18-bit variety, as opposed to
the 22-bit variety. I think that the UC07 card will support both 18 and 22
bit busses. If I understand correctly, the processor directly addresses 16
bits but uses some sort of bank mapping register(s) to address additional
bits, but I'm not positive about that.
The 11/03 doesn't have memory management, so it's limited to strictly
16-bit addressing. However, peripherals that use 18-bit addressing should
still work fine.
The 11/23 has memory management and supports 18-bit or 22-bit addressing,
depending on the hardware rev and the backplane.
On 15 May 2014 13:08, Cory Smelosky <b4 at
gewt.net> wrote:
> The /03 is 18-bit right? The SCSI adapter I have has an option for
18-bit
addressing.
6:01 p.m.
On May 15, 2014, at 5:52 PM, Eric Smith <spacewar at gmail.com> wrote:
On Thu, May 15, 2014 at 3:12 PM, Mark J. Blair
<nf6x at nf6x.net> wrote:
Be careful there. The PDP-11/20 doesn?t have MMU either. And the software indeed
manipulates 16 bit addresses. But the I/O bus (Unibus) has 18 bit addresses. The bus
interface supplies 0 for the upper 2 bits if the lower 16 are less than 0160000, and two
bits of 1 if the lower 16 are 0160000 or higher (i.e., the PDP11 I/O page space).
So on Unibus at least, there is no such thing as a 16 bit peripheral; all are 18 bit by
definition.
paul
On May 15, 2014, at 10:26 , Christian Gauger-Cosgrove <
captainkirk359 at gmail.com> wrote:
The LSI-11 and LSI-11/2 (PDP-11/03, in other words) processors are
only 16-bit addressing, actually. If my recollection is correct.
I believe that my system's backplane is the 18-bit variety, as opposed to
the 22-bit variety. I think that the UC07 card will support both 18 and 22
bit busses. If I understand correctly, the processor directly addresses 16
bits but uses some sort of bank mapping register(s) to address additional
bits, but I'm not positive about that.
The 11/03 doesn't have memory management, so it's limited to strictly
16-bit addressing. However, peripherals that use 18-bit addressing should
still work fine. On 15 May 2014 13:08, Cory Smelosky <b4 at
gewt.net> wrote:
> The /03 is 18-bit right? The SCSI adapter I have has an option for
18-bit
addressing.
8:41 p.m.
On Thu, May 15, 2014 at 7:01 PM, Paul Koning <paulkoning at comcast.net> wrote:
On May 15, 2014, at 5:52 PM, Eric Smith <spacewar at gmail.com> wrote:
should
There's also no such thing as a Unibus LSI-11. (Though there are ways to
connect an LSI-11 to a Unibus.)
On Thu, May 15, 2014 at 3:12 PM, Mark J. Blair
<nf6x at nf6x.net> wrote:
>
> On May 15, 2014, at 10:26 , Christian Gauger-Cosgrove <
> captainkirk359 at gmail.com> wrote:
>> On 15 May 2014 13:08, Cory Smelosky <b4 at gewt.net> wrote:
>>> The /03 is 18-bit right? The SCSI adapter I have has an option for
> 18-bit addressing.
>>>
>>
>> The LSI-11 and LSI-11/2 (PDP-11/03, in other words) processors are
>> only 16-bit addressing, actually. If my recollection is correct.
>
> I believe that my system's backplane is the 18-bit variety, as opposed
to
> the 22-bit variety. I think that the UC07
card will support both 18 and
22
> bit busses. If I understand correctly, the
processor directly addresses
16
> bits but uses some sort of bank mapping
register(s) to address
additional
bits, but
I'm not positive about that.
The 11/03 doesn't have memory management, so it's limited to strictly
16-bit addressing. However, peripherals that use 18-bit addressing still work fine.
Be careful there. The PDP-11/20 doesn?t have MMU either. And the
software indeed manipulates 16 bit addresses. But the I/O bus (Unibus) has
18 bit addresses. The bus interface supplies 0 for the upper 2 bits if the
lower 16 are less than 0160000, and two bits of 1 if the lower 16 are
0160000 or higher (i.e., the PDP11 I/O page space).
So on Unibus at least, there is no such thing as a 16 bit peripheral; all
are 18 bit by definition.
16 May
16 May
1:24 p.m.
Be careful there. The PDP-11/20 doesn?t have MMU
either. And the
software indeed manipulates 16 bit addresses. But the I/O bus (Unibus)
has 18 bit addresses. The bus interface supplies 0 for the upper 2 bits
if the lower 16 are less than 0160000, and two bits of 1 if the lower
16 are 0160000 or higher (i.e., the PDP11 I/O page space).
The smae applies to the 11/05 and 11/10. And the 11/35, 11/40, 11/45, etc
(where hte MMU ias actually an option). And I asusme the 11/04.
So on Unibus at least, there is no such thing as a 16 bit peripheral;
all are 18 bit by definition.
It's sim,ialr of Qbus, but IIRC there is an I/O page signal on the bus
(produced by the arbiter, I think, anyway, it's the PCU card tht sources
it) which is asserted when the address is in the approprtiate range. So
the I/O cards don't ahve to decode the top few address lines.
One major difference between Unibus and Qbus concerns DMA (or NPR as DEC
called it). Qbuscan have 22 address lines, a peripheral doing DMA has to
generate the full 22 bit address. Unibus has 18 address lines. The Unibus
machine that allow 22 bit addressing (11/44, 11/70, etc) have their
memory o na private bus, on the Unibus. A DMA peripheral generates an 18
bit address which is then translated to a 22 bit address by a simple MMU
called the 'Unibus Map' which is part of the processor on such machines.
-tony
15 May
15 May
3:16 p.m.
On May 15, 2014, at 5:12 PM, Mark J. Blair <nf6x at nf6x.net> wrote:
On May 15, 2014, at 10:26 , Christian Gauger-Cosgrove <captainkirk359 at gmail.com>
wrote:
The way it works for my CMD CQD-220 is that you can have its
bootstrap ROMs respond to 1773000, the typical bootstrap location,
or 1771000 (my recollection). It's jumper-selectable (including
no bootstrap access at all). Fortunately, my 11/23+ has MSCP boot
in its ROMs, so I don't need to worry about it.
- Dave
On 15 May 2014 13:08, Cory Smelosky <b4 at
gewt.net> wrote:
I believe that my system's backplane is the 18-bit variety, as opposed to the 22-bit
variety. I think that the UC07 card will support both 18 and 22 bit busses. If I
understand correctly, the processor directly addresses 16 bits but uses some sort of bank
mapping register(s) to address additional bits, but I'm not positive about that.
In any case, I'll find out for sure whether it works when I try it. My SCSI card is
still in transit, but hopefully I'll know in a couple weeks or so.
My system's bootstrap ROMs don't include code for MSCP-compatible controllers,
but the UC07 is supposed to have its own built-in bootstrap. I don't know if I'll
still have access to the original bootstrap ROMs after I jumper everything for the UC07
bootstrap. Maybe I'll need to route one or more jumpers out to some external
switch(es) to let me boot from the RX02 when desired? The /03 is 18-bit right? The SCSI adapter I have
has an option for 18-bit addressing.
The LSI-11 and LSI-11/2 (PDP-11/03, in other words) processors are
only 16-bit addressing, actually. If my recollection is correct. 
4:24 p.m.
On Thu, May 15, 2014 at 3:16 PM, David Riley <fraveydank at gmail.com> wrote:
On May 15, 2014, at 5:12 PM, Mark J. Blair <nf6x at
nf6x.net> wrote:
With the CMD CQD controllers you can disable the controller bootstrap
at either 773000 or 771000 if you want to coexist with another
bootstrap in the system (for example on a BDV11), and then if the
other bootstrap is not MSCP or TMSCP capable you can still get the CMD
CQD controller to boot by halting to ODT and using the magic sequence
to access the on board utility and use that to boot:
17772152/005400 123456 <CR>
17772152/001000 100 <CR>
5000G
(where 17772152 is the configured base CSR address + 2)
According to the Emulex UC07 manual it requires the CPU to be
configured in power-up mode 0 to boot through PC at 24 and PS at 26
instead of power-up mode 2 to boot at 773000. (How does that work,
does the controller DMA the bootstrap into system memory on bus
initialization?) I suppose in that case you could configure the CPU
and the UC07 to autoboot, and then if you wanted an alternate boot you
could halt to ODT and then manually execute your other bootstrap at
773000.
My system's bootstrap ROMs don't include code for MSCP-compatible controllers,
but the UC07 is supposed to have its own built-in bootstrap. I don't know if I'll
still have access to the original bootstrap ROMs after I jumper everything for the UC07
bootstrap. Maybe I'll need to route one or more jumpers out to some external
switch(es) to let me boot from the RX02 when desired?
The way it works for my CMD CQD-220 is that you can have its
bootstrap ROMs respond to 1773000, the typical bootstrap location,
or 1771000 (my recollection). It's jumper-selectable (including
no bootstrap access at all). Fortunately, my 11/23+ has MSCP boot
in its ROMs, so I don't need to worry about it.
5:26 p.m.
On May 15, 2014, at 19:24, Glen Slick <glen.slick at gmail.com> wrote:
With the CMD CQD controllers you can disable the controller bootstrap
at either 773000 or 771000 if you want to coexist with another
bootstrap in the system (for example on a BDV11), and then if the
other bootstrap is not MSCP or TMSCP capable you can still get the CMD
CQD controller to boot by halting to ODT and using the magic sequence
to access the on board utility and use that to boot:
17772152/005400 123456 <CR>
17772152/001000 100 <CR>
5000G
(where 17772152 is the configured base CSR address + 2)
Well, if the bootstrap is 771000, you can execute it with
771000g. Maybe I'm misreading what you wrote.
According to the Emulex UC07 manual it requires the
CPU to be
configured in power-up mode 0 to boot through PC at 24 and PS at 26
instead of power-up mode 2 to boot at 773000. (How does that work,
does the controller DMA the bootstrap into system memory on bus
initialization?)
In a lot of cases, that's exactly what happens (including the
above "magic sequence" for the CMD controllers, as well
as the one for bringing up the configuration menu).
From a QBUS standpoint, there isn't any reason the
controller
needs any particular reason to DMA something; it just needs
to request and receive a bus grant, which might as well
happen right after reset.
I suppose in that case you could configure the CPU
and the UC07 to autoboot, and then if you wanted an alternate boot you
could halt to ODT and then manually execute your other bootstrap at
773000.
In my experience, auto boot is 773000; the alternate
would be 771000. A 773000g on my 11/23 boots to ROM.
- Dave
6:21 p.m.
On Thu, May 15, 2014 at 5:26 PM, David Riley <fraveydank at gmail.com> wrote:
Well, if the bootstrap is 771000, you can execute it with
771000g. Maybe I'm misreading what you wrote.
Well yeah, you could do that too if you if you don't have anything
else at 771000, which is probably true in most configurations. I was
just covering the alternative method where you might have a need to
completely disable the CMD CQD bootstrap memory space. Also, if you
boot through the on board utility you can interactively choose the
boot device instead of the autoboot default.
In my experience, auto boot is 773000; the alternate
would be 771000. A 773000g on my 11/23 boots to ROM.
Autoboot at 773000 if it uses the CPU in power-up option 2. If the
autoboot mechanism uses the CPU in power-up option 0 as in the case
with the UC07 there may not be any bootstrap code visible at any
location on the controller.
4:40 p.m.
On May 15, 2014, at 15:16 , David Riley <fraveydank at gmail.com> wrote:
The way it works for my CMD CQD-220 is that you can
have its
bootstrap ROMs respond to 1773000, the typical bootstrap location,
or 1771000 (my recollection). It's jumper-selectable (including
no bootstrap access at all). Fortunately, my 11/23+ has MSCP boot
in its ROMs, so I don't need to worry about it.
As I recall from my first skimming of the UC07 manual, I need to change a boot mode jumper
on the CPU card to use the UC07 bootstrap. Now that I think of it, I should still be able
to get to the original bootstrap by halting the machine and then jumping to 1773000 in ODT
if I need to boot from a floppy. Or maybe I'll do the opposite, having it boot from
floppy by default but manually jumping to the UC07 bootstrap when needed.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
12:49 p.m.
Can a PDP-11/03 handle a SCSI Adapter? Something like this might be fun for my
PDP-11/73. It's already practically silent since I moved it to 3.5" SCSI drives.
:-)
An 11/03 can handle any qbus scsi adapter. They are getting a bit expensive
lately, though.
Sadly, it was listed as being out of stock when I
tried to order a couple of them. I hope they'll reappear soon. I also want to try one
in my Amiga 3000, where the Aztec Monster CF adapter that I tried didn't make the
computer happy. I ended up with another card reader meant for 3.5" floppy bays just
sitting loosely in the system's hard drive bay, since the mounting screws didn't
line up. If the SCSI2SD will work with my A3000, it should install more neatly.
The A3000 is a system that this seems perfect for, I for one will be interested in
hearing your results.
Zane
--
healyzh at aracnet.com
http://blog.zanesphotography.com
http://www.flickr.com/photos/zanes-photography/
11:50 a.m.
From: Josh Dersch
Sent: Thursday, May 15, 2014 1:04 AM
Michael was extremely receptive to the idea (he was
already working on
256 byte/sector support) and added non-standard sector size support
(from 64 to 2048 bytes/sector) and I tried it out with my XL1200.
It would be very nice if that were stretched just 2 bits, to 8192. This
would allow it to format for the Toad-1, which uses 2304 or 4608 as the
sector sizes. We can always use a Paralan SE-to-differential ("HVD") card
to take care of that part of the equation.
Mind seeing what he thinks about that?
Rich
Rich Alderson
Sr. Systems Engineer
Living Computer Museum
2245 1st Ave S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
3876
days inactive
3878
days old
24 comments
19 participants
participants (19)
-
ard＠p850ug1.demon.co.uk -
b4＠gewt.net -
bfranchuk＠jetnet.ab.ca -
captainkirk359＠gmail.com -
chd＠chdickman.com -
classiccmp＠crash.com -
derschjo＠gmail.com -
drlegendre＠gmail.com -
emu＠e-bbes.com -
fraveydank＠gmail.com -
glen.slick＠gmail.com -
healyzh＠aracnet.com -
mouse＠Rodents-Montreal.ORG -
nf6x＠nf6x.net -
paulkoning＠comcast.net -
RichA＠LivingComputerMuseum.org -
roe＠liveblockauctions.com -
spacewar＠gmail.com -
toby＠telegraphics.com.au