potatohead's Blog

Check out the 7800 Schematics and how the expansion port (top right corner - J2 Periphrial Port Output). I'm not sure whether it's an input or output. Also recognize that the 7800 output is a kinda out of spec versus NTSC standards for line periods (half a colorbust clock short) and lines per frame/field (non-interlaced, no half lines).

 

I will say that the only reason to do anything in this hobby is because you want to; 'cause at the end of the day you're going to have to pour the blood, sweat & tears into making it a reality.

Check out the 7800 Schematics and how the expansion port (top right corner - J2 Periphrial Port Output). I'm not sure whether it's an input or output. Also recognize that the 7800 output is a kinda out of spec versus NTSC standards for line periods (half a colorbust clock short) and lines per frame/field (non-interlaced, no half lines).

 

I will say that the only reason to do anything in this hobby is because you want to; 'cause at the end of the day you're going to have to pour the blood, sweat & tears into making it a reality.

 

Hmm... thanks for the pointer. I think I'm just going to hack a cart and inject some video and see what happens.

 

The video generation capability of the propeller chip is a largely software affair. (Which is why I really like it.) What you output is really up to you. (within some limits) At this stage, the out of spec issue does not appear to be a show stopper. (Their own demo is not quite NTSC from what I can see.)

 

I've just begun looking their video output demo over at the assembly level. One must write a display kernel to map memory to video output, or draw on the fly 2600 style. Interestingly, things like sprites and hardware collision are not part of the system. These are done with the software kernel. From what I can tell, the approach so far is to dedicate at least one of 8 CPU cores to the task of generating video images. That provides a graphics 'mode' similar to how a 2600 kernel would provide the graphics mode upon which the game then runs. That's what triggered my purchase. Very interesting hardware that just might end up being able to reproduce that Atari feel that comes with the intermingling of display generation and game logic. At the end of the day, it's that feel that I really enjoy. We'll see if this actually ends up being the driver. Right now I think it is.

 

The CPU cores, called COGS, each run in parallel with one another at the same time and can share access to the video output. This really is what interests me from a hobby computing stand point. There are lots of limitations but lots of power too. Hackability. If one wanted a 2600 style video display with a playfield, some sprites, etc... two COGS could perform in software, what is normally done in silicon, leaving the rest of the unit to actually handle I/O and actually run the game engine.

 

Of course you are completely right about doing it for the love of it. My only real question was one of possible shared interest down the line. If the project would end up being some $200 thing, I'll be the only one that ever enjoys it. On the other hand, $35.00 and a few folks might be able to afford to have some fun too. That's really the meat of it.

 

Plenty of time for that assessment later, I suppose.

 

Right now, I've got to finish getting my head wrapped around the development environment and write a video kernel or two. Wondering if a kernel can really do something like hardware collision detection does.

Oh, so you're trying to add a framebuffer to the 7800 which the propeller chip will update. Hmmm.... interesting. Let me have a think.

 

The 7800 uses a display list concept to display graphics. So, the 7800 stub application would create a dummy display list which would map a chunk of ROM address space to be displayed as a really big sprite. The display list itself has to be in RAM, so unless the stub copies ROM to RAM every frame, the palette bits in the display list entries will be fixed.

 

Alrighty, 160B mode (4 bits/pixel) will give you 13 colors per pixel at 160 pixels/line. The 320 modes really cut into the color capabilities. Sure the 160B mode is a little whacked in bit-order, but you might be able to handle that in hardware with some creative wiring and buffering.

 

You might be better off using one of the other consoles which had a dedicated video pass-through (i.e. ones which had compatibility add-ons).

 

Hardware collision detection has a couple of significant issues. First, for N sprites you need N*(N-1)/2 collision detection bits. Second, does a collision occur when the sprite squares overlap, or only when the non-transparent pixels overlap? (Or do you have a second set of sprite collision bitmasks?)

