Emulators that can read .edd or .nib files?

[cbe...@gmail.com]

I've been trying to figure out if there are any Apple ][ emulators able to read a .edd or .nib file (or any format that preserves copy protection) but I have come up empty so far.

Is there such a thing or is the only option to run such disks an actual Apple ][ and the original disks?

Thanks.

[Steve Nickolas]

Most emulators can do nib. MESS/MAME can kindasorta do edd.

-uso.

[qkumba]

> > I've been trying to figure out if there are any Apple ][ emulators able
> > to read a .edd or .nib file (or any format that preserves copy
> > protection) but I have come up empty so far.
> >
> > Is there such a thing or is the only option to run such disks an actual
> > Apple ][ and the original disks?
> >
> > Thanks.
> >
>
> Most emulators can do nib. MESS/MAME can kindasorta do edd.

Yes, and we are working to improve it further.

[BLuRry]

Jace reads NIB and the NIB variant of 2MG as well, as long as either of the two are of an expected length. It currently does not deal with custom NIB formats that have more than standard amount of data per track. I haven't encountered any such images to test with so it shouldn't be too much of a hinderance.

[D Finnigan]

I feel like this is a question that has come out of a time-warp from the
past. The very first Apple II emulators from the late 1980s and early 90s
could *only* accept nibblized disks because they emulated a Disk II card of
course, and that's all that it was designed to read.

--
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

[qkumba]

> Jace reads NIB and the NIB variant of 2MG as well, as long as either of the two are of an expected length. It currently does not deal with custom NIB formats that have more than standard amount of data per track. I haven't encountered any such images to test with so it shouldn't be too much of a hinderance.

I have 36-track NIBs here somewhere, because Faial really used 36 tracks.

[BLuRry]

On Wednesday, January 13, 2016 at 9:59:23 AM UTC-6, qkumba wrote:
> > Jace reads NIB and the NIB variant of 2MG as well, as long as either of the two are of an expected length. It currently does not deal with custom NIB formats that have more than standard amount of data per track. I haven't encountered any such images to test with so it shouldn't be too much of a hinderance.
>
> I have 36-track NIBs here somewhere, because Faial really used 36 tracks.

If you pass those over my way I'll figure out how to support them. :)

-B

[Antoine Vignau]

The NIBs dine with i'm fEDD up have the same number of bytes per track but, depending on the file size, there can be .25, .50 steps per track and up to $27 tracks.

Some are at http://www.brutaldeluxe.fr/nibnib/

Antoine

[BLuRry]

Is it possible from a firmware side to have a disk reporting an even higher number of tracks? What is the theoretical limit of tracks from an RWTS perspective? What's the limit for sectors? Is it 256 for each? I'm at a point where I have a non-working Disk ][ and no patience to invest in old hardware, but no reason not to re-use my existing Disk ][ cards if possible. :)

[Antoine Vignau]

At 300 RPM, with a bit every 4us, you can write around 6656 bytes.
With a 6*2 encoding, with a few sync nibbles, you can write the equivalent of around 19 sectors, 18 for sure.

For the nb of tracks, some drives go up to 40 tracks, the disk II can go to 36 with no troubles.

The RWTS can be patched to format more than 35 tracks, but not more than 16 sectors.

Antoine

[BLuRry]

Right, but if you just have some jumpers on the logic pins and run them to a microcontroller, what is the limit of what the firmware can do? :D 256 tracks? If so then you could run a 1mb disk without modifying the RTWS -- in theory.

[Michael J. Mahon]

The ultimate device limit to track density is set by the width of the head
(for erasing/writing) and the radial precision of the head positioner.

The media limit is the signal-to-noise ratio of the medium as track width
diminishes.

Sophisticated error correction can make lower signal-to-noise ratios
usable, at the cost of capacity and complexity.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

[BLuRry]

Yes, all true. I'm talking about a microcontroller emulating a floppy drive in the digital domain though...

[fadden]

On Thursday, January 14, 2016 at 1:36:06 PM UTC-8, BLuRry wrote:
> Yes, all true. I'm talking about a microcontroller emulating a floppy drive in the digital domain though...

