Text Video Display

[RichCini]

Martin_H wrote:

Thanks guys, I'm glad you liked the video.

That's a great video, thanks Martin.

[8BIT]

I finally got around to updating my website with the Text Video V2 information. Sorry it was so late. I included an optional Flip-flop that will help with the handshaking issues discovered and discussed previously.

Schematic

Here's a link to my page:

http://sbc.rictor.org/vid2c.html

This uses a 6522 serial shift register and PB7 for handshaking. Other forms of IO can be used as well, including RS-232, parallel, and SPI. Contact me if you have any questions.

thanks!

Daryl

[8BIT]

Edited the web page and zip file - the font images were misaligned.

Daryl

[tet00]

8BIT wrote:

Edited the web page and zip file - the font images were misaligned.

Hi Daryl and others,

Thanks for developing this, I have one of these that Rich Cini graciously supplied, however I would like to change the font used by the mega88. I can re-program the 88 fine, but I am not sure how to generate a new bin, or change an existing dump, to update which font I would like to use.

Is there a way to rebuild the bin, or is it just a matter of patching a saved image?
Thanks!

[8BIT]

The best way would be to get the source code from Rich (in case he has modified anything). Then edit the main source file. At the very end, there are one or two ".include filename" statements that load the font tables in the right place.

Are you wanting to use one of the fonts I have already created, or you wanting your own custom font?

Once that is all done, use the AVR Studio assembler to regenerate the hex file.

What programmer/software are you using to program the Mega88?

Daryl

[tet00]

8BIT wrote:

The best way would be to get the source code from Rich (in case he has modified anything).

Hi Daryl.

After I posted I realized it would be a trip into AVR studio to re-compile for a custom font, which I am willing to try, but being able to flash the existing bins with the current font options would be nice as I have a programmer (TL 866) that can save and re-flash them quickly and easily.

I don't know if Rich's version has modified them, but I modified the r2.7 board to enable jumper-ing the PAL/NTSC pin and that works, which I take as a good sign.

[8BIT]

So, what you are asking is possible. The font table is located in flash at word $0800 (byte $1000) and is 2048 bytes in size. Each character is 8x8 pixels.

The font data itself is organized by rows. The first 256 bytes are for the top row (row 1). The next 256 bytes are for the second row, and so on.

So, the space character (ASCII $20) would be 8 $00 bytes. These are located at $1020 (row 1), $1120 (row 2), $1220 (row 3), down to $1720 (row 8).

Now all you have to do is create a bin image of your font.

Good luck with your project!

Daryl

[RichCini]

tet00 wrote:

8BIT wrote:

Edited the web page and zip file - the font images were misaligned.

Hi Daryl and others,

Thanks for developing this, I have one of these that Rich Cini graciously supplied, however I would like to change the font used by the mega88. I can re-program the 88 fine, but I am not sure how to generate a new bin, or change an existing dump, to update which font I would like to use.

Is there a way to rebuild the bin, or is it just a matter of patching a saved image?
Thanks!

I can definitely give you the sources, but IIRC I sent you the chip with the Commodore font. Thinking about it now, the Commodore font is kind of funny in how capital letters are treated. "a" will show up on the screen as "A" while "A" will be a Commodore graphics character. There are two ways to fix this. You can look at the text strings in EhBASIC and make all of the initial caps lower-case. I never tried it, though, but it should work.