Oh, so you're trying to add a framebuffer to the 7800 which the propeller chip will update. Hmmm.... interesting. Let me have a think.

 

The 7800 uses a display list concept to display graphics. So, the 7800 stub application would create a dummy display list which would map a chunk of ROM address space to be displayed as a really big sprite. The display list itself has to be in RAM, so unless the stub copies ROM to RAM every frame, the palette bits in the display list entries will be fixed.

 

Alrighty, 160B mode (4 bits/pixel) will give you 13 colors per pixel at 160 pixels/line. The 320 modes really cut into the color capabilities. Sure the 160B mode is a little whacked in bit-order, but you might be able to handle that in hardware with some creative wiring and buffering.

 

You might be better off using one of the other consoles which had a dedicated video pass-through (i.e. ones which had compatibility add-ons).

 

Hardware collision detection has a couple of significant issues. First, for N sprites you need N*(N-1)/2 collision detection bits. Second, does a collision occur when the sprite squares overlap, or only when the non-transparent pixels overlap? (Or do you have a second set of sprite collision bitmasks?)

 

Actually that's a really interesting idea! But it's not where I was headed.

 

I've not had a chance to test the video pin on the 7800 yet (outta town at the moment, just playing with the prop), but I was hoping it works like the sound one does in that whatever is there gets mixed in with the 7800 output. That's what I plan to test with a composite signal when I get a chance.

 

If that's the case, then the prop generated video would get mixed in with the 7800 video, with both images ending up on the TV. One could choose to graphics with either display system, but not have the two interact directly. The case I am seriously considering, if the prop video capability is what I think it is, would be one where the 7800 is not drawing much with the MARIA chip. On screen graphics would largely reside on the prop, using the 7800 for I/O and perhaps some graphic display as well. Sound could come from either place, probably the 7800 would be easiest.

 

Game logic could be both places, depending on what graphics system does what.

 

The prop is not a memory mapped design. It's CPU's and RAM are internal. When powered on, it loads it's internal ram from an eeprom, via a very simple serial communication scheme that takes a coupla pins. After that, each of it's 32 i/o pins are completely general purpose. So a few of them would get used up to generate the composite video to be sent into the 7800 cart video line. A few more could be dedicated to create sound. (Both of these methods use a few resistors to form a DAC.) The remainder could be used to facillitate communication between the prop and the 7800.

 

