Need help with video driver (TRS80)
pullmoll
Posts: 817
My first try to write a specific video driver, one to mimic the TRS80 hardware, is stuck, because I don't know enough about video signal generation.
The code produces some video signal, but either the timing is way off what I would need, or I have an error in my design.
The TRS80 hardware, for those who don't know:
Since rendering the 6 pixel wide font or the blockgraphics within the video task seemed to be too much, I decided to try a 2 cog solution. The video cog draws a raw bitmap consisting of 2 scanlines, always alternating between them. It's kind of double buffering, but just the scanline instead of an entire frame buffer. The render cog fills these 2 scanlines by decoding characters or block graphics and counting the character scanrows resp. 3rds. The first two 3ds contain data from the font, the last 3rd is blank. The block graphics use bits 5..0 of a character code to decide which pseudo pixels are on.
The synchronization between both cogs is done with a long containing the current scanline. The video cog increments it after finishing to output a line, the render cog waits until the other buffer is free and can be refilled. So far for the theory [noparse]:)[/noparse]
It's probably best to have a look at the video, so I attach the source.
Thanks to Cluso99 for the Debug_1pinTV driver which this code is based upon. I ripped out almost everything but the inner active loops. The timing is calculated for a pseudo 48x24 with 8x8 character cells screen, which yields the same dimensions (384x192) as a 64x16 with 6x12 character cells.
TIA,
Juergen
FWIW: It looks more like a software synchronization problem than a hardware issue. The picture may be stable and just my code not syncing both cogs as I intended.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/22/2010 12:32:23 AM GMT
The code produces some video signal, but either the timing is way off what I would need, or I have an error in my design.
The TRS80 hardware, for those who don't know:
- 64x16 character display with the 1K video RAM at a fixed address.
- 6x12 pixel character cells with 6x8 pixel text in the upper 8 scan rows.
- 128 alphanumeric characters, 64 block graphics characters repeated once.
- blockgraphics cell is 2x3 i.e. each pseudo pixel is 3x4 pixels.
Since rendering the 6 pixel wide font or the blockgraphics within the video task seemed to be too much, I decided to try a 2 cog solution. The video cog draws a raw bitmap consisting of 2 scanlines, always alternating between them. It's kind of double buffering, but just the scanline instead of an entire frame buffer. The render cog fills these 2 scanlines by decoding characters or block graphics and counting the character scanrows resp. 3rds. The first two 3ds contain data from the font, the last 3rd is blank. The block graphics use bits 5..0 of a character code to decide which pseudo pixels are on.
The synchronization between both cogs is done with a long containing the current scanline. The video cog increments it after finishing to output a line, the render cog waits until the other buffer is free and can be refilled. So far for the theory [noparse]:)[/noparse]
It's probably best to have a look at the video, so I attach the source.
Thanks to Cluso99 for the Debug_1pinTV driver which this code is based upon. I ripped out almost everything but the inner active loops. The timing is calculated for a pseudo 48x24 with 8x8 character cells screen, which yields the same dimensions (384x192) as a 64x16 with 6x12 character cells.
TIA,
Juergen
FWIW: It looks more like a software synchronization problem than a hardware issue. The picture may be stable and just my code not syncing both cogs as I intended.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/22/2010 12:32:23 AM GMT
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I will try and get some time to look later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I also love them. There ought to be a text editor not with syntax highlighting, but with bug highlighting [noparse]:)[/noparse]
I had to fiddle around with when to set the scanrow back to 0 when a new frame begins to make a stable picture. Now I'm experimenting with when to increment the scanrow and so make the renderer begin writing to the bitmap buffer. It seems as if the renderer sometimes misses the next scanrow and leaves the buffer as it was.
BTW with #define NTSC in the top level file I get a flickering picture, while PAL seems ok...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/22/2010 9:30:47 AM GMT
Anyway, I'm happy with my 2 cog solution now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-- Terry
Model I, definitely not the CoCo [noparse]:)[/noparse] I'm using a 1 pin TV driver, so there is no colo(u)r.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Robert
Now that you say it! I have to try to fit that mode support in the video cog alone, because the renderer cog is filled to the limit. It should be possible by changing the pixel and frame widths, but collecting the 6 bit chunks from the bitmap line is going to be difficult, because they overlap the longs :-P
The other way would be to reload both cogs with different code to do the even position characters only double width display.
Edit: No, Smile, I forgot I had moved the font to the hub RAM, so there is space in the renderer cog. I'll leave that for later, though, because it is not that important to support this mode.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 3/25/2010 6:25:07 AM GMT
Do you have any ideas to solve this problem? This screen driver would be very very great