Sharp MZ

ok, here is what I think how we should compute the wait states for: PUSH rr: T1 AB:000 DB:-- M1 | T2 AB:000 DB:C5 M1 MREQ RD | Opcode read from 000 -> C5 T3 AB:000 DB:-- RFSH | T4 AB:000 DB:-- RFSH MREQ | Refresh address 000 T5 AB:000 DB:-- | -----------------------------------------------------+ T6...

@S_U_C Any access to $0000-$0FFF through /CS0 signal (from LSI) is emulated by adding one /WAIT state in EmuZ-700 so it should be effective. I checked that when emulating my 512KB ROMDISK (now called IPL512) on EmuZ-700. I'll check for I/O port access but it should already be handled as I believe IN...

I finally got a file called Timings.xlsx which described the M-cycles and T-states more precisely for instructions including the undocumented ones. But man! it will be very hard to take them into account without some big changes.

For me it doesn't flicker. It is stable with/without those alternate rows. I don't have "some misses, some hits". For your information, I'm getting the signals on the inner video connector which are pure TTL connected to my logical analyzer (100 Mhz and 50 MHz). But I reckon the edges of CPU clock a...

Ok, there were an error I fixed in d_cpu->get_insn_clock(). if(!blank_vram) { int delta = d_cpu->get_insn_clock(); *wait = BLANK_S + delta - 4 - get_passed_clock_since_vline(); blank_vram = true; } This is more logical to ADD delta then SUBSTRACT 4 due to opcode fetching considering what I staticall...

I have a good news: } else if(mem_bank & MEM_BANK_MON_H && (0xd000 <= addr && addr <= 0xdfff)) { if(!blank_vram) { *wait = BLANK_S - d_cpu->get_insn_clock() - 4 - get_passed_clock_since_vline(); //d_cpu->write_signal(SIG_CPU_BUSREQ, 1, 1); blank_vram = true; } } I added a method which normally gives...

Oh I just realized the case where you execute a code in VRAM. There is a memory fetch in the opcode fetch so any instruction will be locked pretty much instantaneously. That makes the changes harder if possible.

@Sdw Have you a way to check with other screens? I believe your CRT is a little pricky to accept the MZ-700 video timing. My assumption is as long as you are not trying messing on raster line level, you won't see any flickering. Remember I got my cycles from MZ-700 video timings through a logic anal...

@Sdw 1) The registered free cycles is 80 which is correct if compared with the logic analyzer. We get 91 free cycles IF the locking instruction is a PUSH, it would be 101 cycles with LDIR I think. Those higher free cycles are due to the way how /BUSREQ works under emulator instead of using /WAIT sta...

@Sdw As you said 82 cycles was the max working I had a doubt. So I tried `wt` on my genuine MZ-700. 83 is the max working (phew!) IMG_20200712_190010.jpg Higher than 83 shows a permanent disruption. IMG_20200712_190021.jpg So that confirms my equation: N cycles are working if N - 4 < 80. For NTSC, i...