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

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.

- 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?

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.

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).

I was into other things so I put this project aside for a while. 4164 dram chips I ordered recently arrived and I'll revisit this project. With the lousy interfacing I was not able to properly build the sram interface. Maybe it was the software that was problematic but now I want to try it again with these dram chips. The connections will be much more straightforward.

The question is : Would I be able to bankswitch this 64k dram into 4 16k segments? Considering the address input to these dram chips are multiplexed. I guess I'd need a 2 to 1 multiplexer with it's select line tied to either RAS or CAS? Do you think that will worth the effort when using this chip?

Using the 4164 to replace the 4116 as far as the read write timing etc goes seems to work fine. I've used one on a board already wired for the 4116 as seen here http://www.primrosebank.net/computers/mtx/projects/mavram/mavram.htm

Running this setup I've had no data loss issues from that particular chip only getting 7 bits of refresh as a result of the surgery to make it fit the board.

Though that might be an issue if you were attempting to make use of all 64k, as only the active bank would be refreshed. Someone more up on Dram might be able to confirm that.

You could make things so much simpler by just going for a V9938 or V9958 and some DRAMs.

http://www.ebay.co.uk/itm/351494243872 - 10 lots of 64Kx4bit DRAMs, $10.39 inc. shipping

http://www.ebay.co.uk/itm/360806353409 - 1 lot of V9958, $8.99 inc. shipping

The only complication is the fact that the IC is shrink DIP so sockets are a bit pricy.

http://www.ebay.co.uk/itm/391314851450 - 2 lots of Shrink DIP64 socket, £6.46

Assuming you were to prototype this on breadboard, you'd want some kind of adapter. I made my own, or you can buy them, though they are hard to find.

The blogpost documenting my success in prototyping up a V9958 with my micro:

http://aslak3.blogspot.co.uk/2014/09/pc ... rupts.html

EDIT: the are other advantages, beside the DRAMs, with the V9958. The main one for me was that it has an 80 column text mode, but there are many more features beside that.

Apologies if you have absolutely no interest in anything but the 9918.

The TMS9918 circuitry can't support the TMS4164 (32K x 4) DRAM chips. Can it???? Is that what you're now using 4164 (32K x 4) DRAM?

Do you have the layout part for the TMS9958 chip that I can use in EagleCAD or something? Thanks!

Here is the code I use to interface to the chip

@cbmeeks : Thanks for the documents!