You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(from old issues page)
jaggies commented on Mar 2, 2019
While going back and forth between real hardware, I found VCC is tolerant of not clearing FIRQ/IRQ/NMI sources (e.g. forgetting to read GIME register 0xff93 to clear the interrupt). I had to break out the oscilloscope to figure out what was going on. :) Applications that are written correctly don't have a problem, of course, but it makes cross-developing code more challenging since code that works fine on the emulator locks up the real hardware.
The text was updated successfully, but these errors were encountered:
BGPierce commented on Dec 11, 2019
Sorry for the long wait, but it's been a tough time around here.
I understand what you are saying, but I'm not sure of the actions that should happen.
Explain as best you can what happens in VCC and a real Coco when the interrupts are not cleared.
I'm not a tech or engineer, so the simpler the explanation the better :-)
Vcc is single threaded which means all peripheral activity is synchronized. This means the emulated cpu is halted until peripheral activity completes. Fix would be to run each peripheral in a separate thread which is a complex change that could break things. Might be worth trying someday.
(from old issues page)
jaggies commented on Mar 2, 2019
While going back and forth between real hardware, I found VCC is tolerant of not clearing FIRQ/IRQ/NMI sources (e.g. forgetting to read GIME register 0xff93 to clear the interrupt). I had to break out the oscilloscope to figure out what was going on. :) Applications that are written correctly don't have a problem, of course, but it makes cross-developing code more challenging since code that works fine on the emulator locks up the real hardware.
The text was updated successfully, but these errors were encountered: