AI’s Math Tricks Don’t Work for Scientific Computing - Low-precision number formats don’t suit many simulations

I didn't fully appreciate just how good the humble TMS9900 and its later derivative TMS99k were until we tried to implement the same realtime acquisition system on the notionally much faster 68k platform.

This could get interesting in embedded systems if the working register set pointer ever found itself pointing at ROM. In a noisy industrial environment a dead man's handle was needed to recover from such glitches (10kV flashovers were recoverable but the machine tended to latch up).

And graphics chips with dedicated sprite engines like TMS9918 made a lot of difference too. That was a nice chip in its day.

Even back then there were a few fairly good embedded compilers but there was always some very low level stuff that you couldn't avoid doing in assembler or worse as included hexadecimal magic byte constants that were included in the nefarious CODE( ) statement in Logitech's M2.

The thing the 68K had going for it was lots (8?) of second sources. First question out of my mouth when talking to a CPU vendor was to ascertain who their second sources were. No desire to get in bed with a sole source supplier and have your product held hostage to delivery delays.

Yes. Just change the WSP (to some other area you've previously set up to hold a new workspace).

With the 68K, you didn't have any way of knowing *if* a chunk of the processor state had been altered and needed preserving. You could hack the FPU trap to avoid capturing the state of the FPU if it hadn't been used since the last context switch (assuming you hooked it). But, no such hooks for the ~20 registers in the programmer's model.

Note that some processors recognized this and didn't prestack any state. Or, deliberately stacked a subset of state (like FIRQ). Some required moving individual registers to/from the stack, one per opcode. Others could do this in a single opcode (e.g., PUL xxx)

Actually, we used to exploit the fact that certain parts of the address space were R/O. Or, that a read and write of a single address "went different places".

With the Z80, INC (HL) was a preferred hack to check for delimiters. It had the pleasant side-effect of screwing over folks who were trying to copy the code, executing it out of R/W memory (to facilitate patching).

And, few folks understood that the Z80 (et al) had a 64K address space for I/O (most folks think it's just 256 addresses). So, you could leverage I/O cycles to write and read in the same cycle!

The 9918's problem (for video games) was that it only supported 16 sprites. Many of the games had dozens/scores of moving objects so the sprites' collision detection logic wasn't useful enough.

There were a lot of interesting designs available in the 70's and 80's as folks explored what was possible and useful. Even simple peripherals like counter-timers were "more clever" than their modern equivalents (though none as obscene as the 9513). It's as if the hardware folks have stopped thinking about how their mechanisms will be used and just put in "the obvious".

Yes, but that was usually easy to do (even before the "asm" pragma). Though the approach wasn't always portable.

Nowadays, it's usually not worth relying on ASM for much of anything as compilers can be directed to produce the object that you want in a more portable manner that is easier for others to follow. Even in ISRs. The idea of writing a VMM system in ASM is just folly, expecting to get every nit correct.

The downside of HLLs is folks are usually clueless as to the code that is being generated. Ask someone how deep his stack *needs* to be (ask him if he even knows how deep it *is*!) and watched the glazed look fill his eyes...

It had the MOVEM opcode, so you could stack all the registers with one instruction.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics