Long ago I wrote my own really incomplete vi subset for the C64 that I really should dust off. But there's a more polished vi clone for 6502 machines, including the C64, Apple II and Atari: https://vi65.sourceforge.net/

Zaccaria pinballs I think used it pretty heavily as well. Again, no clear explanation there either.

I've got a TurboExpress. Recapped, it's a great little handheld. Screen is adequate for the era (though I've seen upgrades). My favourite 6502-based handheld is still the Atari Lynx, but this is close.

I have a lynx II, and it is a brick (huge! heavy!).

I regularly wipe my stethoscope, but I have never sterilized it. I doubt many would survive an autoclave.

I've actually found them pretty terrible. I can't hear subtle findings at all with those. My usual stethoscope is an older-model Littman Cardiology III with stiff rubber and a dual pediatric-adult head. I've had it for over 25 years.

I guess it's different strokes, because I can definitely hear subtle sounds much easier with them. In fact normal sounds sound like it is going to blow out my ears. The only issue I have is consistency; it's difficult to gauge how much something has changed over time with different stethoscopes, especially pulmonary edema and wheezing.

Yes. None of the 603 series, including the 603e, was intended for multiprocessing, so the same hacks were required.

Top-quality passive-aggressive FAQ.

Unfortunately, 6502 can't XOR the accumulator with itself. I don't recall if the Z80 can, and loading an immediate 0 would be most efficient on those anyway.

XOR A absolutely works on Z80 and it's of course faster and shorter than loading a zero value with LD A,0. LD A,0 is encoded to 2 bytes while XOR A is encoded as a single opcode. XOR A has the additional benefit to also clear all the flags to 0. Sub A will clear the accumulator, but it will always set the N flag on Z80.

Yeah, the article seems to have missed the likely biggest reason that this is the popular x86 idiom - that it was already the popular 8080/Z80 idiom from the CP/M era, and there's a direct line (and a bunch of early 8086 DOS applications were mechanically translated assembly code, so while they are "different" architectures they're still solidly related.)

Ah, thanks, I couldn't recall off the top of my head.

should set Z too

You're absolutely right, I stand corrected.

The 6502 gets by doing immediate load: 2 clock cycles, 2 bytes (frequently followed by single byte register transfer instruction). Out of curiosity I did a quick scan of the MOS 1.20 rom of the BBC micro:

  LDY #0 (a0 00): 38 hits
  LDX #0 (a2 00): 28 hits
  LDA #0 (a9 00): 48 hits

Are you sure you're not an LLM? There is no way anybody writing 6502 would do anything else, because there's no other way to do it.

(You can squeeze in a cheeky Txx instruction afterwards to get a 2-or-more-for-1, if that would be what you need - but this only saves bytes. Every instruction on the 6502 takes 2+ cycles! You could have done repeated immediate loads. The cycle count would be the same and the code would be more general.)

> Are you sure you're not an LLM?

Hard to tell, but I don't think so ;-)

I suppose using Txx instructions rather than LDx is more of an idiom than intended to conserve space. Also, could an LDx #0 potentially be 3 cycles in the edge case where the PC crosses a page boundary? (I'm probably confused? Red herring?)

I don't know how the 6502's PC increment actually worked, but it was an exception to the general rule of page crossings (or the possibility thereof) incurring a penalty, or, as was also sometimes the case, just ignored entirely. (One big advantage of the latter approach: doing nothing does take 0 cycles.)

The full 16 bits would be incremented after each instruction byte fetched, and it didn't cost any extra if there was a carry out of the MSB.

The Z80 can do either LD A,0 or SUB A or XOR A, but the LD is slower due to the extra memory cycle to load the second byte of the instruction.

PowerPC: "r0 occasionally" (with certain instructions like addi, though this might be better considered an edge case of encoding)

If you're running this in VICE, run it under the SuperCPU with warp mode on.

That's a good idea because, although I love this, 1 minute per token is absolutely savage. Whereas if you can juice the performance you're into semi-credible Jar Jar Binks simulator territory.

It does also make me wonder what you could do with somewhat more powerful retro hardware. I'd love to see what a transformer running on a PSX or an N64 could do.