Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: What is the largest drive that NetBSD/VAX will support?

I quite agree Mark. However I have found that the original Zip-100
drive is too small for the contents of the drive that the process on
the webpage. I've got it started using the block file that the
original author wanted. I also thought about sticking a second SCSI
drive in the computer, since I've got an AHA2940 card in the system,
its a Dell branded one, and the drives seem to work best with it. But
I've got some interesting issues with that idea.

Oh and one more thing, for Linux hosts using PCap based networking it
looks for .SO object files, and I needed to upgrade to a newer release
of LibPCap, and even TCPDump, I chose the sources delivered with 14.1
of Slackware.

Oh and Dave if you're reading this, there's a fake Yeti in the room
with you, he's really a second visiting Bigfoot.
Gregg C Levine gregg.drwho8%gmail.com@localhost
"This signature fought the Time Wars, time and again."

On Fri, Feb 19, 2016 at 8:25 AM, Mark Pizzolato <Mark%infocomm.com@localhost> wrote:
> On Friday, February 19, 2016 at 12:00 AM, John Klos wrote:
>> > I'm currently setting up a new project. In this case its an
>> > arrangement of SIMH/VAX running on Linux/I386. The host has a Zip100
>> > drive installed. And as it happens I'm wondering, with this issue:
>> > "What is the largest drive that NetBSD/VAX will support?". Conversely
>> > it becomes "What is the smallest drive that NetBSD/VAX will support?".
>> The largest drive it'll support without any extra fuss, I think, would be
>> 2 TB (2^32-1 blocks of 512 bytes each). The smallest, I think, would be one
>> sector.
> That is indeed the upper limit.  I can't imagine any amount of 'fuss' which
> could extend it beyond that.  The boundary is based on the fact that the
> MSCP protocol has a 32bit field containing the logical block number (thus
> the 2^32-1) and all sectors are 512 bytes.  This is a limit of the hardware being
> simulated due to the structure of the MSCP protocol.
>> > That presupposes I can successfully point the program to a Linux
>> > device driver who itself is connected to that physical drive.
>> >
>> > Obviously for the mechanics of such things I'll have to ask on the
>> > SIMH list. That's next.
>> It should be possible to give SIMH a whole device such as the GNU/Linux
>> equivalent of NetBSD's /dev/rsd0d. I've done this when using an SD card
>> which was the boot disk of a real VAX with SIMH on NetBSD through a USB
>> card reader.
> Simh has 2 mechanisms which can access a device.  The default SIMH mode
> uses stdio (fopen/fread/fwrite/fseeko/fclose) to access the simulated disk
> image file.  The RAW mechanism uses open/read/write/lseek/close to access
> the simulated disk.  RAW mode disk sizing is done using lseek(f, (off_t)0, SEEK_END);
> if that works on your device things should work well.
> - Mark

Home | Main Index | Thread Index | Old Index