Are you asking what the Disk ][ firmware can report? It's not that sophisticated -- it doesn't report anything. It just does what you tell it. That's why, when you boot a disk or get an error, it makes that distinctive "recalibration" noise... it's driving the head back towards track zero without knowing its current position, so it usually bangs up against the limit for a bit.

There are some practical limitations imposed by the planned usage, of course. For example, the DOS 3.3 filesystem has a limit imposed by the VTOC. UNIDOS puts two 400K volumes on an 800K disk (by creating a filesystem with 50 32-sector tracks), because it can't create a single 800K volume.

[gid...@sasktel.net]

On Thursday, January 14, 2016 at 3:36:06 PM UTC-6, BLuRry wrote:
> On Thursday, January 14, 2016 at 3:28:26 PM UTC-6, Michael J. Mahon wrote:

My guess is it is limited by the OS that you write for it. An 8 bit OS probably would allow up 65536 tracks.

But this is probably all moot since, for example, Rich Drehers CFFA card allows up to a 128 GB. I wrote a driver that allows Prodos 8 to access up to 8 GB and would have only needed another screen hole to allow up to the 128 Gb.

8 Gb's gives me 256 volumes of 32 Mb each. I thought that that was enough.

So in essence, this is a 24 bit address

[Cedric Beust]

On Thursday, January 14, 2016 at 2:35:07 PM UTC-8, fadden wrote:

> That's why, when you boot a disk or get an error, it makes that distinctive "recalibration" noise... it's driving the head back towards track zero without knowing its current position, so it usually bangs up against the limit for a bit.

If I recall correctly, it goes back a lot more tracks than it really needs to (something like a hundred?), which is why it makes this crazy noise. I've always wondered why it doesn't go just MAX_TRACKS + 1 or something like that.

--
Cédric

[Steve Nickolas]

Don't quote me but I want to say 80 half-tracks.

-uso.

[Antoine Vignau]

$50 phases IIRC

[Michael J. Mahon]

Antoine Vignau <antoine...@laposte.net> wrote:
> $50 phases IIRC
>

...which is 40 tracks.

[Don Bruder]

In article <alpine.BSF.2.02.1...@frieza.hoshinet.org>,

$50 PHASES, not tracks or fractions thereof - just step backwards $50
times. That's sufficient to drag the head back to zero (and probably
bounce off the stop a few times) no matter where it starts out, and
without caring where the software might *THINK* it is or was. Step back
$50 phases, set your "where's the head now?" variable to 0, and presto!
Your software is now guaranteed to be in sync with your hardware.

--
Security provided by Mssrs Smith and/or Wesson. Brought to you by the letter Q

[qkumba]

But backtracking a bit - yes, the firmware doesn't care about the track number, it just responds to the number of phases that you request, so it will step for any many steps as exist. The OS is indeed the limitation, and some OSes don't even keep track/sector information, but rely solely on the drive head moving appropriately.

[gid...@sasktel.net]

On Friday, January 15, 2016 at 9:56:33 PM UTC-6, qkumba wrote:
> But backtracking a bit - yes, the firmware doesn't care about the track number, it just responds to the number of phases that you request, so it will step for any many steps as exist. The OS is indeed the limitation, and some OSes don't even keep track/sector information, but rely solely on the drive head moving appropriately.

IIRC when using Dos 3.3, the drive only re-calibrated on startup. But if one were to load a file, then load a different file that resides on a different track, the drive did not recalibrate. So there must be some info somewhere.

[Michael J. Mahon]

And most drives/controllers supported a "track 0 detect" switch that
usually disabled backward seeks, so there'd be no "clatter".

[qkumba]

> IIRC when using Dos 3.3, the drive only re-calibrated on startup. But if one were to load a file, then load a different file that resides on a different track, the drive did not recalibrate. So there must be some info somewhere.

DOS 3.3 will recalibrate whenever there's a read error, but based on what it thinks is the current track (so there's no hammering sound, just the sliding sound). When the request to seek passes through DOS, then DOS compares that request with the current track from the previous seek, and then seeks relative to the current track. DOS requires that the track number is present in the sector address field, so that it knows if it found what was requested.

[Michael 'AppleWin Debugger Dev']

Doesn't this get into the whole CAV / CLV (constant Angular Velocity vs Constant Linear Velocity) thing?

* https://en.wikipedia.org/wiki/Constant_angular_velocity
* https://en.wikipedia.org/wiki/Constant_linear_velocity

Sure, 6656 bytes is for track 0, but what is it for track 34 ?

No, seriously, I'm actually curious because did anyone actually do this on the Apple 2 ?? I mean it would be total PITA, but theoretically we should be able to easily store 19+ sectors on track 34.

