medium spaced 6 sprites with color + graphics

[+rbairos]

Hi.

Basically I am trying to achieve:

1_2_3_4_5_6

Where:
Each digit is 8 pixels, and has a unique color per digit/sprite,
and each underscore actually represents 8 blank pixels.

Ive read about the VDEL 6 digit trick, but so far the best I can get (on paper) seems to be
4 individually colored digits,
1_2_3_4

or
6 digits, where the last two digits take their color from the middle two.
1_2_3_4_5_6

I'd even settle for 5 digits, uniquely colored.

Any advice appreciated!

Thanks,
Rob.

Edited November 30, 2017 by rbairos

[+rbairos]

Actually wondering if its easier to draw inversed, and update the playfield color in time somehow.

[+SpiceWare]

It's possible with the use of Bus Stuffing - that's what we're doing to create the tile display used in the RPG demo:

 

 

We just shift the players left/right like this:

1_2_3_4_5_6_
_1_2_3_4_5_6
1_2_3_4_5_6_
_1_2_3_4_5_6

then alternate on the next frame:
_1_2_3_4_5_6
1_2_3_4_5_6_
_1_2_3_4_5_6
1_2_3_4_5_6_

I don't believe it's possible to get that many colors with unique pixels without the use of bus stuffing.

 

 

The inverse drawing is how we pulled off the 2 color 48 pixel graphics, used to great effect in Stay Frosty 2 as well as my menus. I cover the development of it in detail in this blog entry (scroll down to the section Menu Graphics):

 

 

 

 

 

 

[+rbairos]

Alright, thanks for confirming my suspicion.
I was in fact hoping to alternate columns per frame as you described, once the 6-colored digits was resolved.

I may go with the 4 digits (or 6 digits, with the last 2 shared colors) for now, as Im hoping to get my experiment working on 'standard' atari hardware at this point.

Thank you for the logs, I will read them carefully!

Cheers

[ZackAttack]

It's possible with some serious limitations. Here's a demo of how it can be done with a standard 4k cart. I though of a second way to do it which is better, except the 6th sprite is only 6 pixels wide and only the top 64 colors of the palette can be used ($80-$FE)

 

If we limit to 5 sprites the results are much better. The only limitation is the restricted 64 color palette. There's a few more cycles free too. Which should make it possible to move 8 pixels each scanline.

 

In all three cases the effect can be accomplished with a standard 4k cart, but you'd really need to couple it with the Harmony hardware to make it usable in anything more than a demo. What's cool is that it doesn't require bus stuffing, so we could still make a decent RPG engine using the 5 sprites with interleave.

 

I implemented the 6 sprite algorithm enough to render 6 unique graphics and colors.

 

 

5 Sprites:

color               colup0          colup1          lda #           PCH             PCL                
graphic             grp0del         grp1del         grp0            A               X               Y       
                    00000000        11111111        00000000        11111111        00000000        ________
                   sta---gp1lda---sta---cp0stx---gp0JSR------cp1cp0---sty---gp1lda---sta---gp0    

6 Sprites with missing pixels (Ball is used to fill in one of the 3 missing)

color               colup0          colup1          lda #           PCH             PCL             lda #   
graphic             grp0del         grp1del         grp0            A               X               Y       
                    00000000        11111111        00000000        11111111        00000000        __B11111
                   sta---gp1lda---sta---cp0stx---gp0JSR------cp1cp0---sty---gp1lda---sta---gp0sta---cp1     

​6 Sprites​ with challenging graphics on 4th and 5th

color               colup0          colup1          A               A               X               A & X   
graphic             grp0del         grp1del         grp0            PCH             PCL             Y       
                    00000000        11111111        00000000        11111111        00000000        11111111
                   sta---cp0lda---JSR------gp1gp0---sta---cp1sty---gp1stx---cp0st?---gp0sax---cp1           

Edit: Fixed minor errors in timing diagrams

sixfun.asm

sixfun.bin

Edited December 2, 2017 by ZackAttack

[ZackAttack]

5 sprites looks pretty good. The color of D and E depends on the 6507 PC. Harmony would need to dynamically generate the JSR target according to the colors of the next line and then virtually move the routine to the correct address space. It would also need to inject the graphics and color data just as DCP+ currently does fast fetch. Of course the address would need to be in ROM which is why the palette is cut in half. The 13th address bit, A12, must always be set.

 