The alternative is to re-flash the MEGA88 with firmware that uses an alternative font (the Apple font doesn't exhibit this trait). For this, you'll need the software from Atmel, a programmer (like the avrdude programmer from Adafruit), an external oscillator, and a breadboard. The fuses are set for an external clock since that's how the chip is used on the board, thus the need for the oscillator. I bought a small proto board and a zero-insertion-force socket and made up a small programming jig for it.

[java6502]

Has anyone tried to run Daryl's Text Video Display on an Atmega328p? I'm trying to port this over and I'm not having much luck. The source code assembles fine with the m328Pdef.inc file replacing the m88PAdef.inc file, however no signal on PD1 and PD2. I'm guessing these chips are different enough that the source code will not work as is, however, given that Grant Searle used the same code as the starting point for his display (which runs on a 328p), I figure this should be possible. I don't have a lot of experience with assembly on the AVR chips, so if anyone has actually done this already, that would make life so much easier.

[8BIT]

The ATMega328P can be used to replace the ATMega88 as it also has the USART in SPI mode feature.

Be sure the set the fuses for an external oscillator. Also, the interrupt jump table is different and uses JMP vs. RJMP opcodes.

I don't have a 328P to test on and no time to research it more, so I'm not sure if there is anything else that would need to be changed.

Good luck with your project.

Daryl

[barnacle]

I tried similar projects with the 324 (not 328) in the past, but it's (ten years back) SPI has a nasty insistence of a high output for one clock pixel before it would output the next byte. Irritating, but livable with if you can live with black text on white.

Neil

[drogon]

barnacle wrote:

I tried similar projects with the 324 (not 328) in the past, but it's (ten years back) SPI has a nasty insistence of a high output for one clock pixel before it would output the next byte. Irritating, but livable with if you can live with black text on white.

Neil

The work-around for that is to use the 2nd SPI port based on the USART. It doesn't suffer that one extra bit issue.

I did my initial video device for my Ruby boards based on the ATmega 1284p - 16KB internal RAM so I could have 320x220 pixel graphics display rather than a text based display. The down-side was that as the video generation code needed some 60-7% of all CPU cycles it was a bit slow...

-Gordon

[barnacle]

Ah, I never got that far... I was generating a base non-interlaced pal with 1us per cell, so probably 256 vertical lines and 52 character cells across. Just enough time to read a byte from video ram, index into the character set, and output it. And as you say, little time for anything else.

I do recall that to avoid timing jitter, I put the processor to sleep at the end of each active line so it could wake up exactly to start the next sync. That was the only way to guarantee the timing; so the thing spent all its time either asleep or servicing the timer interrupt.

Neil

[drogon]

barnacle wrote:

Ah, I never got that far... I was generating a base non-interlaced pal with 1us per cell, so probably 256 vertical lines and 52 character cells across. Just enough time to read a byte from video ram, index into the character set, and output it. And as you say, little time for anything else.

I do recall that to avoid timing jitter, I put the processor to sleep at the end of each active line so it could wake up exactly to start the next sync. That was the only way to guarantee the timing; so the thing spent all its time either asleep or servicing the timer interrupt.

Neil

My strategy was to generate an interrupt every 64µS then use that 64µS to time each line. SPI clock being 8Mhz. This seemed to fit well with PAL timing - I had 64 byte times of horizontal time, so I could make up the line with the front/sync/back porch outputs then a potentially elongated back porch for picture left/right adjustment then the 40 bytes (320 bits/pixels) of data.

The more left the picture is, the more time at the end of each 64µS pulse for user programs to run.

That's then the end of the 64µS interrupt and the time left until the next one is left to the user program.

There is a line counter for each frame too for vSync and adjusting the image up/down within reason. vSync time is the biggest chunk of 'free' time for the user program to run - the interrupt is still taken but it can exit early when it's doing vsync. (or dummy lines top & bottom to make up your 312.5 lines)

My code was 100% C - looking back at it now, I can see where I might optimise it if I went to assembler but it's more or less locked into that 64µS window.

It worked very well and I was quite pleased with it, but as my 6502 project advanced I wasn't too happy with the lack of speed so decoded to go for a plan B.

A couple of videos I made of it:

https://www.youtube.com/watch?v=1Iv-bDmkW2M
https://www.youtube.com/watch?v=09zhGUbVxdU

Cheers,

-Gordon

[java6502]

Thanks for the replies everyone.

I will try the suggestion Daryl made and report back on my progress. I'm using an Arduino Uno, and so I already have a 16MHZ external clock. Not sure if I need to change the fuse bit for an external clock, so please let me know if I misunderstood.

Also, while using this code is nice, I would much rather learn how in general to implement composite video, or even VGA for that matter. There are two books I recently came across, "The Cheap Video Cookbook" and "Son of Cheap Video" by Don Lancaster. I'm sure you are all familiar with these. Are they a good place to start? I am particularly interested in Composite Video, as it seams this should be the simplest to start with. The Atmega328p is just able to do this work, but lets suppose I had an new Arduino Uno Rev4, with an ARM cortex6 running at 48MHZ. It has 256 kB of flash, and 32kB of RAM and it runs at 5 volts. With a device like this, I should be able to generate a fairly decent video signal and not even have to use assembly. I could generate a clean composite video signal all in C, and get a better understanding of a how it's supposed to work before reimplementing in assembly. I have found that sometimes it's easier to do things in C just to figure out how in principle they are supposed to work, and then, if performance is still an issue, do it in assembly.

I've looked around online, and oddly have come up short finding a nice article on how to go about building this. Please let me know if you have any good sources. And thank you all again for being so helpful and friendly.