what program for disassemble?

classic Classic list List threaded Threaded
333 messages Options
12345 ... 17
Reply | Threaded
Open this post in threaded view
|

Re: what program for disassemble?

silverdr@wfmh.org.pl

> On 2018-04-02, at 23:11, David Holz <[hidden email]> wrote:
>
> On 03/31/2018 05:00 AM, [hidden email] wrote:
>> OTOH I am quite a fan of what WhiteFlame did in JS. It is very
>> promising one to me. Just "not there yet" as I can't seem to be able
>> to load definitions files plus some other things.
>
> What other things do you want out of it?  Importing a simple list of
> label definitions would be pretty easy to add.

That's like a good starting point.

What I'd love to eventually see/use is a tool that allows me to:

- drop some files on it - let's start with two only: the binary (or whatever format you already support) and the label definition file
- get it/them disassembled (including interactive selection of data types)
- navigate through the JMPs/JSRs
- add comments as appropriate
- automatically mark fragments, which are not accessed directly
- save the disassembly to a few popular formats

Some things are already there, which is why I find it so promising.

> Unfortunately, I'm not going to be adding in .asm export for a while.
> There's too many issues to solve for the general case (ie, wildly
> varying platform assumption, multiple file overlays, WFDis allowing
> names the assembler doesn't like, etc) and I don't want to lock it into
> a simpler model that I'd have to tear out later.  The main thrust of the
> project is to explore mechanical "understanding" of the code, not
> necessarily a code modification & reassembly tool... yet.

I am not sure I understand this correctly. It is not about using your tool to do modification / reassembly although this is obviously welcome. It is more about "what good is a tool for if one can't really keep/use the outcome of its work?" Yes, you can analyse some short passages this way in order to get understanding but not much beyond that.

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: what program for disassemble?

David Holz-2
On 08/23/2018 07:30 AM, [hidden email] wrote:
>
> What I'd love to eventually see/use is a tool that allows me to:
>
> - drop some files on it - let's start with two only: the binary (or whatever format you already support) and the label definition file
Drag'n'drop support was there in the beginning, but had some problems. 
It shouldn't be too hard to reenable that as browser support on such
things should have stabilized by now.

> - get it/them disassembled (including interactive selection of data types)
> - navigate through the JMPs/JSRs
> - add comments as appropriate
> - automatically mark fragments, which are not accessed directly
> - save the disassembly to a few popular formats
>
> Some things are already there, which is why I find it so promising.
Yep.  I just need time to work on it.  Currently the internals are in a
large rewrite, so there haven't been any newly published versions in a
while, during this transition.

>> Unfortunately, I'm not going to be adding in .asm export for a while.
>> There's too many issues to solve for the general case (ie, wildly
>> varying platform assumption, multiple file overlays, WFDis allowing
>> names the assembler doesn't like, etc) and I don't want to lock it into
>> a simpler model that I'd have to tear out later.  The main thrust of the
>> project is to explore mechanical "understanding" of the code, not
>> necessarily a code modification & reassembly tool... yet.
> I am not sure I understand this correctly. It is not about using your tool to do modification / reassembly although this is obviously welcome. It is more about "what good is a tool for if one can't really keep/use the outcome of its work?" Yes, you can analyse some short passages this way in order to get understanding but not much beyond that.
>
You can currently keep/use the output.  There is a save/load binary
format encompassing all the workspace's information.  This gets saved
into the browser LocalStorage, and can be imported/exported as a normal
.wfdis file on your computer as well.  I guess exporting a textual
format without regard to any given assembler's specific format would
also be reasonable, before full support is figured out.

As an example of problems with real asm syntax support, I label many
local loop destinations as "+" or "-", which few assemblers would
recognize.  Label names also don't have to be unique, and can have
spaces and punctuation in label names as I figure out what things are,
like "Save X-Coord(?)", all of which would confuse assemblers if they
were exported as-is.  Graphics and colors in the WFDis workspace also
would need to translate to source somehow, hopefully in a visually
representative way, or maybe as separately linked .fnt/.spr/.koa/etc files.


Reply | Threaded
Open this post in threaded view
|

Re: what program for disassemble?

silverdr@wfmh.org.pl


> On 2018-08-24, at 01:05, David Holz <[hidden email]> wrote:
>
> On 08/23/2018 07:30 AM, [hidden email] wrote:
>>
>> What I'd love to eventually see/use is a tool that allows me to:
>>
>> - drop some files on it - let's start with two only: the binary (or whatever format you already support) and the label definition file
> Drag'n'drop support was there in the beginning, but had some problems.
> It shouldn't be too hard to reenable that as browser support on such
> things should have stabilized by now.

Yes, I use a cross-browser "drag'n drop" for file upload in daytime projects for some time already. Still - by "dropping" files on it I didn't necessarily mean literal dropping. More like "giving it to process" in any easy to use way :-) Obviously drag'n drop is very much welcome too.

>> - get it/them disassembled (including interactive selection of data types)
>> - navigate through the JMPs/JSRs
>> - add comments as appropriate
>> - automatically mark fragments, which are not accessed directly
>> - save the disassembly to a few popular formats
>>
>> Some things are already there, which is why I find it so promising.
> Yep.  I just need time to work on it.