fivefun.bin

fivefun.asm

[ZackAttack]

I'd even settle for 5 digits, uniquely colored.

Any advice appreciated!

 

I made some improvements to the 5 sprite kernel and was able to save enough cycles to make it usable with DPC+. This comes with two limitations. The two right most sprites must share an 8 color palette and that palette must consist of colors in the range CCC1 PPPX where CCC are the 3 bits that vary in a given palette and PPPP chooses one of the 8 available palettes. The second limitation is that there are no cycles left to try to move everything over. You'd have to alternate between frames instead of between lines.

Have to do this:
x x x x x
x x x x x
x x x x x
x x x x x
x x x x x

Instead of this:
x x x x x
 x x x x x
x x x x x
 x x x x x
x x x x x

I've put comments where the fast fetchers would need to be used in the DPC+ implementation. All the loads use accumulator and there's only 11 different streams. Pretty sure that's within the DPC+ specs.

 

 

 

 

​

fivefun.asm

[+SpiceWare]

Slick. Think CDF's fastjump would free up enough time for line-by-line shifting?

[+rbairos]

Alright.
Lots of good information here.
I scribbled a couple of notes about JSR and PHP before I posted but figured it was beyond me to make work. Great stuff.

Im trying to figure out an optimal format for playing back video.
I've played with countless variations so far over the last two weeks, some bad, some somewhat recognizable.
dithering, different interleaving patterns, combinations of monochrome + blurred color areas with varying results.

My goal is to build an "Atari Movie Cart" for fun.
I figure about 1 to 8 gig SD card has enough throughput and capacity for a full length feature movie in such a format.

For hardware, I think I could get away with a low power microcontroller, embedded in a cart, powered by the console,
as the code will be almost entirely linear.
No branches, and an occasional jmp statement to keep the PC in check.
More importantly it can get away with only reading two address lines.

A12 of course, and A11 to detect reset requests.
For reset, I can get away with ignoring A0, by feeding the same byte for both hi + low address, example '0x1010' as I don't care as long as its in 4k space.
(Though this might cut the palette further in your example).

For reading input, (ie: joystick to rewind/forward/pause), I can read the input at a known time (eg end of each frame), so again I'll know when data is being presented
on the bus, and where it came from. That will just affect which block to queue up on the SD card.

The kernel would need enough cycles to write to the audio once per scanline though (11.52 khz).

So given all that, does that provide more flexibility in the kernel?
Any tips or insights appreciated as always.

Rob.

[+rbairos]

To be clear, the SD card will be ridiculously inefficient. In won't hold frame data that is looked up and inserted into a kernel. Instead, it will simply hold millions of repetitions of the one scanline kernel and some pre and post per frame stuff. (again no branching). The only branch is at the end of each frame when the microcontroller samples the bus (which will have controller input waiting from a previously pushed store command), and decides which block of code should be queued up next.

Edited December 2, 2017 by rbairos

[ZackAttack]

Interesting. The brute force approach would certainly make this feasible. You could probably get 1-2hrs per 8gb sd card. However, I think you'll find you need the full address bus because there are no control bus signals brought to the cart. If your goal is to play with hardware this sounds like a good project. If your goal is to play movies on the Atari then I'd stick with the existing harmony hardware. Harmony gives you a large pool of potential beta testers and it saves all the time required to design and build a new board. I'm actually working on a new open source driver for it which should allow the SD card to be used during gameplay. There's also a good chance it will be able to support single bus stuffing reliably.

[+rbairos]

Interesting. The brute force approach would certainly make this feasible. You could probably get 1-2hrs per 8gb sd card. However, I think you'll find you need the full address bus because there are no control bus signals brought to the cart. If your goal is to play with hardware this sounds like a good project. If your goal is to play movies on the Atari then I'd stick with the existing harmony hardware. Harmony gives you a large pool of potential beta testers and it saves all the time required to design and build a new board. I'm actually working on a new open source driver for it which should allow the SD card to be used during gameplay. There's also a good chance it will be able to support single bus stuffing reliably.

The harmony does sound cool, but Im interested in how 'low tech' I can go from scratch, so a low power microcontroller sounds like a good hobby project for me.

Are there public specs on the harmony anywhere?

 

