If you mean things like the TVT 6 5/8, it's a fun little device to build but the way it's implemented is too clever by half as it consumes an enormous amount of addressing space. While this was no big deal in the days of the KIM-1 and AIM-65, it sucks for 6502 systems now when most folks are dealing with the full 64K. You'd learn a lot about video by building or studying one, and the concepts he describes are elegant, but don't interface it to the bus the way he did unless you have lots of bits to burn.

_________________
Machine room: http://www.floodgap.com/etc/machines.html

One question: what's your display device? A domestic TV (or older CRT monitor) presents a much slower line scan than a VGA or SVGA monitor (63.5us (NTSC/525) or 64us (PAL/625) vs ~32us for VGA 640x480 or ~26us for SVGA 600x800) with proportionally lower requirements for the dot-clock. A TV has a maximum internal bandwidth of 6MHz, and colour filters make that the practical limit for the dot clock... which simplifies timing requirements in the video generation circuit. Domestic TVs are also a lot more tolerant of timing errors than a more recent monitor might be.

Another: are you planning simply on a text output? In which case, you will need only enough memory for (e.g.) sixteen lines of thirty-two characters - half a K - for the text itself. Whereas a graphical output of the same resolution will require - assuming sixteen lines for each character - 32 * 16 * 16 = 8k

As discussed above by myself and Gordon, generating video is well within the capabilities of the larger AVR chips. It has been discussed several times on the AVRFreaks forum over the years (now part of the Microchip site but a search engine should find it) and in particular a chap named AtomicZombie has done some good work, including colour.

Don Lancaster's approach is not really applicable to an AVR. He causes the processor to execute an instruction that increments the address bus but instead of using that data directly, uses the address bus to access the video ram and serialise the data found there; the processor doesn't see it during the active line time.

With an AVR (or an ARM - though the AVR is simpler because it lacks the multiple internal data busses of the ARM which can make the timing somewhat variable, and because it has a faster interrupt response to timers) one might follow something along these lines to generate text from internal ram:

For each character you display, you will need to know which vertical line of the character you are on (say 0-15) and you will use the value of the character plus that line count to index into the character generator 'rom'. The value you get from there can be output to SPI/UART or to an external parallel-serial adaptor.

You also need to generate sync pulses - short ones, 5us (strictly 4.7) for line syncs and longer ones, three lines (strictly 2.5) for field pulses, and gate these together for a combined sync, and then incorporate this with the video output via resistive mixing for a composite video output.

It is *critical* that the sync generation is rock steady, and also that the timing of character generation is constant. Otherwise, the display will move around on the TV in a way which is most disturbing. However, you can choose to ignore the interlace requirements for PAL/NTSC by not incorporating the half-line sync pulses. This avoids vertical flickering, and is simpler.

This is the briefest overview. There's lots more information on the site - for example, my 'half an idea' thread in the hardware section, which uses discrete logic to generate all the timing signals for SVGA (ignore the co-processor).

Neil

If using an Uno (or clone) i should already be setup for the external 16Mhz crystal and ready to go out the box...



The ATmega 328p is very able to generate PAL (or NTSC) video from C. There should be no need for assembler unless you have the brain cells to spare. Look up the TVout pages on the arduino forum/reference sites... It's a standard library if you're using the Arduino system.

And FWIW: I skimmed the Don Lancaster books some time back, but his was my main reference when I write my code:

http://martin.hinner.info/vga/pal.html

I was also involved in designing timing/generation code for various high resolution video systems in the late 80s too, so all that ken is lurking in my old grey cells too... But read that web page above and once you have the format of a line and then a whole frame you should get the picture....

I avoid other forums like AVRfreaks as there is generally too much negativity there.

But... As this is really an AVR/ATmega issue then you may well be better off there...

Also, lets not forget some of the early systems did video generation the hard way - the ZX80 and the Atari 2600... It generates composite video with minimal hardware assist and virtually no RAM...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

The VGA generation described by barnacle and drogon above can also be implemented with fast 6502. The circuits can be fairly simple if implemented with SPLD or CPLD, but VGA will consume significant graphic memory, about 40K for 640x480 monochrome and 6502 will spent 90% of its throughput chasing after the beam. It still have 10% remaining throughput to do some work during the vertical blanking period. 10% of 25MHz 6502 is 2.5 MHz, so it can do decent bit of works. I'm sure AVR/ARM is cheaper and simpler, but I mentioned 6502 because people may be interested in 6502 implementation here.

