5 ms·

Nice work, congrats! I think the most surprising thing to me is the lack of interrupts. If you read this, jstanley: did you struggle much with that decision? I

Nice work, congrats! I think the most surprising thing to me is the lack of interrupts. If you read this, jstanley: did you struggle much with that decision? I think of interrupts as nearly universally available on 8-bit micros, much less 16, but I have also wondered before how important they really were for what those machines ended up being used for. The (S)NES polled their controllers' shift registers in a really inefficient way, but it turned out fine. On the other hand, though, the vertical blank interrupt was pretty critical to their software and, of course, it became extremely common for NES cartridges to add extra chips to raise interrupts on particular horizontal scanlines. But, aside from neat graphical tricks, maybe interrupts just weren't all that important?

tenebrisalietum 5y ago
The Atari 2600 doesn't use IRQs or NMIs. You have to sync with the frame by setting a timer, making sure your code doesn't run over it, and spinlocking on it until it expires. However, the CPU can tell the video chip to make the CPU halt until the beginning of the next scanline though. That's the only platform I know of that's anything like interruptless.
rzzzt 5y ago
There is a neat story told by Bil Herd about the C128's VDC video chip: https://youtu.be/wzMsgnnDIRE?t=597 https://youtu.be/wzMsgnnDIRE?t=597 > It turns out it didn't have an interrupt when you're done. And when I > figured out, well, the 6845 has got an interrupt, why don't you? I asked > the designer, he said "Well, you can simply look at a register" [...] From > then on, we had this running joke where nobody would wait for the phone to > ring, we just all kept checking our phones whenever this guy was around [...]
retrac 5y ago
> nearly universally available on 8-bit micros, much less 16, but I have also wondered before how important they really were for what those machines ended up being used for Usually available, yes. But not all that widely used by those systems. The stock Apple II for example, has nothing in it that can even generate an interrupt. You'd have to install an expansion card. The standard serial cards can generate an interrupt upon character receipt for example, but they were usually programmed with polled IO anyway. Later with network cards and hard disks, you do see some use of interrupts. > On the other hand, though, the vertical blank interrupt was pretty critical to their software The Atari 2600 had no hardware interrupt support at all. You could tell the graphics IC to sleep the CPU until the next scanline. You'd turn vblank on, generate 3 lines of vblank, then turn vblank off. You'd be lined up with vblank from that point if you counted carefully. On an in-order-execution processor, most things can in principle be translated into periodic polling and cycle counting. But it involves some extraordinarily painful coding. A timer and an interrupt are quite a relief when you're doing something time-sensitive.
- bogomipz 5y ago
  >"The stock Apple II for example, has nothing in it that can even generate an interrupt." Sorry if this is a naive question but how did the keyboard on those work without interrupts?
  - tyingq 5y ago
    There's a good comment from an older discussion here on that: https://news.ycombinator.com/item?id=20404825 https://news.ycombinator.com/item?id=20404825
    - bogomipz 5y ago
      Ah this is fascinating. Thanks for the link. Cheers!
    - stavros 5y ago
      Oh wow, whose excellent idea was it to add a key that hard-reset the CPU right above the return key?
userbinator 5y ago
That surprised me too. The very awkward implementation of interrupts was also one of the things that held back the popularity of the Intel 8008.
jstanley 5y ago
The reason I didn't implement interrupts is that I couldn't understand how to do it. It would be better with interrupts, but only by a little bit. The times I really feel the lack of interrupts are: - the text editor sometimes takes a long time to redraw the screen after reading input, and can drop characters if you type too fast because it isn't ready to poll for another character yet - if a program is stuck in an infinite loop and not doing any system calls, you can't kill it with ^C because the kernel never gets to find out that you typed ^C Those problems would go away if the arrival of a character on the serial port triggered an interrupt which caused the kernel to grab the character from the UART and stick it in a buffer, but I'm not sure the increase in hardware complexity is worth it.
- R0b0t1 5y ago
  It's worth it. I played with Propeller chips a while back. They have multiple cores and a shared memory but no interrupts. They can work, but you dedicate an entire CPU (expensive!) to a task, usually. The scant times you don't need to is because you poured time into a more difficult cooperative multitasking solution that isn't flexible. You don't need to implement a nested vectored interrupt controller. Even just a timer/counter with overflow interrupt would solve your current issues with lockup by allowing you to implement preemptive multitasking. Once you do that it would be easy-ish to extend to the serial controller. Basically, on interrupt flag = 1, 1. Disable further interrupts (no nesting). This makes things easier to implement. 2. Save register state. For speed a special set of shadow registers can be used, or you can put register state on the stack. 3. Jump to interrupt routine code start. 4. Let interrupt handler run, clear interrupt flag, then return. In the simplest case an input flag simply causes a CALL (push pc, jump to address). In that case the interrupt handler needs to know to save state. You can test flags between instructions to see if you need to inject the push/jump.