Not sure why I need the full address bus? Can you explain? I assume I won't need any bus signals, like any cart.

I wish I didnt need A11, but I don't think I can get around ignoring reset requests.

 

In the past I created some artwork that consisted of historic video clips playing on vintage oscilloscopes that was well received.

This is along those lines. I do want it to work on an original atari. The goal is really to create a alternate history movie-rental system like a 'Back to The Future' cart for example.|

Imagining that my 13 year old self could plug in a cartridge and watch a movie.

If that works, I'd make a small tray of 80s classics in one tray, all labelled with appropriate atari/80s blockbuster motifs.

The innards including SD cards would be hidden, to preserve the effect.

 

I just picked up a 13" color TV (described as "retro") for $15 on kijiji as well tonight

 

Cheers

 

 

 

 

 

 

 

Edited December 2, 2017 by rbairos

[ZackAttack]

Not sure why I need the full address bus? Can you explain? I assume I won't need any bus signals, like any cart.

I wish I didnt need A11, but I don't think I can get around ignoring reset requests.

Think about a JMP instruction it is going to be at least 4 consecutive reads to ROM. A12 may or may not change depending on the Atari. So if you're not watching the full address bus how will the MCU know when to replace the 1st byte with the second and so forth. So now you're probably thinking just watch A12 and A0 right? Sounds good until you consider what happens in the JMP example after the 3rd byte is read. The 4th byte will be located at wherever the jump target is and that address could have any number of bits in common with the location of the 3rd byte. Thus you have to watch the entire address bus.

My other post is a bit misleading because the system I used is a pos jr which toggles A12 every cycle. The other two systems that I have don't.

 

 

Slick. Think CDF's fastjump would free up enough time for line-by-line shifting?

 

Good idea. I made some changes to test this and it appears that it does. I made the kernel, so I think you should make the demo Or send me a sample CDF project which I can use as a template and I'll adapt it myself if I have time. Also, when unrolling the loop to produce 3 lines it occurred to me that it might be possible to up the palette to 16 colors by exploiting the fact that bit 0 is ignored.

fivefun.asm

fivefun.bin

[+rbairos]

 

Think about a JMP instruction it is going to be at least 4 consecutive reads to ROM. A12 may or may not change depending on the Atari. So if you're not watching the full address bus how will the MCU know when to replace the 1st byte with the second and so forth. So now you're probably thinking just watch A12 and A0 right? Sounds good until you consider what happens in the JMP example after the 3rd byte is read. The 4th byte will be located at wherever the jump target is and that address could have any number of bits in common with the location of the 3rd byte. Thus you have to watch the entire address bus.

 

Arg!

But even if I have to watch the entire address bus, how is that even reliable? The values are technically undefined for a portion of each cycle, so I assumed A12 was a reliable chip select substitute ?

[EDIT] and since there will be only 2 needs for jumps (one to keep PC from overflowing, one for JSR trick above), which I could control, isn't that enough to keep A0 toggling?

 

 

 

Edited December 2, 2017 by rbairos

[+rbairos]

 

5 Sprites:

color               colup0          colup1          lda #           PCH             PCL                
graphic             grp0del         grp1del         grp0            A               X               Y       
                    00000000        11111111        00000000        11111111        00000000        ________
                   sta---gp1lda---sta---cp0stx---gp0JSR------cp1cp0---sty---gp1lda---sta---gp0    

6 Sprites with missing pixels (Ball is used to fill in one of the 3 missing)

color               colup0          colup1          lda #           PCH             PCL             lda #   
graphic             grp0del         grp1del         grp0            A               X               Y       
                    00000000        11111111        00000000        11111111        00000000        __B11111
                   sta---gp1lda---sta---cp0stx---gp0JSR------cp1cp0---sty---gp1lda---sta---cp1sta---gp0     

​6 Sprites​ with challenging graphics on 4th and 5th

color               colup0          colup1          A               A               X               A & X   
graphic             grp0del         grp1del         grp0            PCH             PCL             Y       
                    00000000        11111111        00000000        11111111        00000000        ___11111
                   sta---cp0lda---JSR------gp1gp0---sta---cp1sty---gp1stx---cp0st?---gp0sax---cp1           

Couple questions:

 

For the 2nd kernel, "__B11111"

Can we also use the missile and make the ball double wide? "MBB11111"