The most common problem we experience with our hobby stuff.

> Currently the internals are in a
> large rewrite, so there haven't been any newly published versions in a
> while, during this transition.

I see.

> You can currently keep/use the output.  There is a save/load binary
> format encompassing all the workspace's information.  This gets saved
> into the browser LocalStorage, and can be imported/exported as a normal
> .wfdis file on your computer as well.

I take you mean that I can import this "normal .wfdis" binary back into your browser application? This I know I can but it is still of very limited use. Suppose I spent sizeable amount of time doing a large disassembly and eventually I have it all the way I like it. What next? Currently I can use a trick to copy-paste the /rendered/ output into a text editor but that's not like a right way to do it. And obviously requires lots of post-processing then too.

> I guess exporting a textual
> format without regard to any given assembler's specific format would
> also be reasonable, before full support is figured out.

It could be a good starting point.

> As an example of problems with real asm syntax support, I label many
> local loop destinations as "+" or "-", which few assemblers would
> recognize.
> Label names also don't have to be unique, and can have
> spaces and punctuation in label names as I figure out what things are,
> like "Save X-Coord(?)", all of which would confuse assemblers if they
> were exported as-is.

Hm, I gave it a run over the whole 251968-03 DOS and didn't notice any of those "cheap, local labels" (+/-) but in general yes, eventually there need to be "export filters", translating what you use internally into what is understandable to a particular external tool. I use ca65 these days (although xa was my previous choice and I still like it a lot) so at least cheap labels are not an issue ;-) Labels - either need to be restricted (there are comments still where one can user whatever he likes) in what form they can take, or escaped/translated on output... but I am sure you know all this and it is mostly the matter of finding time.

> Graphics and colors in the WFDis workspace also
> would need to translate to source somehow, hopefully in a visually
> representative way, or maybe as separately linked .fnt/.spr/.koa/etc files.

I would suggest saving these for the final touches. For a good start any graphical stuff, can be safely surrounded with comments and exported as hex or binary strings. For some limited readability sprite data can f. e. be output in sets of three eight-bit-binary strings per line, etc. This shouldn't be a show-stopper.

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Re: what program for disassemble?

silverdr@wfmh.org.pl
In reply to this post by David Holz-2

> On 2018-08-24, at 03:05, David Holz <[hidden email]> wrote:
> [...]
> Yep.  I just need time to work on it.  Currently the internals are in a
> large rewrite, so there haven't been any newly published versions in a
> while, during this transition.

FWIW - I just checked the December version and I highly appreciate the direction this is moving in! Great job White Flame!

--
SD! - http://e4aws.silverdr.com/


Reply | Threaded
Open this post in threaded view
|

Did Commodore cheat with the quad density floppies?

André Fachat
Hi there,

I was looking at floppy disk recording schemes and I am wondering if the
8050/8250/1001 floppy disk format with over 500kB per side was actually out
of spec of even the Quad Density disks?

The recording frequency was increased from 250kHz to 375kHz (× 1.5, for the
innermost i.e. most critical track/speed zone). That resulted in a much
increased number of bits per inch. See here:
https://extrapages.de/archives/20190102-Floppy-notes.html

What do you think?

Thanks
André



Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

Gerrit Heitsch
On 1/2/19 3:34 PM, André Fachat wrote:
> Hi there,
>
> I was looking at floppy disk recording schemes and I am wondering if the
> 8050/8250/1001 floppy disk format with over 500kB per side was actually
> out of spec of even the Quad Density disks?

I always used the normal Double Density disks with my 8050 back then and
never had any problems.

Does the 5900 bpi number maybe relate to MFM which needs 2 Bits per data
bit while GCR packs the data tighter with the 10/8 scheme?

  Gerrit


Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

Francesco Messineo
In reply to this post by André Fachat
On Wed, Jan 2, 2019 at 3:40 PM André Fachat <[hidden email]> wrote:

>
> Hi there,
>
> I was looking at floppy disk recording schemes and I am wondering if the
> 8050/8250/1001 floppy disk format with over 500kB per side was actually out
> of spec of even the Quad Density disks?
>
> The recording frequency was increased from 250kHz to 375kHz (× 1.5, for the
> innermost i.e. most critical track/speed zone). That resulted in a much
> increased number of bits per inch. See here:
> https://extrapages.de/archives/20190102-Floppy-notes.html
>
> What do you think?
>

I'm sure you know it, but the best reference I've found on the net
about floppy disk drives is here:

http://www.retrotechnology.com/herbs_stuff/drive.html

First of all, 100 tpi drives have an offset recording window with
respect to 48 tpi drives. Track 0 is a bit closer to the outer edge of
the media with respect to the 48 tpi track 0 (or track 1 as CBM
counted them), but that doesn't really change much. The BPI rating of
the media isn't an absolute value imho (3000 for FM at 125Kbps and
6000 for MFM at 250kbps are just what is achievable with these
modulations). I think the CBM designers just tried to pack as many
sectors as it was reliable. Original 2040 format on 48 tpi drive had
one sector more on one zone than the vastly more common 4040/1541
format and I think they just decreased the later format by one sector
because it was a bit too unreliable. Same thing must have happened on
the 100 tpi drives, they tried to pack as much as was possible with
300 oersted media.
Frank

Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

