3 Sep
2010
3 Sep
'10
7:08 p.m.
Hi guys,
I've just (within the last few minutes) finished the "first cut" board
layout for the DiscFerret. It's a 160x100mm Eurocard, with all the
"inputs" (power and USB) on the back panel, and all the disc-drive
interfacing stuff (power and I/O) on the front. Truth be told, it's not
much different to the prototype schematic I posted to the list earlier
this year...
The 40-pin disc I/O connector carries a standard 17-line ("34-pin")
Shugart disc interface with all lines wired, four high-speed 5V TTL
"user I/O" lines, +5V (low current) and ground. The state of the DENSITY
pin (pin 2) can be driven as an open-collector output, or used as an
input (depending on the type of drive you're using).
There's an external "power output" connector for the disc drive. This is
a dual-row 4-pin AMP Micro Mate-n-Lok (P/N 3-794618-4, mating connector
794617-4 with 794610-1 contacts) which carries +12V, +5V and two
grounds. Current-handling capacity is about 1.5A per channel, so plenty
for most PC-style drives. There are no cop-outs here -- you can pull
1.5A from the 12V bus, and 1.5A from the 5V bus *at the same time*
without any adverse effects.
I wanted to use the standard Molex floppy drive power socket, but Molex
only seem to make one PCB-mount variant, which is the "input" socket
(which has a recessed body, but contains male pins -- go figure)...
There are also three status LEDs -- Power, FPGA Status and PIC Status.
The first is always on when the +3.3V regulator is running, the latter
two are controlled by their respective devices. A plastic light-pipe
redirects the light from these LEDs to the front panel. Simples!
For the curious...
Schematic: http://www.discferret.com/temp/discferret_sch.pdf
PCB layout:
Checkplot: http://www.discferret.com/temp/discferret_main_chk.pdf
Top copper: http://www.discferret.com/temp/discferret_main_top.pdf
Bot copper: http://www.discferret.com/temp/discferret_main_bot.pdf
Top overlay: http://www.discferret.com/temp/discferret_main_tov.pdf
EAGLE project files: http://www.discferret.com/temp/eagle/
(you'll need all the files in this directory)
Next step is to do a full design review (i.e. print the board and
schematic out REALLY BIG and go over them with a loupe), create a
Quartus constraints file and test-synthesize the FPGA microcode.
But first... it's 3AM and I'm tired. Sleep time! zzzzzz....
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
3 Sep
3 Sep
7:22 p.m.
On Sat, 4 Sep 2010, Philip Pemberton wrote:
Hi guys,
I've just (within the last few minutes) finished the "first cut" board
layout for the DiscFerret. It's a 160x100mm Eurocard, with all the
"inputs" (power and USB) on the back panel, and all the disc-drive
interfacing stuff (power and I/O) on the front. Truth be told, it's not
much different to the prototype schematic I posted to the list earlier
this year...
Yay! I'm glad you went ahead with this project. The Catweasel has been
such a disappointment. Hopefully this will succeed where the Catweasel
failed.
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
8:15 p.m.
On 3 Sep 2010 at 19:22, David Griffith wrote:
Yay! I'm glad you went ahead with this project.
The Catweasel has
been such a disappointment. Hopefully this will succeed where the
Catweasel failed.
How so with the Catweasel? I've used the CW for years to both read
and write some very weird formats.
--Chuck
8:56 p.m.
----- Original Message -----
From: "Chuck Guzis" <cclist at sydex.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Friday, September 03, 2010 11:15 PM
Subject: Re: DiscFerret update: PCB done!
On 3 Sep 2010 at 19:22, David Griffith wrote:
Did you program the CW yourself? Most people complain about that card
because it was sold for specific activities without the software to do it.
Yay! I'm glad you went ahead with this
project. The Catweasel has
been such a disappointment. Hopefully this will succeed where the
Catweasel failed.
How so with the Catweasel? I've used the CW for years to both read
and write some very weird formats.
--Chuck
9:27 p.m.
On 3 Sep 2010 at 23:56, Teo Zenios wrote:
Did you program the CW yourself? Most people complain
about that card
because it was sold for specific activities without the software to do
it.
Yes--most of the things that I work with would require special
programming anyway.
I guess it all depends on your perspective. Before the CW was
available, I used to prototype hardware to do the job, with all of
the accompanying software. The CW was a godsend.
--Chuck
5 Sep
5 Sep
2:31 p.m.
Chuck Guzis wrote:
On 3 Sep 2010 at 23:56, Teo Zenios wrote:
Maybe they were a little misleading though if they gave the impression that
the software to do task x already existed (or if it did exist - but only in
the sense that someone somewhere had written it, but had no plans to release
it for everyone else to use). That would be rather sly marketing, I think. Of
course saying something like "these are the features, you *could* do x, y and
z with it" might be different. It's all in the wording...
Did you program the CW yourself? Most people
complain about that card
because it was sold for specific activities without the software to do
it.
Yes--most of the things that I work with would require special
programming anyway. I guess it all depends on your perspective. Before
the CW was
available, I used to prototype hardware to do the job, with all of
the accompanying software. The CW was a godsend.
Things I encountered:
1) difficulty in finding data about the product, what products were even
available (vs. considered obsolete - lots of mention of different revisions,
but difficult to see what could actually be bought), and actually purchasing
one (I seem to recall the european website gave the impression of vaporware;
perhaps the US one was better?)
2) I want to be able to support it myself; if the people making it were to
vanish and it broke, I don't want to lose all the time I'd invested in writing
code to use it, or find myself scrabbling around for a replacement - I at
least want schematics etc. so I can have a chance at keeping the thing running
(and probably a spare board on the shelf!).
3) It was hard to see what there was in the way of "community" - again I think
that was more a website failing than anything else, but being able to bounce
ideas and experiences around with other folk who have the boards would be
useful, and it was difficult to see how to get in touch with them.
I've been very tempted to get one at times, but only because (like you say)
the alternative is really to build your own custom stuff - but maybe Phil's
efforts will solve some of the above issues.
cheers
Jules
6 Sep
6 Sep
5:53 a.m.
On Sun, 5 Sep 2010, Jules Richardson wrote:
Things I encountered:
1) difficulty in finding data about the product, what products were even
available (vs. considered obsolete - lots of mention of different revisions,
but difficult to see what could actually be bought), and actually purchasing
one (I seem to recall the european website gave the impression of vaporware;
perhaps the US one was better?)
Unfortunately, Jens' website is a bit scattered. There are a few
different ways to end up at information pages for the CW and they all seem
to take you through slightly different information.
2) I want to be able to support it myself; if the
people making it were to
vanish and it broke, I don't want to lose all the time I'd invested in
writing code to use it, or find myself scrabbling around for a replacement -
I at least want schematics etc. so I can have a chance at keeping the thing
running (and probably a spare board on the shelf!).
There actually is a long OEM coding document available. I found it almost
incomprehensible, however. Took about four read-throughs combined with
some study of third-party code before anything made sense. It suffers
from the same thing that a lot of Linux documentation
does: No context.
There's an assumption that the reader (somehow) knows
everything about the
function of the unit and simply needs a reminder of specific port
addresses or bit combinations.
One example: There is simply no discussion of the basic operational
paradigm of the unit! Took until the third reading until I realized that
the unit operates by storing timer values between detected transitions.
There's lots of discussion that dances a full circle around that
explanation (and assumes you know it), but it is literally _never_ stated
anywhere in those terms.
3) It was hard to see what there was in the way of
"community" - again I
think that was more a website failing than anything else, but being able to
bounce ideas and experiences around with other folk who have the boards would
be useful, and it was difficult to see how to get in touch with them.
In fairness, there are are a few folks out there with CW coding experience
and I found them friendly and very quick with help and pointers. The
Yahoo group has almost no activity, but folks do respond to postings
there.
I've been very tempted to get one at times, but
only because (like you say)
the alternative is really to build your own custom stuff - but maybe Phil's
efforts will solve some of the above issues.
The heart of the CW is an FPGA (I think). Although the bitstream is
provided, you likely will not find the source code nor schematics.
Steve
--
10:25 a.m.
On 6 Sep 2010 at 8:53, Steven Hirsch wrote:
Unfortunately, Jens' website is a bit scattered.
There are a few
different ways to end up at information pages for the CW and they all
seem to take you through slightly different information.
You have to understand Jens' motives for the CW. In a word, Amiga
support. But for the very latest MK IV, all versions have had some
sort of support for Amiga peripherals--and at least one model could
be "flipped" (turned upside-down) and inserted into an Amiga. So
it's understandable that his interest outside of Amiga support is
minimal.
The documentation (mostly the INSIDE.TXT document) is sparse and has
a feeling of "if you lived here you would know what I'm talking
about". But it's quite useful and I've seen far worse.
Much of what Jens does could now be handled with most modern medium-
scale microcontrollers. I think that's what most of the other
products, such as the Deviceside do. All you need is a PWM-style
timer with a "capture" mode and the ability to address about 128K of
DRAM and a uC that runs at a sufficient speed to reduce aliasing
effects. There's really no magic involved at all.
You can get an AVR Mega (with external addressing capability) to
produce acceptable results; an ARM-type uC would also be a good
choice and most DSP chips would probably do the job. Given the
rather pedestrian nature of the job and the fast cheap uCs available
today, I doubt that a FPGA makes a lot of cost-effective sense in the
case of floppy work.
And of course, one has to write the software to interpret the
results.
--Chuck
11:46 a.m.
On 06/09/10 18:25, Chuck Guzis wrote:
Much of what Jens does could now be handled with most
modern medium-
scale microcontrollers. I think that's what most of the other
products, such as the Deviceside do. All you need is a PWM-style
timer with a "capture" mode and the ability to address about 128K of
DRAM and a uC that runs at a sufficient speed to reduce aliasing
effects. There's really no magic involved at all.
Indeed -- the SPS guys are doing one (Kryoflux, google it) with an Atmel
SAM chip (if memory serves). Basically an ARM, Flash ROM and SRAM on a
single chip.
I'd be a little concerned about interrupt latency and jitter (the ARM is
a pipelined RISC design, interrupt timing tends not to be 100%
deterministic) but it's a really cool way to do it cheaply...
Given the
rather pedestrian nature of the job and the fast cheap uCs available
today, I doubt that a FPGA makes a lot of cost-effective sense in the
case of floppy work.
The reason I went with the FPGA was partly because I wanted it (the
DiscFerret) to be as flexible as possible. If all you want is floppy
disc reading and analysis, an Atmel AT91SAM chip should be plenty. If
you want to image hard drives (I do) then you NEED the raw speed and
programmability of an FPGA.
It's a feature not everyone will use, I'll admit, but I don't want to be
stuck making a "DiscFerret II" in a couple of years time, just because I
need to clone an MFM drive.
The other thing you can do on an FPGA is run an entire disc controller
IP core inside the GA, then use the microcontroller to pipe data in and
out. In this way, you could have (say) the Suska WD1771 controller core
running in the FPGA, reacting as a real WD1771 would when presented with
the same input data.
So not only can you read and write discs at bit-transition level, you
can see how a real disc controller would handle the discs. Assuming, of
course, you have an IP core for the disc controller in question
(apparently the Intel 8271 isn't hard to clone, the 1771 has already
been cloned, and I'm willing to bet someone's got an NEC 765 IP core)
And of course, one has to write the software to
interpret the
results.
But of course :)
Cheers,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
12:55 p.m.
On 6 Sep 2010 at 19:46, Philip Pemberton wrote:
On 06/09/10 18:25, Chuck Guzis wrote:
If it's got a "capture" mode on a timer, then jitter and latency are
of little concern--the CPU need only come around often enough to read
the capture register and stash it away. Some DSPs even include a DMA
mode for capture events, so the CPU is more or less out of the loop.
What kind of hard drive MFM resolution are you going for on the DF?
The CW samples floppies at 56MHz; similar resolution on an ordinary
ST506 hard drive would seem to require a clock of 560MHz, which is
high, even for an FPGA.
Synthesizing a commodity floppy controller is of little interest to
me, as much of what I deal with is very far from "standard" 3740-type
floppies. Group code, weird address marks, hard sectoring, unique
CRCs (or even integer checksums) are more the rule. Besides, I think
that the SMSC floppy controller is still available (in TQFP).
--Chuck
Much of what Jens does could now be handled with
most modern medium-
scale microcontrollers. I think that's what most of the other
products, such as the Deviceside do. All you need is a PWM-style
timer with a "capture" mode and the ability to address about 128K of
DRAM and a uC that runs at a sufficient speed to reduce aliasing
effects. There's really no magic involved at all.
Indeed -- the SPS guys are doing one (Kryoflux, google it) with an
Atmel SAM chip (if memory serves). Basically an ARM, Flash ROM and
SRAM on a single chip.
I'd be a little concerned about interrupt latency and jitter (the ARM
is a pipelined RISC design, interrupt timing tends not to be 100%
deterministic) but it's a really cool way to do it cheaply...
7:26 p.m.
On 06/09/10 20:55, Chuck Guzis wrote:
If it's got a "capture" mode on a timer,
then jitter and latency are
of little concern--the CPU need only come around often enough to read
the capture register and stash it away. Some DSPs even include a DMA
mode for capture events, so the CPU is more or less out of the loop.
Depends if the capture mode has auto-retrigger. Some PICs implement
capture/compare by storing the timer value and throwing an interrupt on
an external event. The timer is left running -- IIRC there isn't an
option to reset it after the C/C event.
What kind of hard drive MFM resolution are you going
for on the DF?
The CW samples floppies at 56MHz; similar resolution on an ordinary
ST506 hard drive would seem to require a clock of 560MHz, which is
high, even for an FPGA.
Quartus reckons the ACQCLK will go to 200MHz internal. External
oscillator is a 20MHz crystal, which gets PLL'd up accordingly.
On a standard floppy, the rate I've been using most often is 40MHz.
80MHz is most likely going to be the default in the 'release' microcode.
As for HDDs.. decoding a 5Mbps stream with a good margin would require
about 10 clocks per bit. 50MHz. I'd sample at 100MHz or 200MHz just for
a bit of additional margin.
20Mbit ESDI will most likely be a "design a controller and implement in
an FPGA" exercise -- timing-acquisition might not work particularly well
for that kind of bitrate.
Synthesizing a commodity floppy controller is of
little interest to
me, as much of what I deal with is very far from "standard" 3740-type
floppies. Group code, weird address marks, hard sectoring, unique
CRCs (or even integer checksums) are more the rule. Besides, I think
that the SMSC floppy controller is still available (in TQFP).
Point taken. But the SMSC floppy controller is a bitch to find, and if
memory serves it has issues with precompensation (if it's anything like
modern controllers, it just plain doesn't do precomp). Totally worthless
for anything vaguely resembling reliable R/W work.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
8:21 p.m.
On 7 Sep 2010 at 3:26, Philip Pemberton wrote:
Depends if the capture mode has auto-retrigger. Some
PICs implement
capture/compare by storing the timer value and throwing an interrupt
on an external event. The timer is left running -- IIRC there isn't an
option to reset it after the C/C event.
As long as the timer is either wide enough (e.g. 32 bit) or wraps to
0 from its maximum count, it really doesn't matter. AVRs definitely
do wrap and so do a number of other chips. ARM uses a 32-bit timer,
which is more than adequate for floppy use.
Point taken. But the SMSC floppy controller is a bitch
to find, and if
memory serves it has issues with precompensation (if it's anything
like modern controllers, it just plain doesn't do precomp). Totally
worthless for anything vaguely resembling reliable R/W work.
The FDC37C78 is still listed in SMSC's current production, but I"ll
agree that it's not easy to find on the spot market. It does have
selectable precompensation (port 3F4):
http://www.smsc.com/media/Downloads_Public/Data_Sheets/37c78.pdf
It even does FM uncomplainingly.
--Chuck
7 Sep
7 Sep
8:23 a.m.
On 07/09/10 04:21, Chuck Guzis wrote:
As long as the timer is either wide enough (e.g. 32
bit) or wraps to
0 from its maximum count, it really doesn't matter. AVRs definitely
do wrap and so do a number of other chips. ARM uses a 32-bit timer,
which is more than adequate for floppy use.
In that case, as long as you start the timer at zero and record when it
wraps, there should be no (significant) problem. You'll need to keep
track of last_counter_value modulo max_counter_value and subtract that
from each timer value, but it should work. Just a
little more effort in
the 'decode to delta' stage.
Also, if you use a 32bit counter, you'll need plenty of RAM to store the
counter values... The DiscFerret prototype stores around 100,000 sample
points for a 500kps MFM track (1.4MB PC HD floppy). Each SP is one byte
long on the DF; quadruple that for a 32-bit counter and you need about
400kbytes of RAM... not practical on most microcontrollers.
The FDC37C78 is still listed in SMSC's current
production, but I"ll
agree that it's not easy to find on the spot market. It does have
selectable precompensation (port 3F4):
http://www.smsc.com/media/Downloads_Public/Data_Sheets/37c78.pdf
Neat. Seems a lot of modern "all-in-one" style Super I/O controllers
have really poor data separators and precomp engines though. I've never
found a PC controller that could even read BBC Micro floppies (250kbps
FM 5.25in) without complaining.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
10:12 a.m.
On 7 Sep 2010 at 16:23, Philip Pemberton wrote:
In that case, as long as you start the timer at zero
and record when
it wraps, there should be no (significant) problem. You'll need to
keep track of last_counter_value modulo max_counter_value and subtract
that from each timer value, but it should work. Just a little more
effort in the 'decode to delta' stage.
The ARM allows for byte access, so you simply set the counter to zero
at the beginning of the sample sequence and store the low order 8
bits. You could keep the "last value" around in a register and
calculate and store the delta as part of the process and have cycles
to burn.
I found that an AVR Mega128 was more than up to the job of sampling
250Kpbs and 500kbps media at 16MHz, using the capture mode with a
timer run at 16MHz. The only place I used actual interrupt servicing
routines was for basic event timing (i.e. seek and head settle) and
index detection. The sample loop simply polled the "capture
complete" status. Rather than use Jens' high-order bit index status
in the sample output, I noted the leading edge of each index with a
00 sample--my own experience told me that the falling edge of index
could vary wildly from drive maker to drive maker.
The result worked amazingly well on the few samples I tossed at it,
but I didn't pose any "tough cases" to see how aliasing affected
recovery. I never investigated if it was good enough for writing,
however.
What I'm investingating currently is if a NXP ARM "thumb" uC can not
only sample but decode on the fly, at least to the extent of
recognizing sector ID headers, so that sector-mode operation is
possible, rather than track at a time.
Does your DF have that capability?
Neat. Seems a lot of modern "all-in-one"
style Super I/O controllers
have really poor data separators and precomp engines though. I've
never found a PC controller that could even read BBC Micro floppies
(250kbps FM 5.25in) without complaining.
I'd have to go back to my samples, but something is itching in the
back of my skull that the Beeb floppies weren't strictly 3740-
conforming. Oddball DAM or IDAM maybe?
--Chuck
6 Sep
6 Sep
12:05 p.m.
On 05/09/10 22:31, Jules Richardson wrote:
Maybe they were a little misleading though if they
gave the impression
that the software to do task x already existed (or if it did exist - but
only in the sense that someone somewhere had written it, but had no
plans to release it for everyone else to use). That would be rather sly
marketing, I think. Of course saying something like "these are the
features, you *could* do x, y and z with it" might be different. It's
all in the wording...
I hope I've not given anyone that impression with the DiscFerret...
In simple terms...
- As sold, a DiscFerret will read floppy discs into timing-format images.
- Write support is on the cards, I need to port it from the old
"FDRW1" proof of concept. For the hard-of-thinking, this means it's not
done yet :)
- It will read anything you feed to it in Timing mode. Anything
written by a NEC 765, WesternDigital 177x or 179x or clone in MFM mode
should also decode to sector data. Decoding of anything else will
require software to be written.
Documentation is on the TODO list -- including a full Theory of
Operation for the FPGA logic and microcontroller firmware, and a
Programmer's Guide which will explain how to talk to the baseline
firmware and make it do stuff, and how to do the same with DiscAPI.
I want a magic box that'll image MFM/RLL/ESDI hard drives and floppies
at transition level, so I can play with the data on the computer and do
data recovery, format analysis, preservation and disc copying.
At the moment, the biggest problem is that the %#$!ing Elektor PCB
Service just charged my card for 100 Euros, the payment went through and
the website now says "There was an unknown error with your payment!".
The 'contact us' link which is SUPPOSED to be there.... isn't. And email
doesn't work (apparently). So I have a pro-forma invoice, a Receipt
Number, and a website that insists I haven't paid when I couldn't
possibly have #2 without having paid first... Ho hum.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
7:28 p.m.
On 06/09/10 20:05, Philip Pemberton wrote:
At the moment, the biggest problem is that the %#$!ing
Elektor PCB
Service just charged my card for 100 Euros, the payment went through and
the website now says "There was an unknown error with your payment!".
The 'contact us' link which is SUPPOSED to be there.... isn't. And email
doesn't work (apparently). So I have a pro-forma invoice, a Receipt
Number, and a website that insists I haven't paid when I couldn't
possibly have #2 without having paid first... Ho hum.
... and it seems the error has fixed itself, because my board is now
showing as "in production"...
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
8 Sep
8 Sep
5:07 a.m.
In message <4C853B7A.8060102 at philpem.me.uk> you wrote:
At the moment, the biggest problem is that the %#$!ing
Elektor PCB
Service just charged my card for 100 Euros, the payment went through and
the website now says "There was an unknown error with your payment!".
The 'contact us' link which is SUPPOSED to be there.... isn't. And email
doesn't work (apparently). So I have a pro-forma invoice, a Receipt
Number, and a website that insists I haven't paid when I couldn't
possibly have #2 without having paid first... Ho hum.
Hi!
Why not using a professional company for making your PCB, where you can
ask, if everything is o.k. with the layout-data.
We do business with EPN (www.epn.de) since 1998 and are fully satisfied.
Axel Harten.
14 Sep
14 Sep
6:23 p.m.
On 08/09/10 13:07, Harten wrote:
Why not using a professional company for making your
PCB, where you can
ask, if everything is o.k. with the layout-data.
We do business with EPN (www.epn.de) since 1998 and are fully satisfied.
I'm probably going to have the full production run done through either
Eurocircuits, Gold Phoenix, or one of the UK manufacturers (Spirit
Circuits aka PCBSnap, Newbury Electronics aka PCBTrain, Photomechanical
Services, ...)
The other issue at the moment is WEEE and RoHS compliance. RoHS is
fairly easy (don't use SnPb solder, make sure parts are RoHS
compliant...) but I'm having a hell of a time figuring out what exactly
I need to do to appease the Gods of WEEE...
EMC compliance is another matter entirely, although I'm pretty sure the
two dozen or so decoupling capacitors (they cost less than a penny each,
so why not have one per Vcc line?) and the massive ground plane are
going to obliterate any chance this thing has of radiating anything...
Even if it does, the spiffy metal instrument case should provide
adequate shielding.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
4 Sep
4 Sep
6:46 a.m.
On 04/09/10 03:22, David Griffith wrote:
Yay! I'm glad you went ahead with this project.
The Catweasel has been
such a disappointment. Hopefully this will succeed where the Catweasel
failed.
Well, there's still a lot to do...
- Get some prototypes made up. I have all the parts I need (with the
possible exception of a few crystals I can buy with cash from the
Farnell trade counter) but I need to get a PCB or two made up.
Unfortunately I don't have the ?150 or so to pay for a prototype run,
and half the vias are under ICs, so homebrew is out of the question :(
- Port the FPGA HDL-code. Dead easy, just need to create a new pin
constraints file, then rebuild.
- Port the MCU firmware. Somewhat harder; the 18F85J50 has a newer,
faster (=better!) parallel bus port. Catch is, this port isn't 100%
backwards-compatible with the old 18F4550. So that means I need to
rewrite fpga_writereg() and fpga_readreg() (aka POKE and PEEK). Will
also need to put together a bootloader and an FPGA microcode loader.
- Add write support. Basically, implement the Disc Write State
Machine (a glorified microsequencer with a timer bolted on for good
measure).
- Documentation. DiscAPI and XDIFAPI are extensively commented,
magdecode is lightly commented, ferret (the tool that reads and writes
discs using the DF) isn't commented at all.
- Code. DiscAPI and Magdecode are covered by my university's
submissions policy (they were part of my final-year BSc project) -- I'm
trying to get a copyright release, but the guy in charge of this is
playing the Ostrich Game: "bury your head in the sand and hope it goes
away". No doubt I'll end up rewriting a lot of code...
... But other than that, everything's peachy :)
Thanks.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
14 Sep
14 Sep
7:09 p.m.
Hi guys -- it's nearly 3AM here, I'm about to fall asleep, and I figure
I should send an update... Here's the to-do list as it stands:
**Get some prototypes made up.**
I'm half way through sorting out my component boxes; I need to find a
few DiscFerret parts which appear to have scuttled off to join the
circus, but other than that, job's a good'un.
The first run of PCBs are due in today. I should hopefully have the PSU
section up and running within a couple of hours of the boards arriving,
and (all being well) a DiscFerret doing USB enumeration by midnight.
**Port the FPGA HDL-code.**
Done this. Perfect compile, first-time. There are a few timing issues
with the MFM sync-word detector, but a bit of logic optimisation and
PLL-elimination (read: recalculating the DPLL tap points for a different
clock frequency/data rate ratio) should fix those.
**Port the MCU firmware.**
I'm going to do a partial-rewrite on this. The original microcontroller
code is pure, unadulterated evil. It's commented, but it's still evil.
**Add write support.**
Still need to port this from the FD1. I want to get the hardware reading
discs before I add write support. It's an attempt to avoid Creeping
Featuritis (where features are added relentlessly, and none of them work
right).
**Documentation.**
I've got an artist working on a logo, found a nice font (URW Neustadt),
and rigged up some OpenOffice templates for the documentation. Just need
to write up the documentation!
**Code**
I'm thinking about doing a complete rewrite on DiscAPI and MfmDecode.
The original code was submitted as part of my university project, and
obtaining a suitable copyright release is proving to be difficult.
**Pre-orders**
I have a few beta-testers who will be receiving a prototype DiscFerret
once I have some built-and-tested units sorted out. Once I've heard back
from the Beta Team, I'll probably start taking
pre-orders of various forms:
- Bare PCB
- PCB with switch-mode PSU chip mounted (it's the only part that
can't be easily installed with a soldering iron)
- Kit of parts (SMPSU chip pre-mounted)
- Fully assembled PCB
- Fully assembled unit
Comments on which one of these you'd be most likely to buy would be
appreciated -- either reply to this message, or send a new message to
discferret at philpem.me.uk.
Thank-you and goodnight! :)
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
15 Sep
15 Sep
11:52 a.m.
Hi,
Congrats on the progress.
On Wed, Sep 15, 2010 at 4:09 AM, Philip Pemberton
<classiccmp at philpem.me.uk>wrote:
**Pre-orders**
I have a few beta-testers who will be receiving a prototype DiscFerret once
I have some built-and-tested units sorted out. Once I've heard back from the
Beta Team, I'll probably start taking pre-orders of various forms:
- Bare PCB
- PCB with switch-mode PSU chip mounted (it's the only part that can't be
easily installed with a soldering iron)
- Kit of parts (SMPSU chip pre-mounted)
- Fully assembled PCB
- Fully assembled unit
Comments on which one of these you'd be most likely to buy would be
appreciated -- either reply to this message, or send a new message to
discferret at philpem.me.uk.
It all depends on the price of course, but if it is in my I-can-afford-it
range, I will either buy a kit or a fully assembled PCB. I like soldering up
kits (if they aren't too much work).
--
Regards,
Torfinn Ingolfsen
5212
days inactive
5223
days old
20 comments
8 participants
participants (8)
-
cclist＠sydex.com -
classiccmp＠philpem.me.uk -
dgriffi＠cs.csubak.edu -
harten＠injectstar.de -
jules.richardson99＠gmail.com -
snhirsch＠gmail.com -
teoz＠neo.rr.com -
tingox＠gmail.com