It means just a double wide pixel, but otherwise colors are right. (two double pixels with interleaving)

 

________MBB1111

MBB1111________

 

 

For the 3rd kernel, was thinking you reflect player graphics, to put the repeated/bad graphics data at the end of the span at least, but that won't help with interleaved data.

 

 

[RevEng]

I made some improvements to the 5 sprite kernel and was able to save enough cycles to make it usable with DPC+. This comes with two limitations. The two right most sprites must share an 8 color palette and that palette must consist of colors in the range CCC1 PPPX where CCC are the 3 bits that vary in a given palette and PPPP chooses one of the 8 available palettes. The second limitation is that there are no cycles left to try to move everything over. You'd have to alternate between frames instead of between lines.

Have to do this:
x x x x x
x x x x x
x x x x x
x x x x x
x x x x x

Instead of this:
x x x x x
 x x x x x
x x x x x
 x x x x x
x x x x x

 

A lot of HDTVs display 240p as 480i, without any cajoling. So they'll automatically convert the former pattern into the latter.

 

This project in particular would be a good place to use an intentionally interlaced display, which in theory would do the same on all TVs. This technique is confirmed to work on at least some CRTs. It remains to be seen if it interlaces on HDTVs that display 240p correctly (though not for lack of trying.)

 

The nice part about the interlace hack, is it only involves a small tweak to vsync timing on odd frames, so it's easy to implement optionally.

[ZackAttack]

Arg!

But even if I have to watch the entire address bus, how is that even reliable? The values are technically undefined for a portion of each cycle, so I assumed A12 was a reliable chip select substitute ?

[EDIT] and since there will be only 2 needs for jumps (one to keep PC from overflowing, one for JSR trick above), which I could control, isn't that enough to keep A0 toggling?

 

 

 

A12 is a reliable chip select, but selecting the chip and address decoding aren't the same thing. Since the 2nd kernel uses JSR for colors and bit 0 of the color is ignored anyway it might be possible to ensure A0 always toggles when a new data value is requested.

 

The biggest challenge I see with this is handling the power on reset. The state of the bus will be undefined for some time before the reset vector is read. I think this could be handled by putting $15 on the data bus on startup and leaving it there. That would give a reset vector of $1515 and then a stream of ORA zpg,X instructions. This would produce a repeating pattern on the A12 and A0 lines for many iterations before the PC exceeds the ROM address space. Simply wait for n iterations of the pattern before injecting the first real instruction.

 

Couple questions:

 

For the 2nd kernel, "__B11111"

Can we also use the missile and make the ball double wide? "MBB11111"

It means just a double wide pixel, but otherwise colors are right. (two double pixels with interleaving)

 

________MBB1111

MBB1111________

 

 

For the 3rd kernel, was thinking you reflect player graphics, to put the repeated/bad graphics data at the end of the span at least, but that won't help with interleaved data.

 

 

I made a mistake in the 3rd diagram. The last sprite wouldn't be missing any pixels. Due to the JSR hack the fourth pixel of the fourth sprite would always be on. That could be masked away with the ball by changing PF priority. I still don't like that option though because of the last color being the bitwise and of the previous two sprites.

 

For the second kernel I think the last two writes are backwards. GRP0 should be written before COLUP1. So using M1 has the same problem as using GRP1. COLUP1 isn't correct until after the first 3 pixels. Ball doesn't have this problem since it has it's own color. Maybe put the ball on the left most pixel and set it to disable, 1 wide, 2 wide or 4 wide depending on what's closest to the desired graphic. For a movie that would probably be acceptable.

 

I wonder if this could be built with an Arduino. They're cheap and SD card shields are readily available for them. If so I could duplicate your setup if you needed help with debugging at some point. I already have all the signals brought out to a breadboard for my harmony project. Would be trivial to fork off A12, A0, and D0-D7 to the Arduino.

[+rbairos]

A12 is a reliable chip select, but selecting the chip and address decoding aren't the same thing. Since the 2nd kernel uses JSR for colors and bit 0 of the color is ignored anyway it might be possible to ensure A0 always toggles when a new data value is requested.

 