6502 as a VGA controller, viewtopic.php?f=4&t=6517

Let me echo Neil by emphasizing that the timing of the sync and video signals must be absolutely rock steady. It may be permissible for the timing to be slightly off-spec in certain ways. But whatever pattern you establish needs to be absolutely unvarying in terms of the exact number of CPU cycles consumed, line after line and frame after frame. This is critical.

I haven't been following what the AVR folk are up to. But, with Don Lancaster's Cheap Video approach, rock steady timing is accomplished by means of lovingly crafted assembly language, carefully tallying the exact number of cycles consumed by each instruction. YMMV, I suppose, and I'm not trying to sway you, but I personally found that to be an enjoyable challenge, and a big buzz when success was achieved!

I implemented my own variations on Cheap Video three times (on two 65xx machines and on a dual-6809 SBC), and I consider Lancaster's technique to have remarkable advantages, particularly in certain resource-constrained scenarios.

And BTW I wasn't bothered by the impact plasmo mentioned wrt CPU throughput. One has the option to implement "fast mode" like that on a Timex/Sinclair ZX81 (another Cheap Video machine). In fast mode, the video display only becomes active when the program is waiting for input from the user.

And, as many of you know, AtomicZombie is yet another alias for Oneironaut, aka our own Radical Brad, famous/notorious on this forum for video-heavy threads such as Vulcan-74 - A 6502 Powered Retro MegaProject !

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Hi Everyone,
So I finally had some time today to dig back into this. As a reminder, I am trying to get Daryl's Text Video Display to run on an Atmega328p (i.e. Arduino Uno). I replaced all of the rjmp instructions with jmp as Daryl suggested, and of course changed the io header from m88PAdef.inc to m328Pdef.inc.

I am now getting the "Banner" and was even able to modify the banner to read 328p instead of 88. So I know things are working on the Arduino side. I then connected the Arduino to the VIA Port B of my W65C02SXB board as explained in the wiring diagram. I first call VInitDisp to initialize the display and try to output some characters using VOutput. I can clear the screen but am unable to output any characters to the screen. The cursor sits there and blinks, but no characters are displayed. I am using the exact 6502 code from Daryl's website, just with my VIA memory location starting at 7FC0.

I have the reset line on the SXB connected to the reset line on the Arduino. When I reset the SXB, it resets the Arduino and Daryl's banner display's. When I try to run my 6502 code to send text to the Arduino, I get nothing. The clock on my board is just under 2MHZ (WDC released some boards with the incorrect clock). I saw in a previous post from Daryl that the system has a 4MHZ limit.

I really like the way the text looks. Very sharp and truly 40 by 25 characters. I just can't get the interface to work. I think this would be a great solution for adding video out to any 6502/65816 system.

I know the 6551 has some bugs. Does the 6522 have any issues? The via shift register is being used to communicate with the Arduino.
Could an additional delay be needed somewhere in the code?

I'm scratching my head on this one. Any advice???

Thanks in advance.

It sounds like you are 90% there. I'm glad it was not too hard.

The VIA shift register protocol uses one zero page location to store a flag bit - V_idle. My code used location $EE. Be sure your OS is not using that location too.

To experiment, try this from your OS command line.
after reset, you see the splash banner.
read portB of the VIA - bit 7 should be 1
call the VInitDisp to set up the display
read the value of the flag - it should be $00
read portB of the VIA - bit 7 should be 1
write $0C to the vsr address to shift out the clear the screen command
read portB of the VIA - bit 7 should be 0
write $41 to the VSR address to send the letter A
read portB of the VIA - bit 7 should be 1

This will test your hardware and the ATMega88 firmware.
Let me know the results.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Daryl,
Currently, I only get 0 on bit 7 when reading PORTB. After the banner appears, after calling VInitDisp, and after calling VOutput. I always get 0 on bit 7.

As for the W65C02SXB side, I am using the user VIA. This is VIA1 on the board. I am using 3 pins on the VIA. PORTB pin 7, and PORTB CB1 and CB2. I am fairly certain I have these connections correct. The attached photo shows the setup.

On the Arduino (Atmega328P), I am using digital pins 13 (PORTB pin 5), 11 (PORTB pin 3), and 9 (PORTB pin1). Pin 13 is connected to CB1, pin 11 is connected to CB2, and pin 9 is connected to the VIA PortB pin 7.

