3 ms·

>Also yes the 68k was clearly a dog when it came to interrupt responsiveness and made no sense in home computers or video games, at least not until the '020. I

by snvzz 2y ago

>Also yes the 68k was clearly a dog when it came to interrupt responsiveness and made no sense in home computers or video games, at least not until the '020. In what world? The interrupts were very fast, taking just a few cycles, and the behavior was deterministic. This is why they were popular in realtime applications, and remained so for decades. Back in the day, they were famously used in e.g. the Eurofighter Typhoon.

tom_ 2y ago
The worst case interrupt latency on the original 68000 is pretty terrible? The instructions take ages and the interrupt handling mechanism adds additional delays. I'm sure the 68020 was better.
- snvzz 2y ago
  >The worst case interrupt latency on the original 68000 is pretty terrible? It has a fixed cost of 44 cycles. Is this somehow bad? I would call it extremely tight. edit: 44 cycles... after the previous instruction finishes. Some instructions (infamously slow division, and many-reg movem) can be slow. Worst case is what matters for realtime, but it is still under 400 cycles.
  - cmrdporcupine 2y ago
    In home computers and video games? Holy crap ... compare that to the 6502. Maximum 13 cycles, including the execution of the instruction that initiated it, and the return from the interrupt... And yes, obviously that's easy when you only have 3 registers ... But this has a serious real world effect for things like video games.
    - snvzz 2y ago
      >But this has a serious real world effect for things like video games. At 1MHz, sure.
      - cmrdporcupine 2y ago
        Well, sure ... and also plaid a part in making an 8mhz Atari ST feel more sluggish than a 1mhz C64 in some things. Obviously in throughput, a different story
        snvzz 2y ago
        Atari ST (68k at 8MHz) had other issues that made it sluggish. It is no Amiga. In most scenarios, most interrupts aren't going to interrupt divisions, as most instructions aren't over 16 cycles[0], thus most interrupts will not be much longer than 44 cycles. In microseconds, a non-issue for a microcomputer. Realtime programmers of the time had predictable behavior, and could simply avoid using the specially long instructions (movem and div) altogether if they needed to bound latency below the upper limit. Performance isn't as important as meeting hard deadlines. 0. https://wiki.neogeodev.org/index.php?title=68k_instructions_timings https://wiki.neogeodev.org/index.php?title=68k_instructions_...

by snvzz 2y ago

tom_ 2y ago

The worst case interrupt latency on the original 68000 is pretty terrible? The instructions take ages and the interrupt handling mechanism adds additional delays. I'm sure the 68020 was better.

snvzz 2y ago
>The worst case interrupt latency on the original 68000 is pretty terrible? It has a fixed cost of 44 cycles. Is this somehow bad? I would call it extremely tight. edit: 44 cycles... after the previous instruction finishes. Some instructions (infamously slow division, and many-reg movem) can be slow. Worst case is what matters for realtime, but it is still under 400 cycles.
- cmrdporcupine 2y ago
  In home computers and video games? Holy crap ... compare that to the 6502. Maximum 13 cycles, including the execution of the instruction that initiated it, and the return from the interrupt... And yes, obviously that's easy when you only have 3 registers ... But this has a serious real world effect for things like video games.
  - snvzz 2y ago
    >But this has a serious real world effect for things like video games. At 1MHz, sure.
    - cmrdporcupine 2y ago
      Well, sure ... and also plaid a part in making an 8mhz Atari ST feel more sluggish than a 1mhz C64 in some things. Obviously in throughput, a different story
      - snvzz 2y ago
        Atari ST (68k at 8MHz) had other issues that made it sluggish. It is no Amiga. In most scenarios, most interrupts aren't going to interrupt divisions, as most instructions aren't over 16 cycles[0], thus most interrupts will not be much longer than 44 cycles. In microseconds, a non-issue for a microcomputer. Realtime programmers of the time had predictable behavior, and could simply avoid using the specially long instructions (movem and div) altogether if they needed to bound latency below the upper limit. Performance isn't as important as meeting hard deadlines. 0. https://wiki.neogeodev.org/index.php?title=68k_instructions_timings https://wiki.neogeodev.org/index.php?title=68k_instructions_...