Re: 8088 and 610 saga continues...

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 list