What is the “two-drive trick” that can read Amiga disks on a PC?

I respectfully disagree. Arduino can be fully understood from the ground up: from voltage-levels, to the clock, to the simple assembly language (and compiler). The AtMega328p is an incredibly simple design... rugged enough to withstand a variety of voltages (1.8V to 5V inputs), and even able to be used on a breadboard.

Even ignoring Arduino, the "toy computers" that people make today are Minecraft Redstone, Factorio circuits, and Dwarf Fortress river-contraptions. Complete computer architectures built up from the fundamentals for the video-game computer scientists of the future.

People play games and use toys because its possible to understand everything.

EDIT: Oh, and the TI-83 calculator. Overpriced obsolete garbage of a calculator, but since its the "standard" calculator of High School, plenty of children will get the opportunity to really learn that machine if they so choose. There's something to be said about the TI-83 community keeping that Z80 chip so well documented and alive...

I got a chance to ask Woz a question at a speaking engagement. I asked him what he thought about the fact that I don't own my IOS device like I owned my Apple II computers-- that I can't tinker with the software and hardware and do what I please with it. His reply, which I don't recall verbatim, was to the effect of: "We have to have locked-down devices today so we can have security."

It made me very, very sad.

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

> or create a byte-array of some sort that gets translated, which while faster, still isn't fast enough.

Except, of course, about 2-3 orders of magnitude faster than the best SVGA era cards were.

I mean, you got many GB/s bandwidth now. Yes, that Tseng Labs ET4000 was amazing, with 7 MB/s over ISA, beating most (all?) other cards I bothered to try back then.

Or some basic (but fast) later PCI card like S3 Trio 64+ 50 MB/s (IIRC).

PCIe 3.0 can do up to 16 GB/s over 16 lanes. Even if it were 7 GB/s in practice, we're still talking about 1000x improvement compared to the best ISA SVGA card. You have also bus mastering and ability to map buffers that way that GPU itself has access to the data.

Setting one pixel might be slow. But who cares when you can just have your "framebuffer" in system RAM and "MOV" away!

It's pretty fast to work with a pixel framebuffer and just blit it to the screen with GDI, DirectX, OpenGL, or something. You might not be able to do 1920x1200 at 60fps but you can do something smaller and stretch it to fullscreen. I wrote a minimal framebuffer library for doing this, because I just wanted to work with pixels: https://github.com/samizzo/pixie

I used it for the Windows port of an MS-DOS demo I wrote recently: https://www.pouet.net/prod.php?which=83648

You could try old systems. The GameBoy Advance is reasonably well-documented[0] (enough for me to write a simple game for it over the summer as my first real C program), and a hacked 3DS[1] can run the game on real GameBoy hardware through Virtual Console injection.

[0] http://coranac.com/tonc/text/ [1] reddit.com/r/3dshacks

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

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

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.

The trick works by using the double sampling rate to inspect the normal data rate disk surface. When the disk surface already has a double data rate, the drive doesn't have a quadruple data rate mode to be able to read it.