Philip Pemberton wrote:
Have you ever actually used Java on anything less than
a 1GHz box?
Yes, constantly for over ten years :-)
When
my laptop steps down to 500MHz, Java apps become intolerably slow.
You know, it seems to depend largely on the VM. Sun have lost the plot in the
last few years and just kept on piling features in when they should have given
up and declared "this is Java" about five years ago. The older VMs scream
along very nicely, but I know the modern one I've got on the laptop is an
absolute dog :(
Admittedly it's nice because a lot of the data
processing algorithms are
already implemented and ready for use, but for some thing's it's just
too slow.
Generally it's very good providing you're not trying to create massive Swing
applications with it using scads of eye-candy. Unfortunately that's exactly
what a lot of people try and do first, and then it gets a bad rep for being slow.
Not to mention the amount of memory it hogs just for
doing
something simple like a "hello world" window.
I'd suggest there are far better languages for writing "Hello World" in ;-)
I was thinking
GTK+ :-)
So compile wxWidgets to use the GTK backend - I get my object-oriented
API (I've been spoiled by Swing), you get your cute little GTK widgets.
Win-win :)
That works. I know nothing about wxWidgets or GTK+, incidentally, other than
being aware that there is a Windows port of the latter :-)
If I have to have some form of cross-platform graphical UI it gets done in
Java (or a web browser via PHP), if it just needs a simple Linux text-mode UI
then it gets done in C, and if it needs to run solely on MS Windows it doesn't
get done at all :-)
USB?! USB?!
:-) Urgh... SCSI, please...
USB: Plug in, install drivers, play.
SCSI: Plug in, fiddle with terminators, play with cables, replace
cables, replace terminators, replace host adapter card, replace
terminators again, try with terminators on and off, try daisychaining in
various combinations, give up, go home.
I don't like SCSI much, can you tell?
:-) Oddly enough I've had exactly the opposite experience to you, and it's
been USB that's plagued with problems, whilst SCSI has Just Worked*.
* Except for whenever I go near a bit of NeXT hardware, where the SCSI bus
automagically seems to break if I so much as look at it funny.
External becomes internal, nice and easy. It's
much harder to do the
reverse, especially with PCI cards.
It's one of the major reasons I don't want a Catweasel, to be honest.
Quick question - does the write protect sensor on
floppy drives also
lock out the write circuitry, or does the drive depend on the controller
not trying to do silly things like writing to protected floppies?
I suspect that's open to interpretation by the drive manufacturer, to be honest.
ST-506 is coming in Version 2 :)
Hmmm. I'm not sure if the current implementation's quick enough
though... you probably need to be sampling at around 50MHz for ST506.
But I assume there are faster chips out there you can use?
I was joking
Well don't! :) Seriously, it's a project that could do with being done by
someone, and in theory it is just a big, fast floppy drive full 'o bits, so if
the interface can be run fast enough (and contain enough buffer memory) it's
possible it could be done.
Scavenging
from scrap I/O cards works well.
Only if you've got scrap I/O cards to scavenge from.
More than you can ever possibly need on your doorstep via your local Freecycle
list :-)
and I can't tell how to jumper it for 300RPM.
It's a YE Data YD-380B,
just on the offchance anyone has a jumper list knocking about...
I'll have a look...
[Out of
interest, I wonder if this gadget will be able to drive one of
those floppy tape units? I've got no idea how their protocol works...]
Might be able to. It'd be mostly a case of writing software, assuming
the data format is fairly standard MFM.
I'm really not sure. I don't know if those sorts of drives just looked like a
big floppy disk (and control was done purely via twiddling head select / step
/ direction), or whether they actually interpreted the data stream from the
FDC in order to carry out commands.
It's not even as high as low priority (!) but I was just curious...
Absolutely...
hence the need for having lots of drives connected at
once via an addressing scheme. It just feels a bit 'cleaner' to have
one drive per cable and have termination set on all drives, somehow.
But never mind, as the way you're doing it, it should still work in
that configuration anyway :)
So you think it'd be better to have TTL out of the I/O port, then have a
set of O/C buffers on the adapter cards, and have a separate O/C buffer
set for the PC FDD port? Hmm, the cost just keeps mounting...
Well I figure it's probably two or three 74xx series ICs, so it's not
expensive/complex. Certainly cheaper than having to build/buy more than one
card. I suppose it depends on typical application, but I suspect any serious
archive box is going to have several drives attached.
I think the main thing though is to have some form of addressing I/O brought
out on the board which can be under software control - then there's at least
the scope for doing this kind of thing. (and it sure beats having a separate
parallel port bodge or something to provide that :-)
I saw some
nice documentation about how M2FM worked *somewhere*. I'll
shout if I remember where it was now.
It's in the Intel Intellec disc controller manuals (on Bitsavers no
less), if this page is accurate:
<http://retrotechnology.com/herbs_stuff/drive.html>
Yeah, that was probably it actually. We've got quite a bit of Intellec stuff
at Bletchley.
cheers
J.
--
"What progress. It's almost as good as taping it... on tapes which self
destruct in seven days."
- Bill Bailey on the BBC's "watch again" service