William Levak


Also, the GCR format is much more reliable than the MFM format.  With a
small number of consecutive zeros, the error rate is less.

On Wed, 2 Jan 2019, Francesco Messineo wrote:

> On Wed, Jan 2, 2019 at 3:40 PM André Fachat <[hidden email]> wrote:
>>
>> Hi there,
>>
>> I was looking at floppy disk recording schemes and I am wondering if the
>> 8050/8250/1001 floppy disk format with over 500kB per side was actually out
>> of spec of even the Quad Density disks?
>>
>> The recording frequency was increased from 250kHz to 375kHz (× 1.5, for the
>> innermost i.e. most critical track/speed zone). That resulted in a much
>> increased number of bits per inch. See here:
>> https://extrapages.de/archives/20190102-Floppy-notes.html
>>
>> What do you think?
>>
>
> I'm sure you know it, but the best reference I've found on the net
> about floppy disk drives is here:
>
> http://www.retrotechnology.com/herbs_stuff/drive.html
>
> First of all, 100 tpi drives have an offset recording window with
> respect to 48 tpi drives. Track 0 is a bit closer to the outer edge of
> the media with respect to the 48 tpi track 0 (or track 1 as CBM
> counted them), but that doesn't really change much. The BPI rating of
> the media isn't an absolute value imho (3000 for FM at 125Kbps and
> 6000 for MFM at 250kbps are just what is achievable with these
> modulations). I think the CBM designers just tried to pack as many
> sectors as it was reliable. Original 2040 format on 48 tpi drive had
> one sector more on one zone than the vastly more common 4040/1541
> format and I think they just decreased the later format by one sector
> because it was a bit too unreliable. Same thing must have happened on
> the 100 tpi drives, they tried to pack as much as was possible with
> 300 oersted media.
> Frank
>
>
>
[hidden email]
SDF Public Access UNIX System - http://sdf.lonestar.org
Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

MiaM
In reply to this post by André Fachat
Den Wed, 02 Jan 2019 15:34:24 +0100 skrev André Fachat <[hidden email]>:

> Hi there,
>
> I was looking at floppy disk recording schemes and I am wondering if
> the 8050/8250/1001 floppy disk format with over 500kB per side was
> actually out of spec of even the Quad Density disks?
>
> The recording frequency was increased from 250kHz to 375kHz (× 1.5,
> for the innermost i.e. most critical track/speed zone). That resulted
> in a much increased number of bits per inch. See here:
> https://extrapages.de/archives/20190102-Floppy-notes.html
>
> What do you think?

Afaik the 8050/8250/1001 drives are supposed to use "QD" disks, which
seems to be a format that's supposed to handle a higher density than DD.

It seems common for people to think that QD was a marketing thing used
for 96TPI DD disks, but I've seen so many 96TPI disks marked DD and
only a few (like one or two, and it was last summer that I first saw
them) disks actually labeled QD. (They contain a book keeping software
package, in Swedish, from the Swedish Commodore importer Datatronic.
Will be preserved as soon as I get my 8050 up and running, which has
been waiting a while for me to find my stash of IEEE cables :) )).

It would be really strange if floppy media didn't evolve the same way
as magnetic tapes did. With media good enough for 250kHz at track 35
when the 5.25" floppys were new, and soon good enough for 250kHz at
track 40, it seems reasonable that some years later the media used for
those drives were actually good enough for 375kHz at the 48TPI
equalient of track 35, which almost is where the highest track number
on a 77 track 100 TPI drive will end up.

(At some point in time a market for cheap rather crappy disks seems to
have evolved though, but those were probably anyway nothing people used
in their 8050/8250/1001 drives).

(Everyone who's been around long enough to remember cassette tapes from
the 70's and the 80's remember that before tapes like Maxell UD and
similar the standard / ferro / type I tapes did really sound crap with
a high noise level and muffled treble. Then something happened in the
late 70's and early 80's, resulting in more and more kinds of tapes
getting a lot better, and at the start of the 90's basically almost all
tapes had a decent sound even though there were of course still
differences between them).

--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

Gerrit Heitsch
On 1/3/19 2:50 PM, Mia Magnusson wrote:

> Den Wed, 02 Jan 2019 15:34:24 +0100 skrev André Fachat <[hidden email]>:
>> Hi there,
>>
>> I was looking at floppy disk recording schemes and I am wondering if
>> the 8050/8250/1001 floppy disk format with over 500kB per side was
>> actually out of spec of even the Quad Density disks?
>>
>> The recording frequency was increased from 250kHz to 375kHz (× 1.5,
>> for the innermost i.e. most critical track/speed zone). That resulted
>> in a much increased number of bits per inch. See here:
>> https://extrapages.de/archives/20190102-Floppy-notes.html
>>
>> What do you think?
>
> Afaik the 8050/8250/1001 drives are supposed to use "QD" disks, which
> seems to be a format that's supposed to handle a higher density than DD.

