On Wed, Feb 20, 2019 at 11:40 PM Warner Losh via cctalk
wrote:
> At least on the Rainbow the floppy chip is kept in MFM mode all the time,
> unless you've written something to hack it to read alien disks.
And modified the hardware. On the Rainbow the 'Dden/' pin of the
floppy controller chip is
> Ability to read MFM data with FM headers (RX50)
On 2/20/19 3:40 PM, Warner Losh wrote:
The RX50's are MFM encoded. There's no FM anything on it, unless it's
that way on all MFM diskettes.
Other DEC diskettes may have done this, but RX50's are just higher track
density, but old pre IBM-AT
On 2/20/19 3:40 PM, Warner Losh wrote:
> The RX50's are MFM encoded. There's no FM anything on it, unless it's
> that way on all MFM diskettes.
>
> Other DEC diskettes may have done this, but RX50's are just higher track
> density, but old pre IBM-AT data encoding rate diskettes.
>
> At least
On Tue, Feb 19, 2019 at 3:38 PM Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:
> On 2/19/19 2:02 PM, Fred Cisin via cctalk wrote:
>
> > Ability to read MFM data with FM headers (RX50)
>
> It's not that simple. There's the matter of "DEC MFM" which encodes a
> few bit patterns differently
On Wed, 20 Feb 2019 at 18:08, Eric Korpela via cctalk
wrote:
>
> Don't forget hard sector CompuColor II, GCR, and variable speed GCR. :)
Well, yes, OK, but one step at a time.
Step 1: a generic USB floppy controller that allows 5¼" and 8" (and
other standard Shugart-interface) FDDs to be
On Tue, Feb 19, 2019 at 4:39 PM Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:
> On 2/19/19 3:40 PM, William Sudbrink via cctalk wrote:
> > A design that can manage Ohio Scientific as well would be nice.
>
> Might as well add Victor 9000...
>
Don't forget hard sector CompuColor II, GCR,
Hello folks,
I'm coming into this a bit late but a bloke called David Given is working
on such a floppy controller right now, it's called Fluxengine and is based
around a Cypress microcontroller that connects directly to a floppy drive
and is driven by USB. Early days as yet in that it supports
> By the time that I got out (for other reasons), XenoCopy had not been
> profitable for a while. THAT handled files, but the user still had to
> deal in other ways with modifications that they needed to the content
> of
> the files.
True, but at that point that is the user's problem. The idea
With all deference to the real collectors, I don't see the objective here.
The thing should be NEC 765 compatible? Why? What about non-NEC-based
sytems (e.g. the bulk of CP/M and countless other systems that don't use
an LSI controller)? Or those systems that permanently already have a
I would like to see software for . . .
THEN, I would like to see that software as . . .
THEN, I would like to see that . . .
On Tue, 19 Feb 2019, alan--- via cctalk wrote:
What's stopping you from writing it?
It's in the queue!
Which is longer than my expected remaining lifespan.
There are
On 2019-02-19 19:42, Fred Cisin via cctalk wrote:
On Tue, 19 Feb 2019, Ali wrote:
Are we being a little sarcastic or serious? :)
A lot of BOTH
I would like to see software for flux transition hardware that would
extract sectors.
THEN, I would like to see that software as a subroutine, with
Doesn't SuperCard Pro already do this? The hardware isn't open source,
but the USB control protocol to read and write flux transitions on an
entire track is open and well documented. And there are already several
tools to exercise the protocol. Sure, one could replicate the hardware
work
On Tue, 19 Feb 2019, Ali wrote:
That would make for a very powerful tool but as you pointed out yourself
how many users would learn to use it? Unless it is a simple driver that
gets loaded and the user has to simply put in a couple of generic
parameters, e.g. "device=c:\drives\emudsk.sys
Fred,> Are we being a little sarcastic or serious? >:)>>A lot of BOTHJust
making sure. ;)>I would like to see software for flux >transition hardware that
would >extract sectors.>THEN, I would like to see that software as >a
>subroutine, with an interface similar to >INT13h.>THEN, I would like
On Tue, 19 Feb 2019, Paul Koning wrote:
I' reminded of the Bordynuik tape reading machine that uses an MR head.
Capturing analog flux levels at, say, 10x the nominal flux change
density means all the rest is simply digital signal processing. That
can be done in real time if you must, but much
> On Feb 19, 2019, at 8:00 PM, Fred Cisin via cctalk
> wrote:
>
> On Tue, 19 Feb 2019, Fred Cisin via cctalk wrote:
>> As I see it, flux transition hardware COULD be all that is needed for
>> hardware. Emulation of FDC could be done in software with flux transition
>> hardware.
>
> That
On Tue, 19 Feb 2019, Fred Cisin via cctalk wrote:
As I see it, flux transition hardware COULD be all that is needed for
hardware. Emulation of FDC could be done in software with flux
transition hardware.
That should read flux transition plus appropriate control signals for the
drive.
A design that can manage Ohio Scientific as well would be nice.
On Tue, 19 Feb 2019, Chuck Guzis via cctalk wrote:
Might as well add Victor 9000...
It was in my original list :-)
On Tue, 19 Feb 2019, Ali wrote:
Are we being a little sarcastic or serious? :)
A lot of BOTH
I would like to see software for flux transition hardware that would
extract sectors.
THEN, I would like to see that software as a
subroutine, with an interface similar to INT13h.
THEN, I would like
On 2/19/19 3:40 PM, William Sudbrink via cctalk wrote:
> A design that can manage Ohio Scientific as well would be nice.
Might as well add Victor 9000...
--Chuck
On Tue, 19 Feb 2019, dwight wrote:
Actually, I'd like to see it just read/write flux changes + index marks
onto a SD card for later analysis. Building all the smarts into the
controller means that some formats will get missed. One can later write
translation code for what ever format one has.
On 2/19/19 2:31 PM, dwight via cctalk wrote:
> Actually, I'd like to see it just read/write flux changes + index marks onto
> a SD card for later analysis.
You want to do the analysis at the time of capture, in case you need to re-read
the media, or wiggle the head
to try to push off a bit
Ability to read MFM data with FM headers (RX50)
On Tue, 19 Feb 2019, Chuck Guzis via cctalk wrote:
It's not that simple. There's the matter of "DEC MFM" which encodes a
few bit patterns differently to avoid collision with FM headers.
Which is presumably a matter of appropriate code for
> Actually, I'd like to see it just read/write flux changes + index
> marks onto a SD card for later analysis
...
> We no longer need proprietary hardware.
Well some of us might not and then there is the rest of us who just need a
tool that kind of works.
I guess the question is "who is your
A design that can manage Ohio Scientific as well would be nice.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Fred,
Are we being a little sarcastic or serious? :)Honestly, a sw implementation
would be interesting but would it work on vintage hw? Or are you suggesting for
use only with a modern system? For example here is my dilemma: my stinkers,
whom you have met, are getting old enough to want to
On 2/19/19 2:02 PM, Fred Cisin via cctalk wrote:
> Ability to read MFM data with FM headers (RX50)
It's not that simple. There's the matter of "DEC MFM" which encodes a
few bit patterns differently to avoid collision with FM headers.
--Chuck
I'm planning on a USB controller, but I've seen ISA projects that are
also microcontroller based so I think it wouldn't be awfully difficult
to replace the USB data pipe with an ISA one.
On Tue, 19 Feb 2019, Ali via cctalk wrote:
Well just because you don't have enough to do please plan on an
28 matches
Mail list logo
