Re: RE: RE: RE: How to design non-trivial cartridges for c-64?

From: André Fachat (afachat_at_gmx.de)
Date: 2007-05-28 20:11:35

Hi Bil,

what I am talking about is a board for my slot-based
6502 computer. I have a video board for it, as well as many
other boards. You can even use these boards in a C64 or a PET
using an adapter. 
See http://www.6502.org/users/andre/csa/index.html
The problems I mentioned are from a board I am currently developing,
the RAMDisk board using the SIMMs.

I have written a number of tests and found the problems using
the tests. These problems occur:

1) The test I currently use fill a page with the byte address of the byte
written (write 0 for first, 1 for second byte and so on) and reads it
back. Some addresses are either not written or not read correctly,
I have yet to check that. Using different types of TTL in the decoder
(ALS, LS, F) I found that that making /CAS go high faster
seems to improve the situation - with 'F TTL only two addresses in those
256 byte blocks are "broken". Using 'ALS about 1/8-1/4 is "broken",
and with 'LS much more is "broken". (broken meaning not reading the
value written to it) Could be a situation similar to 
what you described with lines influencing each other. Maybe that is 
also a point for termination, or using PHI0.

2) I have a byte address counter that increments the lowest
8 bit of the dRAM address (before multiplexing) on each 
read or write access, the data
is accessed via a separate data register.
The auto-increment is triggered fine during write cycles,
however, during reads it seems there are spurious spikes on the
counter input, so an address is skipped. This is spurious and
only when reading, not when writing, which is a mystery to me.
I am about to suspect that the dRAM draw to much power during read
to produce a spike, maybe resulting in a ground pin lift. 
I found this using loops of setting the byte 
address to zero and reading/writing 255 bytes, then checking the
overflow output of the counter with my oscilloscope, seeing that
the overflow triggers during reads, indicating
a spurious count. The code uses "LDA abs", not crossing a page
boundary, on a R65C02P4. Changing the single opcode to "STA abs" 
"fixes" it, "LDA abs" is broken. Interrupts are disabled. 
I can work around in the driver by setting the read address
before every read, which is inefficient but works so far.
  
I've asked the webmin of www.6502.org to publish a new tag of my
website, where the RAMdisk is in a hidden directory, it's probably
best to discuss this with the schematics.

I will be able to work on this again next weekend only, though

Regards,
André

-------- Original-Nachricht --------
Datum: Mon, 28 May 2007 12:49:45 -0400
Von: "Bil Herd" <bherd@ids-business.com>
An: cbm-hackers@ling.gu.se
Betreff: RE: RE: RE: How to design non-trivial cartridges for c-64?

