+SpiceWare Posted June 27, 2012 Share Posted June 27, 2012 The 32 character routines are far enough along for what I needed in Space Rocks, so work on the 32 character routines for general use will resume once Space Rocks is completed. What I'm planning to do is create a demo like I did for DPC+ where each bank (1-5) will show off a different feature. There won't be a demo in bank 0 because that's where the ARM code and font data are located. You will be able to utilize space in bank 0 for storing text strings and such as the ARM code doesn't have the bank restricts that 6507 code does because the ARM sees the entire cartridge w/out having to do any tricks. Quote Link to comment Share on other sites More sharing options...
mos6507 Posted March 10, 2013 Share Posted March 10, 2013 Has anyone tried doing a gapless Stellar Track kernel like what was being planned for Chimera? I like this because it has the full ATASCII character set, therefore it looks like something Atari Inc. would have done. We were planning on having this be both a character or bitmap mode, kind of the standard 1-bit bitmap mode, and another would have been an ARM-driven version of the Suicide Mission kernel. So games could be targeted to these as if they were genuine graphics modes like on a home-computer. Quote Link to comment Share on other sites More sharing options...
iesposta Posted March 10, 2013 Share Posted March 10, 2013 Has anyone tried doing a gapless Stellar Track kernel like what was being planned for Chimera? I like this because it has the full ATASCII character set, therefore it looks like something Atari Inc. would have done. We were planning on having this be both a character or bitmap mode, kind of the standard 1-bit bitmap mode, and another would have been an ARM-driven version of the Suicide Mission kernel. So games could be targeted to these as if they were genuine graphics modes like on a home-computer. Your video is private. Personally I love bitmap mode like Suicide Mission. It's so different. I even have an idea for a game if I learn enough. Scumsoft was the last member working on something like this. He went missing/silent. He posted a demo where a bitmap knight can move all around a 92 x 100 something, if I remember correctly using Harmony tricks, planned to go 115 x ? wide. Quote Link to comment Share on other sites More sharing options...
mos6507 Posted March 10, 2013 Share Posted March 10, 2013 I just changed it back to public. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted March 10, 2013 Share Posted March 10, 2013 Has anyone tried doing a gapless Stellar Track kernel like what was being planned for Chimera? It can be gapless vertically, but not horizontally. The vertical gaps are added in the C code, by line *start++ = 0;, in order to save ROM space in the FONT data. for(x=0;x<32;x += 2) { start = &TEXT_COLUMN[(x>>1) * TEXT_COLUMN_HEIGHT]; for(y=0;y<gRowCount;y++) { char_l = TEXT_SCREEN_MEMORY[y*32+x]; char_r = TEXT_SCREEN_MEMORY[y*32+x+1]; shift_l = (char_l & 1) ? 4 : 0; shift_r = (char_r & 1) ? 0 : 4; char_l >>= 1; char_r >>= 1; start_char_l = flashdata + FONT_LOCATION + char_l * FONT_HEIGHT; start_char_r = flashdata + FONT_LOCATION + char_r * FONT_HEIGHT; for(i=0;i<FONT_HEIGHT;i++) *start++ = (0x70 & (*start_char_l++ << shift_l)) + (0x07 & (*start_char_r++ >> shift_r)); *start++ = 0; } } Remove that line and the vertical gap goes away, though you'll want to change the font data from this: .byte zz_XXX__X_ ; 0 1 .byte zz_X_X_XX_ .byte zz_X_X__X_ .byte zz_X_X__X_ .byte zz_XXX_XXX to this: .byte zz_XXX__X_ ; 0 1 .byte zz_X_X_XX_ .byte zz_X_X__X_ .byte zz_X_X__X_ .byte zz_XXX_XXX .byte zz________ and increase the constant FONT_HEIGHT by 1. The horizontal gaps are also added in C code, by the 0x70 & and 0x07 &, but they are added due to this timing issue in the kernel: The datastream is compensated for the issue by this bit of C code: // compensate for sprites 11, 13 and 15 being off by 1 pixel start = &TEXT_COLUMN[TEXT_COLUMN_HEIGHT*11]; start_char_l = &TEXT_COLUMN[TEXT_COLUMN_HEIGHT*13]; start_char_r = &TEXT_COLUMN[TEXT_COLUMN_HEIGHT*15]; for(i=0;i<TEXT_COLUMN_HEIGHT;i++) { *start++ <<= 1; *start_char_l++ <<= 1; *start_char_r++ <<= 1; } 2 Quote Link to comment Share on other sites More sharing options...
mos6507 Posted March 10, 2013 Share Posted March 10, 2013 I remember it was tricky getting the gapless Stellar Track kernel to work but I have old threads on my blog documenting the process and the help I received. Stellar Track requires gaps between characters and processing time between rows but the kernel in my demo doesn't require either. The way it spools data out via hotspots is, based on what I've read, not that different from how Harmony works. So it seems in theory this sort of kernel would work on Harmony, but it sounds like nobody's tried doing it yet. Not to disparage what this other kernel does, of course. In my demo it really was like a true text mode and you could print to it. I was talking to Chimera through a serial port and every character I typed in Hyperterminal on my PC got printed onto the screen. There is a perception of gaps betwen characters in my demo by virtue of the flicker, but it's not really there. If you used it like a bitmap mode then you'd have sort of a column-like artefact due to the flicker. I always wanted to see how something like that might look with something other than text. There are, of course, many strategies for packing as many bits onto a line as possible. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted March 10, 2013 Share Posted March 10, 2013 (edited) Yeah, the DPC+ kernel for this is a loop that reads in bitmap data for the whole screen. If sprite positions 11, 13 and 15 could be corrected then the kernel could be used to draw a 128x100 bitmapped image. I have 2 main ARM routines that are called to update the text. Print() and RenderScreen(). Print() accepts a string and updates TEXT_SCREEN_MEMORY with the characters to disply. RenderScreen() takes the contents of TEXT_SCREEN_MEMORY and converts it to bitmapped data that the kernel reads in. The snippet of code above with for(x=0;x<32;x += 2) is the main section of RenderScreen(). In Space Rocks I call PrintChar(), instead of Print() as I'm simulating 300 baud speeds, in Overscan and RenderScreen() in Vertical Blank. http://youtu.be/FjNSrskWngM Edited March 10, 2013 by SpiceWare Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 15, 2016 Share Posted February 15, 2016 9 Quote Link to comment Share on other sites More sharing options...
eshu Posted February 16, 2016 Share Posted February 16, 2016 (edited) 128.pngPlease tell me there is bus stuffing here?!?!?!? Edit: wow there isn't! Seriously amazed!!! Edited February 16, 2016 by eshu Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 16, 2016 Share Posted February 16, 2016 Pretty cool, eh? cd-w figured it out. Quote Link to comment Share on other sites More sharing options...
iesposta Posted February 16, 2016 Share Posted February 16, 2016 Pretty cool, eh? cd-w figured it out. The last I saw this capture from Stella, there was not the duplicate error on the left. No one answered if it was a fix in Stella or a fix in the display routine. I would guess a fix in Stella because we program for real hardware? Quote Link to comment Share on other sites More sharing options...
iesposta Posted February 16, 2016 Share Posted February 16, 2016 When I ran a BBS from an Atari 800XL I had written a text adventure you could play on the BBS like a super-simple Zork. I remember putting a lot of time into it. There is a small chance I still have it, but last time I went through my floppies I didn't see it. That would be kind of cool to do another text adventure using the 32 character display. I know it's been done with Sears original Stellar Track, and its hack into Dark Mage, still... And just yesterday I started to build up another RetroPie, and it installs with Zork I, II, & III as a default, and I played a bit of Zork I. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 16, 2016 Share Posted February 16, 2016 The duplication error's still there, it's just hidden behind the playfield. Hitting COMMAND-N to disable the playfield results in this: Compare the screenshot in #133 with the one in #61. 1 Quote Link to comment Share on other sites More sharing options...
Omegamatrix Posted February 16, 2016 Share Posted February 16, 2016 My understanding is, this is still the 32 char routine, except that there are no gaps? So you can draw 128 pixels now. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 16, 2016 Share Posted February 16, 2016 Yup, effectively 128 pixel, "hires" buffered graphics on an Atari 2600. 1 Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted February 16, 2016 Share Posted February 16, 2016 Is there a bin for this? I'd like to see it on CRT and LCD tvs. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 16, 2016 Share Posted February 16, 2016 My understanding is, this is still the 32 char routine, except that there are no gaps? So you can draw 128 pixels now. Yep! cd-w figured it out: ; The sprites are positioned: ; |_0_0_0_1___10_010_ ; |0_0_0_1_101X_0___0 ; NOTES: ; 1) The left 2 copies of P0 are junk - they dont show on real hardware, ; but in Stella they are displayed. I'm using a PF mask to cover them up. ; 2) The X position is an extra copy of sprite 0 that needs to be masked by ; the ball. It isn't possible to modify NUSIZ0 early enough to prevent this ; copy showing. ; 3) The multi-RESP0 trick is used to create the second copy of P0 - it is ; performed at cycles 39/45 and 47/53 to avoid any gaps. try changing both difficulty switches 128_20160215.bin I do see a minor glitch from when I implemented even/odd frames. The first 2 characters are missing the topmost scanline. I plan to replace the "stairs", used for confirming GRP0 and GRP1 updates are correct, with a line drawing demo. I'll post the source when that's done. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted February 16, 2016 Share Posted February 16, 2016 My understanding is, this is still the 32 char routine, except that there are no gaps? So you can draw 128 pixels now. Yep! cd-w figured it out: ; The sprites are positioned: ; |_0_0_0_1___10_010_ ; |0_0_0_1_101X_0___0 ; NOTES: ; 1) The left 2 copies of P0 are junk - they dont show on real hardware, ; but in Stella they are displayed. I'm using a PF mask to cover them up. ; 2) The X position is an extra copy of sprite 0 that needs to be masked by ; the ball. It isn't possible to modify NUSIZ0 early enough to prevent this ; copy showing. ; 3) The multi-RESP0 trick is used to create the second copy of P0 - it is ; performed at cycles 39/45 and 47/53 to avoid any gaps. Is there a bin for this? I'd like to see it on CRT and LCD tvs. I'm not quite ready to release it, but here it is anyway Try out both difficulty switches 128_20160215.bin I just noticed a minor glitch from when I implemented even/odd frames. The first 2 characters are missing the topmost scanline. I plan to replace the "stairs" test pattern, used for confirming GRP0 and GRP1 updates are correct, with a line drawing demo. I'll post the source when that's done. 5 Quote Link to comment Share on other sites More sharing options...
Joe Musashi Posted February 16, 2016 Share Posted February 16, 2016 Very cool !!! ( 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. ) 1 Quote Link to comment Share on other sites More sharing options...
iesposta Posted February 17, 2016 Share Posted February 17, 2016 Questions: Did CD-W do this with or without DPC+? It just says without bus stuffing. I know Spice did his with DPC+. Does DPC+ let you update NUSIZ0 early enough so as not to need the Ball as a masking object? Would Bus Stuffing let you update NUSIZ0 early enough? Is a blank scan line still required between rows? Quote Link to comment Share on other sites More sharing options...
cd-w Posted February 17, 2016 Share Posted February 17, 2016 (edited) Questions: Did CD-W do this with or without DPC+? It just says without bus stuffing. I know Spice did his with DPC+. Does DPC+ let you update NUSIZ0 early enough so as not to need the Ball as a masking object? Would Bus Stuffing let you update NUSIZ0 early enough? Is a blank scan line still required between rows? My kernel requires DPC+ also - it is very similar to the previous approach, I just reorganised things a bit to avoid the vertical gaps. Bus stuffing should allow the ball to be removed, and the lines to be individually coloured. The blank line between rows is artificial - there is no need for any horizontal or vertical gaps. Chris Edited February 17, 2016 by cd-w Quote Link to comment Share on other sites More sharing options...
iesposta Posted February 17, 2016 Share Posted February 17, 2016 Amazing! I wish more 'retrogamers' actually understood what is accomplished here. The old 2600 has two 8-bit registers to draw its player 'sprites'. Simply two places to put eight ones and/or zeroes: 11111111 10101010 Here you take that space for just 16 on or off dots, and turn them into rows of 128 dots that change both across the display, and change down the display. Most of it done with just assembly programming precise timing. All on 1970's hardware technology. Quote Link to comment Share on other sites More sharing options...
ZackAttack 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! Quote Link to comment Share on other sites More sharing options...
cd-w Posted February 17, 2016 Share Posted February 17, 2016 (edited) 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. ) 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 Edited February 17, 2016 by cd-w Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 17, 2016 Share Posted February 17, 2016 Here you take that space for just 16 on or off dots, and turn them into rows of 128 dots that change both across the display, and change down the display. Most of it done with just assembly programming precise timing.To be fair we should speak about 2x64 dots (which made the task even more complex). 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.