On the C64 apparently they had 20 sectors!? (684*324) !?
http://www.pagetable.com/?p=656

[Michael 'AppleWin Debugger Dev']

On Monday, January 18, 2016 at 9:55:20 AM UTC-8, Michael 'AppleWin Debugger Dev' wrote:

So I dug up a blank floppy and measured it.

Dimensions are 5.1/4" by 5.1/4". DUH. :-) What I* didn't* know was how big the center holder hole was and the radios of the tracks:

The inner track (roughly) has a radius 3/4"
The outer track (roughly) has a radius of 2"

I then realized that since Track 0 is on the *outside* of the disk then that means Track 34 would have the *smallest* number of "sectors" available, with Track 0 having the most.

Now to just work out the math for the circumference and how many bytes can "reasonable" fit on the tracks ... <to be continued> ...

[Tom Greene]

I can't think of any way this would be possible with the Disk II hardware. The amount of data that can be written in one revolution of the drive is constant regardless of what track the head is on because the drive speed is fixed and so is the data rate between the controller and drive.

Tom

[Michael 'AppleWin Debugger Dev']

On Monday, January 18, 2016 at 11:57:50 AM UTC-8, Tom Greene wrote:

> I can't think of any way this would be possible with the Disk II hardware. The amount of data that can be written in one revolution of the drive is constant regardless of what track the head is on because the drive speed is fixed and so is the data rate between the controller and drive.

So that means the Apple Disc Controller has different RPMs for the various tracks then?

i.e. If the circumference of track 0 though track 34 decreases, but the (max) data written is constant, that implies that the rotational speed would have to vary, no ?

Sorry, I'm a software guy, not a hardware guy. :-)

[Tom Greene]

No, the disk speed is constant ~300rpm. The bits would be physically closer together on the inner tracks, but that doesn't matter. Only the time between bits is important. The data rate is 1 bit every 4 CPU cycles.

If my math is correct, it works out to about 51024 bits per track, assuming perfect 300rpm speed etc., which is 6378 raw disk bytes (nibbles). With 6-and-2 encoding that would be about 4783 data bytes, not considering any other overhead like sector headers and sync nibbles.

Tom

[Howard Poe]