Is it possible to test in isolation on each side. For the Arduino, how could I set up something like a chrout (character out) function in the AVR code so I could for example load a register, call the function, and have it appear on the screen. This might come in handy for troubleshooting.

On the 6502/6522 side, I have never used the shift register on the 6522 before. Is there some simple test I could run in isolation to demonstrate that the 6522 setup is correct.

Finally, the setup seems very similar to SPI. I have a good SPI setup on my board. Does the AVR code already support using SPI? I have connected arduino's as an SPI slave to my SXB many times. I know I can get this to work.

Thanks again for your help. Hope we can get this figured out.

To test just the Arduino, can you put an LED with resistor to ground on the Port B pin 1 to see if it is set high?
Per the AVR code, PB1 gets set high upon initialization and will toggle after each shift in is completed.

Next, set up an SPI port to feed one byte to the Arduino using PB3 & PB5 (MOSI,SCLK). it looks like I have the Arduino set for Slave mode and mode 3 SPI.

Feed $0C to the Arduino and verify the screen clears and the PB1 output changes to 0.

To test the W65C02SXB, it will be a little harder. You can place a jumper on Port B bit 7 and move it from Vcc to gnd and read the port to ensure the input is following the value on the pin. Testing the serial out will be a little harder. You could try connecting it to an SPI slave set for mode 3 and send various values and read the SPI data register to ensure that is functioning.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Daryl,
I connected PORTB pin 1 (Arduino DP9) to an LED. When the banner comes up on reset the LED lights and once the banner is completely loaded and the cursor starts to blink, the led turns off. I will try using SPI next and get back to you (probably need a chip select for SPI as well).
Thanks again.

Daryl,
Fantastic news. SPI works perfectly. Thank you so much for all of your help. This is awesome. I'm going to clean up some things and then post in detail exactly what we did so the next person can get this figured out a little easier.

I'm glad you have a working solution. However, if you are not using the handshake pin, there is a chance that you can send characters faster than the display is able to receive them, especially during scrolling. With using the SPI port, does the handshake line change state after each character is processed? I found the place in the code where the handshake pin is brought low as the last step before the main loop starts in the Arduino. Once the first character is received, the state will toggle high and then alternate after receipt of the following ones.

I cannot make sense of my 6502 VInitDisp code setting the V_idle variable to 0. It should be set to $80 as the VOutput routine first toggles its state before doing the comparison with the handshake pin. I don't have any hardware or time to rebuild this now, but if you do see the handshake line changing state, you might consider testing the VOutput code with the V_Idle variable initialized to $80.

Either way, I'm happy that you have a working display and can now move on to the next phase of your project!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Daryl,
So it looks like I got out ahead of my skis on this. You are correct, SPI works great until the screen scrolling routine on the AVR kicks in, then it's too fast. I tried setting the v_idle to $80, and this didn't work.

On the AVR, the first call to VOutput works, however, it seems that the AVR gets stuck in the VOutput1 loop, and the ack pin gets stuck on 1. It appears that the acknowledgement is not toggling. I noticed in the AVR code in the Main routine that there is a comment about the older Atmega8 needing some additional code. I wonder if the 328p might need something different.

Anyway, It seems that the handshake is definitely where the issue is. I'll keep digging and let you know. So close!

I assembled the stock code (modifying the interrupt table from rjmp to jmp) using a 328P definition and it looks like the code assembles properly, especially the code after main3 where the handshake gets updated after each character is received. it should work.

I don't use arduino's, is there something with the hardware setup or firmware that stays resident in the 328? (bootloader or something else?)

Can you write a quick test program to ensure the PB1 pin can be pulsed high and low and back to high? We could also modify the code to use another output pin for the handshake.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Daryl,
PB1 does toggle after each character. I verified this by connecting it to an LED. I can check this now and create a wait in conjunction with the spi transfer. This fixes the problem with SPI being too fast during scrolling. So current status, everything works fine using SPI. The handshake works as expected and as far as I can tell everything on the AVR side works. I will continue to look into using the shift register on the VIA. For now, I'm happy to have SPI with the handshake working.

Thanks again for you help.

For anyone interested in this exchange, make sure you have a common ground between the master and the AVR. I think this was the cause of some of the initial trouble.