9 posts / 0 new
Last post
TED internals

Hi,
While the VIC-II chip has a very good documentation on zimmers none has created a similar document for the TED. I would like to understand the internals of TED so I started to analyze the signals inside a plus4 with a logic sniffer. One critical part is the timing on the system bus between TED the CPU and the memory (bus protocol). One thing I don't understand is how the MUX signal is created by TED from the clock signals (using the 17.7Mhz PAL or 14.3 NTSC clock?). Does anyone know whether there is any rule how to produce the MUX signal? Any logic equiation? As I can see it this is similar to a clock signal but it doesn't have symmetric duty cycle. It is somehow tied to the CPU clock and most probably delayed with half a CPU clock cycle. Bil do you have any idea how to produce it? Does it use phi1 and phi2 clocks which are not produced by the 7501 CPU but maybe the TED internally? Also, how is RAS and CAS related to the MUX signal?
Any hint would be good!
Thanks
Hege

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
While there are very good emulators on the TED chip (with source code available), plus my logic analyzer + scope measurements, one of the most mysterious part of TED is the attribute and color/char pointer fetch mechanism. We know that there are internal buffers for storing the fetched attribute and character information for 8 scan lines but how are these buffers internally managed? As the attribute fetch happens on the last scanline of a character row (scan line 7) TED must store these to different buffers than the the preceding character row's attributes otherwise the last scanline of current character row would have incorrect attributes. Emulators solve it with additional temporary attribute buffers but I feel it is solved in a different way in the real HW. Another interesting question is why is there always a one cycle (single clk cycle) delay in events happening based on horizontal counter locations. Something must be related to internal multiplexed architecture. Bil, if you still have connection to original chip designers (Diorio), I am not sure whether they still remember the details but would be good to ask these and give us some hints, directions. I am really interested in how the horizontal and vertical counters are implemented inside (plus their user readable/writable registers). Also would be good to know whether they used any FSM inside and for which parts of the chip. Thanks Hege

Hege

Log in or register to post comments