The biggest challenge I see with this is handling the power on reset. The state of the bus will be undefined for some time before the reset vector is read. I think this could be handled by putting $15 on the data bus on startup and leaving it there. That would give a reset vector of $1515 and then a stream of ORA zpg,X instructions. This would produce a repeating pattern on the A12 and A0 lines for many iterations before the PC exceeds the ROM address space. Simply wait for n iterations of the pattern before injecting the first real instruction.

 

 

I made a mistake in the 3rd diagram. The last sprite wouldn't be missing any pixels. Due to the JSR hack the fourth pixel of the fourth sprite would always be on. That could be masked away with the ball by changing PF priority. I still don't like that option though because of the last color being the bitwise and of the previous two sprites.

 

For the second kernel I think the last two writes are backwards. GRP0 should be written before COLUP1. So using M1 has the same problem as using GRP1. COLUP1 isn't correct until after the first 3 pixels. Ball doesn't have this problem since it has it's own color. Maybe put the ball on the left most pixel and set it to disable, 1 wide, 2 wide or 4 wide depending on what's closest to the desired graphic. For a movie that would probably be acceptable.

 

I wonder if this could be built with an Arduino. They're cheap and SD card shields are readily available for them. If so I could duplicate your setup if you needed help with debugging at some point. I already have all the signals brought out to a breadboard for my harmony project. Would be trivial to fork off A12, A0, and D0-D7 to the Arduino.

For reset condition, If we go with A0, 2-byte instructions like ORA zpg,X are fine, as I'll know whether Im in first byte or second byte of that instruction when I need to start injecting,

but originally I thought about an operand in the 4K space, that didnt take a second byte, so I could feed it repeatedly, and interject immediately at any point.

Something like: Clear Carry Flag (hex 18) which is always a single byte.

 

The reason I reason I thought Id want A11 though, is to detect resets *after* startup. Without it, it means the only way to restart the movie is toggling the power, since the reset button would have no effect, which may be annoying. Not sure yet. But the fewer address lines the better.

 

I actually have a couple arduinos lying around, and an SD shield I used for an old project, but discounted them, thinking they weren't bare bones enough. I was originally leaning towards PICs (which I'm way more familiar with in terms of optimized code), but if the Arduino fits, it might be a *really* accessible approach for the reasons you list. I know you can intermix assembler with C on the Arduino IDE easily enough, which I needed (The digitalWrite() is about 50x slower then simply setting the bit directly if my memory serves)

 

Your help has been great. You've been filling in all the holes of my rough notions. Feel free to duplicate/expand/explore on anything. Duplicating anything I come up with as well sounds super helpful thanks.

 

First thing Im still trying to nail down is the kernel. Ive made some test renders based on your kernel2 above (with the repeated graphic-data at the end and limited palette in the middle), but the limited color palette is throwing off the dithering badly in the middle of the screen. Inaccurate graphic data seems to be much more tolerable (since the dithering is noisy anyways), then bad coloring, so Im going to explore rearranging parts of that kernel to use JSR on GP data instead.

 

Cheers.

[ZackAttack]

For reset condition, If we go with A0, 2-byte instructions like ORA zpg,X are fine, as I'll know whether Im in first byte or second byte of that instruction when I need to start injecting,

but originally I thought about an operand in the 4K space, that didnt take a second byte, so I could feed it repeatedly, and interject immediately at any point.

Something like: Clear Carry Flag (hex 18) which is always a single byte.

Actually that's a much better idea. I was originally thinking it could be problematic since multiple cycles would hit the same address, but that shouldn't matter because it will always toggle A0 when transitioning to the next instruction.

 

The reason I reason I thought Id want A11 though, is to detect resets *after* startup. Without it, it means the only way to restart the movie is toggling the power, since the reset button would have no effect, which may be annoying. Not sure yet. But the fewer address lines the better.

The reset switch on the Atari isn't related to the physical reset pin of the 6507. You have to poll the value of the reset switch just as you would with the joystick button. The only way to put the CPU into a reset state is to power cycle it. Well, I suppose you could modify the motherboard too...

 

I actually have a couple arduinos lying around, and an SD shield I used for an old project, but discounted them, thinking they weren't bare bones enough. I was originally leaning towards PICs (which I'm way more familiar with in terms of optimized code), but if the Arduino fits, it might be a *really* accessible approach for the reasons you list. I know you can intermix assembler with C on the Arduino IDE easily enough, which I needed (The digitalWrite() is about 50x slower then simply setting the bit directly if my memory serves)

