4 ms·

I'm confused about something. After they've implemented their final solution that lets tiles become corrupted before they're overwritten, what happens to the so

• ricardobeat 13y ago
  At that rate, sound glitches would be in the sub-millisecond range and impossible to hear, specially with 8-bit audio.
• lunixbochs 13y ago
  The problem isn't that sound is written to the screen, but that triggering an interrupt pushes to the stack (which is pointing at the screen). Their fix of drawing in the opposite order works because a push/pop of the stack will then affect the upcoming graphics bytes instead of the previous ones.
• pflanze 13y ago
  Calling the interrupt routine to play a sound sample used the stack, hence wrote register contents (and return addresses upon subroutine calls within the handlers) onto the tile target. No problem, as while the interrupt routine was running, the normal program was stopped. After returning from the interrupt, the stack pointer would be reset to the original value, and the normal program would go on overwriting the locations that had just been used for the interrupt handler stack. Playing the audio would not be disturbed at all. (This assumes that the stack wraps around at the end. Actually, there was probably still image corruption happening, if the irq was triggered at the very end of the stack range. Except perhaps the stack size was 16bit?) Edit: yes, the stack pointers were 16 bit (http://en.wikipedia.org/wiki/Motorola_6809 http://en.wikipedia.org/wiki/Motorola_6809).
  • tmoertel 13y ago
    You have a quick mind to spot that edge case! See footnote 2 of the article for how we handled it.
• axman6 13y ago
  The interrupt routine would only be writing the next byte of audio to the DAC which would be at a fixed address, whats causing the corruption is that the CPU stores the state of the CPU when the interrupt occurs onto the stack; this isn't where the audio is being played from void execute_interrupt(void * isr) { // push the registers of the program running when // the interrupt happens onto the stack that's currently // in use. this is something the CPU looks after usually // (I think). // This meant in the article that the contents of the // registers were being pushed to the buffer holding // the current image, overwriting whatever data was // above the stack pointer. The fix was to swap which // register was the source and which the dest, so that // the ISR would be pushing to the buffer that was about // to be written to. pushRegs(); // do whatever's needed to get the CPU into a consistant // state for the ISR zeroRegs(); // call the interrupt service routine for whatever interrupt // has occured isr(); // just decrements the system stack pointer, leaving // whatever was above the point corrupted in the // original version using the two stack regs popRegs(); }