Hi! [Marko] > I noticed this old message when I was cleaning up my mailbox. Levente > partially confirmed an old theory on $d011 destroying the RAM contents. > [that was me] >> >> BTW the coil is a 2.2uH one (it was from another broken c64 board). ... >> Maybe, it's too, a good occassion to anyone experiencing such problems to find >> the solution. >> Phew, forget that thing. I bet it worked by accident; some time later, I experienced such crashes again running Second Reality / Smash. I got a bit upset, so I disassembled the unit again. And I seem to found another (now, hopefully working solution). The problem is, say, the VIC pulls AEC' low when R/W' is still low. And since the 6510's bus driver logic goes tri-state, some garbage appears on the system bus while the proc is still in a write cycle. ...Then, what to do? Well, thinking straightforward, any circuit solving this should either delay AEC' a bit, or make VIC unable to pull AEC' while R/W' is low. ...Since I got quite strange results when I tried to make the delay longer, I changed my way and tried the another possibility. Well, what I did is: I piggy-backed a simple 74ls00 4x 2-input NAND gate to an existing chip with bent out pins. I bent VIC's AEC' pin out and inverted the original AEC' signal by one NAND gate. Then I feed this signal to the second NAND gate, and to the other input, I connected R/W'. Now, I got a signal which is equal with AEC' , except R/W' is low (say, always 'AEC' ' except the processor is in a write-cycle). This was my new AEC signal. When testing, this also gave strange results; all times when the VIC performed graphic mask fetch and the processor was in a write cycle, the graphic data was invalid and the screen flickered a lot. ...Then, what? The old problem occured (the memory trash), when the VIC started cycle-stealing DMA. In other words, it never crashed anything when normal graphic data fetch ran, even though the 6510 bus timing seems to be quite 'pipelined' from the side of control-signals. ...If I could find a signal which is equivalent with the 'base' AEC' signal (= high whenever the proc is in control and low when the VIC), that may be a solution, because now we have a signal which doesn't ever crash the memory but is not correct either in all cycles. ..Look, how the bus is shared in the C64. Everything is based on the clk signals. That's based on the experience, but if I take the Phi2 output of the 6510, it seems to be good for the task. Phi0 seems to be too early. Now, I extended the circuit. I took this manipulated AEC' and connected to another NAND input. To the other input, I connected a line from Phi2. ...Now, the output is high if either Phi2 or the modif AEC' is low. Now, all necessary is to invert this output and voila' ! ...We have a line which is low if either Phi2 is low, or (the original AEC' is low and R/W' is high). All I had to do to use this line as AEC' in the place of the original AEC' ...Phew, it's all easier than said. ..I can't say much, but 2ndReal seems to run with no failures... :-) > Maybe adding the coil would even cure the 6569R1 bug that destroys the > RAM contents when switching from hi-res to text (toggling $d011 between > $1b and $3b). Ah, well, sorry for the 'dezinformation' :-(. But, does really the 6569R1 have such a feature? ..I'm surprised 'cos my 8360 TED used to contain it too :-(. Interestingly, it doesn't crash anything as long as the switching happens somewhere in the borders. Demos or intros containing digital music + scroll + multicolor bitmap graphic used to crash because digital zax make correct timing harder (...well, not impossible but most programmers didn't know timing tricks well) and the switching position from $ff06 = $3b-> $1b is often seems to dance like Prodigy --> and the TED appreciates it with some memory faults. Levente Ps. 01 Have you, guys watched Second Reality / Smash Designs? ...I suppose everybody to do so. 02. Hey Marko, tell me, what have you meant by that 'Commodore IDE URL' you mentioned in one of your letters? ..Well, do you know the URL of the stuff? Thx.
Archive generated by hypermail 2.1.1.