best route for video

[cbmeeks]

Dr Jefyll wrote:

OTOH video may be the toy with which you choose to fill your play time!

This is exactly what got me into electrical engineering. My first real circuit was generating a B/W NTSC signal with a PIC mico-controller. I was hooked after that.

[Vladimir]

Hi
After some thinking, I tend to design my video as composite PAL with ATmega88. I could copy one of Daryl's projects, but unfortunately, the upper part of his code table is occupied by the control codes. I want to put the Cyrillic alphabet there.
My skill level with ATMEGA's is something as 'easy LED blinking', so the work is progressing slowly, but there are already some successes.
I decided to use the ATmega's SPI interface as an output device for data and 16-bit timer for sync-pulses. The transfer of bytes from the host should be done in parallel (frankly speaking, I'm not completely sure that this will greatly speed up the transfer, but I hope).
I do not know how long this job will take, but so far it seems interesting to me. Tips and wishes will be greatly appreciated.

Vladimir

[GARTHWILSON]

Vladimir wrote:

After some thinking, I tend to design my video as composite PAL with ATmega88. <...> I decided to use the ATmega's SPI interface as an output device for data and 16-bit timer for sync-pulses. The transfer of bytes from the host should be done in parallel (frankly speaking, I'm not completely sure that this will greatly speed up the transfer, but I hope).

With a quick look at the ATmega88 data sheet, what I'm seeing is that the ATmega88 can do 4Mbps on SPI in master mode, which is 512KB/s if there's no idle time between bytes. The fastest SPI devices can go nearly 100Mbps, meaning SPI itself is potentially much faster than the microprocessors and microcontrollers we're dealing with; but it looks like the ATmega88 can indeed do parallel transfers faster than it can do SPI transfers.

[jim30109]

The TeleMate arrived today. I don't have anything around that does RS232 at logic levels right now but hope to lashup a test jig soon.

A "video card" the size of a postage stamp. The source code and some info on the design is on their website.

Jim

[Vladimir]

jim30109 wrote:

...The source code and some info on the design is on their website.

Jim

Hi Jim. I noticed your information about the TellyMate a week ago, thank you very much. As I mentioned before, currently I'm trying to create something like this. In the part concerning TV interface it's very similar. In the course of the work there are many problems and it is naturally interesting for me to know how these problems are solved by other people. The firmware of TellyMate is written in C language, which I do not know at all, but, fortunately, the source code is accompanied by a good description in plain English, which I read with great pleasure. Since the efforts required for creating the device on the basis of published information are practically zero, I will most likely make DIP version of TellyMate for comparative testing. Although hardware of it is the same as mine, software solutions are different, so practical tests would be very interesting. The answer to the question "Why am I doing this" has already been given earlier by Dr Jefyll. And, it seems that the process itself is more interesting than the final result. So to speak 'The way is the goal'. Otherwise, really, it would be easier to buy this thing.

Vladimir

[jim30109]

I'm happy to learn I'm not the only one who tinkers in assembly language but never bothered with C.

Glad you found the source code comments useful. I would like to tinker with it on a platform with more horsepower so I could use the single character graphic programming, but the "page" programming should do all I need for now.

I've also been thinking about emulating "memory mapped" video by setting aside a chunk of memory and using interrupts to "paint" the screen by sending a serial stream of characters several times a second.

Jim

[AldoBrasil]

Never tried it, but, a solution that seems simple and cheap is the VS23S010-L from VLSI Solution.

http://www.vlsi.fi/en/products/vs23s010.html

128k byte sram plus video generator, via SPI.

Only does composite, but I believe you an use three chips to get VGA (theoretically possible).

[Vladimir]

Something tells me that this will work very slowly. Even to display and scroll alphanumeric data, 6502 should have to rewrite more than 100 kbyte of graphical buffer. Is not it?

[jim30109]

For the TellyMate, I would use character graphics. You might take a few seconds to set up user defined characters. I was going to use a memory array to store bytes and then do a block transfer at a regular interval.

A 38x25 display is less than 1k of characters. Adding in start and stop bits, you are talking about around 10 kilobits. It can support baud rates up to 37.6k.

So a screen refresh a second seems reasonable without resorting to any tricks. Withe some more creative coding and using scroll up and scroll down (so you would only have to write a single line) I think I could write some simple games that have update rates of 5 to 10 times per second.

So it's definitely not perfect but seems manageable.

Jim

[Vladimir]

jim30109 wrote:

Adding in start and stop bits, you are talking about around 10 kilobits. It can support baud rates up to 37.6k.