The prop is fairly fast in that each of the 8 COGs run at about 20mips each. This appears to be fast enough to generate lots of different kinds of video, particularly when a couple of them work together. It also seems fast enough to allow emulation of memory mapped I/O, so the 7800 CPU would not know the difference between talking to the prop software and real RAM/ROM located at some address just like an ordinary cart would present. (And that's a guess at this stage)

 

One issue I've identified is timing between the two. A program in the 7800 would have to signal the prop in such a way that it's onboard video signal would be synced with the 7800 one. Of course the other is timing for RAM / ROM emulation.

 

Communication between the two would have to happen via software running on the prop to interact with the 7800 CPU via the cart port pins. If software is fast enough to allow this, lots of very interesting things would be possible because the software could emulate most any addressing scheme. Thus, your idea comes into play as well. I had not thought it through that far.

 

Did some tinkering last night with the assembly video drivers that ship with the chip. It will do NTSC, full color clock per pixel by default, interlaced or not. Timing is software controlled and adjustable as it's basically a big software loop running on one of the COGs. In this way, the thing is very 2600 like. No kernel, no video. Sub color clock pixel widths are possible as well. The primary issue seems to be color. The drivers that ship with the unit are fairly color limited. (4) They did a C64 style color tile scheme where two colors per 16 x 16 pixel area are permitted, with lots of combinations avaliable to choose from for each tile, along with a color or two that works anywhere on screen. I'm assuming this was to only consume one COG and maximize memory use for other things besides graphics. (It is a microcontroller after all)

 

If one applied more than one COG to the problem, lots of other video possibilities become an option.

 

My musings about hardware collision detection really were out of place in the other post. Where I was going with that is the COGs run at the same time, in sync. It's possible to have more than one of them helping to build the video display, as the output pins are shared. One could be generating what we would call playfield graphics on the 2600, while another draws what we would call sprites. The state of the video signal, as it appears electrically on the pins, is shared among all COG's. So a quick read before changing that state would enable one COG to know if it is drawing on top of, or underneath what the other COG is doing, based on some flags set in memory before hand. That's really what I was writing about --the ability to literally build a video generator that is applicable to the game at hand, similar to how I see people here do it for the 2600, only with the added ability to craft collisions detection that's necessary without having to do more than that. Prop memory and speed constraints prevent one from just throwing up a full color bitmap and going for it however. That's where the art of it lies, again similar in concept to the systems we all play with here.

 

Anyhow, where you write above about creative wiring, etc... , I'm thinking of using one COG to handle the communication issues where logic gates and such would be used otherwise. That's essentially 4 software loops running on half the avaliable COG's, two handling video, one doing sound, and one handling communication via some sort of memory address emulation. (Maybe two doing that) That leaves a lot of compute on both sides to do actual game stuff.

 

Here's the chunk of assembly that reads from RAM and outputs an NTSC bitmapped display:

 

---

'*******************************

'* Assembly language TV driver *

'*******************************

 

org

'

'

' Entry

'

entry mov taskptr,#tasks 'reset tasks

 

mov x,#10 'perform task sections initially

:init jmpret taskret,taskptr

djnz x,#:init

'

'

' Superfield

'

superfield mov taskptr,#tasks 'reset tasks

 

test _mode,#%0001 wc 'if ntsc, set phaseflip

if_nc mov phaseflip,phasemask

 

test _mode,#%0010 wz 'get interlace into nz

'

'

' Field

'

field mov x,vinv 'do invisible back porch lines

:black call #hsync 'do hsync

waitvid burst,sync_high2 'do black

jmpret taskret,taskptr 'call task section (z undisturbed)

djnz x,#:black 'another black line?

 

wrlong visible,par 'set status to visible

 

mov x,vb 'do visible back porch lines

call #blank_lines

 

mov screen,_screen 'point to first tile (upper-leftmost)

mov y,_vt 'set vertical tiles

:line mov vx,_vx 'set vertical expand

:vert if_z xor interlace,#1 'interlace skip?

if_z tjz interlace,#:skip

 

call #hsync 'do hsync

 

mov vscl,hb 'do visible back porch pixels

xor tile,colortable

waitvid tile,#0

 

mov x,_ht 'set horizontal tiles

mov vscl,hx 'set horizontal expand

 

:tile rdword tile,screen 'read tile

or tile,line 'set pointer bits into tile

rol tile,#6 'read tile pixels

rdlong pixels,tile '(2 instructions between reads)

shr tile,#10+6 'set tile colors

movs :color,tile

add screen,#2 'point to next tile

mov tile,phaseflip

:color xor tile,colortable

waitvid tile,pixels 'pass colors and pixels to video

djnz x,#:tile 'another tile?

 

sub screen,hc2x 'repoint to first tile in same line

 

mov vscl,hf 'do visible front porch pixels

mov tile,phaseflip

xor tile,colortable

waitvid tile,#0

 

:skip djnz vx,#:vert 'vertical expand?

ror line,linerot 'set next line

add line,lineadd wc

rol line,linerot

if_nc jmp #:line

add screen,hc2x 'point to first tile in next line

djnz y,#:line 'another tile line?

 

if_z xor interlace,#1 wz 'get interlace and field1 into z

 

test _mode,#%0001 wc 'do visible front porch lines

mov x,vf

if_nz_and_c add x,#1

call #blank_lines

 

if_nz wrlong invisible,par 'unless interlace and field1, set status to invisible

 

if_z_eq_c call #hsync 'if required, do short line

if_z_eq_c mov vscl,hrest

if_z_eq_c waitvid burst,sync_high2

if_z_eq_c xor phaseflip,phasemask

 

call #vsync_high 'do high vsync pulses

 

movs vsync1,#sync_low1 'do low vsync pulses

movs vsync2,#sync_low2

call #vsync_low

 

call #vsync_high 'do high vsync pulses

 

if_nz mov vscl,hhalf 'if odd frame, do half line

if_nz waitvid burst,sync_high2

 

if_z jmp #field 'if interlace and field1, display field2

jmp #superfield 'else, new superfield

'

'

' Blank lines

'

blank_lines call #hsync 'do hsync

 

xor tile,colortable 'do background

waitvid tile,#0

 

djnz x,#blank_lines

 

blank_lines_ret ret

'

'

' Horizontal sync

'

hsync test _mode,#%0001 wc 'if pal, toggle phaseflip

if_c xor phaseflip,phasemask

 

mov vscl,sync_scale1 'do hsync

mov tile,phaseflip

xor tile,burst

waitvid tile,sync_normal

 

mov vscl,hvis 'setup in case blank line

mov tile,phaseflip

 

hsync_ret ret

'

'

' Vertical sync

'

vsync_high movs vsync1,#sync_high1 'vertical sync

movs vsync2,#sync_high2

 

vsync_low mov x,vrep

 

vsyncx mov vscl,sync_scale1

vsync1 waitvid burst,sync_high1

 

mov vscl,sync_scale2

vsync2 waitvid burst,sync_high2

 

djnz x,#vsyncx

vsync_low_ret

vsync_high_ret ret

'

'

' Tasks - performed in sections during invisible back porch lines

'

tasks mov t1,par 'load parameters

movd :par,#_enable '(skip _status)

mov t2,#paramcount - 1

:load add t1,#4

:par rdlong 0,t1

add :par,d0

djnz t2,#:load '+119

 

mov t1,_pins 'set video pins and directions

test t1,#$08 wc

if_nc mov t2,pins0

if_c mov t2,pins1

test t1,#$40 wc

shr t1,#1

shl t1,#3

shr t2,t1

movs vcfg,t2

shr t1,#6

movd vcfg,t1

shl t1,#3

and t2,#$FF

shl t2,t1

if_nc mov dira,t2

if_nc mov dirb,#0

if_c mov dira,#0

if_c mov dirb,t2 '+18

 

tjz _enable,#disabled '+2, disabled?

 

jmpret taskptr,taskret '+1=140, break and return later

 

movs :rd,#wtab 'load ntsc/pal metrics from word table

movd :wr,#hvis

mov t1,#wtabx - wtab

test _mode,#%0001 wc

:rd mov t2,0

add :rd,#1

if_nc shl t2,#16

shr t2,#16

:wr mov 0,t2

add :wr,d0

djnz t1,#:rd '+54

 

if_nc movs :ltab,#ltab 'load ntsc/pal metrics from long table

if_c movs :ltab,#ltab+1

movd :ltab,#fcolor

mov t1,#(ltabx - ltab) >> 1

:ltab mov 0,0

add :ltab,d0s1

djnz t1,#:ltab '+17

 

rdlong t1,#0 'get CLKFREQ

shr t1,#1 'if CLKFREQ < 16MHz, cancel _broadcast

cmp t1,m8 wc

if_c mov _broadcast,#0

shr t1,#1 'if CLKFREQ < color frequency * 4, disable

cmp t1,fcolor wc

if_c jmp #disabled '+11

 

jmpret taskptr,taskret '+1=83, break and return later

 

mov t1,fcolor 'set ctra pll to fcolor * 16

call #divide 'if ntsc, set vco to fcolor * 32 (114.5454 MHz)

test _mode,#%0001 wc 'if pal, set vco to fcolor * 16 (70.9379 MHz)

if_c movi ctra,#%00001_111 'select fcolor * 16 output (ntsc=/2, pal=/1)

if_nc movi ctra,#%00001_110

if_nc shl t2,#1

mov frqa,t2 '+147

 

jmpret taskptr,taskret '+1=148, break and return later

 

mov t1,_broadcast 'set ctrb pll to _broadcast

mov t2,#0 'if 0, turn off ctrb

tjz t1,#:off

min t1,m8 'limit from 8MHz to 128MHz

max t1,m128

mov t2,#%00001_100 'adjust _broadcast to be within 4MHz-8MHz

:scale shr t1,#1 '(vco will be within 64MHz-128MHz)

cmp m8,t1 wc

if_c add t2,#%00000_001

if_c jmp #:scale

:off movi ctrb,t2

call #divide

mov frqb,t2 '+165

 

jmpret taskptr,taskret '+1=166, break and return later

 

mov t1,#%10100_000 'set video configuration

test _pins,#$01 wc '(swap broadcast/baseband output bits?)

if_c or t1,#%01000_000

test _mode,#%1000 wc '(strip chroma from broadcast?)

if_nc or t1,#%00010_000

test _mode,#%0100 wc '(strip chroma from baseband?)

if_nc or t1,#%00001_000

and _auralcog,#%111 '(set aural cog)

or t1,_auralcog

movi vcfg,t1 '+10

 

mov hx,_hx 'compute horizontal metrics

shl hx,#8

or hx,_hx

shl hx,#4

 

mov hc2x,_ht

shl hc2x,#1

 

mov t1,_ht

mov t2,_hx

call #multiply

mov hf,hvis

sub hf,t1

shr hf,#1 wc

mov hb,_ho

addx hb,hf

sub hf,_ho '+52

 

mov t1,_vt 'compute vertical metrics

mov t2,_vx

call #multiply

test _mode,#%10000 wc 'consider tile size

muxc linerot,#1

mov lineadd,lineinc

if_c shr lineadd,#1

if_c shl t1,#1

test _mode,#%0010 wc 'consider interlace

if_c shr t1,#1

mov vf,vvis

sub vf,t1

shr vf,#1 wc

neg vb,_vo

addx vb,vf

add vf,_vo '+53

 

xor _mode,#%0010 '+1, flip interlace bit for display

 

:colors jmpret taskptr,taskret '+1=117/160, break and return later

 

mov t1,#13 'load next 13 colors into colortable

:colorloop mov t2,:colorreg '5 times = 65 (all 64 colors loaded)

shr t2,#9-2

and t2,#$FC

add t2,_colors

:colorreg rdlong colortable,t2

add :colorreg,d0

andn :colorreg,d6

djnz t1,#:colorloop '+158

 

jmp #:colors '+1, keep loading colors

'

'

' Divide t1/CLKFREQ to get frqa or frqb value into t2

'

divide rdlong m1,#0 'get CLKFREQ

 

mov m2,#32+1

:loop cmpsub t1,m1 wc

rcl t2,#1

shl t1,#1

djnz m2,#:loop

 

divide_ret ret '+140

'

'

' Multiply t1 * t2 * 16 (t1, t2 = bytes)

'

multiply shl t2,#8+4-1

 

mov m1,#8

:loop shr t1,#1 wc

if_c add t1,t2

djnz m1,#:loop

 

multiply_ret ret '+37

'

'

' Disabled - reset status, nap ~4ms, try again

'

disabled mov ctra,#0 'reset ctra

mov ctrb,#0 'reset ctrb

mov vcfg,#0 'reset video

 

wrlong outa,par 'set status to disabled

 

rdlong t1,#0 'get CLKFREQ

shr t1,#8 'nap for ~4ms

min t1,#3

add t1,cnt

waitcnt t1,#0

 

jmp #entry 'reload parameters

'

'

' Initialized data

'

m8 long 8_000_000

m128 long 128_000_000

d0 long 1 << 9 << 0

d6 long 1 << 9 << 6

d0s1 long 1 << 9 << 0 + 1 << 1

interlace long 0

invisible long 1

visible long 2

phaseflip long $00000000

phasemask &n

I've not had a chance to test the video pin on the 7800 yet (outta town at the moment, just playing with the prop), but I was hoping it works like the sound one does in that whatever is there gets mixed in with the 7800 output. That's what I plan to test with a composite signal when I get a chance.

There's no video pin on the 7800 cartridge port. (Only a mono audio pin, used for POKEY output.) The expansion port has the MARIA video outputs, and a CVIDEO pin, but I don't think you can use those pins as inputs. (Even in 2600 mode the MARIA video pins would be pulled low.) So any mixing would have the be done on your board. (Probably easiest to use the MARIA video outputs (which are digital) rather than CVIDEO, although MCOL might be tricky since that's more of an analog signal.) You could probably use the MSYNC (or BLANK) to genlock the propeller video output to the 7800; you'd just need to modify the propeller code to match the 7800 line & frame timing.

 

If that's the case, then the prop generated video would get mixed in with the 7800 video, with both images ending up on the TV. One could choose to graphics with either display system, but not have the two interact directly. The case I am seriously considering, if the prop video capability is what I think it is, would be one where the 7800 is not drawing much with the MARIA chip. On screen graphics would largely reside on the prop, using the 7800 for I/O and perhaps some graphic display as well. Sound could come from either place, probably the 7800 would be easiest.

Hmm... unfortunately, the expansion port doesn't have much in the way of true I/O pins. (I'm not sure it has any input capabilities at all...) Now, if you wanted to be tricky, you could use the MARIA video outputs to send data from the 7800 to the propeller board during the "offscreen" rasters. Kinda like closed captioning. (That's assuming that you don't go for some kind of cart+expansion port hybrid.)

I've not had a chance to test the video pin on the 7800 yet (outta town at the moment, just playing with the prop), but I was hoping it works like the sound one does in that whatever is there gets mixed in with the 7800 output. That's what I plan to test with a composite signal when I get a chance.

There's no video pin on the 7800 cartridge port. (Only a mono audio pin, used for POKEY output.) The expansion port has the MARIA video outputs, and a CVIDEO pin, but I don't think you can use those pins as inputs. (Even in 2600 mode the MARIA video pins would be pulled low.) So any mixing would have the be done on your board. (Probably easiest to use the MARIA video outputs (which are digital) rather than CVIDEO, although MCOL might be tricky since that's more of an analog signal.) You could probably use the MSYNC (or BLANK) to genlock the propeller video output to the 7800; you'd just need to modify the propeller code to match the 7800 line & frame timing.

 

If that's the case, then the prop generated video would get mixed in with the 7800 video, with both images ending up on the TV. One could choose to graphics with either display system, but not have the two interact directly. The case I am seriously considering, if the prop video capability is what I think it is, would be one where the 7800 is not drawing much with the MARIA chip. On screen graphics would largely reside on the prop, using the 7800 for I/O and perhaps some graphic display as well. Sound could come from either place, probably the 7800 would be easiest.

Hmm... unfortunately, the expansion port doesn't have much in the way of true I/O pins. (I'm not sure it has any input capabilities at all...) Now, if you wanted to be tricky, you could use the MARIA video outputs to send data from the 7800 to the propeller board during the "offscreen" rasters. Kinda like closed captioning. (That's assuming that you don't go for some kind of cart+expansion port hybrid.)

 

 

Of course you are right! I mistook the expansion port for the cart port!

 

That does put the nix on my idea, unless I want to hack the actual hardware. (might consider this at some point, thus making it a one time deal for sure.)

 

I think only one of my 7800 machines has the expansion port. The hybrid idea is viable, but only applicable to a subset of the 7800s out there.

 

Gonna park this for now and get my video kernels done on the prop, then go from there.

 

Thanks for entertaining me for a bit. It's educational being able to talk about these things!