tenebrisalietum 5y ago

The Atari 2600 doesn't use IRQs or NMIs. You have to sync with the frame by setting a timer, making sure your code doesn't run over it, and spinlocking on it until it expires. However, the CPU can tell the video chip to make the CPU halt until the beginning of the next scanline though. That's the only platform I know of that's anything like interruptless.

rzzzt 5y ago

There is a neat story told by Bil Herd about the C128's VDC video chip: https://youtu.be/wzMsgnnDIRE?t=597 https://youtu.be/wzMsgnnDIRE?t=597 > It turns out it didn't have an interrupt when you're done. And when I > figured out, well, the 6845 has got an interrupt, why don't you? I asked > the designer, he said "Well, you can simply look at a register" [...] From > then on, we had this running joke where nobody would wait for the phone to > ring, we just all kept checking our phones whenever this guy was around [...]

retrac 5y ago

> nearly universally available on 8-bit micros, much less 16, but I have also wondered before how important they really were for what those machines ended up being used for Usually available, yes. But not all that widely used by those systems. The stock Apple II for example, has nothing in it that can even generate an interrupt. You'd have to install an expansion card. The standard serial cards can generate an interrupt upon character receipt for example, but they were usually programmed with polled IO anyway. Later with network cards and hard disks, you do see some use of interrupts. > On the other hand, though, the vertical blank interrupt was pretty critical to their software The Atari 2600 had no hardware interrupt support at all. You could tell the graphics IC to sleep the CPU until the next scanline. You'd turn vblank on, generate 3 lines of vblank, then turn vblank off. You'd be lined up with vblank from that point if you counted carefully. On an in-order-execution processor, most things can in principle be translated into periodic polling and cycle counting. But it involves some extraordinarily painful coding. A timer and an interrupt are quite a relief when you're doing something time-sensitive.

bogomipz 5y ago
>"The stock Apple II for example, has nothing in it that can even generate an interrupt." Sorry if this is a naive question but how did the keyboard on those work without interrupts?
- tyingq 5y ago
  There's a good comment from an older discussion here on that: https://news.ycombinator.com/item?id=20404825 https://news.ycombinator.com/item?id=20404825
  - bogomipz 5y ago
    Ah this is fascinating. Thanks for the link. Cheers!
  - stavros 5y ago
    Oh wow, whose excellent idea was it to add a key that hard-reset the CPU right above the return key?

userbinator 5y ago

That surprised me too. The very awkward implementation of interrupts was also one of the things that held back the popularity of the Intel 8008.

jstanley 5y ago

The reason I didn't implement interrupts is that I couldn't understand how to do it. It would be better with interrupts, but only by a little bit. The times I really feel the lack of interrupts are: - the text editor sometimes takes a long time to redraw the screen after reading input, and can drop characters if you type too fast because it isn't ready to poll for another character yet - if a program is stuck in an infinite loop and not doing any system calls, you can't kill it with ^C because the kernel never gets to find out that you typed ^C Those problems would go away if the arrival of a character on the serial port triggered an interrupt which caused the kernel to grab the character from the UART and stick it in a buffer, but I'm not sure the increase in hardware complexity is worth it.

R0b0t1 5y ago
It's worth it. I played with Propeller chips a while back. They have multiple cores and a shared memory but no interrupts. They can work, but you dedicate an entire CPU (expensive!) to a task, usually. The scant times you don't need to is because you poured time into a more difficult cooperative multitasking solution that isn't flexible. You don't need to implement a nested vectored interrupt controller. Even just a timer/counter with overflow interrupt would solve your current issues with lockup by allowing you to implement preemptive multitasking. Once you do that it would be easy-ish to extend to the serial controller. Basically, on interrupt flag = 1, 1. Disable further interrupts (no nesting). This makes things easier to implement. 2. Save register state. For speed a special set of shadow registers can be used, or you can put register state on the stack. 3. Jump to interrupt routine code start. 4. Let interrupt handler run, clear interrupt flag, then return. In the simplest case an input flag simply causes a CALL (push pc, jump to address). In that case the interrupt handler needs to know to save state. You can test flags between instructions to see if you need to inject the push/jump.