Hi Ruud, Michał!, IMHO there are too many possibilities, as soon as dynamic rams are in in the picture... especially if their access is directly affected by a number of (basically independent) signals. ; tale mode on ; tale 1.) People who coded demoeffects for C64 and the 264 series usually know, that certain effects sometimes "crash" on some machines, whilst they just work fine on others. C64 programmers would name DMA delay and other DMA related effects. On the TED, DMA delay is usually not exploited, yet, flaky timing can (and sometimes does) still clear and force DMA conditions. On some machines, these effects would crash the demo in just some seconds. Never inspected how all this happens on C64 (haven't been a C64 democoder myself). Back then, I coded demos for the TED... and could meet the effect pretty frequently (due to screen mode switching with flaky timing). Here comes the possibly interesting part: anytime the machine crashed, I could notice the corruption of a position of _each_ memory page. (Ie. if address $xxab was hit, then each addresses of $00ab, $01ab, $02ab, ..., $ffab were all corrupted... the low part of the address was usually nonpredictable). This is pretty similar to Michał's description of how the memory got corrupted in the 610. ...I wouldn't draw conclusions at this point, however. After all that time, I still don't know how/why all that happened... only, that it did. (Note that the machine in question has been a memory expanded C16, with 41464 (64k*4) chips installed ie. the memory was refreshed in 256 cycles; "unfortunately", I could never reproduce the effect on any of my other 264 series machines that had 4164 rams. I still do have C64s that usually crash upon DMA-effects, AFAIK they all have 64k*4 chips, so they wouldn't be a good reference either). ; tale 2.) Some months ago I spent some days by reproducing Hannes Lux' / Christian Schäffners 256k memory expansion scheme for the Plus/4. I re-designed the circuit since I didn't want to piggyback chips in the computer (as the original schema expects), and created a prototype board, still using DIP-packaged HCT ttls. The new circuit didn't work correctly. After some headaches, the ultimate reason turned out to be the 10-15ns extra propagation delay imposed by the 74HCT151 my design used, over the original designs 74HCT257... MUX-to-CAS' delay appears to be time critical a bit here... ; tale mode off All in all, dynamic rams are IMHO a nasty business. You can't be sure of anything, before you did some well-organized tests and measurements. If there are multiple signals in the circuit, that add up to form row address, column address and/or the control signals, you practically can't be sure that timing would be right, and/or the muxed addresses would be correct. One could possibly write some code that triggers the problem, keeps running (reproducing the problem) in a loop, but somehow avoids the consequences ie. it won't crash because of the memory corruption effect; and then, measuring the dram control signals using an o'scope could possibly give some answers. Best regards, Levente On 2011-01-27 07:55, Baltissen, GJPAA (Ruud) wrote: > Hallo allemaal, > > >> If the data on the lines does not go back to zero fast enough, >> it could appear as refresh data. > > A normal refresh would NEVER change the data IMHO. If during a refresh > CAS is enabled as well, and according the right timing, then it isn't a > refresh anymore but a data access. But even that doesn't have to be > harmfull as well. A data access can only be destructive if the WE > (write) line has been activated as well. And if it is a data access, > only one address is involved. Which isn't according the facts :( > > Hmmm, just struck my mind: during a normal refresh WE is always (H) > AFAIK. What happens if WE is accidently enabled during a refresh? Can > that be tested in some way? > > A second thought trail: why $21 and $A1 only ??? The only thing that > comes to my mind is that we find port B of the 6525 at address $21 of > the I/O part of the 8088. If a write to I/O $21 accidently triggers the > RAS line in one or another way, short circuit for example, you have > found your trouble shooter. A real refresh would only read port B which > wouldn't do any harm and therefore would go unnoticed. The only problem > I have with this idea: it would mean an error on the 8088 board and that > would mean that the problem should have shown up on the 720 as well. But > just in case... Message was sent through the cbm-hackers mailing listReceived on 2011-01-27 10:00:03
Archive generated by hypermail 2.2.0.