Re: 1541/2031 combo adapter

From: groepaz_at_gmx.net
Date: Thu, 29 Oct 2020 17:35:24 +0100
Message-ID: <1859923.DIVbhacDa7_at_rakete>
Am Mittwoch, 28. Oktober 2020, 07:35:27 CET schrieb Spiro Trikaliotis:
> > The difference is the size of bytes in the gap between the header and the
> > data. IIRC the -02 ROM and earlier have 8 bytes, the -03 nine.
>
> Your memory is right.
>
> The 4040 wrote a gap of 8 GCR byte (that is, 10 "raw" byte), while the
> 2031 used 8 "raw" byte.
>
> > Reading should never
> > be a problem. According several sources writing can. I myself cannot
> > remember having any trouble when using 4040 disks in a 1541 and vice
> > versa. But that was before I heard about the possible problem.
>
> The problem should be there only if using a 4040 disk in a 2031, 1540 or
> 1541 with a -01 or -02 ROM ("very early 1541"), as these have the 8 byte
> gap [*]
>
> The 9 byte gap seems to be a good compromise to be compatible with both the
> 4040 as well as with the 2031/1540/"very early 1541".
>
> To be more precise: The problem is when writing a disk in the 4040
> drive, as it will leave a bigger gap than the 2031/1540 and it will be
> already in the SYNC mark when starting to write. Contrary, writing a
> disk formatted in a 4040 with the 2031/1540 should not be a problem, as
> the floppy just starts writing earlier.
>
> Of course, if writing the block over and over again, from the different
> drives (the BAM block comes to mind) might have its own rules...

coincidently, i have just fixed a related bug in VICE a while ago - the "old"
format was broken. can someone point me to a complete description of that
format, ie both header and tail gap sizes for all tracks/speedzones? right now
i have used guessed values that somewhat work, but i am sure they are not
correct. related commit: https://sourceforge.net/p/vice-emu/code/38826/


--

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

Some electronic components are now so small that more time is spent looking
for them than using them.
<Arthur C. Clarke>
Received on 2020-10-29 18:00:02

Archive generated by hypermail 2.3.0.