the (german) user manual that came with my 8050 back then mentioned
'single density' as the disks required. Not that I ever tried that,
always used DD.

  Gerrit


Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

Francesco Messineo
In reply to this post by MiaM
On Thu, Jan 3, 2019 at 2:51 PM Mia Magnusson <[hidden email]> wrote:

>
> Den Wed, 02 Jan 2019 15:34:24 +0100 skrev André Fachat <[hidden email]>:
> > Hi there,
> >
> > I was looking at floppy disk recording schemes and I am wondering if
> > the 8050/8250/1001 floppy disk format with over 500kB per side was
> > actually out of spec of even the Quad Density disks?
> >
> > The recording frequency was increased from 250kHz to 375kHz (× 1.5,
> > for the innermost i.e. most critical track/speed zone). That resulted
> > in a much increased number of bits per inch. See here:
> > https://extrapages.de/archives/20190102-Floppy-notes.html
> >
> > What do you think?
>
> Afaik the 8050/8250/1001 drives are supposed to use "QD" disks, which
> seems to be a format that's supposed to handle a higher density than DD.

"QD" disks have the very same 300 oersted magnetic media as SD/DD disks,
it was only the mechanics and R/W heads that allowed to use more
effectively the storage media.
Later HD drives used different R/W heads (or different currents) and
required 600 oersted media, doubled bitrate to 500 Kbps and changed
speed to 360 rpm.

At the university, we had a few Olivetti LSX-3005 that were equipped
with 96tpi 5 1/4" drives (QD, not HD obviously),
I remember nobody ever tried to find "QD" disks, normal DD 48TPI disks
were used (albeit I remember good quality brands were purchased
usually, like 3M, Olivetti).

> It seems common for people to think that QD was a marketing thing used
> for 96TPI DD disks, but I've seen so many 96TPI disks marked DD and

again, 96TPI DD is just the same media as 48TPI DD, just maybe tested
better (or just advertised as 96TPI, who knows).

> only a few (like one or two, and it was last summer that I first saw
> them) disks actually labeled QD. (They contain a book keeping software
> package, in Swedish, from the Swedish Commodore importer Datatronic.
> Will be preserved as soon as I get my 8050 up and running, which has
> been waiting a while for me to find my stash of IEEE cables :) )).
>
> It would be really strange if floppy media didn't evolve the same way
> as magnetic tapes did. With media good enough for 250kHz at track 35
> when the 5.25" floppys were new, and soon good enough for 250kHz at
> track 40, it seems reasonable that some years later the media used for
> those drives were actually good enough for 375kHz at the 48TPI
> equalient of track 35, which almost is where the highest track number
> on a 77 track 100 TPI drive will end up.

I really think the better Kbps rating is due to the use of the more
efficient GCR code instead of the MFM.

>
> (At some point in time a market for cheap rather crappy disks seems to
> have evolved though, but those were probably anyway nothing people used
> in their 8050/8250/1001 drives).
>
> (Everyone who's been around long enough to remember cassette tapes from
> the 70's and the 80's remember that before tapes like Maxell UD and
> similar the standard / ferro / type I tapes did really sound crap with
> a high noise level and muffled treble. Then something happened in the
> late 70's and early 80's, resulting in more and more kinds of tapes
> getting a lot better, and at the start of the 90's basically almost all
> tapes had a decent sound even though there were of course still
> differences between them).

There're two different issues on compact cassette:
1) different (really much different) magnetic media, type I (Fe2O3,
iron oxide), Type II (CrO2), type III (FeCr), type IV (metal), these
media required different equalization and different recording
currents. Type I are usually very bad sounding and noisy, type IV have
the best quality, but the recorder really NEEDS to know what type of
tape it's trying to record into, otherwise you wouldn't get much
better results, unless maybe a bit less noise if you use a type IV
tape on a old, low quality recorder.
2) Dolby NR pre/de-emphasys. These noise reduction techniques have
been introduced starting from 1965, last one afaik was introduced in
1986. Not all recorder were equipped with these circuits. A type I
with the best NR circuit could sound really better than a type II with
no Dolby.
So, all in all, nothing in common with floppy disks :)

Frank

Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

Francesco Messineo
In reply to this post by Gerrit Heitsch
On Thu, Jan 3, 2019 at 3:13 PM Gerrit Heitsch <[hidden email]> wrote:
>
> the (german) user manual that came with my 8050 back then mentioned
> 'single density' as the disks required. Not that I ever tried that,
> always used DD.
>
Also SD didks don't really "exists", in the sense they are the same
original 300 oersted media. If you record it with FM at 125 Kbps, you
get
the so called "single density". Densities rather refer to the
modulation scheme used, rather than the actual media used.
SD/DD/QD is the same media, with different mechanisms (the 48TPI vs
96TPI vs 100TPI mechanics/heads) and with different modulations.
Again, I suggest reading the fine informations contained here:
http://www.retrotechnology.com/herbs_stuff/drive.html

