hi all,
Since completing my SBC based on the 65C02. I've now starting work to design an Video adapter using the V9958 (as used in the MSX2 computer). I've done some web searches and it appear no one that I can find using V9958 with 6502.

My plan is to have V9958 using simple 1 or 2 SRAM chip with some latches to interface to the V9958 DRam interface. Any help or comment will be very much welcome.

As a start I've designed and produced a breakout board so that I can use 0.1" pinout configuration. I've attached the Gerber file in case if anyone else would like to get the PCB make.



eddie

I've been collecting documents and schematics based around the TMS9918 for a while now.

I know the 9938 and 9958 are newer but still fall into the same family.

If you come up with some schematics, I'd sure love to put them in my repo if you wouldn't mind.
There is a schematic that might help in my repo that shows how to use SRAM with the 9918.

Good luck!

https://github.com/cbmeeks/TMS9918

_________________
Cat; the other white meat.

thanks for the info.

hi all,
I've done more research and have put a design together using DRAM for now (planned to use SRAM in the future). The design will have 192KB vram and a VGA output.

Any comment or advise will be most welcome.

thanks,
eddie

I'm not seeing a lot of connections. Are some of the lines blue?

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

Yes, most of the markings are blue. I've attached a converted version, though I'm not sure how well a two-page document works as a PNG.

You really should find yourself a way to display things as monochrome. Blue should turn out as a dark grey.

hi all,
I've attached black & white version of the the pdf document for better viewing.

thanks,
eddie

To be fair, even for people who are not colour blind (my employer insists on testing me at every medical and apparently I’m normal, I often joke with the nurse that I’m far from normal ), some of these multicoloured schematics do my head in.

The different bright colours can be distracting, and if you try to print the diagram out, you either need a colour printer (with all the cartridges operational). Or printer driver for your monochrome printer that is actually good at producing sensible gray shades (not all are).

You just can’t beat a well laid out schematic diagram that is clear, no overlapping symbols or text, uncluttered, easy to understand, puts blocks that are relevant next to one another and is easy on the eye. There should be no need for colour. My feeling is, if you need colour to ‘make it work’, then your schematic diagram is poor.

The only time that I deliberately set out to use colour, is when I want to show existing circuitry and modifications on the same diagram (for example when documenting wires added to an existing PCB to overcome a mistake in the track layout or when changing the design for any other reason).

Sometimes I use colour if there is something that is really important that needs highlighting and bold text alone is not enough (high voltages for example).

Not all, but often if you look at the hand drawn schematic diagrams from the past, the person that drafted it took pride in making the diagram clear, logical and easy to read.

Far too often nowadays, a schematic is nothing more than a bunch of rectangles with text listed around the sides. Often much time can be wasted hunting for the ‘other end’ of a signal as you cast your eye around looking for a match. It’s fair enough if a signal line is part of a bus (address bus, data bus etc.) to put them in a group.

But for independent signal lines, or control lines, I much prefer an actual line to follow. Or alternatively if there are only two nodes, for the text to indicate the source or destination of the signal (at each end).

It’s a similar story when choosing whether to depict a chip as a rectangular box, or a symbol that enables the reader to more easily recognise the function. So I prefer the American logic symbols for example.

</rant ends>

Mark

I try to strike a happy medium between "mess of wires" style and "netlist" style in my diagrams.

Using the bus tool in KiCad helps a great deal, as otherwise I potentially have to route 24 address and data lines to multiple devices sharing the main CPU bus. The single bus line (or alternatively, one for address, another one for data) is sufficient to lead the eye in the right direction. It also makes sense to bundle select and control lines into a bus, if they are logically grouped, but see below.

Since that takes care of the majority of global signals in the system, a relatively small number of labels are then relatively easy to follow. There are both input and output style labels, giving a visual distinction between circuits where a signal is produced and consumed. I often use these for power, clock, interrupt, R/W, /OE and /WE lines which have to go pretty much everywhere.

The distinction between logical and physical pin layout can be debated. To illustrate one extreme, why don't you try to figure out, at a glance, what the attached circuit (sketched the other day in Digital) is supposed to do?

I can't read it.

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

The point is, the diagram shows the various chips as DIP packages, labelled only with their part numbers. Unless you're a walking parts catalogue, you won't know which ones are RAM, ROM, shift registers, latches, or multiplexers - the only immediately identifiable component is the XOR gate, which is meaningless without context. Maybe you could guess some of them by looking at the pin labels, but that's a very inexact science. And because of the physical pin layout, routing the signals is especially awkward visually.

KiCad's symbols are usually more logically oriented, though they're still based on a particular physical product. This means you can efficiently use it to design a logic system, rather than merely simulating an existing one. Unfortunately, it then lacks the simulation part entirely, so it's much harder to check your work without actually building it.

I'm wondering if this will work. Doesn't it require 128KB of VRAM and 64KB of DRAM? I've not gone through the entire spec sheet, but it seems VRAM needs separate data in and data out buses at least, or am I out to lunch? I've only seen this chip used with 4164 style DRAM which can be configured that way.

I'm most likely mistaken though, but willing to learn.

_________________
Bill

thanks for taking time to look over my design. I am also learning on the go as well.

As far as I've worked out from my research, V9958 required minimum of 128kX8 DRam (maximum 192kX8) to work. So currently I will use 6 x 64kX4 Dram. As far as I can tell it uses regular DRam only.

thanks,
eddie

I designed some v9958 cartridges for the c64 and vic, and even made a run of pcbs, but they had errors and i just let the project slide. Later i found there is a issue with read-modify-write opcodes on the 6502 that interfere with some of the v9958 functions so i need to do a redesign of my boards.
http://www.6502.org/users/sjgray/projec ... index.html

Christian Forstrueter has successfully created a v9958 board for Commodore b-series (6509 cpu).
You can find info on my cbm2 Facebook group.

Use of R-M-W instructions on any hardware register is considered bad programming practice, regardless of MPU. As you have discovered, the 6502 does a dummy write before it does the real one, which can cause a lot of trouble in some cases. The 65C02's behavior is to do a dummy read followed by the actual write, but that too can malfunction in some cases. Better to not use any R-M-W instructions on hardware.


I thought all the B-series machines were in landfills or museums. Also, where does one acquire a V9958? That's ancient silicon.

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