Thanks,
Mark
I had a look to your Web page.
The only thing interesting that I found is: "This board is part of a
treasure trove that was given to me by Dave Baldwin, former editor of
The Computer Journal."
Well... Many years ago, before the Internet, I subscribed to every
remaining CP/M and 8-bits newsletters. One of them was TCJ. I kept
sending them articles but, except my collection of articles about Gary
Kildall, they never published them. They were hardware-oriented, while
I am a programmer.
Anyway, after the disappearance, as usual, of TCJ, many people wanted
to have its published stuff on a Web site. If I remember well, there
was one or two articles per issue online, as an advertisement.
But what became the source code of all the articles?
Would you be able to setup a Web site and republish all the articles
ever published in TCJ? (You would have no longer any problem with
spare time, then...) (If they were written in WordStar (What else?),
there is a WS4-to-HTML File Converter which was published several
months/years ago in the comp.os.cpm Newsgroup, so setting up the Web
page of a Web site are childplay.)
And: "*This just goes to show how it's novelty that makes things seem
special, not what it actually does. I'll never forget the Mac and
converted Lisas spitting out 3.5" disks automatically and how cool it
looked back then (as well as how stupid it seemed from a practical
standpoint of someone who was going to be damned if he was ever going
to ask a computer to pretty please give the disk back.)"
Well, the Epson QX-10 had no jetissonable floppies but, instead of
turning a lever like on the IBM Clown, you pushed a button to eject
them, like later 3.5" drives. (I am talking, of course, of 5 1/4"
drives, in 1983.) ZIP-100 can still be jetissoned. Without an
artificial arm, this is not very useful. On IBM Mainframes, they have
automatic insert/remove "datapacs".
Yours Sincerely,
Mr. Emmanuel Roche, France
Mark,
I knew David, even wrote a few articles publised in TCJ. Anyhow what
you are after is two possible paths. Either partially format the
drive as no one ever said you had to use it all. Or fix the BIOS to
partiton a larger drive. Do not forget the version of CP/M used is
V2.2 which had a hard limit of 8MB per logical drive and a maximum of
16 logical or physical drives. They drew the line at 11 partitions
(88mb) to allow for multiple logical and physical floppies.
On my system I went the latter route and used a 45mb scsi drive the
software available at the time (1991) didn't know so I had to tweek it
as 5 partitions of 8mb and one of 5mb. That worked well for me as
that allowed me to keep software divided up on a per drive basis
as CP/M has a flat directory.
Allison
I've got no connection to TCJ except as a former occasional reader,
I'm afraid. I ran across Dave Baldwin while shopping at a local
electronics surplus house (HSC) and in the course of conversation he
offered me some old systems he was looking for a home for, since he
was moving and wouldn't have room for them. I followed him home and
got a bunch of neat stuff.
But, I'm in no position to publish anything that was in the TCJ. Being
in the right place at the right time to get this stuff was pure dumb
luck. I'm trying to be worthy of it all by having as much fun with it
as I can in the time I've got to spare. :)
-Mark
I'm very interested in what you find out Mark. I've got an Ampro Littleboard
in a Series 100 bookcase enclosure and I'd really like to be able to use a hard
disk with it.
g.
--- Synchronet 3.15a-Win32 NewsLink 1.85
The Retro Archive - telnet://bbs.retroarchive.org
I've contacted Mark privately (via his posting address) to tell him
that I sell old SCSI drives, in the Apple Macintosh world. Those
machines used SCSI drives for many years, and people still use those
machines today, and need drives. These are used drives of course, I
test and verify (with Macs) the drives I sell, and I have SCSI drives
that small. If anyone is interested, see my Web site at;
http://www.retrotechnology.com/herbs_stuff/m_drives.html#scsi
I hear about SCSI to IDE adapters, but they seem to be priced over
$100. I have no experience with them, and that price is above what
most people will pay to update older systems for hobby use. There are
old SCSI to MFM adapters, they were sold with external drives, but
that's going in the wrong direction today.
Herb Johnson
Herbert R. Johnson New Jersey USA
http://www.retrotechnology.com/ retro-technology home pages
-- S-100, CP/M history by "Dr. S-100"
-- other old tech in iron, glass, rock
domain mirror: retrotechnology.net
email: hjohnson AAT retrotechnology DOTT com
Thanks! If I'd checked comp.os.cpm before I started working on the
system tonight I would have saved some time thanks to your answer. I
learned that the BDOS is my 88MB limitation when I ran ZMOVCPM to
create a system disk for setting up the hard disk.
I neglected to post it before, but my BIOS is Ampro 1.303, my BDOS is
CP/M2.2, and my CCP is ZCPR3.
I wasn't able to actually try formatting the disk tonight, since it
turned out the actual hard disk utilities weren't on the system disks
I got with the board. Fortunately, the source code disks were included
so I should be set on that tomorrow night.
I spent the rest of tonight setting up the system to have A: and B: as
3.5" 96TPI drives, so I'd have some more working space until the hard
drive's up. C: is a 5.25" so that I can still read the original
diskettes.
I'm going to try formatting the disk under its capacity. I've no
better use for the drive (a 420MB drive pulled out of a dead
HP9000/700 series). But I'm also interested in trying out a BDOS
replacement or modification if there's something out there that allows
larger disks without affecting TPA size. 88MB brings TPA down to 56K
(though I'll probably try to format at about 40MB to get a couple more
K in TPA.)
I'll poke around and see what I can find on my own, but if anyone has
any suggestions of where I might start looking, I'd appreciate it.
Thanks to all for the responses!
-Mark
If you've got a Little Board Plus, a.k.a. a Little Board 1B, you've
got SCSI onboard. The 1A didn't have built in SCSI, but there was a
daughterboard from Ampro that would add it. Look for an NCR 5380 chip
either on the board or a daughterboard. If it's there all you need is
the right Ampro BIOS and the Ampro hard disk utilities.
If it's not there, you may be able to drum up a daughterboard, or, you
could potentially construct one. I believe there was an article, by
Rick Lehrbaum if I'm recalling correctly, in either TCJ or MicroC
where the schematic was published. I'm really stretching my memory so
I may be wrong. You can see it in the LB+ schematic in the tech
manual: http://www.hartetechnologies.com/manuals/Ampro/
-Mark
Dang, I should've visited your URL before I posted--I love your site!
I'll let you know how things work out on my system. I'm considering
modifying the Ampro code to allow selection of smaller disk capacities
if it finds a disk with a capacity over what the system is configured
for. We'll see. A BDOS replacement or mod might be the way to go, too.
Then I could have a 1GB disk with 8MB of data rattling around on it
(that's as much as I've ever had on a CP/M hard disk in the past.) ;)
Probably the best (and certainly the simplest) thing to do to allow
the use of oversized disks is to only use part of them.I'll see if I
can get away with lying to the HDD programs first (maybe only use one
out of 9 of the heads), if that doesn't work take a look at the code
and perhaps insert something that allows editing of parameters that
have been automatically collected from the SCSI device.
Now I'm curious about how CP/M 3.0 handles disks...once I've got time
to read up on that.
>On Jul 28, 12:55�am, saundby <saun...@gmail.com> wrote:
Once you get to 56K your good.
It is possible to make the DPB/DPH a table that are on a per drive
basis. One of the later versions of the AmproLB+ HDD BIOS did this.
This allows each partition to be sized with different block sizes with
out affecting the floppies.
In the end the tables eat some space as does the ALV (allocation
vector bitmap).
>Probably the best (and certainly the simplest) thing to do to allow
>the use of oversized disks is to only use part of them.I'll see if I
>can get away with lying to the HDD programs first (maybe only use one
>out of 9 of the heads), if that doesn't work take a look at the code
>and perhaps insert something that allows editing of parameters that
>have been automatically collected from the SCSI device.
>
You can do that. Another way would be a utility that allows changing
the DPB to "unmount" a partition and "mount" a new partion from
elsewhere on the drive. it's a you do it, some assembly required
thing but I have that one one system and its handy. Unfortunatly the
bios and the utility is not portable but nothing about that particular
system was (test dog).
>Now I'm curious about how CP/M 3.0 handles disks...once I've got time
>to read up on that.
Not much different. The cleaned up a math truncation so it can have
larger partitions 32mb.
A better solution, if your not being purist is one of the enhanced
BDOS (ZRdos, DOS+ and many others) that are a real upgrade to CP/M 2
but compatable and can have larger partitions.
Allison
> If you've got a Little Board Plus, a.k.a. a Little Board 1B, you've
> got SCSI onboard. The 1A didn't have built in SCSI, but there was a
> daughterboard from Ampro that would add it. Look for an NCR 5380 chip
> either on the board or a daughterboard. If it's there all you need is
> the right Ampro BIOS and the Ampro hard disk utilities.
>
I've got the NCR chip on board. I've never been able to get any of the HDs I
have to work at all. I do have a few SCSI-IDE bridges ($35 on ebay) now and I
should probably try that.
Thanks..
> To: saundby
> Re: Re: Ampro Little Board Plus Hard Disk Constraints
> By: saundby to comp.os.cpm on Tue Jul 28 2009 01:10 am
>
> > If you've got a Little Board Plus, a.k.a. a Little Board 1B, you've
> > got SCSI onboard. The 1A didn't have built in SCSI, but there was a
> > daughterboard from Ampro that would add it. Look for an NCR 5380 chip
> > either on the board or a daughterboard. If it's there all you need is
> > the right Ampro BIOS and the Ampro hard disk utilities.
> >
>I've got the NCR chip on board. I've never been able to get any of the HDs I
>have to work at all. I do have a few SCSI-IDE bridges ($35 on ebay) now and I
>should probably try that.
You still have the same problem to a point. Small MFM drives are
getting scarce.
At the other end of the scale I have two or three SCSI to MFM adaptors
(Xebec and Adaptec) plus the drives from ST506(5MB) to Quantum
D540s(31mb) to use with them. A few ST150s (Shugart 20M SCSI drives)
and a boat load of old DEC RZ22E (52MB) and 23L (121mb). They (dec
RZ22-E) are still available in the used market for about $100 maybe
less.
The major problem with getting most HDs (via adaptor) or SCSI is that
the ROM has to be a late version and the HDINIT and related software
has to know the SCSI controller/drive or basic SCSI drive or they
cant install the drive. Back then there were only a few combos that
existed (Xebec or adaptec and ST225 was one) and the ST150 or 158
scsi drive (also around 20mb) was the other. Good new is that all the
docs and sources are found on line these days. Back then (1993)
they weren't.
To get past that I had to understand the Ampro BIOS and the scsi BIOS
to create a custom version. What does make it simpler is allof the
SCSI drives are 512bye sectors (blocks) and all are addresses as a
block address rather than CHS. So logical drive 0 starts at block 0,
drive 1 starts at 16384, and so on making it easy to map multiple
logical disks in the physical space. This works as well with larger
drives too.
Allison
I tried running HINIT, the formatting program, against two different
SCSI disks, a Conner 425S (420MB) and a Seagate Hawk 1.1 GB drive. In
both cases I got a SCSI DATA PROTECT error. I presumed that this was a
result of the disks already being low-level formatted and decided to
proceed to initialization.
I was able to initialize different disk partitions of different sizes
then get directories and STAT: the disks just fine. Unfortunately, the
previous data on he disk meant that the directory areas (and
elsewhere) were filled with garbage as far as CP/M was concerned.
There were all sorts of characters in filenames that my terminal
didn't like, and that ERA wouldn't touch.
I thought of using FINDBAD as a way of wiping the surface, but it
turned out to not be on my Ampro disks. At this point my time for
working on the system ran out for a while.
Right now I'm looking at a few different possibilities:
-Running disk utilities on another system to cover the surface in E5s,
then try again.
-Creating a disk with some existing CP/M utilities that I could use to
wipe the disk, or at least clean up the directories, from within the
Ampro system.
-Modifying the source for HFORMAT to create a new program that wipes
the disk without issuing a SCSI FORMAT command first.
Not sure which route I'll go. For the first I'd either have to find my
disk utilities programs for a PowerPC Mac I've got out, or pull out
one of my Unix workstations that I know has everything on it I need.
If anyone has suggestions for CP/M utilities I might use, I'd be
interested. It wouldn't be tough for me to put them on a disk I can
use on the Ampro.
Not sure how much time I'll be putting into this this weekend, but I'm
still worrying away at it. ;)
>Here's what's happened so far:
>
>I tried running HINIT, the formatting program, against two different
>SCSI disks, a Conner 425S (420MB) and a Seagate Hawk 1.1 GB drive. In
>both cases I got a SCSI DATA PROTECT error. I presumed that this was a
>result of the disks already being low-level formatted and decided to
>proceed to initialization.
Sounds more like a SCSI protocal error. However without exception I
know of SCSI disks are not formatable. The SCSI to MFM controllers do
permit formatting as the drives are MFM (of maybe RLL).
>I was able to initialize different disk partitions of different sizes
>then get directories and STAT: the disks just fine. Unfortunately, the
>previous data on he disk meant that the directory areas (and
>elsewhere) were filled with garbage as far as CP/M was concerned.
>There were all sorts of characters in filenames that my terminal
>didn't like, and that ERA wouldn't touch.
ERA will eb slow or worse. A utility that can do a sector write of
0xE5 such as DU is needed and much faster. That assumes the earlier
SCSI data protect error is't saying the drive is write locked.
>I thought of using FINDBAD as a way of wiping the surface, but it
>turned out to not be on my Ampro disks. At this point my time for
>working on the system ran out for a while.
Likely not the right tool as it will try to verify the sectors as
read/write valid and likely they are.
>
>Right now I'm looking at a few different possibilities:
>-Running disk utilities on another system to cover the surface in E5s,
>then try again.
You need to do that. Maybe on a PC first..
>-Creating a disk with some existing CP/M utilities that I could use to
>wipe the disk, or at least clean up the directories, from within the
>Ampro system.
Once you get a working partition its a matter of PIPing your floppies
into it and configuring the boot.
>-Modifying the source for HFORMAT to create a new program that wipes
>the disk without issuing a SCSI FORMAT command first.
You will need to do that. it should be a minor mod.
FYI: if you havent noted this. CP/M does not use any on disk partition
tables or any of the unix/PC style organization. The partition table
such as it is will be located IN the BIOS itself. So any utility that
creates partitions is actually patching tables in the BIOS.
>Not sure which route I'll go. For the first I'd either have to find my
>disk utilities programs for a PowerPC Mac I've got out, or pull out
>one of my Unix workstations that I know has everything on it I need.
>If anyone has suggestions for CP/M utilities I might use, I'd be
>interested. It wouldn't be tough for me to put them on a disk I can
>use on the Ampro.
The biggest thing is a truely blank disk without MBR or any kind of
unix or PC style boot/partition tables. CP/M does not organize the
on disks structures that way.
From CP/Ms point of view a SCSI disk (or any) is just a repository of
addressable sectors orgainized as CHS. Boot tracks are optional
and typically (for hard disks) only found on the boot partition. The
rest are directory (first n many blocks) and data are in the remainder
of total disk size.
>Not sure how much time I'll be putting into this this weekend, but I'm
>still worrying away at it. ;)
It's do able.
Allison
Do you have the ability to hook one of those drives to an x86 host?
Then you could boot a "live" Linux disk (like Slax or DSL) and wipe the
disk using:
dd if=/dev/zero of=- | tr \\000 \\345 > /dev/sda
which fills SCSI device sda with 0xE5 (octal 345).
Amardeep
When I first started working with SCSI disks attached to Sun
machines (Sun 3/50), I was told that they should be formatted,
so we did that. A little later, we found that wasn't needed
unless you need to change the block (sector) size, but at
least those drives (I believe CDC) allowed one to do it.
I haven't tried since (about 1988).
-- glen
OK, I got a copy of DU off a Kaypro disk and it did the trick.
So, all together, here's what I did to get a large hard disk to work
on the Ampro (as a smaller disk):
Skip HFORMAT.COM--it's not needed, newer disks are already "low-level
formatted."
Use HINIT.COM to set up as many partitions as are desired, up to 11 of
8MB (8000KB) apiece. Numbers above 8000 are possible, somewhere
between 8096 and 8192 CP/M gets unhappy, so I just used 8000 since
it's close enough and easy to remember if I have to run HINIT by hand
in the future.
Use DU.COM to clear the directory space to E5s on the disk,
eliminating garbage from prior uses of the disk:
Commands entered in DU:
>LF (log into the drive defined in HINIT, drive F
here)
>G0 (go to the directory area)
>CH0-7F,E5 (change the sector buffer to all E5)
>< (write it to the current sector)
>>;W;+;/256 (restore, write, advance, repeat 256 times)
repeat the above for each drive defined.
Complete the process as documented by Ampro for Sysgenning the hard
disk and updating the BIOS.
The drive I'm using is a 1.1 GB SCSI-2 disk (a Seagate Hawk series). I
did the above with an HP Barracuda drive and a Quantum 425S as well,
except for the sysgen and BIOS. Everything went fine. I'm going to
use the Seagate in the system since it runs the coolest of the three.
The Quantum would make a good hot plate.
Anything newer than 100MB scsi (and many older) will not permit it.
Now, any MFM or RLL drive connected to ta bridge controller
(SCSI to xxx) will require formatting.
Allison
I see it's an older thread, but here's a data point:
I'm using a 100MB drive out of an old Sun3 workstation. The machine just
ignores anything past the 88MB point. Works fine.
--
Bruce H McIntosh - scot...@afn.og - http://www.afn.org/~scotsman - WA4UF
Retrotechnologist and network geek with a strong affinity for Telecasters
>On Sun, 26 Jul 2009 20:08:32 -0700, saundby wrote:
>
>> I'm bringing up an Ampro Little Board Plus system, and I don't have a
>> SCSI hard disk available that meets the requirements stated in the
>> documentation (less than 88MB.) Can anyone tell me whether I can use a
>> larger disk, and either make changes to the Ampro software to
>> accommodate it, or simply format a larger disk for a smaller capacity by
>> lying about its configuration or something.
>>
>I see it's an older thread, but here's a data point:
>
>I'm using a 100MB drive out of an old Sun3 workstation. The machine just
>ignores anything past the 88MB point. Works fine.
This topic came up before and the answer was yes. My amproLB+ is
running a Fujitsu 3.5" 45mb SCSI drive.
You will need the BIOS sources, they are on line.
Allison