On (14 Feb 95) [EMAIL PROTECTED] wrote... s> From: Simon Cooke <[EMAIL PROTECTED]> s> Date: Tue, 14 Feb 1995 10:40:04 +0000 (GMT)
s> *grins* Okay... I'll look at it in more detail.. It's very sempli realy;-) > s> Ah, but the /RFSH line is the problem -- it doesn't appear to refresh > s> often enough... s> The problem that I was thinking of is the frequency of WAIT states s> buggering it up -- and what if an external device uses BUSREQ too? That was the reason for me shelving the ZilogDMA daughter board as although it'd provide a potentially very fast memory to memory xfer method it fails to generate any refresh cycles in it's faster modes ie when it grabs the bus until terminal count is reached. This means that the size of data moved would have to be restricted to allow refreshes to occour as the next block of params' were loaded into the DMA, thus making it not worth the investment... The WAIT state situation is as it was on the speccy and any other DRAM'd z80 machine ie /WAIT must not be asserted for more than about 1mS at a time.. As in the example I gave 64000 Machine-code instructions per second is a minimum speed that'll safely refresh DRAMS transparently. BTW that ASIC reset 8MHz clock loss bug also affects the 6MHz CPU clock and causes some bits to lose their memory during a hard-reset. I think many inconsistancies in the SAM could be fixed by simply stealing some of the 24MHz master clock and hard dividing it externaly and usin that to replace the 6/8MHz clock signals. Also could use a 12MHz output for when I can get hold of that Z84C50 CPU;-) s> Yeah, but could it be the IORQ & M1 both going low at the start of the s> interrupt that causes the problems? Could the ASIC be receiving spurious s> IO read/writes? It shouldn't as that's the standard z80/8080 interupt acknowledge cycle, in ALL modes, Bruce MUST've known that for years before the ASIC was designed and as the ASIC is the only current source for interupts to the z80 it shouldn't be looking for any I/O whilst it's interupting the z80... Anyway I'd expect that IORQ would have to be qualified by a corisponding RD or WR signal prior to initiating ASIC port decoding... Though only Bruce would have such insider details:-( You could test the theory by using an active M1 to disqualify the active IORQ to the ASIC. I don't think it'd make any difference. Oh thanks for explaining to imc about zilog peripherals and RETI, saves my typin:-) Regards Johnathan. ... I wrote my own benchmark. My machine is now 500MHz! -- |Fidonet: Johnathan Taylor 2:2501/307.9 |Internet: [EMAIL PROTECTED] | | Standard disclaimer: The views of this user are strictly his own.
