6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Mar 29, 2024 10:12 am

All times are UTC




Post new topic Reply to topic  [ 38 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Wed Oct 01, 2014 3:02 pm 
Offline

Joined: Mon Sep 22, 2014 9:02 am
Posts: 6
Location: Germany
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


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 01, 2014 3:46 pm 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 485
Location: Switzerland
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


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 01, 2014 4:18 pm 
Offline

Joined: Mon Aug 05, 2013 10:43 pm
Posts: 258
Location: Southampton, UK
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/


Top
 Profile  
Reply with quote  
PostPosted: Wed Oct 01, 2014 8:18 pm 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 485
Location: Switzerland
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


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 03, 2014 6:49 pm 
Offline
User avatar

Joined: Mon Dec 08, 2008 6:32 pm
Posts: 143
Location: Brighton, England
BigDumbDinosaur wrote:
That, and the 6561 only generates 22 characters per line in text mode.

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!


Top
 Profile  
Reply with quote  
PostPosted: Fri Oct 03, 2014 7:54 pm 
Offline

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands
cbscpe wrote:
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.
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.


PaulF wrote:
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.
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


Top
 Profile  
Reply with quote  
PostPosted: Sat Oct 04, 2014 9:14 am 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 485
Location: Switzerland
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.


Top
 Profile  
Reply with quote  
PostPosted: Sat Oct 04, 2014 1:21 pm 
Offline

Joined: Mon Aug 05, 2013 10:43 pm
Posts: 258
Location: Southampton, UK
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/


Top
 Profile  
Reply with quote  
PostPosted: Sat Oct 04, 2014 4:27 pm 
Offline

Joined: Wed Sep 11, 2013 8:43 pm
Posts: 207
Location: The Netherlands
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


Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 28, 2014 4:54 pm 
Offline

Joined: Sat Jul 20, 2013 8:23 am
Posts: 6
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


Top
 Profile  
Reply with quote  
PostPosted: Fri Nov 28, 2014 11:01 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1918
Location: Sacramento, CA, USA
Looks really nice, Daniel!

Mike


Top
 Profile  
Reply with quote  
PostPosted: Sat Nov 29, 2014 12:23 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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


Top
 Profile  
Reply with quote  
PostPosted: Sat Nov 29, 2014 12:38 am 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
BTW, that is an awesome pic in dithered B&W!

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Nov 29, 2014 6:33 am 
Offline

Joined: Sat Jul 20, 2013 8:23 am
Posts: 6
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 :)


Top
 Profile  
Reply with quote  
PostPosted: Sat Nov 29, 2014 11:10 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 38 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: Proxy and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: