cd-w Posted February 17, 2016 Share Posted February 17, 2016 Indeed it is quite an accomplishment. This is truly inspiring. Have you thought about trying to extend it to the full 160 pixel width? My experiments with bus-stuffing in stella seem to indicate that it's possible, but perhaps this technique can accomplish it with only DCP+. Looking forward to the line drawing demo. Thanks for sharing! Thanks - the 128 pixel kernel has only 2 cycles spare, so there is not enough space to extend to 160 pixels in this version. However, the ball sprite takes us quite a few cycles, so if that could be eliminated it would free up some space. Even so, I'm not sure how to generate a RESPx start signal on the left edge of the screen without leaving a gap ... Chris Quote Link to comment Share on other sites More sharing options...
cd-w Posted February 17, 2016 Share Posted February 17, 2016 Yup, effectively 128 pixel, "hires" buffered graphics on an Atari 2600. Maybe you will implement Elite fully now Chris Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 17, 2016 Share Posted February 17, 2016 (edited) Not anytime soon. How about a new kernel in bBasic, with line drawing, filled rectangles, text plotting etc. support? That way, the hardware specs can be completely abstracted from the developers. We should also experiment with interlaced graphics (480i). Maybe those look better on modern TVs? Edited February 17, 2016 by Thomas Jentzsch Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 17, 2016 Share Posted February 17, 2016 Is a blank scan line still required between rows? The blank scanlines between rows are because I dropped cd-w's routine into the existing 32 character demo, which had this in it: *start++ = 0; // add blank line between rows I hadn't gotten around to commenting it out yet - when I do, the results are: Which look good, but now the text doesn't go all the way down the screen so there's still more work to do. That's part of why I've not released the source yet 3 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 17, 2016 Share Posted February 17, 2016 Very cool !!! IMG_0721.JPG ( This is PAL60. There seems to be another small glitch. I think I've seen this before while doing interlace experiments. There may be something wrong with the vsync/vblank/overscan timing, but it likely will only show on PAL systems. ) That color change is odd. I took a quick look at the code but don't see what could be causing it. Quote Link to comment Share on other sites More sharing options...
Joe Musashi Posted February 17, 2016 Share Posted February 17, 2016 What kind of glitch are you seeing on PAL - is the screen rolling or is it the weird coloring at the top of the screen? Chris Sorry, I should have been more clear. The image position is stable, I meant the color switch at the top. That color change is odd. I took a quick look at the code but don't see what could be causing it. The VSync code looks ok. But Stella tells me that VBlank is enabled at line 237 and disabled at line 34. That may be a bit too much. It's also possible that starting VBlank at an uneven line may confuse the TV. Quote Link to comment Share on other sites More sharing options...
Joe Musashi Posted February 17, 2016 Share Posted February 17, 2016 Not anytime soon. How about a new kernel in bBasic, with line drawing, filled rectangles, text plotting etc. support? That way, the hardware specs can be completely abstracted from the developers. We should also experiment with interlaced graphics (480i). Maybe those look better on modern TVs? In case you need some code for interlace syncing. This demo contains macros for both NTSC and PAL. 1 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 17, 2016 Share Posted February 17, 2016 Thanks. However I found a problem on my PAL CRT. In interlaced mode only, the top two texts have a different color. The topmost is blue/orange, the 2nd one in between the top and the bottom colors. Any idea what is causing this? Quote Link to comment Share on other sites More sharing options...
Joe Musashi Posted February 17, 2016 Share Posted February 17, 2016 Do you experience this problem with the 128 pixel kernel or with the scrolling demo? On my CRT, the scrolling demo looks ok. The 128 pixel kernel however also shows a color shift in the top two rows. But it is already happening without interlacing. I suspect this is because of the non-standard blanking. I should note that the AtariAge interlace demo is made for PAL50. I'm not 100% sure that the sync code would also be the same for PAL60. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 17, 2016 Share Posted February 17, 2016 It was the scrolling demo. But I made a mistake and assembled for NTSC. Assembled for PAL it looks perfect. Though it is interesting to see, that the colors change from PAL to NTSC(?) in the NTSC version. Quote Link to comment Share on other sites More sharing options...
iesposta Posted February 18, 2016 Share Posted February 18, 2016 Help me out here, experts. If you are going to have flicker blinds, or any "every other frame" flipping, why not figure out the extra code that comes closest to a true specification NTSC interlaced signal? I'm sure I read it was tried and succeeded. Just something about having to start the screen frame 1/2 way into the display... Like a half then 239 lines for one frame and some other way for the 2nd frame. (I remember closed captioning failing because of the need to generate a lot of changes across a scan line. Or maybe it was because the Atari pixels are more rectangular than square. If you've ever seen the line near the top of the display with the blinking white segments, that's the closed captioning info.) Do CRT's still show flicker if the TV combines both frames? Is an NTSC interlaced frame 240 lines with every other line blank, and 2 fields every 60Hz? Bonuses would be: New displays would not flicker or drop evey other line. Two "frames" per screen means more time to run CPU commands? The interlaced AtariAge vertical scrolling did not flicker when I tested it. Any negatives besides having some extra code to start/stop the scan line at the proper interlaced Point? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 18, 2016 Share Posted February 18, 2016 That's 480i. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 19, 2016 Share Posted February 19, 2016 The VSync code looks ok. But Stella tells me that VBlank is enabled at line 237 and disabled at line 34. That may be a bit too much. It's also possible that starting VBlank at an uneven line may confuse the TV. I've always taken VBLANK register as "video blank" as it tells TIA to output blacker than black even if the TIA registers have data that would show something. SMPTE colorbars include an onscreen display of blacker than black, it's used to properly calibrate your television's brightness levels. I've used VBLANK mid-screen myself, in the original two-color 48 pixel routine. It was developed for Stay Frosty 2, but first publicly revealed with Frantic. It looks great when brightness is properly adjusted: but is quite noticeable if its misadjusted: My understanding is VBLANK has to be on when sending VSYNC; otherwise the TV might not "see" the sync signal, because it's hidden by the playfield/players/missiles/ball, resulting in screen rolls. Does Collect have any odd color changes? It turns VBLANK on at line 191 and off at 38. 3 Quote Link to comment Share on other sites More sharing options...
RevEng Posted February 19, 2016 Share Posted February 19, 2016 All of the bB kernels turn on VBLANK right after the visible display. I do the same with most of my own kernels. I think if it was an issue it likely would have come out by now. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 19, 2016 Share Posted February 19, 2016 Same here. I frequently use VBLANK directly after the kernel, especially because it might save me some bytes for clearing TIA registers. Quote Link to comment Share on other sites More sharing options...
Joe Musashi Posted February 19, 2016 Share Posted February 19, 2016 I do that too. But it may be important at which line this happens on a PAL system. I don't know if the way VBlanking is used in the 128 pixel kernel is really the cause for the color change. I hope the code gets released at some point, then I will do some experimenting. Stay Frosty 2 looks OK. I'll check Collect later today. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 19, 2016 Share Posted February 19, 2016 I hope the code gets released at some point, then I will do some experimenting. I hope to publicly release it this weekend, though things don't always go according to plan. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 22, 2016 Share Posted February 22, 2016 things don't always go according to plan. And they didn't - ended up dealing with a work computer issue this weekend. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted October 8, 2016 Share Posted October 8, 2016 I never got around to finishing what I'd planned to do with this demo, so here's the source since I'm now busy with the Bus Stuffing driver: 128_DPCplus.zip 2 Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted August 16, 2018 Share Posted August 16, 2018 That's exactly what I was looking for. Thanks! Now I just need to port the kernel over to C. 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted August 22, 2018 Share Posted August 22, 2018 That's exactly what I was looking for. Thanks! Now I just need to port the kernel over to C. A working printf for the 2600.. Never thought we'd go from Adventure to Colossal Cave Adventure! Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted August 23, 2018 Share Posted August 23, 2018 A working printf for the 2600.. Never thought we'd go from Adventure to Colossal Cave Adventure! I was actually referring to the 128 pixel gapless aspect. Had I posted to the topic I meant to reply to that would have been more obvious. There was just enough room to add support for changing the color each line. The plan is to use this for 128pixel title screens. If text is the only thing you need there's a 36 char kernel. That one's not gapless so it's only good for text. Eventually they will both find their way into the Strong-ARM framework. 2 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.