The speed on the Disk ][ drive is constant, and the bits per track is the same, so the bits are less dense on the outer tracks and more on the inner (this is the common way for floppy drives to work.)

Apple used Sony variable speed drives for their double density 3.5 inch disks, so instead of 720k on a constant speed disk, they were able to put 800k. Apple also used GCR (group code recording) instead of MFM (modified frequency modulation), so their disks aren't readable by normal PC floppy controllers. The Apple Superdrive floppy drives could read and write both MFM and GCR, allowing for better compatibility on high density disks. For compatibility, Apple used constant speed MFM on high density disks for 1.44mb storage, same as IBM compatible systems.

Apple did make the "Apple II 3.5 controller", which allowed use of 1.44mb Superdrives on the Apple II series, formatted for constant speed MFM. With one of these, you can read and write the high density 3.5 inch Apple II floppies on a PC, I've used them with Ciderpress to copy files to/from my Apple IIgs before the CFFA 3000 made things much easier...

https://en.wikipedia.org/wiki/Group_code_recording

[qkumba]

Infocom created a format with minimal header and which is one huuuge sector (unlike Roland's RW18, which is three sectors). It's the equivalent of 18 sectors large. The most that you can write at 300rpm on a 5.25" is really about 18.5 sectors' worth. To get the full 19, you'd have to slow the drive a bit.

[ian kim]

In my opinion,
DISK][ Controller doesn't care which track writing or reading.
Controller just transfer the data from the head.
Most of all R/W signal handling by DISK driver not by controller.
If Drive could handle much tracks, DISK controller could have data for Read/Write.

But, DOS system side,
it using track number and sector number for DOS track format.
If could make OS for much tracks for 255 tracks and 255 sectors and Emulated Disk drive would work for it.

If someone wants more tracks and more sectors. I could make device to accept the huge tracks or sectors.
But, Much sectors isn't good idea cause it takes some time to get the last sector. So, much tracks are good way faster access.

DISK Emulator doesn't have physical step motor so, shorter step motor for head is acceptable for faster track travel.

And OS side, DOS3.3 couldn't handle much tracks, it can only handle up to 50 tracks. if we want to access more than 50 tracks, we have to consider to modify PRODOS to accept much tracks.
Anyway, it's very interesting.

[BLuRry]

Right -- and realistically it might be more efficient to write a bootloader that plays nicely with RWTS but then sends a patched Prodos loader with an alternate driver that speaks a different protocol to the attached device. There's a few different ways that one could go about that when you take away the need to support RWTS thanks to a lot of recent advances in Prodos conversions. :D

[gid...@sasktel.net]

On Monday, January 18, 2016 at 10:49:43 PM UTC-6, qkumba wrote:
> Infocom created a format with minimal header and which is one huuuge sector (unlike Roland's RW18, which is three sectors). It's the equivalent of 18 sectors large. The most that you can write at 300rpm on a 5.25" is really about 18.5 sectors' worth. To get the full 19, you'd have to slow the drive a bit.

There is an article in nibble that has a program to write to a whole track at once for maximum data. There are no sectors so no need for sector headers.

The article is called Ultra Fast Pix and is in the March 1987 issue.

It was introduced to see how fast hi-res pictures can be loaded from a disk. The de-nybblizing routine works on the fly so that the data is stored directly to the hi-res screen. 5462 disk bytes or 4096 data bytes or exactly 2 tracks are needed per hi-res picture for a total of 17 pictures on a floppy disk. And one free track. Very cool read.

[Antoine Vignau]

Leather goddesses of Phobos, side B :-)

[qkumba]

> Leather goddesses of Phobos, side B :-)

The original release was single-sided, for a 48kb system. Only later did they move it to the 128kb version.
No, I was thinking of A Mind Forever Voyaging, Bureaucracy, and Border Zone, which was the order in which I encountered them.
There were others for sure.

[Scott Alfter]

In article <946901cc-4eb3-4a00...@googlegroups.com>,
BLuRry <brendan...@gmail.com> wrote:
>Is it possible from a firmware side to have a disk reporting an even
>higher number of tracks? What is the theoretical limit of tracks from
>an RWTS perspective? What's the limit for sectors? Is it 256 for each?

With a special formatter, I could reliably get 38 tracks from the drives in
a DuoDisk. IIRC, ProDOS needed no changes to work with these disks; it was
just a matter of formatting the three additional tracks and marking them in
the volume bitmap as free.

_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

[Michael 'AppleWin Debugger Dev']

On Thursday, January 14, 2016 at 11:05:55 AM UTC-8, Antoine Vignau wrote:
> At 300 RPM, with a bit every 4us, you can write around 6656 bytes.

That seems a tad high, no? :)

I _finally_ got around to calculating where this number comes as part of the background for my question here:

http://retrocomputing.stackexchange.com/questions/503/absolute-maximum-number-of-nibbles-on-an-apple-ii-floppy-disk-track

The Cole's Notes (or Michael? :) would be:

* The disks is spun at (roughly) 300 RPM (Revolutions per Minute)
* 1000 ms/sec / (300 RPM / 60 sec/ms) = ~200 ms / revolution,
* 200 ms/revolution * 1000 μs/ms / 4 μs/bit = 50,000 bits / (8 bits/byte) = 6,250 nibbles/track.

This also helps clarifies why Beneath Apple DOS on page 3-7 briefly mentions 50,000 bits. Sadly, the authors never gave a formula nor showed which hat they pulled this number out of. Just wished I had clued onto this value 20 years ago. :-)

Hmm, now what is the best way to represent a bit-stream in AppleWin ... *whoops* :-)

[Michael 'AppleWin Debugger Dev']

On Monday, January 18, 2016 at 12:36:05 PM UTC-8, Tom Greene wrote:
> No, the disk speed is constant ~300rpm. The bits would be physically closer together on the inner tracks, but that doesn't matter. Only the time between bits is important. The data rate is 1 bit every 4 CPU cycles.

Ah, thanks! 1 bit / 4 CPU cycles is also good to know.

> If my math is correct, it works out to about 51024 bits per track, assuming perfect 300rpm speed etc., which is 6378 raw disk bytes (nibbles). With 6-and-2 encoding that would be about 4783 data bytes, not considering any other overhead like sector headers and sync nibbles.

Any chance you could post your math? I'm getting an exact 50,000 bits/track (with a perfect 300 RPM) ...

Cheers
Michael

[Tom Greene]