Frank

Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

Gerrit Heitsch
In reply to this post by Francesco Messineo
On 1/3/19 3:15 PM, Francesco Messineo wrote:

> I remember nobody ever tried to find "QD" disks, normal DD 48TPI disks
> were used (albeit I remember good quality brands were purchased
> usually, like 3M, Olivetti).

When I bought a whole lot of C64, 1541, an Amiga 2000A and some other
stuff in 2011 for 20 Euros total on ebay (those were the days...), the
lot also included about 500 floppy disks. When making D64 images from
them, I came about a few QD disks, so they did exist.


> There're two different issues on compact cassette:
> 1) different (really much different) magnetic media, type I (Fe2O3,
> iron oxide), Type II (CrO2), type III (FeCr), type IV (metal), these
> media required different equalization and different recording
> currents. Type I are usually very bad sounding and noisy, type IV have
> the best quality, but the recorder really NEEDS to know what type of
> tape it's trying to record into, otherwise you wouldn't get much
> better results, unless maybe a bit less noise if you use a type IV
> tape on a old, low quality recorder.

Back when Type II was established, the type II tapes had an extra notch
next to the erase control tab and most recorders had a sensor that
detected the type that way. Wasn't something like this also added for
type IV as well?

  Gerrit


Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

Francesco Messineo
On Thu, Jan 3, 2019 at 3:39 PM Gerrit Heitsch <[hidden email]> wrote:

>
> On 1/3/19 3:15 PM, Francesco Messineo wrote:
>
> > I remember nobody ever tried to find "QD" disks, normal DD 48TPI disks
> > were used (albeit I remember good quality brands were purchased
> > usually, like 3M, Olivetti).
>
> When I bought a whole lot of C64, 1541, an Amiga 2000A and some other
> stuff in 2011 for 20 Euros total on ebay (those were the days...), the
> lot also included about 500 floppy disks. When making D64 images from
> them, I came about a few QD disks, so they did exist

yes, I've never said the don't write SD/QD/DD on the boxes. I'm sure
they did, I have a few 96TPI DD boxes (BASF afair) myself, which seems
a contadiction, since DD was 48TPI :)
But anway, the media properties are all the same, 300 oersted is what
really matters (VS 600 oersted needed for the HD drives).
Lucky you anyway :)

>
>
> > There're two different issues on compact cassette:
> > 1) different (really much different) magnetic media, type I (Fe2O3,
> > iron oxide), Type II (CrO2), type III (FeCr), type IV (metal), these
> > media required different equalization and different recording
> > currents. Type I are usually very bad sounding and noisy, type IV have
> > the best quality, but the recorder really NEEDS to know what type of
> > tape it's trying to record into, otherwise you wouldn't get much
> > better results, unless maybe a bit less noise if you use a type IV
> > tape on a old, low quality recorder.
>
> Back when Type II was established, the type II tapes had an extra notch
> next to the erase control tab and most recorders had a sensor that
> detected the type that way. Wasn't something like this also added for
> type IV as well?

yes, every kind of compact cassette had different holes, but recorders
were not forced to auto-detect, my recorder in the '80s supported type
I and IV but had no autodetect, I needed to "inform" it via a switch
on what kind of cassette I had put in it.
The high end ones I'm sure had autodetect.
Frank

Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

Groepaz
In reply to this post by Gerrit Heitsch
Am Donnerstag, 3. Januar 2019, 15:38:49 CET schrieb Gerrit Heitsch:

> On 1/3/19 3:15 PM, Francesco Messineo wrote:
> > I remember nobody ever tried to find "QD" disks, normal DD 48TPI disks
> > were used (albeit I remember good quality brands were purchased
> > usually, like 3M, Olivetti).
>
> When I bought a whole lot of C64, 1541, an Amiga 2000A and some other
> stuff in 2011 for 20 Euros total on ebay (those were the days...), the
> lot also included about 500 floppy disks. When making D64 images from
> them, I came about a few QD disks, so they did exist.
>
> > There're two different issues on compact cassette:
> > 1) different (really much different) magnetic media, type I (Fe2O3,
> > iron oxide), Type II (CrO2), type III (FeCr), type IV (metal), these
> > media required different equalization and different recording
> > currents. Type I are usually very bad sounding and noisy, type IV have
> > the best quality, but the recorder really NEEDS to know what type of
> > tape it's trying to record into, otherwise you wouldn't get much
> > better results, unless maybe a bit less noise if you use a type IV
> > tape on a old, low quality recorder.
>
> Back when Type II was established, the type II tapes had an extra notch
> next to the erase control tab and most recorders had a sensor that
> detected the type that way. Wasn't something like this also added for
> type IV as well?

something like this WAS added for 3.5" HD floppies :)

(and yes, QD disks are just the same as SD/DD)

--

http://hitmen.eu                 http://ar.pokefinder.org
http://vice-emu.sourceforge.net  http://magicdisk.untergrund.net

I see in C64.h a list of defines.
<Wildstar>





Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

