+SpiceWare Posted October 20, 2016 Share Posted October 20, 2016 CURRENT VERSIONS OF THE DEMOS: 2016-12-31 reply #60 - 18 colors per scanline1 2017-01-01 reply #64 - 128 Chronocolour demo1 2017-01-20 reply #79 - 128 pixel demo1 2017-06-16 reply #185 - RPG Demo2 2016-11-02 reply #49 - Draconian reboot1 Some demos were original posted in other topics. NOTE: At this time these demos only work on real hardware via a Harmony Cartridge. 1 demos prior to June 6, 2017 run under Stella 5.0.0-pre6 or pre7. 2 demos from June 6 on need Stella 5.0.0-pre8 or newer. 1,2 most demos now work using Stella 6.7 or newer. Instead of having demos all over, I thought I'd consolidate them into a single topic. As I update the demos I'll update this post so it's easy to find the current versions. RPG demo - this creates a 12x16 multicolor tile display. As with the other demos, this only works on real hardware via a Harmony cartridge. Stella support will be released once we finalize the driver. rpg_20161019.bin At this time this is a non-interactive demo. However, you can specify your TV Type via the difficulty switches. Left Difficulty=A, Right=B for PAL60: Left=A, Right=A for SECAM60: Left=B for NTSC: 12 Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted October 20, 2016 Share Posted October 20, 2016 Is flicker used? Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 20, 2016 Author Share Posted October 20, 2016 Is flicker used? Yes, only way to create a 96 pixel display on the 2600. If you have trouble with 30 Hz flicker try wearing a pair of polarized sunglasses, that'll help. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted October 20, 2016 Share Posted October 20, 2016 No trouble here. Just trying to work out the algorithm you used. Looks really good btw. I assume the character would move in tile sized steps and take the place of the background. That would work nicely for an RPG. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 20, 2016 Author Share Posted October 20, 2016 No trouble here. Just trying to work out the algorithm you used. Usual 96 pixel display created by alternating between 2 layouts, even odd: and odd even: even and odd refer to the positions of the players on each scanline: ; The players are positioned: ; EVEN: 0-1-0-1-0-1- ; ODD: -0-1-0-1-0-1 This is the update for the even Scanlines: sty GRP0 ; before 34 sty COLUP0 ; before 34 sty GRP1 ; before 39 sty COLUP1 ; before 39 sleep a few ; 35 sty GRP0 ; 3 38 @37-43 sty COLUP0 ; 3 41 @37-43 sty GRP1 ; 3 44 @41-49 sty COLUP1 ; 3 47 @41-49 sty GRP0 ; 3 50 @47-54 sty COLUP0 ; 3 53 @47-54 sty GRP1 ; 3 56 @52-59 sty COLUP1 ; 3 59 @52-59 The @x-y are the cycle ranges those instructions must finish on, they're the cycles between instances of each player. Bus stuffing makes it possible to change both the image and the color in those cycles. Odd scanlines use same update pattern, just with slightly different cycle ranges. cd-w worked out the timing. The kernel also supports PF1 and PF2 updated on every scanline (symmetrical mirrored) with background and playfield color changes on every line, but based on another test we decided we're going to remove that and put the ball behind the "hero" instead. The ball will be colored based on the tile the hero's standing over, so the black behind the hero standing in the road would be grey instead. It won't be a perfect replacement though, when standing over the grass the green behind the hero would be solid instead of the alternating dot pattern. Looks really good btw. I assume the character would move in tile sized steps and take the place of the background. That would work nicely for an RPG.Yeah, much better than I was expecting. Yep, the hero moves a tile at a time. The engine's flexible, while I'm demoing it as a 12x16 display with 8x12 tiles it could just as easily be 12x12 with 8x16 tiles, 12x24 with 8x8 tiles, 12x25 with 8x8 tiles etc. The height of the tiles just needs to be a multiple of 2. I'll be releasing the source for all the demos once we finalize Bus, we're still making changes to it that will break the current demos. 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 21, 2016 Author Share Posted October 21, 2016 Volcano & lava, ball now used to backfill behind the hero: rpg_20161020.bin Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 22, 2016 Author Share Posted October 22, 2016 Yes, it displays correctly with right diff in 'A' position on my sixer! I added an auto-detect to the 128 Chronocolour demo. If it works right you won't have any gaps or overlaps. 128chronocolour_20121022.bin Left Difficulty=A for PAL. This is only checked one time, when you power up the console. The demo starts with a 240 line display. Which you can decrease with the joystick in order to get a higher refresh rate, and thus less flicker. For those trying this out, 240's quite a bit less than the usual 262 scanlines so your TV may not like the picture. If this demo scrolls when first loaded, then Artillery Duel and Buck Rogers probably don't work on your TV either. Quote Link to comment Share on other sites More sharing options...
iesposta Posted October 22, 2016 Share Posted October 22, 2016 (edited) Did the previous ChronocolourTM start at 240? Those worked no problem. Because the best I can get with this last one on a Framemeister to LCD is split-screen. Same no go on Sony 32" TV. Starts out all over the place. Joystick down ends in last spot split screen. Edited October 22, 2016 by iesposta Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 22, 2016 Author Share Posted October 22, 2016 Did the previous ChronocolourTM start at 240? Those worked no problem. The previous Chronocolour is part of the 128 pixel demo and outputs a steady 262 scanlines. This build was created specifically to test this idea, I'm not surprised at all that it doesn't work with a modern display. I don't think 128 Chronocolour will be useful unless the framerate could be increased. My C= 1084 can handle a variety of framerates if it could handle down to 131p then the flicker would be exactly the same as Andrew Davie's Chronocolour examples... Turns out my C= 1084S can handle down to around 190 scanlines, about 80 frames per second. That does result in a better picture, but is still pretty bad as far as flicker goes. Quote Link to comment Share on other sites More sharing options...
iesposta Posted October 22, 2016 Share Posted October 22, 2016 I'm still testing. No go on 3rd try. 27" WEGA. This display won't jitter, where others do. Going to try RF on a pre-2000 CRT. This is fun. The previous Chronocolour is part of the 128 pixel demo and outputs a steady 262 scanlines. This build was created specifically to test this idea, I'm not surprised at all that it doesn't work with a modern display. Turns out my C= 1084S can handle down to around 190 scanlines, about 80 frames per second. That does result in a better picture, but is still pretty bad as far as flicker goes. Quote Link to comment Share on other sites More sharing options...
iesposta Posted October 23, 2016 Share Posted October 23, 2016 Success! The Zenith 27" works. Figures. That's the display that the 1-pixel playfield scroller worked, where the others would only show 3 steps or 2 steps. I thought there was always a slight space visible between every player strip, but some places it doesn't. It changes also. The text has pairs on the right without gaps. The 100 and 200 blu car picture is different. And the ChronocolourTM has a big 4 player solid block then a three player solid block on the right. Maximum squish: Atari Jr. w/scrap built S-Video: Heavy 6er RF, no squish: Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 23, 2016 Author Share Posted October 23, 2016 The 100 and 200 blu car picture is different. 100 = 128x100 pixels 200 = 128x200 pixels Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 23, 2016 Author Share Posted October 23, 2016 Turns out the on-the-fly color conversion was taking too much time for PAL and SECAM. So I removed it and configured the project for NTSC and PAL60 builds. rpg_20161022_NTSC.bin rpg_20161022_PAL.bin You can now run around. What you're on controls your speed: roads=fast, swamp=sluggish. The world's been expanded to 6 screens. Left Difficulty A changes the status line to show time remaining, with Vertical Blank on the left and Overscan on the right. Something scrambled, like this time for Vertical Blank, just means the even and odd frames are taking different amounts of time. Quote Link to comment Share on other sites More sharing options...
iesposta Posted October 23, 2016 Share Posted October 23, 2016 100 = 128x100 pixels 200 = 128x200 pixels I was still referring to the slight gap between the Players, and that each demo has different groups of Players that DON'T have the slight dark gap. Quote Link to comment Share on other sites More sharing options...
alex_79 Posted October 23, 2016 Share Posted October 23, 2016 Yes, it displays correctly with right diff in 'A' position on my sixer! I added an auto-detect to the 128 Chronocolour demo. If it works right you won't have any gaps or overlaps. It works! Alignment is now correct on both my 6 and 4 switches consoles. Anyway I cannot get the tv to sync correctly. At start the screen just rolls and by increasing the scanline count with the joystick the best I can get is a stable "split-screen" arrangement like in the pictures posted by iesposta above. Also, I only get the chronocolour car image (with NTSC colours), the firebutton doesn't cycle through different screens like previous demos. Is this the expected behaviour? The latest RPG demos work fine! Very nice! Previous version showed a screen-roll in SECAM mode. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 23, 2016 Author Share Posted October 23, 2016 It works! Alignment is now correct on both my 6 and 4 switches consoles. Awesome! I'll migrate the autodetect routine to the original 128 pixel demo. Most likely this will happen mid-to-late November as I need to get the BUS demos I'll be showing at the Houston Arcade Expo wrapped up. Also, I only get the chronocolour car image (with NTSC colours), the firebutton doesn't cycle through different screens like previous demos. Is this the expected behaviour? Yep, I cloned the 128 demo and ripped everything else out except chronocolour in order to minimize overhead (ie: remove OverScan). That way I could shrink the scanline count (down to 240) before the car image had to be made smaller. Likewise the NTSC/PAL was changed to minimize overhead, it used to run every frame in the now missing OverScan, so I moved it to Initialize(), which only runs when you first power up. Set Left Difficulty=A for PAL then load the demo. I updated reply #7 to include this info. The latest RPG demos work fine! Very nice! Previous version showed a screen-roll in SECAM mode. Great! There were way too many color changes to calculate for PAL and SECAM - 6 colors per scanline, so 1152 per frame. For games like Draconian that's not a problem as only a single color is calculated per display object (so maybe 20 times per frame). If there's RAM space it'd be possible for me to preconvert all the colors when you specify the TV Type via (the not yet in place) menu. However, the shape & color info is intermingled like this so it would use up a lot of RAM. Forest_ID = (*-Tiles)/(TILE_HEIGHT*2) .byte %00000000, GREEN+4 ; 0 .byte %00010000, GREEN+4 ; 1 .byte %00111000, GREEN+6 ; 2 .byte %00111000, GREEN+4 ; 3 .byte %01111100, GREEN+4 ; 4 .byte %01111100, GREEN+6 ; 5 .byte %11111110, GREEN+4 ; 6 .byte %11111110, GREEN+4 ; 7 .byte %00111000, GREEN+6 ; 8 .byte %00010000, OCHRE+4 ; 9 .byte %00010000, OCHRE+4 ;10 .byte %00010000, OCHRE+4 ;11 The data's like that as the C code can use unsigned short int (works with 2 bytes at a time) for faster performance when copying the player-color data into the frame buffer. You can see the impact in the current RPG demo via the TV Type switch. COLOR = original unsigned char (works with 1 byte at a time), alternates between $10 and $11 left over in VB: B&W = unsigned short int, alternates between $12 and $14 left over in VB: So unsigned short int is 2-3 scanlines faster. Not enough to compensate for the color conversion routines though. Original routine using unsigned char: unsigned char* player_data; unsigned char* tiles[12]; ... player_data = ((unsigned char *)(DD_BASE + PLAYER_DATA)); ... for(i=0;i<TILE_HEIGHT;i += 2) { // EVEN *player_data++ = *tiles[ 0]++; // shape *player_data++ = *tiles[ 0]++; // color *player_data++ = *tiles[ 2]++; // shape *player_data++ = *tiles[ 2]++; // color *player_data++ = *tiles[ 4]++; // shape *player_data++ = *tiles[ 4]++; // color *player_data++ = *tiles[ 6]++; // shape *player_data++ = *tiles[ 6]++; // color *player_data++ = *tiles[ 8]++; // shape *player_data++ = *tiles[ 8]++; // color *player_data++ = *tiles[10]++; // shape *player_data++ = *tiles[10]++; // color // ODD *player_data++ = *tiles[ 1]++; // shape *player_data++ = *tiles[ 1]++; // color *player_data++ = *tiles[ 3]++; // shape *player_data++ = *tiles[ 3]++; // color *player_data++ = *tiles[ 5]++; // shape *player_data++ = *tiles[ 5]++; // color *player_data++ = *tiles[ 7]++; // shape *player_data++ = *tiles[ 7]++; // color *player_data++ = *tiles[ 9]++; // shape *player_data++ = *tiles[ 9]++; // color *player_data++ = *tiles[11]++; // shape *player_data++ = *tiles[11]++; // color for(c=0;c<COL_COUNT;c++) tiles[c] += 2; } Revised routine using unsigned short int: unsigned short int* player_data; unsigned short int* tiles[12]; ... player_data = ((unsigned short int *)(DD_BASE + PLAYER_DATA)); ... for(i=0;i<TILE_HEIGHT;i += 2) { // EVEN *player_data++ = *tiles[ 0]++; // shape & color *player_data++ = *tiles[ 2]++; // shape & color *player_data++ = *tiles[ 4]++; // shape & color *player_data++ = *tiles[ 6]++; // shape & color *player_data++ = *tiles[ 8]++; // shape & color *player_data++ = *tiles[10]++; // shape & color // ODD *player_data++ = *tiles[ 1]++; // shape & color *player_data++ = *tiles[ 3]++; // shape & color *player_data++ = *tiles[ 5]++; // shape & color *player_data++ = *tiles[ 7]++; // shape & color *player_data++ = *tiles[ 9]++; // shape & color *player_data++ = *tiles[11]++; // shape & color for(c=0;c<COL_COUNT;c++) tiles[c]++; } 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 23, 2016 Author Share Posted October 23, 2016 I was still referring to the slight gap between the Players, and that each demo has different groups of Players that DON'T have the slight dark gap. Gotcha! The gaps should appear based on when adjacent players are on alternate scanlines. If I disable bus stuffing then the text, line, and both car demos have this arrangement: where you can see the players appear next to each other a few times on the right, but not at all on the left, so you should see fewer of those slight gaps on the right side. They should all be the same though, don't know why you're seeing different results. The chronocolour demo does use a different arrangement: Turning off bus stuffing causes some of the left side to get messed up for some reason, but you can still see the difference on the right side, which would cause the gaps to be different. 1 Quote Link to comment Share on other sites More sharing options...
maiki Posted October 23, 2016 Share Posted October 23, 2016 It is really bad news that you have to use interlacing because it simply sucks. On the other hand, so many people do not care about proper image of vintage video games nowadays, using crappy LCDs or plasmas... that it probably does not matter... which is bad news as well... Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted October 23, 2016 Share Posted October 23, 2016 It is really bad news that you have to use interlacing because it simply sucks. On the other hand, so many people do not care about proper image of vintage video games nowadays, using crappy LCDs or plasmas... that it probably does not matter... which is bad news as well... Just because these demos happen to use interlacing doesn't mean all applications of the new BUS driver will need to. I'm sure he could have just as easily demonstrated a full width asymmetric playfield with multi colored sprites plastered all over the place. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 23, 2016 Author Share Posted October 23, 2016 It is really bad news that you have to use interlacing because it simply sucks. On the other hand, so many people do not care about proper image of vintage video games nowadays, using crappy LCDs or plasmas... that it probably does not matter... which is bad news as well... There are 5 Bus Stuffing demos so far, 3 use interlace, 2 do not. I'm running all of these demos on my C= 1084S that I've had since purchasing my Amiga 2000HD back in 91. All the demos look fine on it with the exception of the 128 Chronocolour demo. I've stated before that the 128 Chronocolour is just an interesting tech demo, but not something useful due to the flicker. If you're talking specifically about the RPG demo then yes, we must use interlacing to generate a 96 pixel display. There's no getting around that with the 2600. Up until now we've been able to get at most 2 colors per scanline(not counting the background color) with a 96 pixel display: We wanted to see how far we could push that with Bus Stuffing and Chris came up with this 12 color version. We thought it'd lend itself to a tile base game, so decided on a simple RPG demo to see if that was the case. I think the results speak for themselves. Same goes for the 128 pixel demos, interlace is required. Anyway, these are all just demos that we're creating to test out the Bus Stuffing Driver. We need to make sure it works correctly on real hardware, and in Stella, before we can release it for other people to start creating new games. I didn't have to share them, but thought people might find them interesting as we've been talking about Bus Stuffing for years with nothing to show until now. If you don't find them interesting, then don't download them. 5 Quote Link to comment Share on other sites More sharing options...
cd-w Posted October 24, 2016 Share Posted October 24, 2016 It is really bad news that you have to use interlacing because it simply sucks. . Why does interlace suck? On a CRT screen the flicker is hardly noticeable. Many Atari games use flicker, and a constant 30hz interlace looks far better than 15hz flicker. I agree that it looks poor on an LCD TV, but that is because the image is not handled properly by the TV. Chris 2 Quote Link to comment Share on other sites More sharing options...
alex_79 Posted October 24, 2016 Share Posted October 24, 2016 (edited) constant 30hz interlace looks far better than 15hz flicker. It's also better than non-interlaced 30Hz flicker, altough a little worse than a standard 625/525 lines interlaced TV signal, where scanlines are closer together. The RPG demo looks really good on real hardware. Especially for large solid tiles (like the rocks and the trees), the perceived flicker is minimal and it gets even better if you back away a bit from the screen. In the "grass" tiles with small green dots on black background flicker is a bit more evident. Anyway, by tweaking the colors and the graphics to minimize the effect, I think that the kernel could be very well used in a game. Edited October 24, 2016 by alex_79 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 24, 2016 Author Share Posted October 24, 2016 I guess the snow-peaked mountains need something better than programmer graphics Mountain_ID = (*-Tiles)/(TILE_HEIGHT*2) .byte %00000000, WHITE ; 0 .byte %00001000, WHITE ; 1 .byte %00011000, WHITE ; 2 .byte %00111100, WHITE ; 3 .byte %00111100, WHITE ; 4 .byte %00111100, OCHRE+12 ; 5 .byte %01111110, OCHRE+10 ; 6 .byte %01111110, OCHRE+8 ; 7 .byte %01111110, OCHRE+6 ; 8 .byte %11111111, OCHRE+4 ; 9 .byte %11111111, OCHRE+2 ;10 .byte %11111111, OCHRE ;11 I've made a color change which may help: Mountain_ID = (*-Tiles)/(TILE_HEIGHT*2) .byte %00000000, WHITE ; 0 .byte %00001000, WHITE ; 1 .byte %00011000, WHITE ; 2 .byte %00111100, WHITE ; 3 .byte %00111100, OCHRE+6 ; 4 .byte %00111100, OCHRE+6 ; 5 .byte %01111110, OCHRE+4 ; 6 .byte %01111110, OCHRE+4 ; 7 .byte %01111110, OCHRE+2 ; 8 .byte %11111111, OCHRE+2 ; 9 .byte %11111111, OCHRE ;10 .byte %11111111, OCHRE ;11 I have asked for contributions if anybody's willing 1 Quote Link to comment Share on other sites More sharing options...
iesposta Posted October 24, 2016 Share Posted October 24, 2016 I keep asking, but get no definitive answer. From what I have learned, it seems to me "VCS flicker" and "interlaced display kernel" are different. Tell me if this is wrong, please. If the VCS sends the CRT a properly formed NTSC interlaced scan lines, which are like flicker Frame A and Frame B, using the spec of almost what kernels are using with the 3 Vblanks etc, but in the proper line format of the first and last scan line being "half a scan line" we would have 480i. Doesn't the CRT display 480i better than the "VCS flicker"???? The true interlaced demos look like a new display mode to me, and not like flicker. And wouldn't the extra work to get this output be lessened by splitting work up in both A & B frames? Would this true Atari interlaced mode be 480i at 30Hz or 30 FPS, but real broadcast TV is 480i 60Hz 60 FPS, or am I mixing apples and oranges? Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 24, 2016 Author Share Posted October 24, 2016 They are different. If you look closely at the display of the 2600 you might notice that the scanlines are thicker than the gaps between the scanlines. What you think of being like this: xxxxxx xxxxxx xxxxxx (xxxxxx = scanlines, blanks = gap between scanlines) is more like this: xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx The alternate frame for a 480i signal would be like this: xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx So the upper & lower edges of the scanlines of the even and odd frames overlap(capital XXXXXX), which helps to hide the flicker. XXXXXX xxxxxx XXXXXX xxxxxx XXXXXX xxxxxx XXXXXX xxxxxx XXXXXX xxxxxx XXXXXX An interlaced display gives you more vertical detail. The reason we typically use flicker on the VCS is to show more horizontal detail per scanline than the VCS is capable of - more than 2 independently moving sprites, more than 48 pixels, more colors (such as the timer in Lady Bug), etc. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.