I think I can do a little bit better; maybe 10% faster.

https://www.theexplodingwhale.com/evidence/resources/dave-ba...

https://github.com/historicalsource/asteroids

Though, to be sure, most often TRS-80 is used to refer to the Model 1, 3, 4 line. But plenty of people will think of the Color Computer when they hear TRS-80. Or, possibly, their line of rebranded pocket and laptop computers like the TRS-80 Model 100 or TRS-80 Pocket Computer 1.

The Model 1 version does require a hardware mod to get access to vsync.

I wrote those programs and couldn't have done it without something of a virtuous circle of trying stuff on the real hardware and then improving the emulator to more accurately model the hardware and so on.

To cite a reference, the first issue of "80 Microcomputing", a magazine dedicated to the TRS-80 line of computers. See the second paragraph of Wayne Green's editorial "80 Remarks" on page 8:

https://archive.org/details/80-microcomputing-magazine-1980-...

You can see this with today's word by guessing MOTTO. The leftmost T will be yellow and the rightmost will be black.

Similarly, if you guess TENET the initial T is black but the final T is green.

Today's word is ZBVFG (rot13).

   PMESS  LD   A,(HL)     ; get character from message
          INC  HL         ; move message pointer to next character
          CP   10         ; newline?
          RET  Z          ; return if so
          OR   A          ; zero?
          RET  Z          ; done if so
          CALL PCHAR      ; print character
          JP   PMESS      ; keep looping

          CP   10
          JP   Z,DONE     ; 10 cycles, jump taken or not
          ...
          JP   PMESS
   DONE:  RET             ; 10 cycles, BTW

Incidentally, the Z-80 also has relative branches (JR) that differ in execution time whether they are taken or not. The branch offset is a single byte so JR is only 2 bytes compared to JP's 3. A JR is 7 cycles if not taken, 12 otherwise. Again, we can treat it as a hard-coded branch prediction that predicts the branch is not taken. If space or distance to target is not a problem, a JR is faster if taken less than 60% of the time.

The 6502 has only an 8 bit stack pointer which points into page 1 only (addresses 0x100 .. 0x1FF).

https://www.youtube.com/watch?v=r5g9AglBmSI

Usually out of pride or the sunk cost fallacy (or something like it) I'll convince myself there was no other way the problem was going to be solved. Either way the next time around I spend just a little bit longer trying to think of an easy way out.

It did serve as a back-end search for Yahoo! though it never could keep up with the full query volume. It was lambasted by the creators of Google for experimenting with putting clearly-marked ads in search results. That transgression looks hilariously quaint to modern eyes.

https://www.referenceforbusiness.com/history2/72/Open-Text-C...

Just don't bother with these as they've already been done: https://www.dropbox.com/sh/yqpc3bglatpmpvl/AACA2CXFv1XeA1ZmL...

The TMS34010 was something like a CPU and 2D graphics processor combined. It has the ability to change its word size from anywhere between 1 and 32 bits with data addressable on bit boundaries. It's wild.

https://en.wikipedia.org/wiki/TMS34010

Like many games at the time the code in the ROMs had tamper protection. The basic idea is to detect if the ROM has been altered and if so assume it is a pirated copy and do something to cause the game to fail. Pirates could still make exact copies but they'd have to retain copyright notices and trademarks which makes them more vulnerable to detection and prosecution.

At the last minute Dave changed the position of some logos on screen but forgot to update the copy protection. When an illegal copy was detected the game would use some of the digits of the score obtained at the end of the game to zap bytes in memory if the overall score itself was within some range. This kind of random scrambling that only happens semi-randomly is better than copy protection that triggers deterministically. Imagine if the game did a checksum of its ROM and immediately said "Illegal Copy Detected - Program Halted". It would make it easier to find the copy protection routines and disable them.

So the first version that shipped thought it was an illegal copy and triggered the random scrambling. It so happens that sometimes the random scrambling would result in giving the player 40 credits.

There were other effects which players discovered and are listed here: https://forums.arcade-museum.com/archive/index.php/t-79058.h...

Mostly it was applying higher-resolution tiles and sprites but some had particle effects added. For instance, some exhaust smoke on the cars in Frogger.

My favorite was Gyruss which is somewhat like Space Invaders of Galaxian but with a 3rd person view from behind the player's ship so you see enemies come toward you in pseudo-3D. We found that the game internally used polar coordinates and had a fair bit of code that converted those 2D and chose the right sized sprites. Replaced all that with 3D models rendered at the same spot in space.

I view these techniques along a continuum where you're essentially changing the porting layer. An emulation puts that layer at the hardware. A hybrid approach pushes it some ways into the game. A source code port is above the binary but some ways into the code. A remake is at the "game design" level.