It comes out a little higher than 50 kbits since the Apple clock is slightly faster than 1MHz. According to "Understanding the Apple II" the CPU clock runs at 1020484.32 cycles per second. So:

(1020484.32 cycles per second / 4 cycles per byte) * (60 seconds/300rpm) = 51024.216 bits per track.

Of course the clock and drive speeds are not likely to be perfect, so the actual track length will vary somewhat. A slow clock or fast drive will make the track shorter, and a fast clock or slow drive will make it longer.

Tom

[Michael J. Mahon]

I recall that some disks could only be written if the drive was running a
little slow, and the speed tolerance couldn't be tighter than +/-5%, so I'd
expect that some nibble images would have up to 5% more than the "exact"
speed would suggest.

The disk controller is certainly capable of reading at what it would see as
a faster data rate.

And, of course, finding the track's "splice" point requires reading more
than a full revolution.

[John Brooks]

Below are some notes from the high-capacity 5.25 format I've been working on:

300 RPM = 5 rotations per second = rotation time of 200ms.

200ms / 980ns PH0 clock = 204081 cycles / 4 cycles per bit cell = 51020 bits per track.

5.25" has 48 tracks per inch or track pitch of .0208. 1/2 tracks are 0.0104. 1/4 tracks are 0.0052.

Outermost track 0 radius=2.25 inches, circumference=14.14 inches, density @ 300 RPM = 3608.9 BPI.

Innermost track 34 radius=1.54 inches, circumference=9.69 inches, density @ 300 RPM = 5263 BPI.

Early 5.25 double-density media is rated at 5600-5900 BPI. Later DD media is 6000 BPI.


Ideally, emulators would store a bitstream for each 1/4 track and shift the bitstream through the disk controller (or IWM) read latch just as the Woz controller does. This would provide correct behavior for floating nibbles (>2 consecutive 0 bits), hidden leading 0 bits, and non-standard sync fields.

IIRC, I've been able to write & read back 60 tracks per side using a custom shingled recording which utilizes a mix of 1/2 track & 1/4 track head positioning.

BTW: Current emulators do not appear to properly emulate the logic and timing of the Sony floppy controller inside 3.5" drives. Primarily in the areas of changing motor RPM every 16 tracks, head step/settle time, and motor-on spin-up timing.

HTH,
-JB

[Michael 'AppleWin Debugger Dev']

On Tuesday, May 17, 2016 at 9:08:04 AM UTC-7, John Brooks wrote:
> 200ms / 980ns PH0 clock = 204081 cycles / 4 cycles per bit cell = 51020 bits per track.
>
> 5.25" has 48 tracks per inch or track pitch of .0208. 1/2 tracks are 0.0104. 1/4 tracks are 0.0052.
>
> Outermost track 0 radius=2.25 inches, circumference=14.14 inches, density @ 300 RPM = 3608.9 BPI.
>
> Innermost track 34 radius=1.54 inches, circumference=9.69 inches, density @ 300 RPM = 5263 BPI.
>
> Early 5.25 double-density media is rated at 5600-5900 BPI. Later DD media is 6000 BPI.

Great metrics ! Thanks!

Ah, so double-density is rated higher. I had been wondering about the quality of those.

> BTW: Current emulators do not appear to properly emulate the logic and timing of the Sony floppy controller inside 3.5" drives. Primarily in the areas of changing motor RPM every 16 tracks, head step/settle time, and motor-on spin-up timing.

Hmm, looking over AppleWin's Disk source .. I'm not sure the the 3.5" code is, but for the 5.25" ...
https://github.com/AppleWin/AppleWin/blob/master/source/Disk.cpp

... I see that we have a flag if the motor is on/off and a spinning counter which is set to this magic number on line #236.

g_aFloppyDisk[currdrive].spinning = 20000;

Looks like we nee a bug report for this.

> Primarily in the areas of changing motor RPM every 16 tracks,

I know nothing about 3.5" disks. Do you have a reference for this please?

Thanks!

[Michael 'AppleWin Debugger Dev']

