27 May
2005
27 May
'05
9:44 a.m.
From: "Vintage Computer Festival" <vcf at
siconic.com>
---snip---
I was thinking more in terms of space. A disk is much more efficient in
this regard. You can stack N times the number of disks in the same space
that a drum takes up.
The problem with disk, of course, is the variable BPI.
Today, with the electronics so cheap, the CD-ROM is made
with a spiral track and it runs at a constant BPI by
changing the rotation speed as it reads the disk.
Dwight
27 May
27 May
11:49 a.m.
Dwight K. Elvey wrote:
The problem with disk, of course, is the variable
BPI.
Today, with the electronics so cheap, the CD-ROM is made
with a spiral track and it runs at a constant BPI by
changing the rotation speed as it reads the disk.
Dwight
Which, of course, is a problem in itself in that most drives change the
spin rate and so seek times are awful.
Exercise for the student: implement a constant angular velocity drive to
read constant linear velocity media
--
Tim Riker - http://Rikers.org/ - TimR at Debian.org
Embedded Linux Technologist - http://eLinux.org/
BZFlag maintainer - http://BZFlag.org/ - for fun!
6:35 p.m.
Exercise for the student: implement a constant angular
velocity drive to
read constant linear velocity media
COmmodore floppy drives come close (things like the 8050, 1541, etc).
They're constant angular velocity (only one motor speed), but they change
the data rate (I think 4 or so data rates were used) to pack more sectors
onto the outermost tracks.
-tony
28 May
28 May
10:02 a.m.
On 5/27/05, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
Yes... 4 bit rates - two bits from a TTL 'divide-by-N' counter chip
can be written to by the 650x processor on the drive. The drive
firmware looks at the track number and stuffs the two bits out an I/O
port before reading/writing. ISTR one of the 4 available bit rates
happens to match Apple II data rates, but I don't think anyone ever
wrote a program for a 4040 or 1541 to attempt to decode Apple data.
Not sure how the Apple detects sync marks, but Commodore drives have
an 8-input-NAND attached to a shift register that will go 'true' when
8 bits of ones goes past the read head. The output of that NAND goes
to the pin on the 650x that fiddles the overflow bit... one sees tight
loops in the firmware where the CPU loops at the same address sampling
the overflow bit, and what happens is things (other than IRQs) stop
happening until the sync detector triggers, then the code flow
resumes. I'm sure one could rig up another method of sync detection,
but that one is quite efficient.
One footnote about track densities on Commodore drives - the 2040 and
4040/1541 patterns are different, resulting in different numbers of
blocks per diskette. Disks formatted on a 2040 have one track with
more sectors on it than the same track on a 4040/1541 disk. I presume
there were reliability issues with that particular track stuffing and
cheap media. The 2040 and 4040 have identical hardware; only the
firmware differs. All of my 2040s have been upgraded to 'v2' ROMs
(turning it into a 4040 in all but the label), but I think I have one
set of the old v1 stuff if I ever have to read an ancient PET floppy.
All this code is available on funet, for the curious.
It was not as catastrophic as the Apple 13 to 16-sector conversion,
but for a brief time, there was some media chaos in the PET world.
-ethan
Exercise for
the student: implement a constant angular velocity drive to
read constant linear velocity media
COmmodore floppy drives come close (things like the 8050, 1541, etc).
They're constant angular velocity (only one motor speed), but they change
the data rate (I think 4 or so data rates were used) to pack more sectors
onto the outermost tracks. 
11:36 a.m.
On Sat, 28 May 2005, Ethan Dicks wrote:
Yes... 4 bit rates - two bits from a TTL
'divide-by-N' counter chip
can be written to by the 650x processor on the drive. The drive
firmware looks at the track number and stuffs the two bits out an I/O
port before reading/writing. ISTR one of the 4 available bit rates
happens to match Apple II data rates, but I don't think anyone ever
wrote a program for a 4040 or 1541 to attempt to decode Apple data.
A long, long, long time ago I put a Commodore formatted disk into an Apple
drive and ran a nibble editor on it and I could swear I saw valid disk
bytes. I didn't really pursue it much further.
Not sure how the Apple detects sync marks, but
Commodore drives have
an 8-input-NAND attached to a shift register that will go 'true' when
8 bits of ones goes past the read head. The output of that NAND goes
to the pin on the 650x that fiddles the overflow bit... one sees tight
loops in the firmware where the CPU loops at the same address sampling
the overflow bit, and what happens is things (other than IRQs) stop
happening until the sync detector triggers, then the code flow
resumes. I'm sure one could rig up another method of sync detection,
but that one is quite efficient.
To explain how the Apple does it would take 43 pages :) But suffice it to
say, it is extremely clever.
It was not as catastrophic as the Apple 13 to
16-sector conversion,
but for a brief time, there was some media chaos in the PET world.
Interestingly enough, I found an Apple disk recently that was published in
1981 in 13-sector format(!)
--
Sellam Ismail Vintage Computer Festival
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers ]
[ and academia at www.VintageTech.com || at http://marketplace.vintage.org ]
4:54 p.m.
It was not as catastrophic as the Apple 13 to
16-sector conversion,
but for a brief time, there was some media chaos in the PET world.
The worst problem with the CBM PET drives IMHO was that the 8050 could
not read (or write) the disks from the older drives (like the 4040), and
that there was no easy way to copy certain types of files (I think one of
the random access data file types) between drives in different units.
Which meant there was no way to copy such a file from a 4040 disk to an
8050 disk. And which, in turn, meant you really needed both types of
drive unit conencted to a PET.
At least the Apple ][ 16 sector controller could read 13 sector disks
with special software.
-tony
7148
days inactive
7149
days old
5 comments
5 participants
participants (5)
-
ard＠p850ug1.demon.co.uk -
dwight.elvey＠amd.com -
ethan.dicks＠gmail.com -
Tim＠rikers.org -
vcf＠siconic.com