I mean this:
IDOMERES: LD A,0CH
OUT (0BFH),A
LD HL,0C937H
LD (38H),HL
LD HL,5000
LD A,30H
OUT (0B4H),A
EI
HALT
OUT (0B4H),A
EI
OR A
IDOMERES10: DEC HL
Edit: tomorrow I will test on a Vista OS.
EI enables interrupts only after the *end of next* opcode. So after HALT ... This code fragment seems to be strange for me, at the first glance, but it's possible that I'm tired only
![Smiley :)](/Smileys/phpbb/smiley.gif)
Of course if interrupts were enabled even before EI, it may does not cause too much headache, but if interrupts are disabled, this would halts the CPU, as interrupts are enabled by EI only after the HALT, but it won't occur, as HALT waits for an interrupt ... But I am really unsure ... As HALT can be imagined as a re-executed opcode without incrementing PC. So maybe it's still possible that the stuff above works, because on the "second iteration" of HALT that's already an opcode away from EI, so an interrupt can "kick off" Z80 from HALT state.
http://www.z80.info/zip/z80-documented.pdfAs far as I can see, my second explanation is the right, if you read things about EI and HALT in this nice (and quite useful, in my opinion) documentation on not-so-well-known Z80 features
![Smiley :)](/Smileys/phpbb/smiley.gif)
But anyway, I haven't written the Z80 emulation code itself, it's from Z80EX project, which is basically based on FUSE, which is a Spectrum emulator by the way (Free Unix Spectrum Emulator, or something like that). I can't say that Z80EX is bug-free, but even if it's not, that behaviour is nothing to do too much with the host OS/machine.
Moreover, of course HALT will stop the execution regardless of EI, if no interrupt is got by the Z80 ... Since in EP, all maskable interrupts comes through/from Dave, it's possible, that there is some specific problem in the Dave emulation itself, not the Z80 part. I even have some faint idea ... On a real EP, Dave just runs in "parallel" with CPU, I mean its counters for example. This is not possible in an emulator too much, as emulator is a single sequence of code (ok, you can have more CPU cores, multithreading etc, but then it won't work too much as you can't keep stuffs in sync using a host OS which has its own idea on scheduling processes/threads/etc in this very low scale time factor at least). So Xep128 in reality runs one Z80 opcode and _then_ runs the Dave "tick" function which emulates amount of Dave cycles calculated from the Dave / Z80 clock ratio (fractions are not lost ....). That "tick" funcion is responsible also to decrement Dave counters and causing interrupt for example if it's enabled. Usually this should not make any difference, but I think it will, if very tight cycle exact reaction is needed. But I am really unsure now. In theory, interrupts are not accepted of course within an opcode execution by the Z80, so it won't cause difference, however, there is one exception: if a CPU opcode is long enough (in T-cycles) that multiple Dave ticks "fits", then Dave tick function is called more times without Z80 activity in the emulator code level at least. With the current code structure, I can't avoid that, otherwise the CPU/Dave frequency ratio cannot be kept at all. Well, it's just one possible reason that Xep128 can behave a bit different than a real EP, if accurate timing is important. Some other areas where Xep128 is not exact:
* VRAM timing it totally missing
![Sad :(](/Smileys/phpbb/ds_icon_sad.gif)
It's a quite *big* difference from a real EP! In fact, I think, more important than the case of Dave/CPU sync which is about to be good, just few cycles difference maybe (those inaccurate cycles would "average out" each other on long term, but can cause problem if ONE cycle exact emulation is needed for some reason!)
* Nick/CPU exact timing is also not exact, well this cause the previous VRAM timing problem
![Smiley :)](/Smileys/phpbb/smiley.gif)
But it can be detected by other means, if someone plays with rapid modification of data Nick would read very soon, etc ... I don't think too much people used tricks like this ever ... Maybe IstvanV had a nick program (which even doesn't work on ep128emu) playing with _reading_ Nick registers which would reflect the last bus state between Nick and its RAM (VRAM). Not so easy to do it at a very exact way ...