I'm using a UM6502 chip. This question arose just when I was devising the software part before interfacing the actual hardware.

TMS9918 interfaces to the cpu with following pins,
MODE : Used to differentiate between VRAM access and Register access
/CSR : Low active read signal
/CSW : Low active write signal
CD0..CD7 : Bidirectional data bus connection
/INT : Interrupt generated every screen retrace

For read & write accesses datasheet states that
"The CPU interacts with VRAM memory through the VDP. The amount of time necessary for the CPU to transfer a byte data to or from VRAM memory can vary from 2 to 8 microseconds."

Even 2 microseconds is too slow for 6502 which actually does memory access much under half a cycle (0.5 microseconds)

What should one do in this scenario? Use latches and extra logic for timing and use NOPs when accessing the chip? Use peripheral i/o chips? Or is it possible to accommodate for it solely in software?

I would guess that this is the time required for bytes to transfer in the DRAM. This is not the same as the time a pin needs to be in the active state. How quickly can the code write bytes? In other words how quickly can:



write into the port? Of course usually you will be reading from memory between the stores.

_________________
8 bit fun and games: https://www.aslak.net/

This may be true for write accesses since the chip possibly latches the data already. But for reading effectively you need to wait whatever chip does.



From 6502's internals perspective it takes half a cycle to write or read memory. Chip select signal you decode from the memory mapped address of VDC will be at most half a cycle (much shorter possibly). So it's not a matter of how long the whole instruction lasts but how long cpu puts the address of the VDC on the address bus. (Which you'll use to decode the VDC's write enable or read enable lines.)

I checked the datasheet and it looks like you'd need some hardware support, to stretch the clock or at least to stretch the access. From p82 of http://www.cs.columbia.edu/~sedwards/papers/TMS9918.pdf

@BigEd : Thanks.

It's interesting how did this guy that used 65c02 in his project never faced this issue.
https://hackaday.io/project/5789-6502-homebrew-computer

I don't think 65c02 will help in this regard since VDC doesn't acknowledge an access with an extra output pin that can be used to stretch the clock or stall the cpu.

I guess the problem is only faced if one tries to read from memory interfaced to VDC which there is not much need to.

We can ask about that... over here.

Wait-states.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Or maybe not?

From the datasheet, 2-4:

"The VDP requires approximately 8 microseconds to fetch the VRAM byte following the last data transfer, and 2 microseconds following following address setup."

This matches my experience of using the V9958 on my 2MHz E-clocked 6809, which had no problems keeping up. I've seen others eg. Matt Sarnoff's Ultim09 use the 9918 in a similar clocked computer without wait-states or other complication. The Colicovision, which used the TMS9918 and a Z80 had no special logic, just regular decoding.

Reads and writes are double buffered, in and out of the VRAM. When you are asserting to read, the VDC is pushing the byte which was read out of the DARM and into the VDC on the previous read. There is no reason why it would be slow because of this buffering. That table in the datasheet says one thing. But the text says something rather different.

_________________
8 bit fun and games: https://www.aslak.net/

Hi Folks, BigEd posted a question about this to me, as I am the guy on the Hackaday link above with a working 65c02 driving a 9918.

So I am not using any special wait states, clock extending etc. circuitry at all, it is not required (as alluded by aslak in the last reply). But I am only running my 6502 at 2.68Mhz at the moment, not sure it will drive the VDP reliably above this.

I don't have a schematic, but simple to describe:
- 6502 D0-D7 connected to CD7-CD0 (remembering that the bits are numbered in the opposite sense to the 6502)
- 6502 A0 connected to MODE
- For chip select, CSW and CSR remain high when the VDP is not to be selected, else R/W connected to CSW, with the inverted signal connected to CSR. To do this I have a decode which outputs Low when the VDP is addressed by the 6502, and this decode is inverted and then NANDed with the R/W and inverted W/R signals before being fed to the VDP CSW and CSR line.

