Re: Hardware-based vs software-based emulation

From: groepaz_at_gmx.net
Date: Sat, 18 Feb 2017 12:52:52 +0100
Message-ID: <2256504.RGKB00u8vd@rakete>
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

-- 

http://www.hitmen-console.org    http://magicdisk.untergrund.net
http://www.pokefinder.org        http://ar.pokefinder.org

boah im ganzen scheiss Internet is nix los, ich such mir bald Freunde wenn das 
so weitergeht!



       Message was sent through the cbm-hackers mailing list
Received on 2017-02-18 12:03:10

Archive generated by hypermail 2.2.0.