Peter Ehlert

Sorry, but best estimates of actual Commodore 64 sales are roughly 12.5 million, not 22 million. Still, there's no doubt that they handily outsold Apple II's.

https://www.pagetable.com/?p=547 (includes some neat serial number analysis)

Then why did the C64 sell 22 million units and
the Apple 2 only sold 5-6 million if consumers
had a bad impression of it.

This is bad-faith arguing on your part; it's beneath HN. I clearly didn't say they had a "bad" impression of it. I typed something a lot more nuanced about the different impression folks had regarding the two machines. Feel free to agree or disagree with the points I actually made, but there's no need to make up words and put them into my mouth.

I said it was viewed as a less serious computer; more of a games machine.

I can think of a few reasons for this, in addition to the ones I've named, such as being sold in literal toy stores. Do you think perhaps that influenced peoples' perceptions?

And pretty much everything else. Seriously, in college,
everyone in engineering used TeX. I used TeX on my Amiga.
It produced superior output for math and engineering papers
compared to the best you could achieve on a Mac with WYSIWYG.

Yeah, no doubt. Again, and I'm not sure I can state this explicitly enough given your posting spree here, but I'm not disputing that the C64/128 and particularly the Amiga were better at so many things.

However, the initial simplistic assertion that "[Apple] made…

Indeed, you hit the nail on the head. Or more to the point, on the infinitely thin edges between the nailheads.

The first time I saw this explained clearly was in the original Inside Macintosh, describing the QuickDraw coordinate plane. Some excerpts (with emphasis added to a few key concepts):

# # #

The Coordinate Plane

All information about location or movement is given to QuickDraw in terms of coordinates on a plane. The coordinate plane is a two-dimensional grid, as illustrated in Figure 2.

Note the following features of the QuickDraw coordinate plane:

• All grid coordinates are integers (in the range -32767 to 32767).

• All grid lines are infinitely thin.

These concepts are important. First, they mean that the QuickDraw plane is finite, not infinite (although it's very large). Second, they mean that all elements represented on the coordinate plane are mathematically pure. Mathematical calculations using integer arithmetic will produce intuitively correct results. If you keep in mind that grid lines are infinitely thin, you'll never have "endpoint paranoia"—the confusion that results from not knowing whether that last dot is included in the line.

Points

There are 4,294,836,224 unique points on the coordinate plane. Each point is at the intersection of a horizontal grid line and a vertical grid line. As the grid lines are infinitely thin, so a point is infinitely small.

Figure 3 shows the relationship between points, grid lines, and. pixels, the physical dots…

What are you aiming to reverse-engineer? Applications written in C/C++? Java/.NET? Aged firmware (8/16 bit asm)? ARM code?

I have some experience with the C/C++ part, so I'll try to answer that. Though this is more of a "what to learn in what order" post than a "how to learn it" one. Sorry, I'm mostly self-taught so can't really recommend exhaustive resources.

0: Intel's manuals are great, but mind that they're a reference, not beginner's books. Also, Intel used to give away dead tree versions of their manuals for free, unfortunately I don't think they do that anymore.

1: I don't think you need to learn all the ins and outs of assembly at first - knowing the basic flow control and math/logic operations will be enough. Don't worry about interrupts, descriptor tables, and other magic yet.

2: Once you learn the basics, practice: try to write simple programs in C and step through them in an IDE while looking at the disassembly view. Add inline assembly and practice writing it too.

3: After that, you'll probably need to learn how C++ constructs get translated to assembly code, which is a really large topic. Stanley Lippman's "C++ Object Model" covers quite a lot of it by showing how C++ gets transformed into C-like code, which you should already be familiar with. Mind that each compiler does some things differently than the others, so you should look at at least G++ and MSVC++.

When you get here, it's a good idea to browse around blogs like http://www.nynaeve.net/ and…

I think this is a case where a picture is worth a thousand words. This excellent article "Visualizing Commodore 1541 Disk Contents" [1] by Michael Steil about the Commodore 64 disk format, includes visualizations of the magnetic flux as stored on disk.

This bit is particularly relevant: https://www.pagetable.com/docs/visualize_1541/sector.png See the solid bit at the end of the sector, just before the next header? You could squeeze a few more bytes in there, but if the drive motor is just slightly too fast, it'll overwrite the next sector. That's why there's a gap, tolerance for timing variation.

Most floppy drive technologies wrote blindly, guessing where they were on the disk based on timing estimates since the controller last saw a sector header. This is also why disks needed to be "formatted". Not just in the sense of writing the file system data structures, but writing out all the sector headers. This had to be done all at once with the same drive, due to those small timing variations.

[1] https://www.pagetable.com/?p=1070

Very cool!

I did something related in the past: https://github.com/RussellSprouts/6502-enumerator. It uses C++ templates to share an emulator implementation between z3-powered symbolic execution and actual execution. It was meant to find equivalence between random instruction sequences for peephole optimization, rather than optimizing a specific input sequence.

Shadow instructions are very interesting and cursed. I've seen them used in very limited circumstances for NOP-slides for timing code: https://www.pagetable.com/?p=669. It would be fun to see it applied in otherwise normal code. My enumerator wouldn't support this -- it didn't execute actual 6502 instructions from bytes -- it had its own internal representation for `the first arbitrary absolute pointer` or `the second arbitrary immediate constant`. These would either be initialized with random concrete values or z3 variables.

"Recently revealed" is more like a confirmation of what I had read many years before; and furthermore, that Intel's 64-bit x86 would've been more backwards-compatible and better-fitting than AMD64, which looks extremely inelegant in contrast, with several stupid missteps like https://www.pagetable.com/?p=1216 (the comment near the bottom is very interesting.)

If you look at the 286's 16-bit protected mode and then the 386's 32-bit extensions, they fit neatly into the "gaps" in the former; there are some similar gaps in the latter, which look like they had a future extension in mind. Perhaps that consideration was already there in the 80s when the 386 was being designed, but as usual, management got in the way.