I have no idea if either of those will actually work. I've worked with much more powerful microcontrollers only to find that the I/O latency was too high to directly interface with the 6507 buses. PICs are cool too, so don't let me talk you out of them too easily. Either way the first thing I would do is to put a scope or logic analyzer on it and experimentally verify you can capture the A12 and A0 changes and update an 8 bit bus with a new value quick enough. The good news here is that you'll already know what value to output on the data bus before the transition occurs. So you can write it out as soon as you detect it.

 

Your help has been great. You've been filling in all the holes of my rough notions. Feel free to duplicate/expand/explore on anything. Duplicating anything I come up with as well sounds super helpful thanks.

 

First thing Im still trying to nail down is the kernel. Ive made some test renders based on your kernel2 above (with the repeated graphic-data at the end and limited palette in the middle), but the limited color palette is throwing off the dithering badly in the middle of the screen. Inaccurate graphic data seems to be much more tolerable (since the dithering is noisy anyways), then bad coloring, so Im going to explore rearranging parts of that kernel to use JSR on GP data instead.

 

Cheers.

Always happy to help where I can.

 

If you want perfect color at the expense of graphics you could just vary #3 slightly like this. Due to the 3 pixel cpu cycles the staggered row will lose one more pixel. I marked the potentially incorrect pixels with *. I'm assuming you can't correct with Ball at all because there won't be enough cycles available.

color               colup0          colup1          A               A               X               Y   
graphic             grp0del         grp1del         grp0            PCH             PCL             Y       
                    00000000        11111111        00000000        111*1111        00000000        ***11111
                   sta---cp0lda---JSR------gp1gp0---sta---cp1stx---cp0st?---gp0sty---cp1ldy---sty---gp1           
                            00000000        11111111        00000000        111*1111        00000000        ****1111
                            sta---cp0lda---JSR------gp1gp0---sta---cp1stx---cp0st?---gp0sty---cp1ldy---sty---gp1    

Personally I would recommend using this 5 sprite kernel instead. Then you can achieve perfect colors and graphics for all 5 sprites. This also leaves more cycles to setting audio and background colors. Since you need to use Ball to mask the PCH bit in the second copy of GRP1 anyway, you can use PF to mask the background color on the sides. I bet having the background color set each scanline would improve picture quality a lot more than going from 10 sprites wide to 12 wide. Of course this can be down with a static mirrored PF and static positioned BL.

 

color               colup0          colup1          A               A               Y       
graphic             grp0del         grp1del         grp0            PCH             PCL     
                    00000000        11111111        00000000        111B1111        00000000
                   sta---cp0lda---JSR------gp1gp0---sta---cp1sta---gp1sty---cp0             
                            00000000        11111111        00000000        111B1111        00000000
                            sta---cp0lda---JSR------gp1gp0---sta---cp1sta---gp1sty---cp0             

Btw, it would be easier to come up with kernel ideas if we knew what it's going to look like. Would you provide a few mockups? Are you planning on "reshooting" the movies with tiled graphics or writing some automatic image conversion algorithm to downscale to Atari?

 

Would you mind if I port this to the harmony eventually? I think it would allow a lot more people to see the results on real Atari hardware first hand.

[+rbairos]

All great information.
Didn't realize the 'reset' switch was a fake. Very cool.
Feel free to run with any of this on the Harmony at your own speed while I explore options on a pic microcontroller for example.
My rate of progress will be quite slow, I just started playing with actual (emulated) kernels last night. To say its tricky is an understatement!

Yah, if I can get perfect graphics+color on 5 sprites, I will definitely go with that.

Ive made tonnes of mockups over the last two weeks.
Here's one I just completed right now, based on 'perfect' 5 sprites:


Be sure to play it in HD / 60 fps

set to 60fps playback!
80 colums by 160 rows. one frame of odd colums (8 pixels wide) one frame of even columns (8 pixels wide)
top left: dithering per 8-pixel cell using 128 atari palette colors, but holes are filled in + brighter areas weighted more heavily
top right: dithering on white/black
bottom left: multiplication of top two images
bottom right: imagined on CRT
input image is auto brightened per scene
audio is 4 bit, auto-scaled, about 11khz



