
What is the “two-drive trick” that can read Amiga disks on a PC? - _Microft
https://retrocomputing.stackexchange.com/questions/12747/what-is-the-two-drive-trick-that-can-read-amiga-disks-on-a-pc
======
_Microft
Maybe I am a bit sentimental here but I found the low-level tinkering I did
with computers during school much more interesting than the high-level things
I learned to do later. Things like toggling the keyboards LEDs for the very
first time felt just great. That reminds me how easy (QBasic!) it was to get
started with it. I think it was the lack of abstraction and the verbosity and
_' speaking'_ names of some statements ( _select case_ , _goto_ ) that made it
so accessible for someone with no teacher and without any prior experience
with programming. Even _goto_ s themselves might have helped on that journey
as they made the control flow much more comprehensible. Stuff happens in your
program and _IF_ you want it to happen again _THEN_ _GOTO_ the beginning. That
it worked out of the box and didn't require any setup might have contributed
as well.

~~~
Sohcahtoa82
I miss having low-level access to video memory.

I've kinda wanted to experiment with graphics in a way that would require me
to calculate individual pixels, but AFAIK, unless you use pixel shaders, it is
ungodly slow.

Used to be that you could color a pixel blue with a single MOV instruction.
Now, you either use a graphics API that has a SetPixel function (Which is
incredibly slow for drawing full-screen graphics), or create a byte-array of
some sort that gets translated, which while faster, still isn't fast enough.

~~~
mntmoss
You have ample room to define the hardware you want to see, though. [0]
Setting bytes in a buffer isn't some ultimate graphics abstraction: it's just
one way to express it at a low level, and only capable of drawing anything of
interest in the sense that a Turing Machine can compute anything that can be
expressed digitally. You're gonna crave higher level concepts really quickly.
And going higher level does come with its own limits, but that's always been
the case. Every sufficiently complex production graphics renderer will
eventually develop some kind of hybrid approach to the data representation
while achieving the necessary flexibility: Simply define line segment drawing,
and boom, suddenly you have a vector-to-raster pipeline. Or, maybe you have a
sprite all laid out perfectly for fast memory copies. But then you have to
clip it against the screen bounds, add a mask so that it can overdraw, and so
on...and so you end up carrying geometry and color data around too. And if you
desire to do something fancy like scale and rotate it, you will probably
define it not in terms of bytes but in terms of linear algebra, so now you
have a requirement for some matrix math.

And the only way in which we're more limited is when we start talking about
distributing the work, creating products. Then we start saying, "well, that
API doesn't let me dip into the hardware to create the abstraction I need."
But that's because we moved the goalposts from "it can run on a computer" to
"it can run on many people's computers, in many different contexts." And back
in the day that really was never a guaranteed thing. There were stark
differences between platforms, and many ports amounted to remakes.

So, then, does it matter? Does "minimalism" in programming even functionally
exist, given our unsatiable appetite for dependencies?

[0] [https://prog21.dadgum.com/66.html](https://prog21.dadgum.com/66.html)

------
LIV2
That's a really cool hack, I wonder if it would work on 82077AA or
compatibles? I might give that a try later this month after I resurrect my
A500

Presumably it should be possible to create a simple drive emulator to spit out
that sector/track header without needing an actual disk. Not sure if I'm smart
enough to tackle that but it's worth a try!

I'm already working on a 6502 System at the moment that has an 82077AA
compatible FDC and can read PC Formatted floppies so it should be relatively
easy for me to tool around with this hack.

~~~
jacobush
There are now quite a few floppy emulators of all kinds of flavors.

One:
[https://github.com/keirf/FlashFloppy](https://github.com/keirf/FlashFloppy)

~~~
LIV2
Yeah, I've got a gotek for my A500 but I like to take on stupid useless
projects, like a uC that does nothing except spit out sector headers lol

------
kstenerud
I used this trick to back up my 5000 disk Amiga collection in the 90s. Bought
a few extra floppy drives for $10 each at the local flea market :)

~~~
rasz
According to the writeup this trick was invented in December 1999, was it
known before?

~~~
kstenerud
It was definitely before 1997, because that's when I moved to Japan.

------
mnw21cam
Very clever. Presumably this would be unable to read high density (1.76MB)
Amiga disks.

~~~
rasz
Commodore never upgraded Paula chip (knowing that company they probably
immediately fired designer and didnt keep documentation to the chip), every
model got the same 1985 state of the art Double Density floppy controller all
the way to 1994 bankruptcy. As LIV2 already mentioned even their top of the
line $3.5k A4000 Workstation shipped with gimped Floppy subsystem.

~~~
mnw21cam
The floppy drive could read/write high density 1.76MB disks. I know, I had
one. You're right that the Paula chip wasn't upgraded to handle double the
data rate from the drive. The solution instead was that the disk span at half
the speed.

------
Pete_D
Suppose someone still had a box or two of old Amiga floppies but no old
hardware - what is the easiest way in 2019 to turn them into .adfs?

~~~
tyingq
Not the easiest way, but interesting.
[http://amiga.robsmithdev.co.uk/history](http://amiga.robsmithdev.co.uk/history)

------
nullc
Life, Uh, Finds a Way.gif

