21 May
2013
21 May
'13
1:26 p.m.
This might be a silly question...
Since the specs of the MGT +D disk interface are now out there in the
public domain...
http://www.worldofspectrum.org/NotThePlusD/
... but 720kB 3?" floppy drives are getting rather scarce, I was
wondering... would it be viable to build a version that supported
1.4MB "HD" drives? I realise this would mean a different FDC chip, but
are there other implications apart from tweaking the DOS?
I know few 8-bits supported HD disks, but I don't really understand
why. My electronics knowledge is poor. (Cue Tony Duell.)
I am guessing that an 8-bit would struggled to read/write data fast
enough to keep an HD diskette controller supplied with data, but I was
wondering if that could be overcome with interlacing or adding some
cache RAM?
This is probably a completely pointless exercise - people seem more
interested in using CF or SD media these days, but I enjoy the
nostalgic element of actual floppy diskettes.
--
Liam Proven ? Profile: http://lproven.livejournal.com/profile
Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven
MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven
Tel: +44 20-8685-0498 ? Cell: +44 7939-087884
21 May
21 May
2:48 p.m.
On 05/21/2013 10:26 AM, Liam Proven wrote:
This might be a silly question...
Since the specs of the MGT +D disk interface are now out there in the
public domain...
http://www.worldofspectrum.org/NotThePlusD/
... but 720kB 3?" floppy drives are getting rather scarce, I was
wondering... would it be viable to build a version that supported
1.4MB "HD" drives? I realise this would mean a different FDC chip, but
are there other implications apart from tweaking the DOS?
I know few 8-bits supported HD disks, but I don't really understand
why. My electronics knowledge is poor. (Cue Tony Duell.)
I am guessing that an 8-bit would struggled to read/write data fast
enough to keep an HD diskette controller supplied with data, but I was
wondering if that could be overcome with interlacing or adding some
cache RAM?
This is probably a completely pointless exercise - people seem more
interested in using CF or SD media these days, but I enjoy the
nostalgic element of actual floppy diskettes.
With a 4MHz Z80 CPU, it's possible. There was a stepping of the WD1772
that could be goosed to do 500KHz data rates (The 1770 and 1772 are
denoted by WD as "minifloppy controllers"). You'd have to change some
time-critical components, such as the FDC crystal and probably rewrite
the floppy routines to accommodate a different format, but it's all doable.
I think the Atari ST people goofed around with this one some years back.
--Chuck
5:34 p.m.
On 05/21/2013 01:21 PM, Fred Cisin wrote:
On Tue, 21 May 2013, Chuck Guzis wrote:
And apparently still do--but the modifiable drives are getting harder to
find. Given that the energy induced by the passage of a domain under a
floppy read/write head is proportional to the square of the linear
velocity of the media, I've wondered if this is an advisable mod (shades
of Weltec).
--Chuck
I think the Atari ST people goofed around with
this one some years back.
. . . and some Amiga systems cheated, and just spun the drive at 150RPM
3:33 p.m.
On 05/21/2013 10:26 AM, Liam Proven wrote:
This is probably a completely pointless exercise -
people seem more
interested in using CF or SD media these days, but I enjoy the
nostalgic element of actual floppy diskettes.
This does prompt one to ask "Why not use a regular HD 3.5" drive? Most
handle 2D media just fine and several models can be jumpered to provide
up to 4 drive selects as well as READY/ instead of DISK CHANGED/
--Chuck
4:05 p.m.
This might be a silly question...
Since the specs of the MGT +D disk interface are now out there in the
public domain...
http://www.worldofspectrum.org/NotThePlusD/
... but 720kB 3?" floppy drives are getting rather scarce, I was
Most older 3.5" HD drives support 720K disks. Unlike the 5.25" IBM PC
drives, the spindle speed on the 3.5" ones, and the number of cylinders,
is the same for DD and HD drives (yes, Frid, I am misusing those terms a
bit, but I think you know what I am talking about).
wondering... would it be viable to build a version
that supported
1.4MB "HD" drives? I realise this would mean a different FDC chip, but
are there other implications apart from tweaking the DOS?
In most cases the FDC chip can remain the same, what it needs is a higher
data rate, A faster write clock and a modification to the dat separator
clock. If the FDC is campable of handlign 8" drives, then it can handle
HD 3.5" drives.
I know few 8-bits supported HD disks, but I don't
really understand
why. My electronics knowledge is poor. (Cue Tony Duell.)
The problem is that the higehr data rate on the floppy drive leads to a
higher byte transfoer rate on the processor side of the disk controller.
Msot 8 bit machiens (certain of the Spectrom type) didn't use any form of
DMA fro the floppy controller, it relied o nthe processor to transfew the
bytes as neeeded. Doing this at the DD data rate normally involved some
tight code. I think doing it at the HD rate would be very hard/impossible/
I am guessing that an 8-bit would struggled to read/write data fast
enough to keep an HD diskette controller supplied with data, but I was
wondering if that could be overcome with interlacing or adding some
cache RAM?
It would, but the interfce is not trivial. You bascially have to make
some kind of mini-DMA device to access that RAM and transfer bytes
to/from the FDC as needed. Not hard, but not a single-chip solution
either. Well, actually, it could be a single chip soloution, I susepct a
microcontroller would now be fast enough or you could use an FPGA. But
again you have to program them.
This is probably a completely pointless exercise -
people seem more
interested in using CF or SD media these days, but I enjoy the
nostalgic element of actual floppy diskettes.
There are 2 obvious solutions. The first is to get a 1.44M drive that
reliably supports 720K disks and use that [1]. THe other, of course, is
to get a 720K drive that can be repaired nad maintained (and yes, they
did exist) and keep it running.
[1] I don't know if any of the USB floppy drives do that. But contrary
to what has been said here before. some USB floppy drives contain a
normal floppy drive mechanism, often with a 26 wire flexcable as the
interface, linked to a tiny USB interface board. You could extract the
drive and use it with some other controller.
-tony
5:39 p.m.
On 05/21/2013 01:05 PM, Tony Duell wrote:
The problem is that the higehr data rate on the floppy
drive leads to a
higher byte transfoer rate on the processor side of the disk controller.
Msot 8 bit machiens (certain of the Spectrom type) didn't use any form of
DMA fro the floppy controller, it relied o nthe processor to transfew the
bytes as neeeded. Doing this at the DD data rate normally involved some
tight code. I think doing it at the HD rate would be very hard/impossible/
A few years back, Herb Johnson opened a discussion of this on his web
site. The conclusion was that a 4 MHz Z80 was indeed fast enough to do
this with programmed I/O and DD 8" disks (500KHz data rate) and that it
was *barely* possible to do at 2 MHz Z80 set up correctly and not at all
with a 2 MHz 8080.
I suggested a few schemes where the 8080 might be able to keep up, but
they were big (straight-line code) and used some odd techniques (e.g.
PUSH instead of STAX to do a 16-bit store and decrement). I never was
curious enough to try them--just hand-timed them.
--Chuck
8:08 p.m.
On Tue, 21 May 2013, Chuck Guzis wrote:
On 05/21/2013 01:05 PM, Tony Duell wrote:
Interestingly, a 1 Mhz. 6502 in an Apple 2 can transfer 500Khz data rate
in programmed I/O mode. What it cannot do is take cycles to check the FDC
port status while in the transfer loop. There were all sorts of schemes
cooked up to work around this. I have an SVA "MegaFlex" controller that
had two almost identical software loops one page apart in memory. The
RDY* line on the FDC was used to toggle an address bit whenever it needed
to move between a "do nothing" loop and the "move data" loop. The do
nothing loop incremented the address in the other loop by in-line
modification (firmware ran in static RAM) and killed time until switched
over on the next sector. Clever, and worked well.
Another board from the same vintage used the WAIT line on the CPU to
handshake the transfer.
There were some DMA based controllers (Vista A800 comes to mind), but DMA
was always a bit iffy on Apple 2s.
Steve
--
The problem is that the higehr data rate on the
floppy drive leads to a
higher byte transfoer rate on the processor side of the disk controller.
Msot 8 bit machiens (certain of the Spectrom type) didn't use any form of
DMA fro the floppy controller, it relied o nthe processor to transfew the
bytes as neeeded. Doing this at the DD data rate normally involved some
tight code. I think doing it at the HD rate would be very hard/impossible/
A few years back, Herb Johnson opened a discussion of this on his web site.
The conclusion was that a 4 MHz Z80 was indeed fast enough to do this with
programmed I/O and DD 8" disks (500KHz data rate) and that it was *barely*
possible to do at 2 MHz Z80 set up correctly and not at all with a 2 MHz
8080.
I suggested a few schemes where the 8080 might be able to keep up, but they
were big (straight-line code) and used some odd techniques (e.g. PUSH instead
of STAX to do a 16-bit store and decrement). I never was curious enough to
try them--just hand-timed them. 
22 May
22 May
7:28 a.m.
On Tue, May 21, 2013 at 4:39 PM, Chuck Guzis <cclist at sydex.com> wrote:
A few years back, Herb Johnson opened a discussion of
this on his web
site. The conclusion was that a 4 MHz Z80 was indeed fast enough to do
this with programmed I/O and DD 8" disks (500KHz data rate) and that it was
*barely* possible to do at 2 MHz Z80 set up correctly and not at all with a
2 MHz 8080.
There are hardware issues also relating to your selection of FDC. The
general consensus and experience of the N8VEM CP/M board builders is that
programmed IO with a 8 MHz and up Z80 and a modern 1.44 MHz floppy and a
9266 FDC works perfectly. I assembled a system this winter and that worked
perfectly. Obtaining 8+ MHz chips for modern Z80 designs is non trivial
and involves lots of ebay and searching.
Someday I will remove my CPU canned osc, locate a TTL output function
generator, and figure out exactly what the minimum is. The disk io v3
board has headers and software support for a 8 inch floppy and if I can
locate one I could do pretty extensive testing of different disk
technologies. This type of test with a live system, lots of different
drive types, and a ttl output function generator in place of CPU clock
would certainly prove once and for all what is required for what drive
technology.
9:33 a.m.
On 05/22/2013 07:28 AM, Vince Mulhollon wrote:
On Tue, May 21, 2013 at 4:39 PM, Chuck Guzis
<cclist at sydex.com> wrote:
Actually you have 16us to complete the
transfer. It can be done even
with 8080
but the software loop must assume the in or out has a implied wait (stall)
to keep the loop tight enough to keep up...
The problem is two fold, one if the data ready/request never happens
(open door/no media)
the system is hung.
The other is if your using DRAM you are not refreshing in that state so
a hang or long delay
(like waiting a full revolution for the sector) will likely crash the
system on ram errors.
Interrupts during that time will be pending till the wait is released.
I have done it with 3mhz 8085 easily and 4mhz Z80 this way.
A few years back, Herb Johnson opened a
discussion of this on his web
site. The conclusion was that a 4 MHz Z80 was indeed fast enough to do
this with programmed I/O and DD 8" disks (500KHz data rate) and that it was
*barely* possible to do at 2 MHz Z80 set up correctly and not at all with a
2 MHz 8080.
There are hardware issues also relating to your selection of FDC. The
general consensus and experience of the N8VEM CP/M board builders is that
programmed IO with a 8 MHz and up Z80 and a modern 1.44 MHz floppy and a
9266 FDC works perfectly. I assembled a system this winter and that worked
perfectly. Obtaining 8+ MHz chips for modern Z80 designs is non trivial
and involves lots of ebay and searching.
Someday I will remove my CPU canned osc, locate a TTL output function
generator, and figure out exactly what the minimum is. The disk io v3
board has headers and software support for a 8 inch floppy and if I can
locate one I could do pretty extensive testing of different disk
technologies. This type of test with a live system, lots of different
drive types, and a ttl output function generator in place of CPU clock
would certainly prove once and for all what is required for what drive
technology.
The minimum is:
Assumes a FDC read or write will pull /wait until the FDC
clears it with a data request.
Read or write a byte,
Index to zero byte count
index ram pointer
get next byte in the Acc
jump to start if not zero
Allison
9:56 a.m.
One further item...
Most of the late generation Z80s will over clock if the clock drive has
good edges and
levels. So a 6mhz (especially the CMOS versions) will hit and exceed 10mhz.
Even the old (ca1980) NMOS parts will easily run to 5 and as high as 7mhz.
Allison
-------- Original Message --------
Subject: Re: HD floppies on a ZX Spectrum
Date: Wed, 22 May 2013 09:33:09 -0400
From: allison <ajp166 at verizon.net>
To: General Discussion: On-Topic Posts Only <cctech at classiccmp.org>
On 05/22/2013 07:28 AM, Vince Mulhollon wrote:
On Tue, May 21, 2013 at 4:39 PM, Chuck Guzis
<cclist at sydex.com> wrote:
Actually you have 16us to complete the
transfer. It can be done even
with 8080
but the software loop must assume the in or out has a implied wait (stall)
to keep the loop tight enough to keep up...
The problem is two fold, one if the data ready/request never happens
(open door/no media)
the system is hung.
The other is if your using DRAM you are not refreshing in that state so
a hang or long delay
(like waiting a full revolution for the sector) will likely crash the
system on ram errors.
Interrupts during that time will be pending till the wait is released.
I have done it with 3mhz 8085 easily and 4mhz Z80 this way.
A few years back, Herb Johnson opened a
discussion of this on his web
site. The conclusion was that a 4 MHz Z80 was indeed fast enough to do
this with programmed I/O and DD 8" disks (500KHz data rate) and that it was
*barely* possible to do at 2 MHz Z80 set up correctly and not at all with a
2 MHz 8080.
There are hardware issues also relating to your selection of FDC. The
general consensus and experience of the N8VEM CP/M board builders is that
programmed IO with a 8 MHz and up Z80 and a modern 1.44 MHz floppy and a
9266 FDC works perfectly. I assembled a system this winter and that worked
perfectly. Obtaining 8+ MHz chips for modern Z80 designs is non trivial
and involves lots of ebay and searching.
Someday I will remove my CPU canned osc, locate a TTL output function
generator, and figure out exactly what the minimum is. The disk io v3
board has headers and software support for a 8 inch floppy and if I can
locate one I could do pretty extensive testing of different disk
technologies. This type of test with a live system, lots of different
drive types, and a ttl output function generator in place of CPU clock
would certainly prove once and for all what is required for what drive
technology.
The minimum is:
Assumes a FDC read or write will pull /wait until the FDC
clears it with a data request.
Read or write a byte,
Index to zero byte count
index ram pointer
get next byte in the Acc
jump to start if not zero
Allison
11:39 a.m.
On 05/22/2013 09:33 AM, allison wrote:
On 05/22/2013 07:28 AM, Vince Mulhollon wrote:
8080 code that does that:
; read case
;
; we have 16us to do a read and wait for the next
; so tricks are used to save cycles.
; At 2mhz we have 32 cycles (8080 2mhz case).
; Registers used.
; Acc is IO
; C is bytecount/4
; DE ram write pointer
; we repeat the input operation 4x so the
; a few cycles are saved on the byte count test
; and we can run sectors to 1024 using a single register.
;
; Assumptions, no memory wait states
; DRAM is NOT used, unless self refreshing
; without wait states.
;
; For a z80 not all the Z80 instructions run faster
; so any modification to use z80 insturcitons have
; to be very carefully picked.
;
loop: IN fdcportwait ;10cy
STAX D ;10cy
INX D ;7cy
DCR C ;4cy
; by causing wait on read data available in hardware we save
; a test for data ready and make it with 1 cycle extra.
IN fdcportwait
STAX D
INX D
DCR C
IN fdcportwait
STAX D
INX D
DCR C
IN fdcportwait
STAX D
INX D
DCR C
JNZ LOOP ; 10cy for jump, puts us
close be the system works as
; our read will
happen soon as we get there if data is
; already
waiting. Also it helps if the 8080 is pushed
;
18.432mhz/9=2.048mhz=.488us Tcy
; Most 8080s
will run at 2.5mhz!
Note on a z80 at 2,5mhz or a 8085 at 2.5mhz or faster this works easily.
On an 8080 it works but is very close timing wise. NOTE that even the
slowest 8085 is 3mhz and the slowest z80 is 2.5mhz. If the system is
running at 2mhz for those it may be ok but slower clock is NOT possible.
Allison
On Tue, May 21, 2013 at 4:39 PM, Chuck Guzis
<cclist at sydex.com> wrote:
Actually you have 16us to complete the
transfer. It can be done even
with 8080
but the software loop must assume the in or out has a implied wait
(stall)
to keep the loop tight enough to keep up...
The problem is two fold, one if the data ready/request never happens
(open door/no media)
the system is hung.
The other is if your using DRAM you are not refreshing in that state
so a hang or long delay
(like waiting a full revolution for the sector) will likely crash the
system on ram errors.
Interrupts during that time will be pending till the wait is released.
I have done it with 3mhz 8085 easily and 4mhz Z80 this way.
A few years back, Herb Johnson opened a
discussion of this on his web
site. The conclusion was that a 4 MHz Z80 was indeed fast enough to do
this with programmed I/O and DD 8" disks (500KHz data rate) and that
it was
*barely* possible to do at 2 MHz Z80 set up correctly and not at all
with a
2 MHz 8080.
There are hardware issues also relating to your selection of FDC. The
general consensus and experience of the N8VEM CP/M board builders is
that
programmed IO with a 8 MHz and up Z80 and a modern 1.44 MHz floppy and a
9266 FDC works perfectly. I assembled a system this winter and that
worked
perfectly. Obtaining 8+ MHz chips for modern Z80 designs is non trivial
and involves lots of ebay and searching.
Someday I will remove my CPU canned osc, locate a TTL output function
generator, and figure out exactly what the minimum is. The disk io v3
board has headers and software support for a 8 inch floppy and if I can
locate one I could do pretty extensive testing of different disk
technologies. This type of test with a live system, lots of different
drive types, and a ttl output function generator in place of CPU clock
would certainly prove once and for all what is required for what drive
technology.
The minimum is:
Assumes a FDC read or write will pull /wait until the FDC
clears it with a data request.
Read or write a byte,
Index to zero byte count
index ram pointer
get next byte in the Acc
jump to start if not zero
12:31 p.m.
On 05/22/2013 04:28 AM, Vince Mulhollon wrote:
There are hardware issues also relating to your
selection of FDC. The
general consensus and experience of the N8VEM CP/M board builders is that
programmed IO with a 8 MHz and up Z80 and a modern 1.44 MHz floppy and a
9266 FDC works perfectly. I assembled a system this winter and that worked
perfectly. Obtaining 8+ MHz chips for modern Z80 designs is non trivial
and involves lots of ebay and searching.
But back to the question originally posted--can one use a 1770/1772 FDC
to do 500Kbps 3.5" floppy data transfer. Note that the 1770/1772 and,
for that matter, the slightly different WD1773 are specifically labeled
by the manufacturer as "$.25 disk controllers." In other words, the
manufacturer has specified them for 250 Kbps operation--and indeed, the
datasheet timings revolve around that assumption.
Further, note that these are 28-pin DIP packages, which is remarkable
when you start counting up the number of pins required for the function.
Indeed, none of these has a side-select pin; the 1770/1772 lacks a
DRIVE READY/ pin (performing the function internally, but does have a
motor control output); the 1773 drops the motor-control line and
replaces it with a multiplexed DRIVE READY/ENABLE PRECOMPENSATION pin.
Neither has any drive-select logic. These are single-supply FDCs and are
able to drive the inputs to a 5.25" floppy drive without any additional
buffering. It's easy to see why Atari and others used the
chips--they're a self-contained solution in a low-pin-count package.
I've got one on an ISA prototype board that I assembled some years back
and, for what it is, it's definitely a remarkable product for its time.
I believe that there's a -4 stepping of the 1772 that some have managed
to get working on the Atari ST to do 500Kbps data transfer. A 4MHz Z80
should be more than fast enough. I've never been able to get a 1770 to
operate at that speed.
Regarding slower processors (e.g. 2MHz 8080), I think Don Tarbell's
original design using the WD1771 (FM only) was a good approach--insert
wait states rather than have the CPU poll for data. The bottom of the
transfer loop is a conditional jump that tests for termination by the
FDC--no counting of data bytes transferred is necessary. For the time,
it was a great solution.
The original poster asked if a cache could be used to improve the data
transfer picture. Perhaps not a cache, but a FIFO might be the simplest
approach to accomplish this; I haven't examined the question in detail.
--Chuck
1:16 p.m.
On 05/22/2013 12:31 PM, Chuck Guzis wrote:
On 05/22/2013 04:28 AM, Vince Mulhollon wrote:
That and it just will not run that fast.
There are hardware issues also relating to your
selection of FDC. The
general consensus and experience of the N8VEM CP/M board builders is
that
programmed IO with a 8 MHz and up Z80 and a modern 1.44 MHz floppy and a
9266 FDC works perfectly. I assembled a system this winter and that
worked
perfectly. Obtaining 8+ MHz chips for modern Z80 designs is non trivial
and involves lots of ebay and searching.
But back to the question originally posted--can one use a 1770/1772
FDC to do 500Kbps 3.5" floppy data transfer. Note that the 1770/1772
and, for that matter, the slightly different WD1773 are specifically
labeled by the manufacturer as "$.25 disk controllers." In other
words, the manufacturer has specified them for 250 Kbps operation--and
indeed, the datasheet timings revolve around that assumption.
Further, note that these are 28-pin DIP packages, which is remarkable
when you start counting up the number of pins required for the
function. Indeed, none of these has a side-select pin; the 1770/1772
lacks a DRIVE READY/ pin (performing the function internally, but does
have a motor control output); the 1773 drops the motor-control line
and replaces it with a multiplexed DRIVE READY/ENABLE PRECOMPENSATION
pin. Neither has any drive-select logic. These are single-supply FDCs
and are able to drive the inputs to a 5.25" floppy drive without any
additional buffering. It's easy to see why Atari and others used the
chips--they're a self-contained solution in a low-pin-count package.
I've got one on an ISA prototype board that I assembled some years
back and, for what it is, it's definitely a remarkable product for its
time.
They are. I have a few and the AMPROLB+ uses the 1770/1772 and the
1770 no matter what you
do will not run fast enough to do the data rate and its not a CPU issue.
I believe that there's a -4 stepping of the 1772
that some have
managed to get working on the Atari ST to do 500Kbps data transfer. A
4MHz Z80 should be more than fast enough. I've never been able to get
a 1770 to operate at that speed.
I've heard same but in that era WD was often a bit optimistic with their
specs and getting fast parts.
However Like I said the 1770 parts I've seen just don't!
If you need a 1770 like controller it's a home grown board with a 1793
and 8229(or similar) plus TTL to get
the interface and still present the right stuff to the pins on the CPU side.
Regarding slower processors (e.g. 2MHz 8080), I think
Don Tarbell's
original design using the WD1771 (FM only) was a good approach--insert
wait states rather than have the CPU poll for data. The bottom of the
transfer loop is a conditional jump that tests for termination by the
FDC--no counting of data bytes transferred is necessary. For the
time, it was a great solution.
I have an Altair 8800BT with one and its good save for NO DRAM allowed.
Several designs did that. I also did that with the 765 early on to get
to 500kbs (8"DD and later 3.5")
using a 8085 at 3mhz and it works very well. One trick added was to or
the DRQ and INT lines as the
765 does timeout on its own if read/write fails (assuming it gets enough
pseudo index pulses).
The original poster asked if a cache could be used to
improve the data
transfer picture. Perhaps not a cache, but a FIFO might be the
simplest approach to accomplish this; I haven't examined the question
in detail.
Cache is not a complete solution, a simple DMA (upcounter, sequencer,
and some ram) to a local pool of
ram then an IO port to read it out when ready. I have done this, a
simple state machine, select logic for
read, write and address counter plus logic to detect DMA complete
(sectorsize). This is the way the early
hard disk guys (teltek, and others) did it as MFM at 1byte/microsecond
was way to fast for any cpu then
(ok, 8x300 or bit slice could).
In this day and age a moderately fast micro can easily do it all and the
ram needed to buffer a cylinder
as well plus provide a 17xx interface to the host.
Allison
21 May
21 May
6:19 p.m.
> wondering... would it be viable to build a
version that supported
> 1.4MB "HD" drives? I realise this would mean a different FDC chip, but
> are there other implications apart from tweaking the DOS?
On Tue, 21 May 2013, Tony Duell wrote:
Most older 3.5" HD drives support 720K disks.
Unlike the 5.25" IBM PC
drives, the spindle speed on the 3.5" ones, and the number of cylinders,
is the same for DD and HD drives (yes, Frid, I am misusing those terms a
bit, but I think you know what I am talking about).
Sometimes it's just more practical for conveying the idea. Such as
referring to "360K" disks and drives V "1.2M" disks and drives, etc..
Sometimes it's just futile to tilt at that mill. ("1.44M", 65.535K,
1024000 byte "MB", "DB9", etc.)
However, I worry that use of "HD" V "DD", particularly in the context
of
thinking that that will require a different FDC chip MIGHT be due to a
marketing inspired misunderstanding and mistaken assumption that HD is
different from DD without realization that it IS DD at a higher speed.
In most cases the FDC chip can remain the same, what
it needs is a higher
data rate, A faster write clock and a modification to the dat separator
clock. If the FDC is campable of handlign 8" drives, then it can handle
HD 3.5" drives.
Minor nit: That should be clarified/limited as 8" DD
(Machines that handle only 8" SSSD would not be capable)
--
Grumpy Ol' Fred cisin at xenosoft.com
8:07 p.m.
On 05/21/2013 03:19 PM, Fred Cisin wrote:
Regardless, that was the nub of my comment. The WD1770 and 1772 are not
rated for 8" applications. Some late revisions will work at the higher
frequency. Note that the 1770 and -72 are a "one chip" FDC solution in
a 28-pin package; data separator, write precomp circuitry included under
the epoxy--there is no separate data clock. You're probably thinking of
the NEC 765 type chips.
--Chuck
In most cases
the FDC chip can remain the same, what it needs is a higher
data rate, A faster write clock and a modification to the dat separator
clock. If the FDC is campable of handlign 8" drives, then it can handle
HD 3.5" drives.
Minor nit: That should be clarified/limited as 8" DD
(Machines that handle only 8" SSSD would not be capable)
22 May
22 May
4:44 p.m.
clock. If the
FDC is campable of handlign 8" drives, then it can handle
HD 3.5" drives.
Minor nit: That should be clarified/limited as 8" DD
(Machines that handle only 8" SSSD would not be capable) 
5:45 p.m.
On Wed, 22 May 2013, Tony Duell wrote:
Wouldn't it? I would have thought it would, but only using FM (single
density) recording on the 3.5" drive. In other words you wouldn't get
1440K [1] on the disk, but it would work.
[1] I flatly refuse to call 1024*1000 a mega-anything...
Mebibytes for life!
clock. If
the FDC is campable of handlign 8" drives, then it can handle
HD 3.5" drives.
Minor nit: That should be clarified/limited as 8" DD
(Machines that handle only 8" SSSD would not be capable) -tony
--
Cory Smelosky
http://gewt.net/ Personal stuff
http://gimme-sympathy.org Experiments
6:02 p.m.
> Minor nit: That should be clarified/limited as
8" DD
> (Machines that handle only 8" SSSD would not be capable)
On Wed, 22 May 2013, Tony Duell wrote:
Wouldn't it? I would have thought it would, but
only using FM (single
density) recording on the 3.5" drive. In other words you wouldn't get
1440K [1] on the disk, but it would work.
Exactly!
If one were attempting to implement 1.4M (it multiplies out to
1474560, or 1.40625M), as I inferred from the original discussion,
[1] I flatly refuse to call 1024*1000 a
mega-anything...
then it wouldn't be suitable. But SSSD 3.5" with 128
bytes per sector sounds like fun.
--
Grumpy Ol' Fred cisin at xenosoft.com
7:01 p.m.
On 05/22/2013 03:02 PM, Fred Cisin wrote:
If one were attempting to implement 1.4M (it
multiplies out to
1474560, or 1.40625M), as I inferred from the original discussion,
So? Invent a new unit. How about KiKB? Pronounced kick-bee...
--Chuck
[1] I flatly refuse to call 1024*1000 a
mega-anything...
then it wouldn't be suitable. But SSSD 3.5" with 128
bytes per sector sounds like fun.
21 May
21 May
4:19 p.m.
On Tue, 21 May 2013, Liam Proven wrote:
This might be a silly question...
Since the specs of the MGT +D disk interface are now out there in the
public domain...
http://www.worldofspectrum.org/NotThePlusD/
... but 720kB 3?" floppy drives are getting rather scarce, I was
wondering... would it be viable to build a version that supported
1.4MB "HD" drives? I realise this would mean a different FDC chip,
WHY?
I know few 8-bits supported HD disks, but I don't
really understand
why. My electronics knowledge is poor. (Cue Tony Duell.)
Tony can address electronics, but the immediate OBVIOUS reason why is
HISTORY.
HD diskettes came about AFTER 8 bits were going, going, almost GONE.
Few 8 bit machines were around when 3.5" drives came out, and fewer when
HD.
I am guessing that an 8-bit would struggle to
read/write data fast
enough to keep an HD diskette controller supplied with data, but I was
wondering if that could be overcome with interlacing or adding some
cache RAM?
Got DMA?
8 bit is not the issue. Many 8 bit machines handled 8" double density
which is exactly the same requirements (other than cabling and pin-outs)
as HD 5.25" or 3.5"
This is probably a completely pointless exercise -
people seem more
interested in using CF or SD media these days, but I enjoy the
nostalgic element of actual floppy diskettes.
It's not pointless if you enjoy working on it.
This is a HOBBY.
It is s'posed to be pointless.
--
Grumpy Ol' Fred cisin at xenosoft.com
4046
days inactive
4047
days old
20 comments
8 participants
participants (8)
-
ajp166＠verizon.net -
ard＠p850ug1.demon.co.uk -
b4＠gewt.net -
cclist＠sydex.com -
cisin＠xenosoft.com -
lproven＠gmail.com -
snhirsch＠gmail.com -
vince＠mulhollon.com