MiaM
In reply to this post by Francesco Messineo
Den Thu, 3 Jan 2019 15:15:43 +0100 skrev Francesco Messineo
<[hidden email]>:

> On Thu, Jan 3, 2019 at 2:51 PM Mia Magnusson <[hidden email]> wrote:
> >
> > Den Wed, 02 Jan 2019 15:34:24 +0100 skrev André Fachat
> > <[hidden email]>:
> > > Hi there,
> > >
> > > I was looking at floppy disk recording schemes and I am wondering
> > > if the 8050/8250/1001 floppy disk format with over 500kB per side
> > > was actually out of spec of even the Quad Density disks?
> > >
> > > The recording frequency was increased from 250kHz to 375kHz (×
> > > 1.5, for the innermost i.e. most critical track/speed zone). That
> > > resulted in a much increased number of bits per inch. See here:
> > > https://extrapages.de/archives/20190102-Floppy-notes.html
> > >
> > > What do you think?
> >
> > Afaik the 8050/8250/1001 drives are supposed to use "QD" disks,
> > which seems to be a format that's supposed to handle a higher
> > density than DD.
>
> "QD" disks have the very same 300 oersted magnetic media as SD/DD
> disks, it was only the mechanics and R/W heads that allowed to use
> more effectively the storage media.
> Later HD drives used different R/W heads (or different currents) and
> required 600 oersted media, doubled bitrate to 500 Kbps and changed
> speed to 360 rpm.
>
> At the university, we had a few Olivetti LSX-3005 that were equipped
> with 96tpi 5 1/4" drives (QD, not HD obviously),
> I remember nobody ever tried to find "QD" disks, normal DD 48TPI disks
> were used (albeit I remember good quality brands were purchased
> usually, like 3M, Olivetti).

As I recall, some 48 TPI disks actually caused problems when used as 96
TPI.

A qualified guess is that once 96 TPI DD disks became rather common,
they just made that kind of disks and labeled some of them as 96 and
some as 48 TPI for market / pricing purposes.

Later when the market settled for 40 TPI DD and 96 TPI HD the
manufacturers could well have switched back to media that only support
48 TPI, if there were ever any kind of issue with track-to-track crosstalk.

> > It seems common for people to think that QD was a marketing thing
> > used for 96TPI DD disks, but I've seen so many 96TPI disks marked
> > DD and
>
> again, 96TPI DD is just the same media as 48TPI DD, just maybe tested
> better (or just advertised as 96TPI, who knows).

Well, with narrower tracks, the signal to noise ratio will be worse
with all other parameters the same, so 96 TPI disks might actually
differ from some 48 TPI disks.

> > only a few (like one or two, and it was last summer that I first saw
> > them) disks actually labeled QD. (They contain a book keeping
> > software package, in Swedish, from the Swedish Commodore importer
> > Datatronic. Will be preserved as soon as I get my 8050 up and
> > running, which has been waiting a while for me to find my stash of
> > IEEE cables :) )).
> >
> > It would be really strange if floppy media didn't evolve the same
> > way as magnetic tapes did. With media good enough for 250kHz at
> > track 35 when the 5.25" floppys were new, and soon good enough for
> > 250kHz at track 40, it seems reasonable that some years later the
> > media used for those drives were actually good enough for 375kHz at
> > the 48TPI equalient of track 35, which almost is where the highest
> > track number on a 77 track 100 TPI drive will end up.
>
> I really think the better Kbps rating is due to the use of the more
> efficient GCR code instead of the MFM.

Why wouldn't Commodore had used that in the
2040/3040/4040/2031/2031LP/1540/1541/1551/1570/1571 drives too then?

> > (At some point in time a market for cheap rather crappy disks seems
> > to have evolved though, but those were probably anyway nothing
> > people used in their 8050/8250/1001 drives).
> >
> > (Everyone who's been around long enough to remember cassette tapes
> > from the 70's and the 80's remember that before tapes like Maxell
> > UD and similar the standard / ferro / type I tapes did really sound
> > crap with a high noise level and muffled treble. Then something
> > happened in the late 70's and early 80's, resulting in more and
> > more kinds of tapes getting a lot better, and at the start of the
> > 90's basically almost all tapes had a decent sound even though
> > there were of course still differences between them).
>
> There're two different issues on compact cassette:
> 1) different (really much different) magnetic media, type I (Fe2O3,
> iron oxide), Type II (CrO2), type III (FeCr), type IV (metal), these
> media required different equalization and different recording
> currents. Type I are usually very bad sounding and noisy, type IV have
> the best quality, but the recorder really NEEDS to know what type of
> tape it's trying to record into, otherwise you wouldn't get much
> better results, unless maybe a bit less noise if you use a type IV
> tape on a old, low quality recorder.
> 2) Dolby NR pre/de-emphasys. These noise reduction techniques have
> been introduced starting from 1965, last one afaik was introduced in
> 1986. Not all recorder were equipped with these circuits. A type I
> with the best NR circuit could sound really better than a type II with
> no Dolby.
> So, all in all, nothing in common with floppy disks :)