> Hi Andre
> 
> Sounds like you have the basics covered.  Problem with deriving mux
> through several inversions is that if the chip is fast, say 1ns, you have only
> 4ns, if it is slow, say 4 ns, you have 16; huge change as parts in a chip
> tend to track each other. 
> 
> The shift register approach is a very usable approach, saved my ass a few
> times (see the 8563 story).  I could even move a wire from tap to tap like
> adjusting the dwell in a car.  Problem is we used one half cycle of the
> 8mhs clock I think, and again frequencies are controlled but not duty cycles.
> 
> I used to say it's all analog, we just call certain voltages after certain
> time periods a one or a zero but it was very analog to get there.  The
> insides of the old NMOS chips even more so, they would pick device sizes based
> on analog parameters to drive digital circuitry.
> 
> An important part of any DRAM development is a GOOD DRAM test, the last
> thing you want to do is catch a dram problem by backtracking a crash.  The
> one problem I told you about where the one bit would get drug along with the
> rest (ground pin lift) was not caught in a DRAM test, it would just crash. 
> I noticed that it often put an "@" sign into a spot in the video memory
> early in the crash so I hooked a light pen to the scope and analyzer and held
> it up to the spot on the monitor where the @ sign would sometimes appear
> and triggered the equipment within one screen time of the write.  I got
> lucky and found the cause within 10 minutes.
> 
> So does your circuit work sometimes, most of the time, or not at all?  Do
> you have circuit timings and schematic I could glance at?  For a good
> description including the math of what I learned an intuitive feel for you might
> want to check out
> http://www.amazon.com/High-Speed-Digital-Design-Handbook-Black/dp/0133957241/ref=pd_bbs_sr_1/103-1146968-2278230?ie=UTF8&s=books&qid=1180370749&sr=8-1
>  I have bought three of these books and give them away every couple of
> years to old friends, young engineers, etc.  
> 
> So is the thing your talking about a video board or a C64 expander?  I am
> kind of confused.
> 
> Regards,
> 
> Bil Herd
> 
> 
> 
> 
> -----Original Message-----
> From: owner-cbm-hackers@ling.gu.se [mailto:owner-cbm-hackers@ling.gu.se]
> On Behalf Of "André Fachat"
> Sent: Monday, May 28, 2007 12:17 PM
> To: cbm-hackers@ling.gu.se
> Subject: Re: RE: RE: How to design non-trivial cartridges for c-64?
> 
> 
> Hi Bil,
> 
> in my computer I already use dRAMs in the (working) video board. I produce
> the /RAS from Phi2 by delaying Phi2 and XORing both. So I have
> two possible dRAM cylces, one during Phi1 and one during Phi2.
> Which works fine for 1Mhz and 2MHz BTW.
> This line is fed to the dRAMs as /RAS, then delayed, fed to the 
> address mux (MUX), delayed again and then switched on/off depending
> on whether the dRAM is selected or not and fed to /CAS. 
> 
> How did you produce the delay between /RAS, MUX and /CAS. I use the
> pretty crude method of using a 7414, i.e. a slow inverter, passing
> the signal through it a number of times.
> [The Phi2 delay for the /RAS used to be done this way to but is now
> done by shifting Phi2 through a shift register with 8 times Phi2 clock
> and then using an appropriate output to XOR with Phi2]
> 
> During Phi1 I have either
> the video address read (from a CRTC - did I mention my computer
> is not a C64, but a self-built and expanded PET replica?) on the
> video board or a refresh counter on the RAMDisk. /WE is 
> setup before /RAS goes low. And I don't use any fancy access mode.
> I try to keep it as simple as possible.
> I ran into the precharge specs with the video card. Timing and
> architecture I think I can cope with.
> 
> But I grew up in a digital world ;-)
> so I do have problems with the noises and glitches.... :-(
> (I probably shouldn't say that too loud, as I am physicist by
> education, so I know the theory, but as you know "in theory
> there is no difference between theory and practice".... ;-)
> 
> It seems I have to also look into the termination stuff again.
> 
> Regards,
> André
> 
> -------- Original-Nachricht --------
> Datum: Mon, 28 May 2007 11:43:00 -0400
> Von: "Bil Herd" <bherd@ids-business.com>
> An: cbm-hackers@ling.gu.se
> Betreff: RE: RE: How to design non-trivial cartridges for c-64?
> 
> > Hi Andre,
> > 
> > There are three aspects to making DRAMs work; absolutely getting all of
> > the timings correct, the environmental aspects of noises, glitches and
> > terminations, the architectural issues such as access mode and DRAM
> organization,
> > refresh, etc.
> > 
> > For DRAM timings you absolutely need a stable source of control signals;
> > you need to be able to generate /RAS, /CAD, /WE and the direction
> controls. 
> > You need to be able to multiplex the addresses to coincide with those
> > major controls, and then you need to cleanly get the signals propagated
> into
> > and out of the arrays.
> > 
> > Lastly, the logical function of DRAM's may not be the same.  The old CBM
> > where the simplest use of drams, we didn't use nibble or page mode
> accesses,
> > we didn't rely on self refresh devices.  With that said I don't know
> what
> > the underlying architecture is of the SIMMS you mentioned.
> > 
> > I don't know what you are doing for DRAM timing signals, are you tapping
> > the VIC chip's signals?
> > 
> > Brief tutorial on olde DRAM use, based on 25 year old memory:
> > 
> > /RAS and /CAS need to go high per the precharge specs
> > 
> > Address set up prior to /RAS per Row Address Setup Spec (I have seen
> this
> > spec blown a lot)
> > 
> > /RAS goes low and addresses are held for Row Address Hold (RAH) time.
> > Only after RAH can you flip the control signal for the address buss mux,
> > we used to create a signal between /RAS and /CAS called MUX for this
> > purpose.
> > 
> > Addresses, Data and /WE set up before /CAS.  You can delay some of this
> > for a late write but you need to know what your doing so best is you
> declare
> > a write cycle prior to /CAS falling.
> > 
> > For reads, data comes out one access time after TCAS (Time CAS Access),
> > there is also a half dozen other specs that determine when data is
> valid,
> > such as the shortest time from RAS, etc.
> > 
> > For a write cycle you have to hold write data per the specs, which are
> > related to CAS not PHI.  As CAS is generally held later than PHI for
> writes
> > you may end up latching the data.
> > 
> > Every now and then you need to generate refresh addresses for the
> dynamic
> > part of DRAM.
> > 
> > CAREFULL layout and series termination of signals is a must.  The one
> > jumper on the C128 production was due to a single reflecting node on one
> > address line when the Z80 was the active CPU.  The jumper is in parallel
> to a
> > trace on the board that is otherwise perfectly fine except there is a
> glitch
> > that "stands" on the line at a certain point in time under certain
> > circumstances.  My boss didn't believe me and ran 10,000 units over the
> weekend to
> > prove that this really did fix the "CPM Loading problem", it was more
> > sensitive on one brand of multiplexers than the other.  Also had a
> problem early
> > on when multiplexing from all ones to all zeros's except for one bit,
> the
> > last bit would get drug to zero also.
> > 
> > As you can see DRAMS are dynamic creatures.  Makes static RAMS look like
> a
> > pretty simple alternative.
> > 
> > I used to say that engineers should have to get certified to do certain
> > parts of a design and that there should definitely be a DRAM badge/stamp
> > before tackling DRAMS for production release.... tricky critters on the
> > outside, very stable once you get your hands around it.  Think of an
> array of
> > capacitors with leakage and you have a DRAM array.  BTW, I have never
> been to
> > school for any of this (electronics or college, etc), it is careful
> study of
> > the specs and then some lumps along the way.  We didn't have simulators
> > back then, we started with timing analysis on graph paper and then later
> used
> > visicalc type programs, there are about 16 specs you need to account for
> > if memory serves.
> > 
> > 
> > Regards,
> > 
> > Bil Herd
> > 
> > 
> > -----Original Message-----
> > From: owner-cbm-hackers@ling.gu.se [mailto:owner-cbm-hackers@ling.gu.se]
> > On Behalf Of "André Fachat"
> > Sent: Monday, May 28, 2007 10:14 AM
> > To: cbm-hackers@ling.gu.se
> > Subject: Re: RE: How to design non-trivial cartridges for c-64?
> > 
> > Hi Bil,
> > 
> > many thanks for the engineering lesson :-)
> > 
> > While I am able to make a coprocessor, or a second processor
> > that takes over the bus on some condition work almost on the first
> > try, I tend to miserably fail with dRAM due to timing problems.
> > So maybe I am one of those you mentioned, who get everything
> > right but... - but then again, I do it for a hobby :-)
> > 
> > Currently I am working on a RAMdisk, re-cycling old 30-pin SIMM
> > memory modules, and I am desperate because I cannot make it work.
> > Probably because the dRAM has much stricter timing requirements.
> > Compared to this, 65xx and 74LSxxx parts seem to be much more 
> > forgiving.
> > 
> > Also the SIMM modules draw a lot of power, and I had to add an
> > extra power supply connector to the board to keep the voltage monitor
> > (7705) from asserting RESET on a low voltage condition.
> > Maybe this power hungryness also puts strains on signal lines...
> > 
> > I will try the Phi0-approch you mentioned, though.
> > 
> > Thanks again
> > André
> > 
> > P.S.: my system is here: http://www.6502.org/users/andre/csa/index.html
> > (the ramdisk is not yet there, though)
> > 
> > -------- Original-Nachricht --------
> > Datum: Mon, 28 May 2007 09:33:03 -0400
> > Von: "Bil Herd" <bherd@ids-business.com>
> > An: cbm-hackers@ling.gu.se
> > Betreff: RE: How to design non-trivial cartridges for c-64?
> > 
> > > Hi Andre
> > > 
> > > Bear in mind that I was from the production world where I had to pay
> > > strict attention to specs or get thousands of failures, not to mention
> > the range
> > > of temperatures, voltages and related part specs that we had to
> account
> > > for. (as it was parts didn't always pay attention to specs and we
> would
> > get
> > > thousands of failures).  You can often get designs to work just fine
> in
> > low
> > > quantities at room temperature under a stable voltage... I.E. some
> > things I
> > > couldn't do will work just fine for experimenters.
> > > 
> > > Using a buffer to hold data valid longer was not a useful approach
> back
> > > then as there generally were no valid minimum times on a chip, I.E.
> your
> > best
> > > off to assume that the output goes invalid almost immediately after
> the
> > > input goes invalid.  I think in terms of data valid propagation and
> > invalid
> > > propagation, hoping a buffer reliably holds the exact same input after
> > > currents start dumping and nodes start discharging is a bad bet when
> > multiplied
> > > times 100,000.  Signetics buffers used to Hi-Z with a vengeance as an
> > > example.
> > > 
> > > A variation on this is where someone will but a buffer between the
> clock
> > > and data lines of a latch hoping to create hold time, problem is that
> > > variations in layout, pin capacitance, etc can result in -1 ns hold
> time
> > worse
> > > case. (not only no delay but negative delay)
> > > 
> > > You also slow things time by the TProp of the buffer so at best you
> pick
> > > up a hold of something like 3ns but slow things down by an additional
> > 20ns.
> > > 
> > > This was a recurring stickyness to 6502 designs, I used PHI0 (clock
> > source
> > > instead of clock output)  a lot and thought about using long traces on
> > > data lines (joke) among other things... more than one engineer got
> > everything
> > > else right except for this part.
> > > 
> > > Bil Herd 
> > > 
> > > 
> > > 
> > > 
> > > -----Original Message-----
> > > From: owner-cbm-hackers@ling.gu.se
> [mailto:owner-cbm-hackers@ling.gu.se]
> > > On Behalf Of "André Fachat"
> > > Sent: Monday, May 28, 2007 8:27 AM
> > > To: cbm-hackers@ling.gu.se
> > > Subject: Re: How to design non-trivial cartridges for c-64?
> > > 
> > > 
> > > > Bil Herd wrote:
> > > > > The area you have to watch is that the data is valid for only a
> > short
> > > > > period after Phi goes low, known as the hold time.  Holdtimes are
> as
> > > > > short as 10-20 ns (shorter if using Phi2) which means that if you
> > have
> > > > > too much logic in line to create the strobe, the data goes away
> > before
> > > > > the strobe (took you longer than 10ns to decide to do something). 
> > > Rule
> > > > > of thumb is the strobe has time for only one level of TTL type
> logic
> > > on
> > > > > anything trying to capture data.  
> > > > >   
> > > > So, for something a bit more time intensive, are there any
> > suggestions? 
> > > > Delay after Phi2 going Hi to start the work?
> > > 
> > > You can delay the data by feeding it through a buffer (e.g. 74ls245)
> > > first.
> > > 
> > > André
> > 
> > -- 
> > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
> > Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
> > 
> >        Message was sent through the cbm-hackers mailing list
> > 
> > 
> >        Message was sent through the cbm-hackers mailing list
> 
> -- 
> Psssst! Schon vom neuen GMX MultiMessenger gehört?
> Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
> 
>        Message was sent through the cbm-hackers mailing list
> 
> 
>        Message was sent through the cbm-hackers mailing list

-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.