potatohead's Blog - Propeller Update

[RSS Bot]

After an extended time off, I've started to tinker with the Propeller again. Another user managed to do what I was trying to do; namely, build an NTSC video driver that's got stable color clocks on every scan line. Now it's possible to emulate the look of nearly any classic machine on this chip! There is enough control over the signal to essentially output any kind of NTSC / PAL signal you want. IMHO, this is really cool --and what I was hoping was doable.

 

I'll have to get a camera, or something for screenies... perhaps this weekend!

 

I was just reading the Closed Captioning thread. This is completely doable on the Propeller. It's got full control of the entire video signal. I'll have to go find a sample waveform to encode...

 

To get warmed up, I modified and built on that driver to output 80x192x8. This is a lot like the GTIA mode on the Atari, only with more color bits. Did this to check out the color possibilities, with nice big easily debugged pixels. Turns out, about 96 different colors are possible, largely due to there only being 6 intensity levels on the chip. It's quite possible to use two of the video generators together to get more, but that's gonna be outside the scope for now. There are 16 distinct hues per pixel, with six intensities. Sub-pixel artifacting, which I've not yet really tried, is gonna yield more. Either way, sub pixel, or combining the output of multiple video generators at the same time, is gonna yield plenty of additional color and intensity levels beyond the 96 done by the hardware.

 

As things stand right now, I've got a driver that outputs one pixel per NTSC color clock, non interlaced. This is exactly what the older Atari hardware does. If the chip had more intensity levels, it would all map out nicely, but it doesn't. It's totally possible to overdrive things to sub-color clock levels and get more direct control of what happens in a given pixel. I'm gonna save that for later.

 

Onboard RAM, being limited to 32K, does limit the color screens. 160x192x8 takes up 30K of ram! Eek. Just enough to build a color demo or two, and that's it. maybe, maybe a small game in assemblier. Breakout or something... It is 8 bit addressable. No color limitations, just a nice high-color bitmap.

 

It appears there is plenty of time between pixels for all sorts of tricks. Pixel packing to generate 32 or 64 color displays is doable and that would make a ~20k or so screen at classic game resolutions. Now there is room to actually do stuff.

 

On the fly video will do better ---or add external RAM. Andre, the designer of the HYDRA game system, that uses the chip, has done this, giving 64K of random access memory, with 500k or so sequential above that. More than plenty for high-color graphics in full on bitmap mode. I'll be playing with that later...

 

For now, the next task is to build an emulation of some of the better Atari modes with sprites. I've a coupla choices in this. Somebody already worked out how to connect atari Joysticks to the VGA port for quick and dirty control interfaces on the Demo Board. On that note, it's a bummer --sort of. The HYDRA game machine has nintendo style ports, and code to read the controllers. This is actually very cool in that modern controllers all function in a similar fashion. The Demo Board, which lacks some storage and essentially limits you to just the 32K in chip, without you building stuff, does not have game inputs, but does have mouse, keyboard, VGA, etc... in common with the HYDRA. If one is using a TV for the display, then that VGA port can easily become a controller port instead! Either system can do this, because all the I/O is bidirectional.

 

Time to make some cables and hook up my Atari stuff! Paddles are gonna be an annoyance as a CAP, charging, timing, etc... are gonna be necessary. All possible, but extra work right now. Joysticks, driving controllers, etc... are gonna be just fine, so I start with those.

 

Have one COG (that's one of the 8 CPU's running on this little bugger) build the screen display one scanline at a time, in high color mode. It works from a buffer that's built by one or two more of the COG's. Those two will be building sprite graphics, read from memory and drawn into the buffer on the fly. Graphics done this way, only need the storage necessary to define the images, with no full screen bitmap required for display. It's like a programmable TIA, essentially. Once the sprite engine is up and running, it will appear as just video hardware to the real game program running on one or more of the other CPU's.

 

I'm finding the Atari style Player missile graphics sprites an interesting design option. The existing sprite engines, for the chip, all use your typical rectangular sprite definitions. Drawing these into the buffer takes time --more time than would be required if all the sprites were screen height! So, vertical movement would be actually moving data, horizontal movement would be changing a register. Maybe add an origin register so we get to say where a particular bit of data ends up on the screen. This might make packing things in memory easier, and vertical movement easier, given the sprite is not to be reused vertically as seen on most every game done on the 8bitters.

 