In practice the cassettes did differ rather much between models and
manufacturers. There were even cassette decks like AKAI CS-707D which
had two different tape positions for "type I" tapes, called LN and LH,
which were intended for usage with older/"European" (Usually
Philips, Agfa, BASF and similar from the 60's and 70's, and the crappy
American tapes like Ampex, Scotch/3M and similar) v.s.
newer/"Japanese" (usually Maxell UD and similar from the 70's, and most
types from the 80's and newer) tapes.

Have a look at any decent cassette tape test in some serious consumer
electronics magazine from back in the days, and you'll find that the
tapes differed a lot within each type.

This must surely have happened on diskettes also, but as the media is
used in a different way the only important things would be that the
noise is under a certain threshold and the "treble response" is good
enough so data won't get lost at higher bit rates, and of course drop
outs.



--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

MiaM
In reply to this post by Francesco Messineo
Den Thu, 3 Jan 2019 15:59:58 +0100 skrev Francesco Messineo
<[hidden email]>:

> > Back when Type II was established, the type II tapes had an extra
> > notch next to the erase control tab and most recorders had a sensor
> > that detected the type that way. Wasn't something like this also
> > added for type IV as well?
>
> yes, every kind of compact cassette had different holes, but recorders
> were not forced to auto-detect, my recorder in the '80s supported type
> I and IV but had no autodetect, I needed to "inform" it via a switch
> on what kind of cassette I had put in it.
> The high end ones I'm sure had autodetect.

Well, type III (FeCr) never had any autodetect holes, unfortunitely.
Therefore there were some cassette units which had a selector with
positions for type III and auto (usually labeled I/II). Metal / type IV
had another notch closer to the center.

The early chrome enabled Philips made cassette decks from the early
70's did auto detect the type and indicated the type with different
colors on a bit of plastic that moved behind a transparent window.

BASF did the most stupid thing, they made cassette recorders that were
only made for using Chrome / type II tapes.

Btw, the better cassette decks could be calibrated by the user for each
different tape brand/model. Sometimes automatic (like for example
Yamaha KX-670) and sometimes manually (and then in some cases only the
bias level like Yamaha KX-1200 or only the signal level like Akai
GXC-760D).

My impression is that those brands that sold best to customers who
wanted many buttons and knobs had manual tape selection while those who
sold to customers who didn't care about all tech details did
autodetect. At some point in time the auto detect took over though,
probably because it was easier to make it a part of the same cassette
mechanism base used for many decks while producing nice looking buttons
on the front panel cost money.



--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

Francesco Messineo
In reply to this post by MiaM
On Thu, Jan 3, 2019 at 5:52 PM Mia Magnusson <[hidden email]> wrote:
&gt;

&gt; &gt;
&gt; &gt; "QD" disks have the very same 300 oersted magnetic media as SD/DD
&gt; &gt; disks, it was only the mechanics and R/W heads that allowed to use
&gt; &gt; more effectively the storage media.
&gt; &gt; Later HD drives used different R/W heads (or different currents) and
&gt; &gt; required 600 oersted media, doubled bitrate to 500 Kbps and changed
&gt; &gt; speed to 360 rpm.
&gt; &gt;
&gt; &gt; At the university, we had a few Olivetti LSX-3005 that were equipped
&gt; &gt; with 96tpi 5 1/4" drives (QD, not HD obviously),
&gt; &gt; I remember nobody ever tried to find "QD" disks, normal DD 48TPI disks
&gt; &gt; were used (albeit I remember good quality brands were purchased
&gt; &gt; usually, like 3M, Olivetti).
&gt;
&gt; As I recall, some 48 TPI disks actually caused problems when used as 96
&gt; TPI.

Probably in the 96TPI HD drives, the ones that need 600 Oersted media.
QD drives need 300 Oersted media, they can't write to 600 Oersted "HD"
media (try yourself)
300 Oersted media is always the same, regardless on what is printed on
the box (SD/DD/QD, 48/96TPI).
HD drives need 600 Oersted media to use the 1.2MB format, but they can
read/write to 300 Oersted media in the FM/MFM formats.
HD drives will usually fail to write 1.2MB formats on 300 Oersted media.
I can assume some manufacturer produced better media than others, but
that was largely independent on what was advertised on the box :)
When I went through my whole lot of Apple II disks, I've found a few
brands of disks that were so degraded that they would leave a lot of
magnetic stuff on the heads, and I had to clean the drive's head after
trying to read such a disk.
On the other hand, some unmarked generic floppies were as good as new
after all these years.


&gt;&gt; &gt; I really think the better Kbps rating is due to the use
of the more
&gt; &gt; efficient GCR code instead of the MFM.
&gt;
&gt; Why wouldn't Commodore had used that in the
&gt; 2040/3040/4040/2031/2031LP/1540/1541/1551/1570/1571 drives too then?

