Peter Ehlert

An excellent article. Bill Gates himself posted a comment: https://www.pagetable.com/?p=43#comment-1033

The Commodore 128 was first in 1985. But there was also a CP/M cartridge for the C64 released in 1983[1], which I think was the first Commodore CP/M compatibility play. It is very disturbing (as an old C64 user) to see CP/M running on the classic blue/light-blue C64 display.... Of course the C64 version suffered from the additional problem over the C128 version that it only had 40 text columns. Lots of other issues with it too apparently. [1] https://commodore.international/2021/12/21/cp-m-for-the-commodore-64/ and https://www.pagetable.com/?p=1312

You can sort of divine them from how the undocumented instructions work. https://www.pagetable.com/?p=39 It more or less falls under true classic highz buses with multiple drivers. You have three options I can see 1) treat it as a spice simulation that aggressively optmizes to synthesizable logic most places other than the problem parts. 2) hand replace the problem parts with synthesizable logic sorta like how Nvidia replaces graphics shaders with had written replacements in their drivers 3) just throw the whole thing into a spice simulation

Indeed! Came here to say the same thing. That code [0] was via Nibble Magazine, which was pretty great back in the day. [0] https://www.pagetable.com/?p=64

I know about that one where the source was taken down. My favorite is Skype however where they used to use SYSENTER directly and read your BIOS using NTVDM: https://www.pagetable.com/?p=27 Not a bug in Skype, but still interesting: http://archives.miloush.net/michkap/archive/2007/11/21/6456609.html

I would recommend marking as a dupe of https://news.ycombinator.com/item?id=14872418 (feels a bit harsh) or pointing to http://www.pagetable.com/?p=39

They would overwrite the CHROUT vector used to show the "READY." text after loading. So when BASIC wanted to print the "R" it would call CHROUT, which was rerouted to your application's loader. More info is available at the excellent Pagetable blog [1]. [1] http://www.pagetable.com/?p=568

"Only legal opcodes were used in this demo" - Great! Some information on 'illegal' opcodes for the 6502 CPU: http://www.pagetable.com/?p=39 http://www.oxyron.de/html/opcodes02.html

My favorite example is from Terminator, blogged about here (not by me): http://www.pagetable.com/?p=64 When I first saw the movie I was with a friend who laughed out loud at that point and said "hey, that's 6502 assembler". I guess "I know UNIX" from Jurassic Park doesn't count.

There was an IE for UNIX back in the 1990s, which meant Solaris and HP-UX. The last version was IE5. http://en.wikipedia.org/wiki/Internet_Explorer_for_UNIX And before that, MicroSoft was best known for its BASIC implementation that wound up on a whole range of eight-bit microcomputers. https://en.wikipedia.org/wiki/Microsoft_BASIC The versions for 6502-based micros shared a codebase: http://www.pagetable.com/?p=46 And, in some versions, they had an easter egg hidden in the constants used to implement SIN: http://www.pagetable.com/?p=43

Also a great relevant read: How MOS 6502 Illegal Opcodes really work http://www.pagetable.com/?p=39 I just finished a 6502 emulator, I recommend doing it for everyone. Lots of fun and very interesting.

You may also like Michael Steil's awesome "Ultimate Commodore 64 Talk": http://www.pagetable.com/?p=54 Amazing technical overview of the C64, including the latest in demo effects, in 64 minutes.

Better yet, Bill Gates was a great hacker too, having written portions of Basic for several CPUs. I like how he shows up to comment on this pagetable post - I would like to believe it's really him, anyway, still with geeky interests... http://www.pagetable.com/?p=43

The video of the talk --- recommended! --- is at http://www.pagetable.com/?p=53.

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

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…

This reminded me of work to get the C64 to do 80 columns in software, using a 3x7 pixel grid (with one row and column used for spacing), some of which were part of commercial products. https://www.pagetable.com/?p=901 > Creating a 4×8 character set that is both readable and looks good is not easy. There has to be a one-pixel gap between characters, so characters can effectively only be 3 pixels wide. For characters like “M” and “N”, this is a challenge.

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.

Related https://github.com/mist64/cbmbasic From 2008 https://www.pagetable.com/?p=48

He went even farther, decapping the CPU and reverse engineering its entire workings to understand how each "undocumented" opcode functioned: https://www.pagetable.com/?p=517

a good essay on how they work https://www.pagetable.com/?p=39

That's exactly right. There's a really good article about it here: https://www.pagetable.com/?p=39

"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.

Ok, so the scanned version was indeed 8080 BASIC. However, the 6502 source has been available unofficially since at least 2015. https://www.pagetable.com/?p=774 Nice to see it out there under the MIT license, certainly. This makes it legal to actually use in many scenarios where it wouldn't be legal to use it previously.

There's the "WAIT 6502,X" Easter egg[0]! Lines 6530 - 6539 are the "MICROSOFT!" that gets printed. Line 4914 is the code to check the address passed to WAIT and, if correct, print the "MICROSOFT!". It really is inconspicuous. A source licensee definitely wouldn't find it by quickly perusing. [0] https://www.pagetable.com/?p=43

Fun fact, GW-BASIC was a descendant of the original Altair BASIC. The "Translation created 10-Feb-83" headers on each source file refer to tooling Microsoft had that automatically translated the 8080 assembly to 8086 (it shouldn't be taken as a build date since they were manually modified after that point). Besides GW-BASIC, source code for the 6502 and 6809 rewrites of Microsoft BASIC were available up to this point (see https://www.pagetable.com/?p=774 and https://github.com/davidlinsley/DragonBasic) but I believe this is the first public release of the original 8080 BASIC code.

A bunch of documentation was posted here, although I’m not sure the links still work (might need to go through archive.org) https://www.pagetable.com/?p=211

There's a fine tradition of this, especially at early Microsoft. It's documented here: https://www.pagetable.com/?p=43 , and includes hidden messages that Gates allegedly added himself to prove that code the company licensed could still be traced back to him. (I hit the Ric Weiland one mentioned on my first computer, the Ohio Superboard II - https://www.pagetable.com/?p=43#:~:text=the%201977/1978-,Ohio%20Superb… ). This was all in the era of Gates' Open Letter to Hobbyists[1], when "Micro-Soft" was licensing their code to companies, perhaps because direct sales to hobbyists didn't work out. [1] https://en.wikipedia.org/wiki/An_Open_Letter_to_Hobbyists