This works because:
- The timing requirement for CSW is 200ns nominal. As the 6502 accesses on half cycle time, then I guess this means my total 6502 cycle time cannot be more than 400ns. This is 2.5Mhz, a little bit slower than the 2.68Mhz I am driving the 6502 at - but not sure whether the term 'nominal' means that CSW could be pulse low for a significantly shorter time.
- The timing requirement for CSR is that data becomes valid no more then 150ns after CSR is low. This is a shorter half cycle than CSR, potentially means 6502 access could be faster for read rather than write.

So the manual then has some words about 2us to 8us cycle time. I think this is misleading because I believe the VDP works as follows:
- the VDP must internally latch the access based on MODE, CSR, CSW and latch any input data present on CD7-CD0
- the VDP then takes between 2us and 8us to perform its internal operations to set or read VRAM
- additionally, the VDP must be reading the first byte in readiness when it is provided a VRAM address to start reading from

Therefore, what is needed is that between 6502 accesses, one needs to wait between 2us and 8us (depending on the screen mode). I just use a bunch of NOPs.

Here's why I think the internal operation works as above. When I was first trying to get the VDP to work, I didn't have enough NOPs. The operation of the VDP is that one can send the VRAM address and then do successive reads or writes which auto increments the address pointer. When I didn't have enough NOPs, I would end up writing to the same VRAM address (which I could tell because my font initialisation was sometimes creating odd looking characters). When reading too fast, the VDP just gives the last successfully read VRAM byte on CD7-0.

There is nothing of note to show in the code. Basically to read a byte, I use LDA MODE0 followed by 5 NOPs. Then I can do another read and the VDP will give me the next byte.

I still don't know the difference between a nominal and a minimum timing requirement, and whilst I think a 6502 at significantly more than 2.5Mhz will be too fast to interface directly, I haven't tried it - but one of my thoughts is to try and drive around 4Mhz to see what occurs (but I can't do this yet as have other things to upgrade which won't work at that speed).

I hope that helps - ask away if I haven't made sense!

Cheers, Dolo

@dolomiah, @Aslak3 : Thanks for all the precious information. Now it's all clear for me. 2us to 8us access times actually relevant to software side as I see. I don't need to delve into stalling the cpu or stretching the cycles to get the access times right.

I've built the sram interface on a breadboard. I'm using a 10.734Mhz crystal (which is in the %0.005 margin mentioned in the datasheet). I've built the cpu interface to the arduino. Got no display

The question is : What is the minimum setup to get a display from this chip? Is VRAM and cpu interface necessary?
What is the result if a crystal used that produces clock slightly out of range as specified by the datasheet?

ps : As I'm using an 9929 actually I measured the clock generated at GROMCLK which is Main clock/24 and it changes between 444.4Khz and 452.8Khz with the crystal I'm using. That makes it in the range 10.665 Mhz - 10.867 Mhz. Both frequencies are not in the range provided by the datasheet. (%0.005 accuracy makes the range 10,684Mhz - 10,791Mhz )

Hi i_r_on. Sounds like you're at a stage I was at a few months ago when trying to get the TMS VDP to go with something minimal to prove it was working.

From memory, a few things to consider..

Clock:
- I use a 21.4xxMHz clock and then a counter to divide by 2 to get the frequency for the VDP. I couldn't get hold of a 10.7xxMHz clock but had double the frequency hence using that. I think that might have helped to also get a sharper square wave output by putting it through a counter. I assume you're using the reference design in the manual where the 10.7MHz crystal can be connected directly to the XTAL pins with some support capacitors and resistors?
- I wonder why the video clock is so variable? I did have variable frequency issues initially, and put it down to poor build - I made sure all wires had good contacts (as far as I could tell) and there were smoothing caps on everything. But in general, there really shouldn't be anything near that level of frequency variability, so double check your crystal clock circuitry (are you getting a consistent strong square wave out?), as you will not get a stable picture with that level of change. I don't think the VDP will care much with the clock being outside of tolerance, the problem is going to be that many monitors may not lock on to the horizontal and vertical sync.
- One weird thing I did have was that my 'scope affected the clock - without the scope I would get a picture, with the scope not! Things are fine and stable now, but capacitance and interference are things to be wary about I feel.

