On 02/18/2017 01:14 PM, HRSFALVI Levente wrote: > On 2017-02-18 12:52, groepaz@gmx.net wrote: >> On Saturday 18 February 2017, 12:48:15 Gerrit Heitsch >> <gerrit@laosinh.s.bawue.de> wrote: >>> On 02/18/2017 12:22 PM, groepaz@gmx.net wrote: >>>> On Saturday 18 February 2017, 12:15:01 Gerrit Heitsch >>>> >>>> <gerrit@laosinh.s.bawue.de> wrote: >>>>> On 02/18/2017 12:08 PM, groepaz@gmx.net wrote: >>>>>> On Saturday 18 February 2017, 12:01:05 Gerrit Heitsch >>>>>> >>>>>> <gerrit@laosinh.s.bawue.de> wrote: >>>>>>> On 02/18/2017 09:38 AM, groepaz@gmx.net wrote: >>>>>>>> On Saturday 18 February 2017, 08:24:26 smf <smf@null.net> wrote: >>>>>>>>> On 17/02/2017 20:26, Gerrit Heitsch wrote: >>>>>>>>>> That can be fixed by using a static RAM instead of DRAMs. >>>>>>>>> >>>>>>>>> It can be fixed by latching signals as well. >>>>>>>>> >>>>>>>>> My point is that a 100% VIC II in an FPGA would have the VSP >>>>>>>>> problem, >>>>>>>>> or >>>>>>>>> it's not 100%. AFAIK vice doesn't have the VSP problem either. >>>>>>>> >>>>>>>> actually x64sc can emulate it :) (its optional, "VSP Bug >>>>>>>> Emulation" in >>>>>>>> VICII settings) >>>>>>>> >>>>>>>> and no, the problem can _not_ be fixed (only) by using SRAM - >>>>>>>> that was >>>>>>>> tried and proven wrong long ago. its an urban myth that doesn't >>>>>>>> want >>>>>>>> to >>>>>>>> die :) >>>>>>> >>>>>>> Well, the VSP-Problem happens because DRAMs use destructive readout, >>>>>>> meaning even a read cycle has to write the data back to the >>>>>>> cells. This >>>>>>> happens inside the DRAM once /RAS goes high. This is not the case >>>>>>> with >>>>>>> SRAM, a read cycle will just read the contens of a cell without >>>>>>> destroying them. So when you have a problem with address lines >>>>>>> changing >>>>>>> while /RAS goes down and your latch latches the wrong address, you >>>>>>> might >>>>>>> read the wrong data, but you CANNOT destroy the RAM contents this >>>>>>> way >>>>>>> as >>>>>>> you can with DRAM when you confuse the row decoder. >>>>>>> >>>>>>> I have done a SRAM replacement for the C64 using a 128KB SRAM, a >>>>>>> 74HCT573 and a 74HCT32 and so far no one was able to detect the >>>>>>> VSP bug >>>>>>> when using it. >>>>>> >>>>>> as said, others have done it too and found that the VSP bug still >>>>>> exists >>>>>> - >>>>>> to remove it for certain you must add an additional circuit that >>>>>> prevents >>>>>> those writes to wrong addresses from happening. (but then, with such >>>>>> circuit, you dont need sram) >>>>> >>>>> Again, there are NO writes, VIC only does read cycles, its R/_W >>>>> line is >>>>> input only and you cannot destroy data in an SRAM with a read cycle. >>>>> >>>>> VSP destroys data due to the way DRAM works. >>>>> >>>>> Got a link to where someone claims to use an SRAM and still have VSP >>>>> problems? >>>> >>>> zero-x tried it iirc, you can find him on ircnet #c-64. >>> >>> Doesn't really help me, a link that describes the test and the circuit >>> used would be much more helpful. When I did my experiments with SRAM to >>> replace the DRAM in a C64 it was never really stable until I added the >>> OR gate to the circuit. Since then it's running perfectly. >> >> you'll have to ask him, i dont think he wrote it down >> > > FYI > > http://www.linusakesson.net/scene/safevsp/ > > Doesn't discuss whether a sram could be a fix though. Yet it (as it's > also referencing Zer0-X's work) might be a good place to start. It also shows quite clearly why an SRAM shouldn't show that problem. In order to use an SRAM, you need to store the row address in a latch, in the case of my circuit a 74HCT573. But even if you can get that into a metastable state and have it fire changing addresses at the SRAM, the SRAM won't care, it will just select the location represented by the levels on the address pins and have the contents of the selected cells appear on the output pins. But since there is no destructive readout as in a DRAM, the data in the cells stays what it is, the only thing that can happen is that VIC reads garbage data. That might cause some flickering on the screen, but will not influence the CPU and won't cause a crash. When using an SRAM in a C64 it is important to remember that even though VIC takes /RAS and /CAS high at the same time, /CAS is routed through the PLA and therefore delayed. Meaning it stays low while /RAS going high frees the latch. So you cannot use just /CAS as /CS for the SRAM, you have to use (/RAS OR /CAS). If you don't and your SRAM is fast enough, you will have data corruption. Gerrit Message was sent through the cbm-hackers mailing listReceived on 2017-02-18 14:00:03
Archive generated by hypermail 2.2.0.