Newsgroups: comp.sys.sinclair Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!swrinde!howland.reston.ans.net!newsfeed.internetmci.com!info.ucla.edu!agate!sunsite.doc.ic.ac.uk!yama.mcc.ac.uk!news.salford.ac.uk!aber!bath.ac.uk!uwe-bristol!hob!rff-ribe From: rff-ribe@csm.uwe.ac.uk (R Ribeiro) Subject: Z80 emulation related facts... Message-ID: <1996Apr27.192904.4095@pat.uwe.ac.uk> Sender: usenet@pat.uwe.ac.uk (uwe nntp usenet poster) Nntp-Posting-Host: usenet@pat.uwe.ac.uk (uwe nntp usenet poster) Reply-To: rff-ribe@uwe.ac.uk Organization: University of the West of England. X-Newsreader: xrn 7.04-beta-2 Date: Sat, 27 Apr 1996 19:29:04 GMT Lines: 83 I have been writing a emulator, and find out some new data.... Any comments on this? ----- Begin Included Message ----- When strange ports are used that the bits from keyboard and joystick are activated, the joystick [kempston and Sinclair] takes precedence over the keyboard. Every emulator got this wrong excep SpecEm and my own [WSpecem]. See games Command4 and Street Hawk. Loading snapshots, if the snapshot destroy some bytes of the Spectrum memory area [as is the case with .SNA, .SNX, .PRG], it helps if after you read the information on this bytes, you put them to 0 (e.g. after loading .SNA, read PC and put word 0 at [SP-2]). I found it out, because there were .SNA games that worked in JPP and when runned with other emulators or converted to other snapshot format would not work. Well-fargo, Bounder, Batman and Enduro Racer saved at critical places... /* interrupt 'switch' interrupts and copy * * IFF1 IFF2 * ---------------------- * | RESET | 0 | 0 | * |--------+-----+-----| * | DI | 0 | 0 | * |--------+-----+-----| * | EI | 1 | 1 | * |--------+-----+-----| * | LD A,I | . | . | - P/V = IFF2 * |--------+-----+-----| * | LD A,R | . | . | - P/V = IFF2 * |--------+-----+-----| * | NMI | 0 | . | * |--------+-----+-----| * | RETN | IFF2| . | * |--------+-----+-----| * | INT | 0 | 0 | * |--------+-----+-----| * | RETI | . | . | - same as RET. (This instruction only exists * ---------------------- to be recognized by external devices) Some of this times were derived by me...there were times in the past, that it was be enough to look to the name of a Z80 instruction to know how many T states it would need. Z80 Timings: Condition test --> 1T Inc/Dec 8 bits reg --> 1T Inc/Dec 16 bits reg --> 2T PC+n --> 5T sum IX+n --> 5T read a memory byte --> 3T read a port byte --> 4T (3T + 1T in Wait) Nmi int --> 6T (3T + 3T - push two words in stack) Int IM 0 --> 10T (3T + 3T + 4T from data bus read) Int IM 1 --> 6T (3T + 3T) Int IM 2 --> 16T (3T + 3T + 4T + 3T + 3T -- the last 6T being 2 memory acesses to read the pointer built by reg I and the data bus value) Rui Ribeiro ----- End Included Message ----- -- ------------------------------------------------------------------------------ | Join the army. Travel to | Rui Fernando Ferreira Ribeiro | | exotic lands, meet exciting | | | and unusual people. Then | rff-ribe@csm.uwe.ac.uk | | kill `em. | i890478@idt-isep.ipp.pt | ______________________________________________________________________________ ---- Path: vanilla!asbach!noris.net!rednet!osn.de!news.gtn.com!genesis.westend.com!news.rwth-aachen.de!news.dfn.de!newsjunkie.ans.net!newsfeeds.ans.net!howland.reston.ans.net!newsfeed.internetmci.com!in2.uu.net!news.tcom.co.uk!morse.ukonline.co.uk!bath.ac.uk!niss!warwick!lyra.csx.cam.ac.uk!mgr11 From: mgr11@cus.cam.ac.uk (M.G. Rison) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 30 Apr 1996 10:20:48 GMT Organization: University of Cambridge, England Lines: 77 Message-ID: <4m4pi0$1pl@lyra.csx.cam.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> Reply-To: rison@hep.phy.cam.ac.uk En la artikolo <1996Apr27.192904.4095@pat.uwe.ac.uk>, R Ribeiro skribis: > [...] > /* interrupt 'switch' interrupts and copy > * > * IFF1 IFF2 > * ---------------------- > * | RESET | 0 | 0 | > * |--------+-----+-----| > * | DI | 0 | 0 | > * |--------+-----+-----| > * | EI | 1 | 1 | > * |--------+-----+-----| > * | LD A,I | . | . | - P/V = IFF2 > * |--------+-----+-----| > * | LD A,R | . | . | - P/V = IFF2 > * |--------+-----+-----| > * | NMI | 0 | . | You presumably mean to say IFF1 here. > * |--------+-----+-----| > * | RETN | IFF2| . | > * |--------+-----+-----| > * | INT | 0 | 0 | ~ May I ask what your evidence/source for this is? I too have assumed that an INT causes an implicit DI (because otherwise if the device causing the INT didn't stop requesting the INT after the INTACK, an infinite loop would result), but I've been totally unable to find an explicit statement of this in any source I've looked at. > * |--------+-----+-----| > * | RETI | . | . | - same as RET. (This instruction only exists > * ---------------------- to be recognized by external > devices) > > > Some of this times were derived by me...there were times in the past, that > it was be enough to look to the name of a Z80 instruction to know > how many T states it would need. > > Z80 Timings: > > Condition test --> 1T > Inc/Dec 8 bits reg --> 1T > Inc/Dec 16 bits reg --> 2T > PC+n --> 5T > sum IX+n --> 5T > read a memory byte --> 3T > read a port byte --> 4T (3T + 1T in Wait) > Nmi int --> 6T (3T + 3T - push two words in stack) > Int IM 0 --> 10T (3T + 3T + 4T from data bus read) > Int IM 1 --> 6T (3T + 3T) > Int IM 2 --> 16T (3T + 3T + 4T + 3T + 3T -- the last > 6T being 2 memory acesses to read the pointer > built by reg I and the data bus value) I don't quite follow this (are you using `T states' to mean `M cycles'?), but I have a question: how long does it take (in M/T cycles) for INTs to be processed? Presumably the answer to this depends on the IM. Does it also depend on the hardware (what's all this about `wait' states above?)? [Or are the above really `T cycles' used in the individual elements which are used to execute an instruction?] Mark ====================================================================== | rison@hep.phy.cam.ac.uk | Esperanto - lingvo inter-nacia | | rison@vxcern.cern.ch | * Mi estas riisto * | ====================================================================== ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!howland.reston.ans.net!newsfeed.internetmci.com!in2.uu.net!news.tcom.co.uk!morse.ukonline.co.uk!bath.ac.uk!niss!warwick!lyra.csx.cam.ac.uk!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 30 Apr 1996 11:54:09 GMT Organization: Oxford University Computing Laboratory Lines: 25 Message-ID: <8270.imc@comlab.ox.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> NNTP-Posting-Host: boothp2.ecs.ox.ac.uk X-Local-Date: Tuesday, 30th April 1996 at 12:54am BST In article <1996Apr27.192904.4095@pat.uwe.ac.uk>, rff-ribe@uwe.ac.uk wrote: > Nmi int --> 6T (3T + 3T - push two words in stack) When an NMI occurs the Z80 performs a machine fetch cycle for 5 Tstates but ignores the result (there are two automatic wait states in this read operation). It takes a further 10 Tstates to jump to the NMI routine at 0x66 (don't ask me why, but it does because I've measured it...). > Int IM 0 --> 10T (3T + 3T + 4T from data bus read) > Int IM 1 --> 6T (3T + 3T) > Int IM 2 --> 16T (3T + 3T + 4T + 3T + 3T -- the last > 6T being 2 memory acesses to read the pointer > built by reg I and the data bus value) When a maskable interrupt occurs the 5T fetch cycle occurs as for NMI (even in mode 1, when the data is ignored). In mode 1 it takes a further 8 Tstates to reach 0038. In mode 2 it takes 14, the extra 6 being the two memory accesses to read the interrupt vector. Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section): http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html New to this group? Answers to frequently-asked questions can be had from http://www.cs.bham.ac.uk/~dmb/speccy/faq.html . Sam Coupé FAQ: http://www.soton.ac.uk/~tsp93/Coupe/FAQ.txt ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!howland.reston.ans.net!newsfeed.internetmci.com!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 30 Apr 1996 14:29:35 GMT Organization: Oxford University Computing Laboratory Lines: 70 Message-ID: <8271.imc@comlab.ox.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4m4pi0$1pl@lyra.csx.cam.ac.uk> NNTP-Posting-Host: boothp2.ecs.ox.ac.uk X-Local-Date: Tuesday, 30th April 1996 at 3:29pm BST In article <4m4pi0$1pl@lyra.csx.cam.ac.uk>, rison@hep.phy.cam.ac.uk wrote: >> * | INT | 0 | 0 | > ~ >May I ask what your evidence/source for this is? I too have assumed >that an INT causes an implicit DI (because otherwise if the device >causing the INT didn't stop requesting the INT after the INTACK, an >infinite loop would result), but I've been totally unable to find an >explicit statement of this in any source I've looked at. I don't know of one, but the best reference is to look at a real Z80 and trust me it does disable the interrupts. :-) >> Condition test --> 1T >> Inc/Dec 8 bits reg --> 1T >> Inc/Dec 16 bits reg --> 2T >> PC+n --> 5T >> sum IX+n --> 5T >> read a memory byte --> 3T >> read a port byte --> 4T (3T + 1T in Wait) >[Or are the above really `T cycles' used in the individual elements >which are used to execute an instruction?] Yes I believe that's what it is, though I think it's sometimes hard to split instructions up in such a manner. For example, an instruction fetch/decode cycle (which I will call an M1 cycle) takes 4 T-states (look at DD, ED and CB for example), but within that you get an 8-bit ALU operation for free (INC A, CP B, LD C,D). So, does a 16-bit increment (e.g. INC HL which takes 6 T-states) consist of a 4T M1 cycle followed by a 2T increment, or does part of the increment happen during the decode? Also, note that the special case of incrementing SP or PC can be done in one cycle - it can also be done during a memory access, hence the following timings. POP HL M1 4T fetch L & increment SP 3T fetch H & increment SP 3T = 10T PUSH HL M1 4T decrement SP 1T store H & decrement SP 3T store L 3T = 11T My guess is that the memory access pathway contains a special purpose 16-bit inc/dec circuit (which may be turned off or indeed used by itself). This also accounts for the Z80's word-fetch operations (LD HL,(nn) and so on). (The mention of wait states is because the Z80 automatically adds a wait state to each I/O cycle in case the hardware is a bit slow. The hardware can add more by itself of course. The data input which occurs at an interrupt has two wait states automatically added). Incidentally, a condition test does not take one cycle - the conditional RET instructions are anomalous in this respect. We have... JP nn M1 + two fetches = 10 JP cc,nn M1 + two fetches = 10 (whether or not the condition is true) JR nn M1 + fetch + addition = 12 JR cc,d M1 + fetch + addition = 12 (if condition is true) M1 + fetch = 7 (if condition is false) DJNZ d M1 + fetch + dec + addition = 13 (if B>0) M1 + fetch + dec = 8 (if B=0). Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section): http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html New to this group? Answers to frequently-asked questions can be had from http://www.cs.bham.ac.uk/~dmb/speccy/faq.html . Sam Coupé FAQ: http://www.soton.ac.uk/~tsp93/Coupe/FAQ.txt ---- Newsgroups: comp.sys.sinclair Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!dispatch.news.demon.net!demon!sunsite.doc.ic.ac.uk!warwick!niss!bath.ac.uk!uwe-bristol!ada!rff-ribe From: rff-ribe@pat.uwe.ac.uk (R Ribeiro) Subject: Re: Z80 emulation related facts... Message-ID: <1996Apr30.153230.6685@pat.uwe.ac.uk> Sender: usenet@pat.uwe.ac.uk (uwe nntp usenet poster) Nntp-Posting-Host: usenet@pat.uwe.ac.uk (uwe nntp usenet poster) Organization: The University of the West of England, Bristol (The Magic Roundabout) X-Newsreader: TIN [version 1.2 PL2] References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4m4pi0$1pl@lyra.csx.cam.ac.uk> Date: Tue, 30 Apr 1996 15:32:30 GMT Lines: 110 M.G. Rison (mgr11@cus.cam.ac.uk) wrote: : En la artikolo <1996Apr27.192904.4095@pat.uwe.ac.uk>, : R Ribeiro skribis: : You presumably mean to say IFF1 here. : > * |--------+-----+-----| : > * | RETN | IFF2| . | : > * |--------+-----+-----| : > * | INT | 0 | 0 | : ~ No, I meant IIF2... The definition of RETN is that IIF1 is loaded with a copy of the IIF2... to recover the interrupt states before the NMI interrupt take over. * so IIF2 will be a copy of IIF1 * : May I ask what your evidence/source for this is? I too have assumed I think it was from a Spanish magazine, but I lost it's track in the midst of times. I am really not sure. : that an INT causes an implicit DI (because otherwise if the device : causing the INT didn't stop requesting the INT after the INTACK, an : infinite loop would result), but I've been totally unable to find an : explicit statement of this in any source I've looked at. I too had this doubt in the past, I sweared I so some reference from Zilog or Mostek where this was stated. Find it yourself. If you still have a Spectrum, write a IM 2 interrupt handler: and write the main body of the handler as: push af ld a,i ld a,0 ld [int_dis],1 jp p,noparty ; don't remember if jump/overflow it this ; in Z80, but you got the ideia? ; jump if patiry == true ld [int_dis],0 pop af jp #38 int_dis db 0 PEEK the location: if int_dis is 0, bingo INT disables interrupts. See the table that I posted for explanation of ld a,i. Drop me a line if you experiment with this. : > Some of this times were derived by me...there were times in the past, that : > it was be enough to look to the name of a Z80 instruction to know : > how many T states it would need. : > : > Z80 Timings: : > : > Condition test --> 1T : > Inc/Dec 8 bits reg --> 1T : > Inc/Dec 16 bits reg --> 2T : > PC+n --> 5T : > sum IX+n --> 5T : > read a memory byte --> 3T : > read a port byte --> 4T (3T + 1T in Wait) : > Nmi int --> 6T (3T + 3T - push two words in stack) : > Int IM 0 --> 10T (3T + 3T + 4T from data bus read) : > Int IM 1 --> 6T (3T + 3T) : > Int IM 2 --> 16T (3T + 3T + 4T + 3T + 3T -- the last : > 6T being 2 memory acesses to read the pointer : > built by reg I and the data bus value) : I don't quite follow this (are you using `T states' to mean `M cycles'?), No, a M1 cycle is the fetching cycle of the instruction. Just for the sake of curiosity, R register is incremented at each M1 cycle. If you mean machine cycles that is exactly the same as saying T states. : but I have a question: how long does it take (in M/T cycles) for INTs to : be processed? Presumably the answer to this depends on the IM. I think you receive a INT aprox. 70000T, but can be sure of that. It doesn't depend of the processor in any way. It's a signal that is feed to the processor by a pin. : Does : it also depend on the hardware (what's all this about `wait' states : above?)? The processor wait (or is put in wait) 1 cycle or more in other cases to allow slower components to comunicate with it. : [Or are the above really `T cycles' used in the individual elements : which are used to execute an instruction?] You guessed it :) Cheers, Rui : ====================================================================== : | rison@hep.phy.cam.ac.uk | Esperanto - lingvo inter-nacia | : | rison@vxcern.cern.ch | * Mi estas riisto * | : ====================================================================== -- ------------------------------------------------------------------------------ | Join the army. Travel to | Rui Fernando Ferreira Ribeiro | | exotic lands, meet exciting | | | and unusual people. Then | rff-ribe@csm.uwe.ac.uk | | kill `em. | i890478@idt-isep.ipp.pt | ______________________________________________________________________________ ---- Newsgroups: comp.sys.sinclair Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!dispatch.news.demon.net!demon!sunsite.doc.ic.ac.uk!warwick!niss!bath.ac.uk!uwe-bristol!hob!rff-ribe From: rff-ribe@csm.uwe.ac.uk (R Ribeiro) Subject: Re: Z80 emulation related facts... Message-ID: <1996Apr30.165216.7748@pat.uwe.ac.uk> To: imc@ecs.ox.ac.uk (Ian Collier) Sender: usenet@pat.uwe.ac.uk (uwe nntp usenet poster) Nntp-Posting-Host: usenet@pat.uwe.ac.uk (uwe nntp usenet poster) Reply-To: rff-ribe@uwe.ac.uk Organization: University of the West of England. X-Newsreader: xrn 7.04-beta-2 References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <8270.imc@comlab.ox.ac.uk> Date: Tue, 30 Apr 1996 16:52:16 GMT Lines: 54 In article <8270.imc@comlab.ox.ac.uk>, imc@ecs.ox.ac.uk (Ian Collier) writes: > In article <1996Apr27.192904.4095@pat.uwe.ac.uk>, rff-ribe@uwe.ac.uk wrote: > > Nmi int --> 6T (3T + 3T - push two words in stack) > > When an NMI occurs the Z80 performs a machine fetch cycle for 5 Tstates > but ignores the result (there are two automatic wait states in this read > operation). It takes a further 10 Tstates to jump to the NMI routine at > 0x66 (don't ask me why, but it does because I've measured it...). > > > Int IM 0 --> 10T (3T + 3T + 4T from data bus read) > > Int IM 1 --> 6T (3T + 3T) > > Int IM 2 --> 16T (3T + 3T + 4T + 3T + 3T -- the last > > 6T being 2 memory acesses to read the pointer > > built by reg I and the data bus value) > > When a maskable interrupt occurs the 5T fetch cycle occurs as for NMI > (even in mode 1, when the data is ignored). In mode 1 it takes a further > 8 Tstates to reach 0038. In mode 2 it takes 14, the extra 6 being the two > memory accesses to read the interrupt vector. > Ok, the T states of the interrupts, I calculated them just from my knowlegde of Z80 behaviour and timings. How have you measured it? Have you any margin for errors, or you can say without doubt that they are really this times? Because (and I think a good point, your timings made me think,....). Listen to this theory: what I calculated could be the minimum times to the Z80 react the interrupt; but both of us know that after the INT signal, first the current instruction must be finished. Have you taken this into account, too? Hum...the discussion is becoming interesting now :) Best regards, Rui > Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section): > http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html > > New to this group? Answers to frequently-asked questions can be had from > http://www.cs.bham.ac.uk/~dmb/speccy/faq.html . > Sam Coupé FAQ: http://www.soton.ac.uk/~tsp93/Coupe/FAQ.txt -- ------------------------------------------------------------------------------ | Join the army. Travel to | Rui Fernando Ferreira Ribeiro | | exotic lands, meet exciting | | | and unusual people. Then | rff-ribe@csm.uwe.ac.uk | | kill `em. | i890478@idt-isep.ipp.pt | ______________________________________________________________________________ ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 1 May 1996 11:50:00 GMT Organization: Oxford University Computing Laboratory Lines: 42 Message-ID: <8281.imc@comlab.ox.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4m4pi0$1pl@lyra.csx.cam.ac.uk> <1996Apr30.153230.6685@pat.uwe.ac.uk> NNTP-Posting-Host: boothp2.ecs.ox.ac.uk X-Local-Date: Wednesday, 1st May 1996 at 12:49am BST In article <1996Apr30.153230.6685@pat.uwe.ac.uk>, rff-ribe@pat.uwe.ac.uk (R Ribeiro) wrote: >M.G. Rison (mgr11@cus.cam.ac.uk) wrote: >: You presumably mean to say IFF1 here. >: > * | RETN | IFF2| . | Wrong line! The comment applied to the underlined part of the previous line, quoted below. >> * | NMI | 0 | . | > > * so IIF2 will be a copy of IIF1 * This seems to agree with the correction. There is of course only one situation in which it makes a difference, because IFF1 and IFF2 are usually equal. That situation arises when an NMI has occurred while interrupts were enabled and then another NMI occurs before IFF1 and IFF2 have been changed further. Is IFF2 zero or one then? The docs say zero but I have never tried it to see what really happens. > If you mean machine cycles that is exactly the same as saying T states. No, a machine cycle is (I think) approximately the same as a memory or I/O operation: hence M1, which is the first machine cycle in each instruction. > I think you receive a INT aprox. 70000T, but can be sure of that. To be entirely pedantic, the number is 69888 on a 48K Spectrum and 70908 on a 128K one. On the +3 the INT pulse lasts just long enough so that if your mode 2 interrupt routine says EI:RET then it will be invoked twice. :-) This makes a small amount of sense because you need the pulse to be long enough to interrupt the longest Z80 instruction (which takes 23 Tstates). Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section): http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html New to this group? Answers to frequently-asked questions can be had from http://www.cs.bham.ac.uk/~dmb/speccy/faq.html . Sam Coupé FAQ: http://www.soton.ac.uk/~tsp93/Coupe/FAQ.txt ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 1 May 1996 12:08:43 GMT Organization: Oxford University Computing Laboratory Lines: 40 Message-ID: <8282.imc@comlab.ox.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <8270.imc@comlab.ox.ac.uk> <1996Apr30.165216.7748@pat.uwe.ac.uk> NNTP-Posting-Host: boothp2.ecs.ox.ac.uk X-Local-Date: Wednesday, 1st May 1996 at 1:08pm BST In article <1996Apr30.165216.7748@pat.uwe.ac.uk>, rff-ribe@uwe.ac.uk wrote: > How have you measured it? Have you any margin for errors, or you can >say without doubt that they are really this times? Because (and I think a >good point, your timings made me think,....). They are the exact times, calculated on a +3. OK, I will now give away a trade secret. :-) Imagine a program which loops in exactly 70908 T-states. This program could draw a pattern on the border which stands still. Now trigger an NMI which consists of a single RETN (the good thing about the +3 is that you can set it up with a POKE-able ROM; this configuration is already supplied in 48K Disk BASIC). The pattern will then move to the right one character square for each four T-states that the interrupt took. It moves 7 character squares, which means that the delay was between 28 and 31 T-states. Now for the tricky bit. If you program the pattern to move to the right very slowly in steps of one T-state then the time at which the pattern jumps will tell you which of 28, 29, 30 and 31 is the correct answer. It turns out to be 29. A Z80 reference gives RETN as taking 14 of them, so the time for the interrupt must have been 15. The Z80 reference says that 5 of these are for the input from the data bus. 7 of them are for pushing the current PC. The other 3 cannot be explained. [Of course, given that my +3 is not here at this moment there is always the chance that I have copied the numbers incorrectly, but I doubt it. :-) ] The same can be done for ordinary interrupts. > Listen to this theory: what I calculated could be the minimum times >to the Z80 react the interrupt; but both of us know that after the INT signal, >first the current instruction must be finished. Have you taken this into >account, too? The amount of delay does not depend upon when the interrupt started. I count the time between when it is recognised and when the Z80 reaches the interrupt routine. Of course there may also be some time between when the INT signal is supplied and when the Z80 recognises it. >> Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section): >> http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html ---- Newsgroups: comp.sys.sinclair Path: vanilla!asbach!noris.net!blackbush.xlink.net!news.ecrc.de!news.compuserve.com!imci4!newsfeed.internetmci.com!uwm.edu!lll-winken.llnl.gov!enews.sgi.com!decwrl!sunsite.doc.ic.ac.uk!warwick!niss!bath.ac.uk!uwe-bristol!dish!rff-ribe From: rff-ribe@csm.uwe.ac.uk (R Ribeiro) Subject: Re: Z80 emulation related facts... Message-ID: <1996May1.132245.19039@pat.uwe.ac.uk> Sender: usenet@pat.uwe.ac.uk (uwe nntp usenet poster) Nntp-Posting-Host: usenet@pat.uwe.ac.uk (uwe nntp usenet poster) Reply-To: rff-ribe@uwe.ac.uk Organization: University of the West of England. X-Newsreader: xrn 7.04-beta-2 References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4m4pi0$1pl@lyra.csx.cam.ac.uk> <1996Apr30.153230.6685@pat.uwe.ac.uk> <8281.imc@comlab.ox.ac.uk> Date: Wed, 1 May 1996 13:22:45 GMT Lines: 30 In article <8281.imc@comlab.ox.ac.uk>, imc@ecs.ox.ac.uk (Ian Collier) writes: > There is of course only one situation in which it makes a difference, > because IFF1 and IFF2 are usually equal. That situation arises when an > NMI has occurred while interrupts were enabled and then another NMI occurs > before IFF1 and IFF2 have been changed further. Is IFF2 zero or one then? > The docs say zero but I have never tried it to see what really happens. > By logic, it should be 0, really. > No, a machine cycle is (I think) approximately the same as a memory > or I/O operation: hence M1, which is the first machine cycle in each > instruction. > Yes, NOW I am inclined to say you're rigth. P.S. I am preparing my revenge :) Ah, congratulations for your emulator, I really like it! ------------------------------------------------------------------------------ | Join the army. Travel to | Rui Fernando Ferreira Ribeiro | | exotic lands, meet exciting | | | and unusual people. Then | rff-ribe@csm.uwe.ac.uk | | kill `em. | i890478@idt-isep.ipp.pt | ______________________________________________________________________________ ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!usenet.eel.ufl.edu!warwick!bignews.shef.ac.uk!not-for-mail From: thdb86%teach@dcs.shef.ac.uk (Damion Yates) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 1 May 1996 15:48:23 GMT Organization: Department of Computer Science, University of Sheffield Lines: 15 Message-ID: <4m8147$fpr@bignews.shef.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <8270.imc@comlab.ox.ac.uk> <1996Apr30.165216.7748@pat.uwe.ac.uk> <8282.imc@comlab.ox.ac.uk> NNTP-Posting-Host: suna30.dcs.shef.ac.uk X-Newsreader: TIN [version 1.2 PL2] Ian Collier (imc@ecs.ox.ac.uk) wrote: : draw a pattern on the border which stands still. Now trigger an NMI which : consists of a single RETN (the good thing about the +3 is that you can set : it up with a POKE-able ROM; this configuration is already supplied in 48K This ram runs slower than in other areas, for a moment I thought that iy acted differently to ix when I was going through all the timings by hand, until I remembered that it was pointing in to this area. Did you take this in to account, or was the ram page set up using 0,1,2,3 ? Damion -- Damion Yates - Sheffield Uni, UK. http://www.bath.ac.uk/~exxdmy ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!dispatch.news.demon.net!demon!sunsite.doc.ic.ac.uk!lyra.csx.cam.ac.uk!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 2 May 1996 13:30:49 GMT Organization: Oxford University Computing Laboratory Lines: 22 Message-ID: <8291.imc@comlab.ox.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <1996Apr30.165216.7748@pat.uwe.ac.uk> <8282.imc@comlab.ox.ac.uk> <4m8147$fpr@bignews.shef.ac.uk> NNTP-Posting-Host: boothp2.ecs.ox.ac.uk X-Local-Date: Thursday, 2nd May 1996 at 2:30pm BST In article <4m8147$fpr@bignews.shef.ac.uk>, thdb86%teach@dcs.shef.ac.uk (Damion Yates) wrote: >This ram runs slower than in other areas, for a moment I thought that iy >acted differently to ix when I was going through all the timings by hand, >until I remembered that it was pointing in to this area. Oh no! I must have been stupid to miss that. Anyway, it doesn't usually make a difference because normal interrupts happen off the screen when the memory is OK. An NMI would have to wait up to 3 cycles before fetching the RETN and after that would be OK (as long as I remembered to have the stack suitably high). The result of this is that my number for the NMI time is up to 3 cycles higher than the correct answer. This accounts for the difference between the NMI and MI timings. I'll have to see if I can repeat the experiment (I have to repair my NMI circuit first). Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section): http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html New to this group? Answers to frequently-asked questions can be had from http://www.cs.bham.ac.uk/~dmb/speccy/faq.html . Sam Coupé FAQ: http://www.soton.ac.uk/~tsp93/Coupe/FAQ.txt ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!gtnduss1.du.gtn.com!news.gtn.com!genesis.westend.com!news.rwth-aachen.de!news.ruhr-uni-bochum.de!news.uni-stuttgart.de!uni-regensburg.de!lrz-muenchen.de!informatik.tu-muenchen.de!Germany.EU.net!howland.reston.ans.net!swrinde!newsfeed.internetmci.com!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 3 May 1996 15:03:42 GMT Organization: Oxford University Computing Laboratory Lines: 34 Message-ID: <8305.imc@comlab.ox.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <8282.imc@comlab.ox.ac.uk> <4m8147$fpr@bignews.shef.ac.uk> <8291.imc@comlab.ox.ac.uk> X-Local-Date: Friday, 3rd May 1996 at 4:03pm BST In article <8291.imc@comlab.ox.ac.uk>, imc@ecs.ox.ac.uk (that's me!) wrote: >In article <4m8147$fpr@bignews.shef.ac.uk>, thdb86%teach@dcs.shef.ac.uk (Damion Yates) wrote: >>This ram runs slower than in other areas, for a moment I thought that iy >>acted differently to ix when I was going through all the timings by hand, >>until I remembered that it was pointing in to this area. >The result of this is that my number for the NMI time is up to 3 cycles >higher than the correct answer. This accounts for the difference between >the NMI and MI timings. I'll have to see if I can repeat the experiment This is of course complete rubbish. If the NMI happens on the screen then the ED byte will have to wait up to 7 Tstates to be read and the 45 will have to wait exactly 4 Tstates [except in the very unlikely circumstance that it happens on the boundary between being on the screen and off it]. So the delay will be a number between 4 and 11 inclusive. The screen is drawn for 128 out of every 228 Tstates on 192 out of 311 lines [this is on the +3], which is about 34.66% of the time. During this time we have an approximately equal chance of getting each delay between 4 and 11, and at other times there should be no delay. I did the experiment 100 times and got the following answers. delay 25 29 30 31 32 33 34 35 36 number of times 72 4 2 2 8 4 1 2 5 This very roughly agrees with the above. RETN takes 14 Tstates, so the time for an NMI is 11. Then the NMI is received there is an M1 cycle taking 5 Tstates which contains a 3T memory read (not an I/O read as I first thought) and a 2T refresh. This leaves 6 Tstates for the CPU to execute the restart to location 0066. Presumably the SP is pre-decremented during the second Tstate of the refresh. imc ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!rz.uni-karlsruhe.de!news.uni-kl.de!news.belwue.de!fu-berlin.de!news.mathworks.com!news.kei.com!nntp.coast.net!lll-winken.llnl.gov!enews.sgi.com!decwrl!sunsite.doc.ic.ac.uk!nntp0.brunel.ac.uk!strath-cs!clyde.open.ac.uk!adminmbx From: rjfm2@student.open.ac.uk (rjfm2) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: Sat, 04 May 1996 11:25:04 GMT Organization: The Open University Lines: 17 Message-ID: <4mfeml$kdd@clyde.open.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> NNTP-Posting-Host: annex-newcastle-3.open.ac.uk X-Newsreader: Forte Free Agent 1.0.82 rff-ribe@csm.uwe.ac.uk (R Ribeiro) wrote: >Loading snapshots, if the snapshot destroy some bytes of the Spectrum memory >area [as is the case with .SNA, .SNX, .PRG], it helps if after you read the >information on this bytes, you put them to 0 (e.g. after loading .SNA, read PC >and put word 0 at [SP-2]). I found it out, because there were .SNA games that >worked in JPP and when runned with other emulators or converted to other >snapshot format would not work. >Well-fargo, Bounder, Batman and Enduro Racer saved at critical places... Would the above explain why some games (Action Force 2 is a good example), play ok but suffer from screen corruption? Rob. ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!dish.news.pipex.net!pipex!news.be.innet.net!INbe.net!news.nl.innet.net!INnl.net!hunter.premier.net!news.mathworks.com!newsfeed.internetmci.com!in1.uu.net!brighton.openmarket.com!decwrl!sunsite.doc.ic.ac.uk!yama.mcc.ac.uk!jumper!simonc From: simonc@jumper.mcc.ac.uk (Simon Cooke) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 9 May 1996 12:21:43 GMT Organization: Manchester Computing Centre Lines: 23 Message-ID: <4mso0n$h4m@yama.mcc.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4m4pi0$1pl@lyra.csx.cam.ac.uk> NNTP-Posting-Host: jumper.mcc.ac.uk X-Newsreader: TIN [version 1.2 PL2] M.G. Rison (mgr11@cus.cam.ac.uk) wrote: : May I ask what your evidence/source for this is? I too have assumed : that an INT causes an implicit DI (because otherwise if the device : causing the INT didn't stop requesting the INT after the INTACK, an : infinite loop would result), but I've been totally unable to find an : explicit statement of this in any source I've looked at. It's in the Z80 Technical manual, as produced by Zilog, though you'll have to get hold of a copy of the Zilog Applications book (1991 I think). Big, blue, and with everything you never needed to know about the Z180, Z280 and all the support chips as well. Also: After an EI, the interrupts aren't re-enabled until /after/ the next instruction. Kind of screws things up if you do a HALT immediately after an EI. Simon -- +- Email:Simon.Cooke@umist.ac.uk ---- Fidonet: 2:250/124.2 (Simon Cooke) -+ | Snail: 26 Woodhouse Lane, Sale, Cheshire, M33 4JX Tel: 0161 976 3426 | | Message Pager: 01426 208084 (55p per min peak, 35ppm offpeak) | +- WWW: http://jumper.mcc.ac.uk/~simonc ----------------------------------+ ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!usenet.eel.ufl.edu!gatech!news.jsums.edu!news2.cais.net!news.cais.net!news.mathworks.com!newsfeed.internetmci.com!netnews2.nwnet.net!arclight.uoregon.edu!dispatch.news.demon.net!demon!mail2news.demon.co.uk!bgserv.demon.co.uk From: Brian Gaff Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: Fri, 10 May 96 10:53:35 GMT Organization: bgserv Lines: 22 Message-ID: <831725615snz@bgserv.demon.co.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4mfeml$kdd@clyde.open.ac.uk> Reply-To: briang@bgserv.demon.co.uk X-NNTP-Posting-Host: bgserv.demon.co.uk X-Newsreader: Demon Internet Simple News v1.29 X-Mail2News-Path: bgserv.demon.co.uk There are certainly some snaps about that appear to have been loaded into an emulator from a Multiface Snapshot without a Multiface emulation. If you snap with a multiface 128, then Z80 will correct the screen. However, if you have a Z80 snap or an SNA with the corruption, and the screen is not redrawn in the program, you are stuck. I noticed this effect when I reloaded my MF1 copy of Monopoly. If you can get a clean screen saved from somewhere, simply load it in Z80 with the load bytes option, and resnap the game. Brian Brian is visually impaired so typomg errors are possible, feel free to laugh, but cut the criticism. This is not a work for posterity! -- briang@bgserv.demon.co.uk Brian Gaff AKA B G Services - Still supporting Z80 The Spectrum Emulator ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!sol.ctr.columbia.edu!news.uoregon.edu!vixen.cso.uiuc.edu!newsfeed.internetmci.com!in2.uu.net!brighton.openmarket.com!decwrl!sunsite.doc.ic.ac.uk!lyra.csx.cam.ac.uk!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 10 May 1996 14:28:51 GMT Organization: Oxford University Computing Laboratory Lines: 27 Message-ID: <8329.imc@comlab.ox.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4m4pi0$1pl@lyra.csx.cam.ac.uk> <4mso0n$h4m@yama.mcc.ac.uk> NNTP-Posting-Host: booth59.ecs.ox.ac.uk X-Local-Date: Friday, 10th May 1996 at 3:28pm BST In article <4mso0n$h4m@yama.mcc.ac.uk>, simonc@jumper.mcc.ac.uk (Simon Cooke) wrote: >Also: After an EI, the interrupts aren't re-enabled until /after/ the >next instruction. Kind of screws things up if you do a HALT immediately >after an EI. Not true! Interrupts are sampled with the rising edge of the last clock state of each instruction. HALT is effectively a series of NOP instructions, each one having a last clock state at which interrupts are sampled. The Z80 enables interrupts at the EI instruction, but does not sample them at the end of the EI instruction (I can't think of a particularly good reason why this might be designed in, although it's entirely possible that at the last clock state of the EI the Z80 doesn't know that interrupts have been enabled yet (hmmm, though this doesn't happen with DI)). If you write "EI:HALT" then all that happens is it prevents an interrupt from occurring between the EI and the HALT. It does not freeze the machine (I should know as I've written enough of them). There is one way to find out for sure: my theory says that if you execute an endless string of EI instructions then no interrupt happens (in practice if you execute a few thousand of them with a loop instruction at the end then a similar effect should be achieved). Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section): http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!dish.news.pipex.net!pipex!news.be.innet.net!INbe.net!news.nl.innet.net!INnl.net!hunter.premier.net!news.mathworks.com!newsfeed.internetmci.com!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!mgr11 From: mgr11@cus.cam.ac.uk (M.G. Rison) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 10 May 1996 15:31:50 GMT Organization: University of Cambridge, England Lines: 34 Message-ID: <4mvnh6$2q8@lyra.csx.cam.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4m4pi0$1pl@lyra.csx.cam.ac.uk> <4mso0n$h4m@yama.mcc.ac.uk> <8329.imc@comlab.ox.ac.uk> Reply-To: rison@hep.phy.cam.ac.uk NNTP-Posting-Host: ursa.cus.cam.ac.uk En la artikolo <8329.imc@comlab.ox.ac.uk>, Ian Collier skribis: > [...] > The Z80 enables interrupts at the EI instruction, but does not sample > them at the end of the EI instruction (I can't think of a particularly > good reason why this might be designed in, although it's entirely possible > that at the last clock state of the EI the Z80 doesn't know that interrupts > have been enabled yet (hmmm, though this doesn't happen with DI)). I think I once read somewhere that the reason was that not doing this might just potentially cause stack overflows (if your interrupt handing routine is long, and the next interrupt keeps coming along while you're still handling the previous once, you'd progressively fill the stack with return addresses). I'm not sure how convinced I am by this explanation; I wonder whether it might just be a post-rationalised design bugette... > [...] BTW, while I'm at it, I'll add FWIW that my CPC emulator also does EX DE,HL when it comes across a DD-ed EX DE,HL. Similar behaviour occurs for a DD-ed EXX, and for DD-ed ED ops. In fact, I'll plug my Z80 technical documentation page, http://www.hep.phy.cam.ac.uk:8080/rison/cpc/tech.html , and reiterate my request for comment, correction and criticism. Mark "I'd especially like to know more about F in block I/O ops!" ====================================================================== | rison@hep.phy.cam.ac.uk | Esperanto - lingvo inter-nacia | | rison@vxcern.cern.ch | * Mi estas riisto * | ====================================================================== ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!dish.news.pipex.net!pipex!news.be.innet.net!INbe.net!news.nl.innet.net!INnl.net!hunter.premier.net!news.mathworks.com!news.kei.com!newsfeed.internetmci.com!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 10 May 1996 15:45:21 GMT Organization: Oxford University Computing Laboratory Lines: 25 Message-ID: <8336.imc@comlab.ox.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4mso0n$h4m@yama.mcc.ac.uk> <8329.imc@comlab.ox.ac.uk> <4mvnh6$2q8@lyra.csx.cam.ac.uk> NNTP-Posting-Host: booth59.ecs.ox.ac.uk X-Local-Date: Friday, 10th May 1996 at 4:45pm BST In article <4mvnh6$2q8@lyra.csx.cam.ac.uk>, rison@hep.phy.cam.ac.uk wrote: >I think I once read somewhere that the reason was that not doing this >might just potentially cause stack overflows (if your interrupt >handing routine is long, and the next interrupt keeps coming along >while you're still handling the previous once, you'd progressively >fill the stack with return addresses) You'd have to be pretty unlucky to get this many interrupts between "EI" and "RET" though, wouldn't you? Contrary to what most Z80 documentation says, I think interrupts are lost if they happen during an interrupt service routine, so it's not as if they are queued up ready to activate the moment the EI comes along (unless, I suppose, the hardware keeps the INT line low until it's been acknowledged). Still, better to be on the safe side I suppose... >Mark "I'd especially like to know more about F in block I/O ops!" me too! :-) Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section): http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html New to this group? Answers to frequently-asked questions can be had from http://www.cs.bham.ac.uk/~dmb/speccy/faq.html . Sam Coupé FAQ: http://www.soton.ac.uk/~tsp93/Coupe/FAQ.txt ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!gtnduss1.du.gtn.com!news.gtn.com!genesis.westend.com!news.rwth-aachen.de!newsserver.rrzn.uni-hannover.de!aix11.hrz.uni-oldenburg.de!uniol!uni-erlangen.de!news.dfn.de!newsjunkie.ans.net!newsfeeds.ans.net!news-w.ans.net!newsfeeds.ans.net!chi-news.cic.net!news.math.psu.edu!news.cse.psu.edu!uwm.edu!math.ohio-state.edu!howland.reston.ans.net!gatech!usenet.eel.ufl.edu!warwick!lyra.csx.cam.ac.uk!mgr11 From: mgr11@cus.cam.ac.uk (M.G. Rison) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 10 May 1996 16:10:19 GMT Organization: University of Cambridge, England Lines: 29 Message-ID: <4mvppb$4ht@lyra.csx.cam.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <8329.imc@comlab.ox.ac.uk> <4mvnh6$2q8@lyra.csx.cam.ac.uk> <8336.imc@comlab.ox.ac.uk> Reply-To: rison@hep.phy.cam.ac.uk En la artikolo <8336.imc@comlab.ox.ac.uk>, Ian Collier skribis: > In article <4mvnh6$2q8@lyra.csx.cam.ac.uk>, rison@hep.phy.cam.ac.uk wrote: > >I think I once read somewhere that the reason was that not doing this > >might just potentially cause stack overflows (if your interrupt > >handing routine is long, and the next interrupt keeps coming along > >while you're still handling the previous once, you'd progressively > >fill the stack with return addresses) > You'd have to be pretty unlucky to get this many interrupts between "EI" > and "RET" though, wouldn't you? Yes, hence the suspicion I expressed in my post that this was a post-rationalisation. > Contrary to what most Z80 documentation > says, I think interrupts are lost if they happen during an interrupt > service routine, so it's not as if they are queued up ready to activate > the moment the EI comes along (unless, I suppose, the hardware keeps the > INT line low until it's been acknowledged). ... as is the case on the Amstrad CPC! Mark ====================================================================== | rison@hep.phy.cam.ac.uk | Esperanto - lingvo inter-nacia | | rison@vxcern.cern.ch | * Mi estas riisto * | ====================================================================== ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!news.mathworks.com!newsfeed.internetmci.com!uwm.edu!math.ohio-state.edu!jussieu.fr!news.forth.gr!news-ath.forthnet.gr!news.acropolis.gr!news From: icarus@acropolis.net (..Wind..) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: Sat, 11 May 1996 13:09:00 GMT Organization: La Mafia Lines: 32 Message-ID: <4n23rg$seq@imia.athens.acropolis.gr> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4mfeml$kdd@clyde.open.ac.uk> Reply-To: localhost NNTP-Posting-Host: ppp85.ath-users.acropolis.gr X-Newsreader: Forte Free Agent 1.0.82 rjfm2@student.open.ac.uk (rjfm2) wrote: >Would the above explain why some games (Action Force 2 is a good >example), play ok but suffer from screen corruption? >Rob. That's because they use a specific means for building up the screen you are watching. Instead of calculating screen addresses, a faster way is this: A list of screen addresses, usually consecutive pixel lines from top to bottom of screen, is contained somewhere in memory. A fast way to obtain those addresses is to temporarily store the stack pointer (SP) someplace, set the SP to the bottom of this list and then POP the addresses. After completing the task, the SP is reloaded with the original value. So, if you interrupt this procedure, a Multiface would place a couple of bytes onto the current stack, which means that the list of addresses gets corrupted. You may or may not be able to play the game correctly after this. That's my 2 drachmas - about half a penny's worth on the subject. ************************************************************ Theo Devil -> http://www.acropolis.gr/~icarus Bill Gates, my Spectrum only needs 48 Kb! ************************************************************ ---- Newsgroups: comp.sys.sinclair Path: vanilla!asbach!noris.net!blackbush.xlink.net!howland.reston.ans.net!swrinde!newsfeed.internetmci.com!uwm.edu!lll-winken.llnl.gov!decwrl!sunsite.doc.ic.ac.uk!yama.mcc.ac.uk!viking.ucsalf.ac.uk!news.salford.ac.uk!aber!bath.ac.uk!uwe-bristol!spoon!rff-ribe From: rff-ribe@csm.uwe.ac.uk (R Ribeiro) Subject: Re: Z80 emulation related facts... Message-ID: <1996May11.133416.654@pat.uwe.ac.uk> Sender: usenet@pat.uwe.ac.uk (uwe nntp usenet poster) Nntp-Posting-Host: usenet@pat.uwe.ac.uk (uwe nntp usenet poster) Reply-To: rff-ribe@uwe.ac.uk Organization: University of the West of England. X-Newsreader: xrn 7.04-beta-2 References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4m4pi0$1pl@lyra.csx.cam.ac.uk> <4mso0n$h4m@yama.mcc.ac.uk> <8329.imc@comlab.ox.ac.uk> Date: Sat, 11 May 1996 13:34:16 GMT Lines: 51 In article <8329.imc@comlab.ox.ac.uk>, imc@ecs.ox.ac.uk (Ian Collier) writes: > In article <4mso0n$h4m@yama.mcc.ac.uk>, simonc@jumper.mcc.ac.uk (Simon Cooke) wrote: > >Also: After an EI, the interrupts aren't re-enabled until /after/ the > >next instruction. Kind of screws things up if you do a HALT immediately > >after an EI. > > Not true! > > Interrupts are sampled with the rising edge of the last clock state of each > instruction. HALT is effectively a series of NOP instructions, each one > having a last clock state at which interrupts are sampled. > > The Z80 enables interrupts at the EI instruction, but does not sample > them at the end of the EI instruction (I can't think of a particularly > good reason why this might be designed in, although it's entirely possible > that at the last clock state of the EI the Z80 doesn't know that interrupts > have been enabled yet (hmmm, though this doesn't happen with DI)). If you > write "EI:HALT" then all that happens is it prevents an interrupt from > occurring between the EI and the HALT. It does not freeze the machine > (I should know as I've written enough of them). > Yes, I agree with this. Remember that documented were I talked about the execution phase of one instruction going trough the M1 cycle (1 T-state), and the first T-cycle of the next instruction...this agrees with that. > There is one way to find out for sure: my theory says that if you execute an > endless string of EI instructions then no interrupt happens (in practice if > you execute a few thousand of them with a loop instruction at the end then a > similar effect should be achieved). > No, I do not agree with this. By the second EI is starting to execute, the interrupts have been enabled, and they could indeed happen. This discussions are inspiring...got to modify my emulator to agree with this. So what happens is that the interrupts at the end of EI are not recognized if they were disabled when EI got is decoding cycle. Cheers, Rui P.S. : Ian, you still got a Z80 at home. Would you try to test the EX IX,DE instruction? ------------------------------------------------------------------------------ | Join the army. Travel to | Rui Fernando Ferreira Ribeiro | | exotic lands, meet exciting | | | and unusual people. Then | rff-ribe@csm.uwe.ac.uk | | kill `em. | i890478@idt-isep.ipp.pt | ______________________________________________________________________________ ---- Newsgroups: comp.sys.sinclair Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!dish.news.pipex.net!pipex!tube.news.pipex.net!pipex!lade.news.pipex.net!pipex!news.be.innet.net!bofh.dot!INbe.net!news.nl.innet.net!INnl.net!hunter.premier.net!news.mathworks.com!newsfeed.internetmci.com!newsserver.jvnc.net!newsserver2.jvnc.net!netnews.upenn.edu!news.voicenet.com!news2.noc.netcom.net!noc.netcom.net!ixnews1.ix.netcom.com!netcom.com!dibald From: dibald@netcom.com (Dave Baldwin) Subject: Re: Z80 emulation related facts... Message-ID: Organization: NETCOM On-line Communication Services (408 261-4700 guest) X-Newsreader: TIN [version 1.2 PL1] References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <8329.imc@comlab.ox.ac.uk> <4mvnh6$2q8@lyra.csx.cam.ac.uk> <8336.imc@comlab.ox.ac.uk> <4mvppb$4ht@lyra.csx.cam.ac.uk> Date: Sat, 11 May 1996 15:56:27 GMT Lines: 42 Sender: dibald@netcom5.netcom.com Ian Collier (imc@ecs.ox.ac.uk) wrote: : In article <4mvnh6$2q8@lyra.csx.cam.ac.uk>, rison@hep.phy.cam.ac.uk wrote: : >I think I once read somewhere that the reason was that not doing this : >might just potentially cause stack overflows (if your interrupt : >handing routine is long, and the next interrupt keeps coming along : >while you're still handling the previous once, you'd progressively : >fill the stack with return addresses) All the 'family' from including the 8080, 8085, and the Z80 and it's descendents and the 8086 and it's descendents have a one instruction delay for exactly that reason. I don't believe this was an after thought. The people who designed these micros had access to much more sophisticated machines to model their designs on. And the instruction sets were modeled on 'big' machines before they were put on silicon. The limit was what would fit on silicon at the time. : You'd have to be pretty unlucky to get this many interrupts between "EI" : and "RET" though, wouldn't you? Contrary to what most Z80 documentation : says, I think interrupts are lost if they happen during an interrupt : service routine, so it's not as if they are queued up ready to activate : the moment the EI comes along (unless, I suppose, the hardware keeps the : INT line low until it's been acknowledged). Still, better to be on the : safe side I suppose... Not really. It's typical for a simple hardware interrupt to pull the int line low and leave it there until it's serviced. So all you need is for a second one to pull it low while you're servicing the first and, if you have a number of asynchronous interrupt sources, it's quite likely that they will stack right on top of each other at some time. That's why there are 'interrupt controllers' like the 8259 and the interrupt daisy chain in the Z80 peripheral chips like the CTC and the SIO. They allow you to stack up interrupts and make sure they get processed in the right order. The Z80 RETI instruction resets the daisy chain in the peripheral chips so that the next highest priority interrupt can be processed. And, yes, the Z80 peripheral chips (and the 8259) do hold interrupts until they become the highest priority and are serviced. -- -=-=-=-=-=-=-=-=-=-=-=- Check out DIBs and TCJ -=-=-=-=-=-=-=-=-=-=-=-=- Dave Baldwin: dibald@netcom.com | The Computer Journal 1(800)424-8825 DIBs Electronic Design | Home page "http://www.psyber.com/~tcj/" Voice : (916) 722-3877 | Hands-on hardware and software TCJ/DIBs BBS: (916) 722-5799 | TCJ/DIBs FAX: (916) 722-7480 -=-=-=-=-=-=- @#$%^&* I can't even quote myself! Oh,well. -=-=-=-=-=-=- ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!howland.reston.ans.net!quagga.ru.ac.za!uct.ac.za!iafrica.com!ROCKY!suesound From: suesound@iafrica.com (Rocky) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: Sun, 12 May 1996 23:26:11 Organization: Internet Africa Lines: 41 Message-ID: References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4m4pi0$1pl@lyra.csx.cam.ac.uk> <4mso0n$h4m@yama.mcc.ac.uk> <8329.imc@comlab.ox.ac.uk> NNTP-Posting-Host: slipper141191.iafrica.com X-Newsreader: Trumpet for Windows [Version 1.0 Rev A] In article <8329.imc@comlab.ox.ac.uk> imc@ecs.ox.ac.uk (Ian Collier) writes: >From: imc@ecs.ox.ac.uk (Ian Collier) >Subject: Re: Z80 emulation related facts... >Date: 10 May 1996 14:28:51 GMT >In article <4mso0n$h4m@yama.mcc.ac.uk>, simonc@jumper.mcc.ac.uk (Simon Cooke) >wrote: >>Also: After an EI, the interrupts aren't re-enabled until /after/ the >>next instruction. Kind of screws things up if you do a HALT immediately >>after an EI. >Not true! >Interrupts are sampled with the rising edge of the last clock state of each >instruction. HALT is effectively a series of NOP instructions, each one >having a last clock state at which interrupts are sampled. >The Z80 enables interrupts at the EI instruction, but does not sample >them at the end of the EI instruction (I can't think of a particularly >good reason why this might be designed in, although it's entirely possible >that at the last clock state of the EI the Z80 doesn't know that interrupts >have been enabled yet (hmmm, though this doesn't happen with DI)). If you >write "EI:HALT" then all that happens is it prevents an interrupt from >occurring between the EI and the HALT. It does not freeze the machine >(I should know as I've written enough of them). >There is one way to find out for sure: my theory says that if you execute an >endless string of EI instructions then no interrupt happens (in practice if >you execute a few thousand of them with a loop instruction at the end then a >similar effect should be achieved). >Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section): >http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html The reason Zilog made the Z80 wait one machine cycle was so that the RETurn at the end of the interrupt would be executed before another interrupt could be serviced to prevent stack growth in a high interrupt environment. Cheers Rocky ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!howland.reston.ans.net!swrinde!sgigate.sgi.com!nntp.coast.net!news.kei.com!news.mathworks.com!uunet!in2.uu.net!lexis-nexis!newsjunkie.ans.net!newsfeeds.ans.net!interaccess!thymaster!arturj From: arturj@thymaster.interaccess.com (Artur Jasowicz) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 16 May 1996 04:04:20 GMT Organization: Chips'n'Bytes Lines: 24 Message-ID: <4ne9g4$4o0@nntp.interaccess.com> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4m4pi0$1pl@lyra.csx.cam.ac.uk> <4mso0n$h4m@yama.mcc.ac.uk> <8329.imc@comlab.ox.ac.uk> <1996May11.133416.654@pat.uwe.ac.uk> Reply-To: arturj@interaccess.com NNTP-Posting-Host: thymaster.interaccess.com X-Newsreader: TIN [version 1.2 PL2] R Ribeiro (rff-ribe@csm.uwe.ac.uk) wrote: : P.S. : Ian, you still got a Z80 at home. Would you try to test the EX IX,DE : instruction? So do I, and I tried it with two diferent CPUs, both dd eb and fd eb caused HL and DE to be exchanged (and not IX or IY). That was the case with Z0840006PSC (6MHz) and Z0840008PSC (8MHz). It is still possible, that microcode in original Z-80A did have these instructions. From my understanding these were actually bugs in microcode, unintended by manufacturer. BTW. am I supposed to understand from that "you still got a Z80" that most of you guys only have emulators??? Shame on you! ;) My TC2048 is still in great shape, although I made some modifications to the board. So far only transistor that drives speaker got fried. For historical reasons I didn't want to just replace it, so I soldered replacement on top of original transistor. My keyboard clicks again! :) -- ---------------------------------------------- -- Artur Jasowicz -- -- arturj@interaccess.com -- -- http://homepage.interaccess.com/~arturj/ -- ---------------------------------------------- ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!usenet1.news.uk.psi.net!uknet!uknet!lyra.csx.cam.ac.uk!news.ox.ac.uk!elliott From: elliott@teaching.physics.ox.ac.uk (John Elliott) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 16 May 1996 14:06:12 GMT Organization: Oxford University Lines: 26 Message-ID: <4nfcok$mfg@news.ox.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4m4pi0$1pl@lyra.csx.cam.ac.uk> <4mso0n$h4m@yama.mcc.ac.uk> <8329.imc@comlab.ox.ac.uk> <1996May11.133416.654@pat.uwe.ac.uk> <4ne9g4$4o0@nntp.interaccess.com> NNTP-Posting-Host: teaching17.physics.ox.ac.uk X-Newsreader: TIN [version 1.2 PL2] In article <4ne9g4$4o0@nntp.interaccess.com>, Artur Jasowicz (arturj@thymaster.interaccess.com) wrote: : R Ribeiro (rff-ribe@csm.uwe.ac.uk) wrote: : : P.S. : Ian, you still got a Z80 at home. Would you try to test the EX IX,DE : : instruction? : So do I, and I tried it with two diferent CPUs, both dd eb and fd eb caused HL : and DE to be exchanged (and not IX or IY). That was the case with : Z0840006PSC (6MHz) and Z0840008PSC (8MHz). It is still possible, that : microcode in original Z-80A did have these instructions. From my : understanding these were actually bugs in microcode, unintended by : manufacturer. The Z80 doesn't have microcode. It's hardwired. As for *why* DD EB acts as EX DE,HL and not EX DE,IX, I've seen an explanation somewhere: EX DE,HL does not actually move data about, it just switches the DE/HL (and the DE'/HL') multiplexers. Thus it redirects all future accesses of DE to HL, and vice versa. The DD and FD codes similarly reroute the next access of HL to IX or IY, but since EX DE,HL doesn't access DE or HL it doesn't get diverted. --------------------------- Cutangle CROCODILE 1 John Elliott | \o_~^~ _o \|/ CHAOS in a sig... | | ==@ |\ V --------------------------- /| ;==;< _//\\ A .|. ---- Path: vanilla!asbach!noris.net!blackbush.xlink.net!tank.news.pipex.net!pipex!usenet2.news.uk.psi.net!uknet!EU.net!newsfeed.internetmci.com!usenet.eel.ufl.edu!bofh.dot!warwick!lyra.csx.cam.ac.uk!news.ox.ac.uk!news From: imc@ecs.ox.ac.uk (Ian Collier) Newsgroups: comp.sys.sinclair Subject: Re: Z80 emulation related facts... Date: 21 May 1996 17:11:15 GMT Organization: Oxford University Computing Laboratory Lines: 44 Message-ID: <8348.imc@comlab.ox.ac.uk> References: <1996Apr27.192904.4095@pat.uwe.ac.uk> <4mso0n$h4m@yama.mcc.ac.uk> <8329.imc@comlab.ox.ac.uk> <1996May11.133416.654@pat.uwe.ac.uk> NNTP-Posting-Host: booth66.ecs.ox.ac.uk X-Local-Date: Tuesday, 21th May 1996 at 6:11pm BST In article <1996May11.133416.654@pat.uwe.ac.uk>, rff-ribe@uwe.ac.uk wrote: >In article <8329.imc@comlab.ox.ac.uk>, imc@ecs.ox.ac.uk (Ian Collier) writes: >> There is one way to find out for sure: my theory says that if you execute an >> endless string of EI instructions then no interrupt happens (in practice if >> you execute a few thousand of them with a loop instruction at the end then a >> similar effect should be achieved). > No, I do not agree with this. By the second EI is starting to >execute, the interrupts have been enabled, and they could indeed happen. It should be noted that I have now tested my theory and it does indeed work as I said. I wrote the following program, LD B,0 LP NOP times 10000 DEC BC JP NZ,LP RET set the frame counter to zero and then executed it [on a Sam Coupé with the screen turned off, if you wanted to know]. The frame counter ended up at 89, which is approximately the value you would expect for something that takes about 1.7 seconds plus interrupt time to execute. I changed the NOP to DI, and got zero, which is also the answer you would expect if interrupts are turned off. Then I changed the DI to EI and got 2, which is very approximately the answer you would expect if interrupts were only allowed after DEC BC and the jump (given that the interrupt line stays active for about 100 µs). >P.S. : Ian, you still got a Z80 at home. Would you try to test the EX IX,DE >instruction? Sorry, it exchanges DE and HL. Ian Collier - imc@comlab.ox.ac.uk - WWW Home Page (including Spectrum section): http://www.comlab.ox.ac.uk/oucl/users/ian.collier/index.html New to this group? Answers to frequently-asked questions can be had from http://www.cs.bham.ac.uk/~dmb/speccy/faq.html . Sam Coupé FAQ: http://www.soton.ac.uk/~tsp93/Coupe/FAQ.txt