Subject: Re: H89 CP/M hard-secored boot diskette

From: "Dwight K. Elvey" <[email-masked]>
Date: Tue Apr 1 12:09:00 2003

Hi
 As I mentioned earlier, I have a Forth that runs standalone
on hard sectored. Since it is standalone, I've used it to
make exact copies of other disk. I've done things like changing
the interleaving to make about a 10X improvement in load
speeds for many programs.
 It has been a while since I had the machine running. I can
fire it up and check what I have. The only issue I have for
making copies for others is the media. I only have a few
hard sectored disk. For some reason, I thought that disk
formats would last at least as long as 33 lp records. I
didn't realize at the time that media was being obsoleted
as fast as it was produced. I know better now.
 Anyway, if I can get it all running, I'll make copies
if someone supplies media.
Dwight

>From: [email-masked]
>
>Don --
>
>Do you have the means to copy such a diskette?  I have a set of the original
>distribution diskettes here, and last time I checked the boot diskette was
>good.
>
>Later --
>
>Glen
>0/0
>
>> On Mon, 31 Mar 2003, Fred Cisin (XenoSoft) wrote:
>>
>> > On Mon, 31 Mar 2003, Jason J. Gullickson wrote:
>> > > On that note, if any of you know where I could find a copy of CPM and a
>> > > compatible C compiler on hard-sectored disks, that would be greeeaaat,
>> > > yeah.
>> >
>> > Don Maslin can probably help you with the CP/M boot disk.  But you are
>> > going to have to immediately come up with software for serial port file
>> > transfer, since that is the only PRACTICAL way to transfer files to or
>> > from hard-sectored disks.
>>
>> I wish that I could, Fred.  Unfortunately, I do not have a hard
>> sectored boot disk for the H89 to make a copy from so I am
>> stumped.
>>       - don
>>
>> > There have been several C compilers for CP/M.  Aztec/Manx is probably the
>> > best, but the most popular was Zolman's BDS C.  Good news!  As of 6 months
>> > ago, BDS C became public domain! :
>> >
>> > On Thu, 26 Sep 2002, Rich Beaudry wrote:
>> >
>> > >
>> > > Don't know how many of you are on comp.os.cpm, but in case you missed
>> > it,
>> > > Leor Zolman has decided to release the full retail package of BDS C,
>> > > including *ALL* source code (compiler as well!) to the Public Domain.
>> > >
>> > > http://www.bdsoft.com/resources.html#bdsc
>> > >
>> > > Check it out!
>> > >
>> > > Rich B.

---

From: Tom Uban <[email-masked]>
Date: Tue Apr 1 12:27:32 2003

Hi Dwight,

I would like a copy. I guess I should locate a source for some
media. Does anyone know of any?

--tom

---

From: Tom Uban <[email-masked]>
Date: Tue Apr 1 12:56:01 2003

Looking further at my H89 documentation does not actually list
enough information to know what type of floppies are used. Since
it only lists 10 SPT, 40 TRK, 256 BPS, I guess that I should assume
SSSD 100K hard sectored (10 SPT) disks. Is this correct?

--tnx
--tom

---

From: ben franchuk <[email-masked]>
Date: Tue Apr 1 13:04:01 2003

> as fast as it was produced. I know better now.

The funny thing some small record companies still produce
records.You can still get records, but not the crappy $7.95 k-tell
stuff, but higher priced and higher quality audio.A good
record changer and other assorted parts ( like a clean record)
is better music wise than any CD.

Can a regular disk be punched to make hard sectored disc?
Ben.

---

From: "Fred Cisin (XenoSoft)" <[email-masked]>
Date: Tue Apr 1 13:28:00 2003

> Can a regular disk be punched to make hard sectored disc?

yes
but it's not THAT hard to find them.

---

From: [email-masked] (Tony Duell)
Date: Tue Apr 1 18:05:01 2003

> Can a regular disk be punched to make hard sectored disc?

It should be possible. One thing I intent to try sometime is to strip 
down an old half-height direct-drive 5.25" floppy drive and mount a 
punch/die in place of the index sensor and an indexing plate in place of 
the rotor on the end of the spindle. It should then be quite easy to 
punch the extra holes. 

Making the new parts is not a major problem (I have a lathe with milling 
facilities and a dividing head...)

-tony

---

From: Don Maslin <[email-masked]>
Date: Tue Apr 1 23:37:01 2003

> speeds for many programs.

Is it available for download, Dwight?

						- don

> if someone supplies media.

<snip>

---

From: Vintage Computer Festival <[email-masked]>
Date: Wed Apr 2 23:00:01 2003

> speeds for many programs.

I always wondered, if it was so easy to change the sector interleave on
disks to make them load faster, why didn't the original
programmers/designers optimize the interleave in the first place?

Things that make you go, "hmm".

-- 

Sellam Ismail                                        Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger                http://www.vintage.org

 * Old computing resources for business and academia at www.VintageTech.com *

---

From: ben franchuk <[email-masked]>
Date: Thu Apr 3 09:46:14 2003

> programmers/designers optimize the interleave in the first place?

It depends on your disk hardware and the speed of your computer.
1) Computers got faster  2) Disk i/o got dma rather than poiled
i/o.

---

From: "Fred Cisin (XenoSoft)" <[email-masked]>
Date: Thu Apr 3 16:54:00 2003

> 1) Computers got faster  2) Disk i/o got dma rather than poiled

It also depends on what kind of processinbg is being done to it during
loading.  For example, dumping file contents into RAM can be done a lot
faster than loading a document into a word-processor.

The fastest interleave occurs if the system can handle the next sector
immediately after the previous.  In that case, the fastest sequence is
plain sequential, and a track can be read in a single revolution.  But
when you add extra processing of the data during reading, (such as a word
processor loading a document), you could end up with NOT being ready for
the next sector in time, resulting in the read taking as many revolutions
of the disk as there are sectors per track.  Alternating sectors might
reduce that to two revolutions (or skipping 2 sectors, etc.), but that can
easily be twice as long as necessary for a task that did NOT need the
extraneous processing.  Most system software developers DO think that
they have optimized it.  But they have optimized it for the type of file
access that they EXPECT you to be doing (usually whatever THEY do most).

BTW, it can be done either by placing the physical sectors in various
orders (such as 1,3,5,7,9,2,4,6,8,10) OR can be done by a translation
between logical sector and physical sector (physical sectors numbered
1,2,3,4, . . . , but data that doesn't finish in sector 1 continues in
sector 3, etc.)