Hello,

well, after a bit of reading I now will probably use a V9958/38 or similar (was compatible to TMS 9918). The VIC seems to compliocated to use and the extra Video RAM seems to be so much better that it is worth buying a new chip.

Now I would like to have some helpful hints (would be great) on how to connect a modern RAM like WS6264 https://cdn-reichelt.de/documents/daten ... LLP-70.pdf to the V9958/38 ? My question is row an column decoder is already in the chip. Furthermore V9958 expects data and adress on the same bus. How could this be adapted ? Is there any solution/idea/note on the internet ?

Thank You once again, I'll keep you informed.

vespacla

Hi vespacla

the RAM you linked is a static RAM, however the V9958 expects dynamic RAM you better take something like four 41464 (4x64k dynamic RAM), here is a schemtic of a MSX2 computer http://fabf38.free.fr/diy/upgrmsx2/ct80msx2.png as the V9958 takes care of all the requirements for dynamic RAM.

Cheers

Peter

The circuit I use, using 41464s, is on my blog. While you could probably create glue logic to allow you to use static RAMs, it seems like far too much of a complication to me.

10PCs of 41464 for £9 from good old UTSource:

http://www.ebay.co.uk/itm/171471828904

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

Or even better, there are complete kits http://www.ebay.de/itm/TMS9900-DIY-Homebrew-microcomputer-kit-with-V9958-VDP-/121437344975?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item1c463ad4cf, even if you don't need all ICs the kit is cheaper than individual parts

I've used the 6561 VIC and it could produce 26 column video before the text exceeded the screen width, with 32 character rows before it exceeded the screen height. Intrestingly, I had no problems producing a 26x32 display, even though the data sheet says that the device can't handle a video size that exceeds 700 characters! 26 character columns is still too small for any sensible text editing.

However, the 6561 VIC is only practical you use it exactly as designed, ie with the CPU slaved to the video chip's clock and running at a slow 1.108MHz. If you want your CPU to run faster, forget using the 6561, the interfacing difficulties are huge.

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!

Thanks for the schematic, I hadn’t found that one. I’ve build a similar circuit, but the RGB output is different on this schematic, and worth trying to improve the picture quality.


Did you also use the 6569 VIC-II? It has a lot more to offer than the VIC. I’m certain it will restrict interfacing with the CPU equally as the 6561.

_________________
Marco

Just out of curiosity. You guys often discuss video controllers with RGB and FBAS output signal. Do you still have such monitors? The only thing from those old days that I have left is a 11" orange on black monitor with a simple video input and I don't even know if it still works as I haven't used it for several years now. I'd rather look into a solution with at least a VGA output, which is still available on many monitors.

cbscpe:

That's very true. Because I'm mostly adding video to my 8 bit computer so I can write and play my own games, I'm happy to use a newish LCD television and hook the VDC up via SCART. Otherwise I access the machine via its UART. That said 15Khz RGB monitors are not that hard to come by today. If I had the room I'd love to own one.

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

As a Commodore enthusiast, I have a Commodore 1702, a Commodore 1801 and a Commodore 1084S. I also have a 22 inch SONY Trinitron TV set which gives a marvelous picture. Old consoles and home computers mostly deliver an FBAS, SVIDEO or RGB with 50Hz frame rate. Modern flat-screen monitors and TV’s can’t deliver a smooth scrolling picture.

_________________
Marco

I just completed a very simple PAL video interface for my MC3 computer. The computer itself is not 6502 based but the video interface uses only standard components and may be of interest anyway.

http://www.waveguide.se/?article=bitmap ... -interface

Regards,
Daniel

Looks really nice, Daniel!

Mike

Nice work, but as someone working on similar video concept I have a few questions/observations:
1) you say you see only a few artifacts, the worst of which are only observed during a 'fill'? You shouldn't see any artifacts, if your idea is valid.
2) have you considered 2 separate videoRAMs?
For your idea to work, I would think that the cpu & the videoRAM would have to run 2x the speed of the video shift register in order for the cpu to modify the videoRAM without any kind of interference observed on the screen. The fill test is the "stress test" and I use it on my boards.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

BTW, that is an awesome pic in dithered B&W!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Thank you for the kind words. I really like that way this interface turned out.

I may have to rephrase the part about the banding artifacts. It's not really an artifact and is coming from the fact that this is an asynchronous write-only interface and the CPU has no way of telling where the beam is at a given point in time.

EXAMPLE: Say you want to update a 24x24 pixel area (or the entire screen) with new data, all at once (that's how I tested it), then the CPU may start writing in memory corresponding to the top left corner of that area and going downwards. At the same time the beam may be halfway down this 24x24 area. Since the CPU is generally faster than the beam this situation will result in the lower part of the 24x24 area being updated with new information before the top part. For a single-shot update the eye will not notice this at all but if the CPU were to update this area with short interval, or more precisely an interval close to the vertical frequency of the video (in my case 50Hz) then some walking bands may show. This is the same kind of artifact you may see when pointing a video camera at a CRT TV. I would not really consider this an issue. It's just... reality

Right, I think this is still referred to as the 'snow effect', i.e. data shifted out to the videoDAC due to the cpu addresses appearing on the 'shared' videoRAM address bus instead of the video pixel address counter.
You're just witnessing effects here and there, which don't seem too bothersome at this point in your project. But the more writing the cpu does to the videoRAM, the worse this conflict shows itself.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502