More precisely, it is 57,6 kbit per second, i.e., your buffer can be transferred about 6 times per second. I also thought about it, but I would not like 6, but 50 times per second. So I started looking towards the parallel interface.
In former times, in my old computer, there was a type-in game from the "Radio" magazine called "Python", a snake running on the screen (a chain of letters "O"). It is possible to port that game for fun (most likely, by full rewriting. The game is very simple).

Edit: spelling

[jim30109]

Have you looked at the L-Star? It is kind of a cool idea because the Propeller chip he uses basically "spoofs" the address space for the 6502. Then behind the scenes he handles the I/O. That may just introduce artificial complexity to what you are trying to do, but it is basically bus connected and would effectively be memory mapped video.

Years ago (around 1980) I traded up my Ohio Scientific C1P for a C4P MF. There was a local users group (I lived in Tulsa at the time) and once a month we'd get together. Some of the guys were in touch with other users groups and there was always a fresh batch of programs to swap and copy every month.

Most weren't really that good, but one month there was a simple "reverse scroll" demo program that just used (if I remember right) one POKE and the screen worked "backwards" where you would fill lines from bottom to top and then once you reached the top things would scroll down (instead of up). Someone had figured it out and shared it, but it gave me an idea.

I built a program I called "Raceway" and it set a fixed width track with cars and people. After initializing the screen, all I had to do was blank out the player's car (which was towards the bottom of the screen), put the new line of the track at the top (which scrolled everything else down), check if the player had moved left or right, check if there was a collision by using PEEK for the location where they car would go, and if there wasn't a collision I would POKE the car back into video memory.

I had shared that and also a modified version that I called "Crossing" that had the same track logic running, but put the user in the middle of the screen as a person instead of a car and let you try to go back and forth across the road without getting hit. Pretty similar in concept to Frogger.

A few months later there was a modified version of my Raceway program that came back from one of the other user groups and had been modified so the track narrowed and shifted as you progressed. I added a bit to that and eventually ended up with a program I called Foo Racer.

I still need to break out the C4P from storage and look at getting it running, but I've been wanting to do a version of Foo Racer for several months now. With the "insert line" feature, I think I'll just have to write one line and let the video controller handle the reverse scroll. I'll still have to blank the car before the scroll, check for a collision, and then put the car (or a wreck) back.

The original was in BASIC, but this time around it will probably be in assembler. I think that with the minimal amount of screen data I can get to ten frames a second or better at full speed. I've also been trying to just get a basic "track" going in the Dodo playground--I'd love to have a Dodo running it one day. I've run into some problems (it may well be me) using the assembler for Dodo and I'm not ambitious enough to learn C at this point. I am seriously thinking about getting an L-Star just because it can emulate the C1P which is where it all began for me.

Thanks,
Jim

[AldoBrasil]

Vladimir wrote:

Something tells me that this will work very slowly. Even to display and scroll alphanumeric data, 6502 should have to rewrite more than 100 kbyte of graphical buffer. Is not it?

If you are talking about the vs23s010, it has a internal blitter to accelerate things, and the lines shown in the screen are a linked list on the memory, so they can be changed on the fly to do scroll.

[Vladimir]

Hi Jim.
Until now, I have not had a chance to get acquainted with the products of Ohio Scientific. Everyone in his life had their own toys. I do not think that you can once again get the same pleasure from that old stuff as in those nice days. The 'first time' is possible only once. Nevertheless, going forward, I would not forget the past, there was a lot of good, and experience is one of the riches of man. We can apply it now. I wish you success in all your endeavors.
About L-Star, I saw something here and try to read more in detail.

AldoBrasil wrote:

If you are talking about the vs23s010, it has a internal blitter to accelerate things, and the lines shown in the screen are a linked list on the memory, so they can be changed on the fly to do scroll.

Maybe I'm wrong. I need to study the datasheet better.
OTOH, as far as I understand, this chip is not yet 'mass production' and manufacturing is not expected in a form convenient for fans. Is not it?

Vladimir.

Edit: Correction of translation of underlined words

[GARTHWILSON]

The serially (SPI) interfaced graphic LCD I mentioned in my last post on the first page of this topic had such a scrolling function too. Basically you just change its top-line pointer in its memory, which has the effect of scrolling, then you only have to fill in the new portion at the top or bottom while the rest remains what you already fed to it earlier, just moved up or down. Some let you do side-to-side scrolling as well. You can also send new data for just a small portion at a time; so for example to display a cursor, you only feed it that portion, not the entire screen.

[Vladimir]

GARTHWILSON wrote:

...you just change its top-line pointer in its memory, which has the effect of scrolling...

I already thought of this in my ATmega88 project (after reading your story about the ACIA-buffer). My screen buffer is a circular one. But, I only have scrolling in one direction. For what it is possible to apply reverse or 'left-right' one, I do not know.