The (thin) vertical black lines between bright areas are an artifact of the video player rescaling the image, but should be greatly reduced when playing back at native resolution.
The (fat) vertical black bars are a result of the playback dropping 60fps

[EDIT: The way its structured, the b/w switch on the atari might be able to easily swap out the top-right image for the bottom-left, as the graphics data are identical in both, just the individual coloring is swapped with the 1-bit monochrome color]

I recommend playing back the original file on something like VLC media player. That particular file is about 10meg, I could probably host somewhere.

Cheers,
Rob.

Edited December 4, 2017 by rbairos

[ZackAttack]

That video looks so much better than I was expecting. For some reason my phone seems to do a better job at holding the 60fps. I'm pretty sure you could just attach a 10mb file to your post here. Isn't the limit 50mb?

 

Did you see my comment about changing the background color per row? Perhaps it would be useful for scenes with 2 bright dominant colors?

 

Now I'm wondering if we can build a youtube app for the Atari or maybe include some cut scenes in future games.

[+rbairos]

Thanks! I was a bit worried people might consider it totally painful.

In terms of background color per row, how do you mean specifically? I made a bunch of test renders playing with a simulated playfield, which would be a low resolution monochrome dithering of the blank spots, but that ended up looking worse, as it suggested everything was blocky and low res.

A youtube app would require a wifi connection on the cartridge, but I like your style.
Cut scenes would be very funny/awesome. You're playing a classic atari blocky game for a while, finish a scene, and are rewarded with a completely unexpected 'hi-res' animation.

I mean, if this kernel was just a bit clearer, you could theoretically use it for anything, including other video games.
It's not quite usable, but here's what dragon's lair would look like:

I can upload as attachment if anyone's interested.

You'd have to hand edit each scene for maximum contrast/clarity. I dynamically changed the coloring on a couple spots as it was rendering out.
The gameplay logic (like the original) would be very basic, like the movie cart logic: At the end of each scene, decide what the next scene is based on the inputs.

Cheers

Edited December 6, 2017 by rbairos

[ZackAttack]

Ok, I've just about got this working on the harmony cart. Still need to mask off the one pixel with BL and fix the JSR target address to map it to account for the bytes of instructions between the previous JSR and the current one. Then I'll drop in some actual data instead of a procedural generated pattern. Also need to implement interlacing, but the flicker isn't too bad with the interweaved pattern.

 

 

 

[iesposta]

Thanks! I was a bit worried people might consider it totally painful.

 

In terms of background color per row, how do you mean specifically? I made a bunch of test renders playing with a simulated playfield, which would be a low resolution monochrome dithering of the blank spots, but that ended up looking worse, as it suggested everything was blocky and low res.

 

A youtube app would require a wifi connection on the cartridge, but I like your style.

Cut scenes would be very funny/awesome. You're playing a classic atari blocky game for a while, finish a scene, and are rewarded with a completely unexpected 'hi-res' animation.

 

I mean, if this kernel was just a bit clearer, you could theoretically use it for anything, including other video games.

It's not quite usable, but here's what dragon's lair would look like:

 

I can upload as attachment if anyone's interested.

 

You'd have to hand edit each scene for maximum contrast/clarity. I dynamically changed the coloring on a couple spots as it was rendering out.

The gameplay logic (like the original) would be very basic, like the movie cart logic: At the end of each scene, decide what the next scene is based on the inputs.

Cheers

 

 

 

Wow!

 

I would have thought a game would be made first with true interlacing because of its unique look with double the vertical resolution.

Then you demonstrate color video!

 

"Bad Apple" with its big playfield squares in black and white was the closest thing to video until this.

Thanks for sharing!

[+rbairos]

 

Wow!

 

I would have thought a game would be made first with true interlacing because of its unique look with double the vertical resolution.

Then you demonstrate color video!

 

"Bad Apple" with its big playfield squares in black and white was the closest thing to video until this.

Thanks for sharing!

Well, its still a work in progress.

My videos are still proof of concept, using GLSL and some custom C++ code, (no stella), while ZackAttack is actually implementing a 5+5 sprite kernel with single frame outputs + short audio currently. Full video will be the ultimate goal, both as a generic solution for Harmony carts, that ZackAttack is working on, and possibly some custom h/w I might explore as one offs, for a learning exercise / maker exhibits.

 

 

 

Edited December 27, 2017 by rbairos