I'm not sure how many will be possible. I strongly suspect this number is high, given the 8 CPU's to work with. It will be possible to have them be more than one color for sure. I don't think I'm there yet where emulating hardware collisions is concerned, either. No biggie, there is plenty of speed and ram to check these things in the usual non-hardware ways.

 

That's it for now. By way of reference, here is the actual 80x192x8 driver code, and the little quick and dirty color demo that went with it.

 

********** Color Demo code first ***************

CODE{ ******** 80 x 192 High Color 1 byte / Pixel display Demo ***********

* This demo writes all the useful color values to the screen *

* Linear addressing, no tiles *

* Derived from CardBoardGuru's Simple NTSC display example *

* Written for HYDRA *

*********************************************************************

}

 

CON

' Set up the processor clock in the standard way for 80MHz

_CLKMODE = xtal1 + pll8x

_XINFREQ = 10_000_000 + 0000

 

VAR

byte displayb[15360] 'allocate display buffer in RAM

'80 x 192 x 1 byte / pixel

long index 'temp offset for byte statement below

 

OBJ

tv : "80x192_NTSC" 'the TV driver, for this example running at 80x192

 

PUB start | j, c, k, o

 

{

fill bitmap with NTSC black color. A zero is below black and will hose the display.

Perhaps it's not a bad idea to have the TV driver watch for this condition...

8 bits / pixel appears to be a waste in that only 120 distinct pixel conditions

result. Of these, perhaps 90 or so are really useful.

 

Of the 8 bits, the first three deal with intensity:

Black = %010

01 Grey = %011

02 Grey = %100

03 Grey = %101

04 Grey = %110

White = %111

 

Useful color exists in the remaining bits as shown by this program. The first row

of darker colors is questionable. On my better TV, it works. On lesser ones, it

doesn't...

 

}

 

'fill bitmap with black pixels, before triggering display

repeat index from 0 to 15360

byte [@displayb] [index] := 2 'another way to point at HUB memory...

 

tv.start(@displayb) 'start the tv cog & pass it the address of the bitmap

 

'draw a border around the visible graphics screen (80 x 192)

repeat j from 0 to 79

plot(j,0,251)

plot(j,191,251)

repeat j from 0 to 191

plot(0,j,251)

plot(79,j,251)

 

'draw 6 intensities possible (black is one)

repeat o from 15 to 55 step 10

repeat j from o to o+9

repeat k from 160 to 180

plot(j,k,o/10+2)

 

'draw useful sets of colors possible

repeat k from 8 to 15

if k == 9

k := 10

c := k

repeat o from 3 to 77 step 5

c := c + 16

repeat j from 20 to 30

plot(o,j+16*(k-8),c)

plot(o+1,j+16*(k-8),c)

 

 

pub plot(x,y,c)

'very simple dot plotter

'one byte per pixel is sweet!

displayb[y*80+x] := c

 

And the driver... actually, it's full of commentary, written my me and the other guy! (Attached instead --actualy I don't know how after the AA upgrade. No biggie...)

 

Just for fun, this is all it really takes to encode the bitmap display, once the framework is all up and running:

 

 

CODE mov VSCL, CALC_user_data_VSCL

 

mov r1, #20 '80 pixels horizontal resolution is 20 waitvids

:draw_pixels rdlong B, A 'get four pixels from hub

waitvid B, #%%3210 'draw them to screen

add A, #4 'point to next pixel group

djnz r1, #:draw_pixels 'line done? Move to sync...

 

Just one tight loop, grabbing bytes, writing them to the screen, etc... BTW, the entire signal is encoded as colors. This is why there are only 6 intensity levels, when three bits are actually defined for this. The other two are below black, for sync. These produce interesting results when present on screen, in the display graphics area! Not all TV's will cope with this either.... That's why the demo program above, filled the display memory with pixel values greater than zero. I'll have the driver itself handle this going forward, so zero will actually be black and not sync!

 

One other thing... I saw the great little project to make a 7800 adapter for the 5200 machine. Didn't know that one had a video input! I'm assuming this is a pass thru kind of thing. If so, one of these little chips could be on a cart, and present itself as ROM, maybe co-exist with the ROM, and output a video signal to be used in lieu of the 5200 one!

 

http://www.atariage.com/forums/index.php?a...;showentry=3295