Minimal set up:
- I started with the minimum set up to check the VDP was operating, without any CPU or VRAM. So feed it a 10.7Mhz clock, tie CSR and CSW high and then yes check GROMCLK frequency. You could also try watching Y on the scope - you should get a pattern which has a burst every 15KHz which represents the horizontal sync (the manual has example h and v sync diagrams to reference).
- Once I was happy that the VDP was clocking at the expected frequency, I connected the CPU but no VRAM. Then I could check that the CPU was talking to the VDP by setting the graphics mode to Text (register 1), and the colour register to a colour I wanted (register 7). This should allow you to connect the VDP to a monitor and check that you're actually getting the background colour you expect, which proves that your CPU can access the VDP and the monitor is locking to the VDP output.

I had a TMS9918 and a TMS9928 - both seemed to work fine, however I decided to go with the 9918 because it has composite output, which although may not be the last thing in video quality, was plenty fine for me and avoided a bit of extra wiring compared to getting component output. However, the 9918 and both work fine with the same software and you can replace one with the other - you just won't get any colour from a 9928 if you feed it in to a composite input.

Cheers, Dolo

In the datasheet there is only series capacitors from XTAL1 and XTAL2 to ground. I guess resistors are used when an oscillator is used instead.

Actually frequency change has a consistent pattern. Maybe it's just because I use a 24Mhz logic analyzer. I don't have a scope.

It goes like this,
LLLLHHLLLLHHLLLLHHLLLL (where L = 444.4khz half cycle, H = 452.8khz half cycle)

I use component input of my LCD tv and currently only using Y output from the chip. A friend suggested I better drive the component luma with an external transistor circuit instead of getting it directly from the TMS chip.

It would be better if I purchased TMS9918 instead of this 9929 chip since I was curious to implement the external video input feature.

Thanks for all the information by the way, it's very valuable.

ps: I got it to display a black image with lots of vertical gray lines. The culprit : a broken connection on video line.

Here is a video of the display, lots of vertical lines. (Only luma is connected, later I got a color display too)
http://www.youtube.com/watch?v=1CjWzx8yxoA

Yes, you're right there are only capacitors in the manual, I was trying to recall from memory. Still, it's strange you're getting a variable half cycle time, it might be just an artefact of the logic analyzer, because if the monitor is locking on to the Y output, then I would have thought the horizontal sync is stable enough. I am taking the signals straight off the VDP by the way, not using transistors to boost the output (but I am using the design suggested in the manual), so you may not need to do any more than that - and I am using a pretty standard Toshiba LCD TV.

Well it looks like you're making progress - next step is to see if you can send the VDP instructions to change the colour? Another way to check is to set register 1 to enable or disable interrupts and then check the interrupt line to see if you're getting a 60Hz pulse when interrupts are on.

Good luck, look forward to seeing your project develop!

Actually I'm controlling it using an arduino at the moment, you can see it in the video below

http://www.youtube.com/watch?v=1CjWzx8yxoA

My aim is to use this video chip in a custom arcade game. Eventually I'll use WDC 65c02 parts. I consider using an MVC approach to hardware where display & audio chip is controller by a separate cpu from the main controller cpu. I'll use SID chip for sound.

This is a very interesting thread!

I've worked on various TMS9918 ideas/circuits in the past. Nothing really came of it because I keep changing my mind on my final design...I've mostly tried to build a TMS9918 emulator for the Propeller.

Anyway, I have a PDF file from BYTE magazine from years ago that talks about building a video card using the TMS9918 and the Apple II. Even has example 6502 asm for clearing screen, etc.

Send me a PM if you're interested in the file. Might be useful for information since the Apple II used the 6502.

_________________
Cat; the other white meat.