9 posts / 0 new
Last post
The MUX signal literally has

The MUX signal literally has to thread the needle between /RAS and /CAS.  If MUX occurs too soon the addresses won't meet the RAS Hold time, too late and the addresses woun't meet the /CAS Setup time. 
On the C64 this was one of teh problems, it's difficult to use an unclocked signal because logic can be faster then expected, specs are usually only for how slow a gate is.  Trying to use the falling edge of the dotclock has issues as the clock has a set frequency but the duty cycle, I.E. the falling edge, can wonder 10% (or more).
Delay lines were too expensive, they cost at least #1 back then, I think more.  We used delay lines in making the towers that emulated chips but not in production on the consumer computers, I think I saw some in the business computers B,D and PETs.
My memory is that the TED used the 14.31818 directly to create an appropriate MUX between /RAS and /CAS, there is plenty of resolution at 14 mhz. 
The MUX also is controlled when it reelases, this is used to hold the R/W signal valid past the end of Phi (7501 clock), mostly because the DRAM timings and the 6502'ish timings are rooted in slightly different timing domains.  Basically the R/W line wiggeling at the end of a cycle would be bad so it's latched.
Bil

Hi Bil,

Hi Bil,
This is a great help, thanks a lot! I was wondering if I want to simulate a ram controller in an FPGA (using external 4464 dram chips and soft 6502 core) how can I create that MUX signal. The 14.31818MHz signal was my idea also (17.73447 for PAL) . I know that it would be easier to use sram for the FPGA but that is not my intention.
The period of 14.31818MHz is about 69.8ns which gives enough resolution only if we use both edges of the signal. I have been thinking in using shift registers to delay the MUX line from phi0. Regarding RAS and CAS producing is an FSM enough that runs on the 14.31818 clock?
Thanks
Hege
 

Hege

Yeah use the falling edge of

Yeah use the falling edge of the clock between the /RAS and /CAS, what the C64 effectively tried to do was use a delayed version of /RAS which wasnt as controllable.

You probably dont need a delay line, you could use  a state machine and create all of the DRAM cycles  (Read, Write, Refresh)

For example you could clock MUX as the falling edge of CLK AND /RAS=0

                               Mux-Flop.JPG

I typically dont use an asynchronous clocks like shown above so you could do something with gates that features some latching feedback to eliminate glitches on subsequent input transitions.  After MUX goes true it will stay valid until the removal of /RAS.  In this instance MUX is shown as a high true signal, it was probably a low true in the TED.

 

Mux-gate.JPG

 

In an FPGA or CPLD you would implement this with equations; in most CPLD's you couldnt have had two clocks (rising edge and falling edge), and in an FPGA it would flag the asynchronous clock and possible race condition of inverting the clock to one flip flop.

Let me know if this helps or is unclear. Have fun with your project!

Bil

Capture

Hi Bil,

Thanks a lot for the help! I have to spend some time on understanding it fully but until that I include here some captures of RAM access from my plus4. I am investigating these signal relations. The capture contains the TED clock (PAL) and phi0 also.

This is a RAM read in double clock mode, only the CPU is active on the bus.

Same as previous but with cursors. Here you can see the needle of MUX between /RAS and /CAS. There is 30ns between /RAS and MUX falling edge and 30ns between MUX and /CAS falling edge.

Same capture with more cursors zoomed in.

I can hardly see here the relation between 17.7MHz and RAS or MUX...

Hege

Hege

Got the point

Hi Bil,
Taking a deeper look into your advise (and read it several times) now I got the point. There are just small differences from real life e.g. the rising edge of phi0 should be used between /RAS and /CAS and the MUX is active low but it is simple to modify the design! This is brilliant idea, now the only thing I have to solve is how the /RAS is activated/deactivated and how the /CAS is activated. /CAS will be the easier, probably for /RAS I have to use an FSM running on 17.7M (or double).
Istvan

Hege

There has been some

There has been some discussion about a memory corruption issue on the C64, when performing an advanced trick called VSP. This trick artificially generates a badline whilst the bitmap generator is in the idle state, with the intent of messing with the counters within the VIC chip, to artificially move the position where the VIC chip "thinks" the memory window starts. 
The bug is described at http://www.linusakesson.net/scene/safevsp/ - and it makes for some interesting reading. I call it a bug, as the corruption could easily occur in normal use of the smooth-scrolling registers, particularly from BASIC.
There is some question as to whether this may arise in the TED series of chips. Does the TED need badlines to get all the data it needs???
 
Callan
 

I read that safeVSP article a

I read that safeVSP article a wile ago and if I recall that had something to do with the dram and its capacitive charge on the data line. Of course the TED has badlines as well (indeed 2 badlines per character) but I don't know whether it is affected with the same bug. It would worth to test it...

Hege

TED attribute fetch

Hege

Log in or register to post comments