On Monday, May 16, 2016 at 3:53:14 PM UTC-7, Tom Greene wrote:
> On Monday, May 16, 2016 at 4:33:47 PM UTC-4, Michael 'AppleWin Debugger Dev' wrote:
> > On Monday, January 18, 2016 at 12:36:05 PM UTC-8, Tom Greene wrote:
> > > No, the disk speed is constant ~300rpm. The bits would be physically closer together on the inner tracks, but that doesn't matter. Only the time between bits is important. The data rate is 1 bit every 4 CPU cycles.
> >
> > Ah, thanks! 1 bit / 4 CPU cycles is also good to know.
> >
> > > If my math is correct, it works out to about 51024 bits per track, assuming perfect 300rpm speed etc., which is 6378 raw disk bytes (nibbles). With 6-and-2 encoding that would be about 4783 data bytes, not considering any other overhead like sector headers and sync nibbles.
> >
> > Any chance you could post your math? I'm getting an exact 50,000 bits/track (with a perfect 300 RPM) ...
> >
> > Cheers
> > Michael
>
> It comes out a little higher than 50 kbits since the Apple clock is slightly faster than 1MHz. According to "Understanding the Apple II" the CPU clock runs at 1020484.32 cycles per second. So:
>
> (1020484.32 cycles per second / 4 cycles per byte) * (60 seconds/300rpm) = 51024.216 bits per track.

Ah, yes, I forgot the MHz was just a hair over 1 MHz. Thanks for the clarification !

> Of course the clock and drive speeds are not likely to be perfect, so the actual track length will vary somewhat. A slow clock or fast drive will make the track shorter, and a fast clock or slow drive will make it longer.

That was going to be next question. So the the actual # of bits written depends on BOTH the CPU and Disk speed. Makes perfect sense.

Thanks Tom!

[John Brooks]

There is no all-in-one reference for the 3.5" drives to my knowledge, but this is a great collection of related docs:

http://www.brutaldeluxe.fr/documentation/iwm/

There are several types of 3.5" drives and they have very different behaviors:
http://tmug.com/tac/html/topic2.html

-JB

[Michael J. Mahon]

John Brooks <jbr...@blueshiftinc.com> wrote:
> On Monday, May 16, 2016 at 1:33:47 PM UTC-7, Michael 'AppleWin Debugger Dev' wrote:
>> On Monday, January 18, 2016 at 12:36:05 PM UTC-8, Tom Greene wrote:
>>> No, the disk speed is constant ~300rpm. The bits would be physically
>>> closer together on the inner tracks, but that doesn't matter. Only the
>>> time between bits is important. The data rate is 1 bit every 4 CPU cycles.
>>
>> Ah, thanks! 1 bit / 4 CPU cycles is also good to know.
>>
>>> If my math is correct, it works out to about 51024 bits per track,
>>> assuming perfect 300rpm speed etc., which is 6378 raw disk bytes
>>> (nibbles). With 6-and-2 encoding that would be about 4783 data bytes,
>>> not considering any other overhead like sector headers and sync nibbles.
>>
>> Any chance you could post your math? I'm getting an exact 50,000
>> bits/track (with a perfect 300 RPM) ...
>>
>> Cheers
>> Michael
>
> Below are some notes from the high-capacity 5.25 format I've been working on:
>
> 300 RPM = 5 rotations per second = rotation time of 200ms.
>
> 200ms / 980ns PH0 clock = 204081 cycles / 4 cycles per bit cell = 51020 bits per track.
>
> 5.25" has 48 tracks per inch or track pitch of .0208. 1/2 tracks are
> 0.0104. 1/4 tracks are 0.0052.
>

> Outermost track 0 radius=2.25 inches, circumference .14 inches, density @

> 300 RPM = 3608.9 BPI.
>
> Innermost track 34 radius=1.54 inches, circumference=9.69 inches, density
> @ 300 RPM = 5263 BPI.
>
> Early 5.25 double-density media is rated at 5600-5900 BPI. Later DD media is 6000 BPI.
>
>
> Ideally, emulators would store a bitstream for each 1/4 track and shift
> the bitstream through the disk controller (or IWM) read latch just as the
> Woz controller does. This would provide correct behavior for floating
> nibbles (>2 consecutive 0 bits), hidden leading 0 bits, and non-standard sync fields.
>
> IIRC, I've been able to write & read back 60 tracks per side using a
> custom shingled recording which utilizes a mix of 1/2 track & 1/4 track head positioning.
>
> BTW: Current emulators do not appear to properly emulate the logic and
> timing of the Sony floppy controller inside 3.5" drives. Primarily in the
> areas of changing motor RPM every 16 tracks, head step/settle time, and
> motor-on spin-up timing.
>
> HTH,
> -JB
>

