Timeline for Z80: Interrupt (IM2) daisy chain for "foreign" peripherals
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 22, 2021 at 8:05 | comment | added | Spektre | @lvd looks like this link from OP confirms it thx for commenting me ... I guess all the ISRs has EI before RETI so is works even with my current implementation... Why is that all the good docs pops out only years after I need them .... | |
| Mar 22, 2021 at 7:53 | comment | added | Spektre | @lvd IRET was a typo (last few years I mix order of letter often not sure why but mostly only 2 consequent letter swap and it gets worse with time :( IRET is 3 places away weird) ... I have to investigate this closer do you have some relevant source about this? Or do you have some binary / test that would fail on using RETI instead of RETN. I would repair the behavior in my emulator as currently my RETI is using the iff? and still passing ZEXALL 100% however iffs are most likely not incorporated to the test CRCs. but I need to know for sure before changing something that works | |
| Mar 22, 2021 at 7:46 | comment | added | lvd | @Spektre First, there is no IRET insn in Z80, only RET, RETI and RETN. Then, you're speaking about RETN, which restores interrupt enableness from iff2 at the NMI return. In contrary, RET and RETI are fully equivalent, except for the number of M1 cycles. | |
| Mar 21, 2021 at 7:13 | comment | added | Spektre | Another (though little) its 'knowledge' is RETI instruction that Z80 executes exactly the same way as RET, except for two opcodes instead of one. Are you sure about this? To my knowledge IRET restores the internal ei/di flipflop iff1 from its backup copy iff2 which RET does not touch ... meaning using RET will screw up your next maskable interrupt unless you EI before RET which could screw things up if used in nonmaskable ISR and pose also stack overflow thread in case the ISR is firing continuously | |
| Oct 30, 2020 at 15:12 | review | Low quality posts | |||
| Oct 30, 2020 at 18:24 | |||||
| Oct 30, 2020 at 15:05 | comment | added | nonchip | so this is what one calls the A/B problem... your answer to "how to do that" is "i don't like to do that, and here's an explanation on the things you already know"? plus i'm afraid "that only useful feature" is wat makes or breaks a modular, interrupt driven computer (unless you want to set up polling/IM0/1 handlers for every possible setup). also as i already said, i did consider and decide against cplds/fpgas. because they're a) quite overkill, b) hard to program unless you get vendor specific proprietary software (and often hardware), and c) i personally find GALasm way easier than VHDL. | |
| Oct 30, 2020 at 14:03 | history | answered | lvd | CC BY-SA 4.0 |