In facts, CBM used the more efficient GCR in their drives :)
LSX-3005 QD MFM drives stored 720Kbytes (double side), using 80 tracks
per side, while the 8250/SFD-1001 GCR drives stored 1Mbyte on the same
disks and using only 77 tracks per side :)
MS-DOS stored 360Kbytes on 40x2 tracks using MFM, 4040/1541 GCR stores
340Kbytes (on two sides) but only on 35x2 tracks (so, using 10 less
tracks!!)
Yes, of course CBM drives also use variable bitrate to store more
sectors in the larger tracks, but this is possible because of GCR
encoding.
All this on 300 Oersted media.

>
> Have a look at any decent cassette tape test in some serious consumer
> electronics magazine from back in the days, and you'll find that the
> tapes differed a lot within each type.
>
> This must surely have happened on diskettes also, but as the media is
> used in a different way the only important things would be that the
> noise is under a certain threshold and the "treble response" is good
> enough so data won't get lost at higher bit rates, and of course drop
> outs.

well really magnetic media is used quite differently on audio tapes VS
floppy disks.
On audio tape you would be interested in dynamic range, frequency response etc.
Floppy disks write at a high enough current level to almost saturate
locally the magnetic media, that is also a good measure against
magnetic memory of the old data written in the same spot.

Frank

Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

André Fachat
On Donnerstag, 3. Januar 2019 18:20:31 CET Francesco Messineo wrote:
> &gt;&gt; &gt; I really think the better Kbps rating is due to the use
> of the more
> &gt; &gt; efficient GCR code instead of the MFM.
> &gt;
> &gt; Why wouldn't Commodore had used that in the
> &gt; 2040/3040/4040/2031/2031LP/1540/1541/1551/1570/1571 drives too then?
>
> In facts, CBM used the more efficient GCR in their drives :)

GCR is NOT more efficient than MFM using the same bit frequency. In fact MFM
is more efficient (writing 8 cells @ 250kHz for MFM vs. 10 cells @ 250kHz for
CBM GCR).

The reason that MFM can do this is that they actually use "half cells" at
250kHz, but still ensuring that flux transitions are at least 4us (i.e. a
250kHz cell) apart.

> LSX-3005 QD MFM drives stored 720Kbytes (double side), using 80 tracks
> per side, while the 8250/SFD-1001 GCR drives stored 1Mbyte on the same
> disks and using only 77 tracks per side :)
> MS-DOS stored 360Kbytes on 40x2 tracks using MFM, 4040/1541 GCR stores
> 340Kbytes (on two sides) but only on 35x2 tracks (so, using 10 less
> tracks!!)

One feature Commodore made more efficient is zoned recording, i.e. increasing
the recording frequency on the outer tracks.

> Yes, of course CBM drives also use variable bitrate to store more
> sectors in the larger tracks, but this is possible because of GCR
> encoding.

No, this is not due to GCR encoding. You could even increase recording
frequency on MFM on outer (i.e. longer, i.e. faster) tracks, as long as you
don't get over the bpi rating of the media. The MFM controllers did not
support it though, so it was not used.

> All this on 300 Oersted media.

Yes

Regards
André




Reply | Threaded
Open this post in threaded view
|

Re: Did Commodore cheat with the quad density floppies?

Mike Stein
In reply to this post by MiaM

----- Original Message -----
From: "Mia Magnusson" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, January 03, 2019 8:50 AM
Subject: Re: Did Commodore cheat with the quad density floppies?


...
> Afaik the 8050/8250/1001 drives are supposed to use "QD" disks, which seems to be a format that's supposed to handle a higher density than DD.

I've never seen a reference to 'QD' disks in any material from Commodore; they usually say you can use SD in the lower capacity drives (15xx, 20xx 40xx etc.) and recommend DD diskettes for the 8xxx higher capacity ones.

> It seems common for people to think that QD was a marketing thing used for 96TPI DD disks, but I've seen so many 96TPI disks marked DD

Interesting; if they were marked DD then how do you know that they were '96TPI disks'? Do you mean (48TPI) DD disks *recorded at* 96 TPI?

Most people consider 'Quad Density' a misleading term not even used consistently by all manufacturers; as Frank points out, the media material and therefore the maximum recording *density* is the same as DD, but with more (narrower) tracks. The only difference aside from marketing hype is that quality improved in the early years and in some cases the diskettes *may* actually have been certified for 96TPI recording.

Just like 3.5" diskettes it really comes down to only two types of 5 1/2" diskettes: 300 Oersted *Low Density* (SD, DD, 'QD', 48TPI, 96TPI, 100TPI) and 600 Oersted HD diskettes (although the coercivity of 3.5" diskettes does not differ quite as much between DD and HD and unlike 5 1/4 diskettes they can often be used interchangeably)

FWIW I've used all sorts of diskettes in my 8050s and never had a consistent problem (other than the usual occasional error) with any type, SD, DD or 'QD', even hard sector diskettes (since most CBM drives don't have an index sensor).

Interesting side note: hard sector diskettes were dirt cheap back in the day since relatively few systems could use them, so I bought quite a few; they came in very handy a few years ago when I acquired some CP/M systems that *did* require them, since by then they were almost unobtainable.

I wonder if part of the answer to Andre's original question may be the fact that Bits per inch is not necessarily the same as Flux transitions per inch/mm...


12345 ... 17