Achievable track density is primarily a function of the erase head width,
which probably varies from drive type to drive type.

Are you getting good results with 3/4 track spacing? It seems from your 60
track result that you are using less than 3/4 track spacing.

[John Brooks]

On Wednesday, May 18, 2016 at 5:02:47 PM UTC-7, Michael J. Mahon wrote:

My experiments on a few drives have shown the write width to be very close to 0.75 tracks. I'm using a track pitch of 0.58 (3 written tracks every 1.75 tracks) using a shingled track technique (partial write overlap) which greatly increases track density.

In the 80's Datasoft had custom duplication equipment which could master 1/2 & 1/4 track floppies. I'm somewhat emulating those mastering techniques by using tightly controlled head stepping routines, overlapping track writes, and a custom DOS.

I've also increased the nibble encoding density by about 5% over 6&2, resulting in 19 sectors per track. I plan to try some additional sectoring improvements which could push it up to 19.25 or 19.5 sectors per track.

Then there's the really 'out there' ideas like using 3usec bit cells on the outer 22 tracks to boost bit density by 33%. Apple really should have run the Disk II at less than 300RPM. 270 would have been a nice increase in disk capacity and still have been well within the floppy media's BPI density spec.

-JB

[Michael J. Mahon]

I guessed that you were using this approach, which means microstepping for
final positioning.

> In the 80's Datasoft had custom duplication equipment which could master
> 1/2 & 1/4 track floppies. I'm somewhat emulating those mastering
> techniques by using tightly controlled head stepping routines,
> overlapping track writes, and a custom DOS.

I suspect they used smaller width heads--which would be completely
practical as media quality improved.

Fitting an 80-track head to an Apple drive should double capacity
instantly.

> I've also increased the nibble encoding density by about 5% over 6&2,
> resulting in 19 sectors per track. I plan to try some additional
> sectoring improvements which could push it up to 19.25 or 19.5 sectors per track.
>
> Then there's the really 'out there' ideas like using 3usec bit cells on
> the outer 22 tracks to boost bit density by 33%. Apple really should have
> run the Disk II at less than 300RPM. 270 would have been a nice increase
> in disk capacity and still have been well within the floppy media's BPI density spec.

Modifying a drive to change speed based on arm position would not be too
difficult.

Of course, the ultimate snag is that overlapping track-write formats would
be read-only for all practical purposes.

[John Brooks]

Yes, microstepping on the write to position the overlapping tracks. Reads do not need microstepping, just normal 1/4 stepping.


I'm not much of a hardware guy, mostly software/firmware, so I'm using stock Apple drives. On the IIGS, the IWM allows some config choices which can increase or decrease the bit cell size.

> Of course, the ultimate snag is that overlapping track-write formats would
> be read-only for all practical purposes.

My thinking here is to place shingled data at one end of the disk and writable single-track spaced data at the other end with both pools filling toward the middle tracks. As the disk fills, I can migrate files from the low-density single-tracked end of the disk to the high-density shingled end. This would also allow migrated files to be defragmented and contiguous.

-JB

[Michael J. Mahon]

Very cool, John--an interesting project!

[sicklittlemonkey]

On a tangential note, does anyone know where the 5.25 inch 300 RPM came from? (Versus 360 RPM for the 8 inch.)

I was kind of assuming it was to do with the physics of the media density and read/write head, but googling around hasn't turned up anything.

If you check out these "oral history" discussions there might have been less engineering involved in that choice than you'd think ...

http://archive.computerhistory.org/resources/text/Oral_History/5.25_3.5_Floppy_Drive/5.25_and_3.5_Floppy_Panel.oral_history.2005.102657925.pdf
http://archive.computerhistory.org/resources/text/Oral_History/8_inch_Floppy_Drive/8_inch_Floppy_Drive.oral_history.2005.102657926.pdf

Cheers,
Nick.

[sicklittlemonkey]

On Tuesday, 19 January 2016 09:36:05 UTC+13, Tom Greene wrote:
> If my math is correct, it works out to about 51024 bits per track, assuming perfect 300rpm speed etc., which is 6378 raw disk bytes (nibbles).

Yep, I got around that (highest was 6400 nibbles) when experimenting for my answer to Michael's question here:
http://retrocomputing.stackexchange.com/a/664/71

I managed to get up to 8309 ($2075) nibbles on track 0 at 231 RPM. Below that it became unstable.

Cheers,
Nick.