+SpiceWare Posted August 11, 2015 Share Posted August 11, 2015 Can it do a 32K game with the 6K extra? The Supercharger has 6K of RAM and a 2K ROM that contains the BIOS. The BIOS lets you load in new sections of code for the same game, Starpath called that a Multi Load game. An example of that would be Dragonstomper. From its manual: Dragonstomper is a Multi Load game. The three levels of Dragonstomper play are far too complex to be loaded into the Starpath Supercharger cartridge at one time. So the game cassette is divided into three sections, each of which is loaded separately from your cassette player into the computer memory of the Supercharger: Load One: The Enchanted Countryside Load Two: The Oppressed Village Load Three: The Dragon's Cave So doing a multi load game would allow you to do whatever size game you want, though it's not as convenient as using a 32K ROM. 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 11, 2015 Share Posted August 11, 2015 I have HD and CRT TVs that play my games perfectly, but my Progressive Scan CRTs look terrible, with jitters and doubled sprites (something I use regularly to get bigger objects) tearing in half with poor sync. Your bB code is probably taking too long to run, which will cause jitter - some displays are more forgiving than others which would be why you don't experience it on all of them. The current version of Stella hides some types jitter, such as that caused by bB code taking too long. I recently added support to Stella so it correctly emulates that, hopefully it'll be part of the 4.7 release. If you happen to be using a Mac you can try the build I posted. Stella also didn't emulate a different jitter issue that could occur in DPC+ if the DFxFRACINC registers weren't re-initalized every frame, my update fixes that too. You can read up about both in this topic. 3 Quote Link to comment Share on other sites More sharing options...
Papa Posted August 11, 2015 Author Share Posted August 11, 2015 (edited) AHAAAAAAA! I just realized that one set of drawscreens I don't sub back to my FRACINC registers! A simple oversight. That should fix whatever was happening with Street Fight World. I don't have any jitters or bad stuff happening on any of my multitude of televisions (nine sets) except the two sets that are progressive scan CRT. HD looks great. Regular old CRT looks great. I've also noticed that the scan counter built into Stella goes ape$#it on several original Atari games, although they look great on regular televisions. I was wondering, though... If the Harmony cart can play Super Charger games then why can't VBb enable extra memory for programming? I'm sure it's just something to do with a mapper that enables Super Charger. So why not make one that mixes the extra memory parts of one with the 32K (or higher) enabling parts of another? ...I know I'm still just dreamin'... Edited August 11, 2015 by Papa Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted August 11, 2015 Share Posted August 11, 2015 I have considered trying to code the Atari BASIC cart just to see what could be done. Before my wife found Bb and downloaded it for me ("Hey..I bet you would really like this!") I was looking at the Compumate. I really don't like blister-keys though. I would tolerate it if it was all I had. I consider getting help from the ARM processor to build carts that play on the original system to fit into my own 'purist' ideals. I like assembly and all, but I just can't seem to get as creative with it as I can with BASIC. I really love the sprite maker and playfield drawing tools in Bb and I seem to think in BASIC. I have all those old books on BASIC programming for Amiga and Atari computers and toy with AMOS and QBasic as well, but the fun of just sitting down and getting results immediately, like with a visual environment or vwBASIC, is very exciting. vwBASIC will be my next learning endeavor. I like that it's been upgraded to include labels, but I also think there is nothing wrong with the simplicity of number lines. Now that I see that each loop can approach 12K compiled it seems bigger. One factor with DPC+ is that the first and last banks are taken up by the ARM code. I've also found that progressive scan capable CRT's don't like DPC+. I have HD and CRT TVs that play my games perfectly, but my Progressive Scan CRTs look terrible, with jitters and doubled sprites (something I use regularly to get bigger objects) tearing in half with poor sync. I will print the manual (although a much deeper explanation with more examples would be helpful) like I did with VBb and BasiEgaXorz (another endeavor). Thanks a LOT for the compliments on my latest work. It means a whole heck of a lot coming from someone like you. You're welcome I agree about BASIC being a creative language and "thinking in BASIC" is a lot of fun, inspires creativity. Regarding using the SuperCharger Memory with bB I think it should be possible to add memory access routines to a 4K bB program so it can access the extra 2K of RAM, I did some work with Loon on routines for this awhile back. The Melody board has 32K to hold a ROM image and 8K for RAM (someone correct me if I've got this wrong) so it should be possible to create a custom bB kernel with 8K of extra RAM and 32K of ROM code, maxing out the Harmony/Melody format. 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 11, 2015 Share Posted August 11, 2015 If the Harmony cart can play Super Charger games then why can't VBb enable extra memory for programming? I'm sure it's just something to do with a mapper that enables Super Charger. So why not make one that mixes the extra memory parts of one with the 32K (or higher) enabling parts of another? bB could be updated to support just about anything, problem is there's a lot of "anythings" that could be done and only so much time to do it. 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 11, 2015 Share Posted August 11, 2015 The Melody board has 32K to hold a ROM image and 8K for RAM (someone correct me if I've got this wrong) That's correct so it should be possible to create a custom bB kernel with 8K of extra RAM and 32K of ROM code, maxing out the Harmony/Melody format. There needs to be a bankswitch driver that makes it work. The driver starts out in ROM, but must be copied into RAM for performance reasons. For DPC+ the driver is 3K, leaving 29K ROM and 5K RAM. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted August 11, 2015 Share Posted August 11, 2015 Out of curiosity, we are talking about 29K COMPILED, not 29K BASIC code, correct? 29K compiled is alot of machine code... 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 11, 2015 Share Posted August 11, 2015 Out of curiosity, we are talking about 29K COMPILED, not 29K BASIC code, correct? 29K compiled is alot of machine code... Compiled code that's 6507 or ARM. The bB's DPC+ Kernel uses up some of that 29K for its own routines, such as the flicker logic for handling 10 sprites, so you'd have whatever is left. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted August 11, 2015 Share Posted August 11, 2015 29K compiled is alot of machine code... Yes, but once you get into nice graphics, 29k get used quite fast. E.g. a 48 pixel, 192 lines graphic (one color, no animation) requires 1152 bytes 10 sprites, 16 lines tall, single line color, 4 frames of animation require up 1280 bytes ... Also, since you can only address 4k at a time, you may have to duplicate some data (or code) Quote Link to comment Share on other sites More sharing options...
Opry99er Posted August 11, 2015 Share Posted August 11, 2015 Yea, for sure... Doing graphics for the Atari must be quite different from the home computers with which I am most familiar... The TI has a character pattern table in the memory map with RAM reserved for data. It would seem that if someone like me wanted to program a simple shooter in bB, 29K would be more than sufficient. Quote Link to comment Share on other sites More sharing options...
Papa Posted August 11, 2015 Author Share Posted August 11, 2015 With Atari you ask it to please draw a line and let be a color if the gods allow it... Quote Link to comment Share on other sites More sharing options...
iesposta Posted August 12, 2015 Share Posted August 12, 2015 Compiled code that's 6507 or ARM. The bB's DPC+ Kernel uses up some of that 29K for its own routines, such as the flicker logic for handling 10 sprites, so you'd have whatever is left.Almost all of the first bank Bank1 is bB DPC+ Kernel. Only 100-some bytes left. Banks 2 through Bank 6 can be batari Basic code. So that is 20K. Graphics defined in those 5 banks get copied to the 4K RAM graphic's bank. You can indirectly change that RAM with the commands: pfpixel, pfline, (or setting Hi/Low points and DFPUSH data there which I've done with the playfield). Then there is the 3K DPC+ that uses ROM and a 1K table of frequency data for the DPC+ music that bB doesn't implement. (So 4K Kernel, 20K program, 4K graphics, and 3K DPC+ and 1K frequency data = 32K, right?) On top of all that you can use the 256K 256 byte stack to file away variables and retrieve them, but using the stack in bB hasn't been explored that much. DK Arcade 2600 only uses 3 stack bytes to flip between the game's score and the game's timer. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted August 12, 2015 Share Posted August 12, 2015 On top of all that you can use the 256K stack to file away variables and retrieve them, but using the stack in bB hasn't been explored that much. DK Arcade 2600 only uses 3 stack bytes to flip between the game's score and the game's timer. Did you mean 256 Byte stack? If not, where's the 256K coming from when the Harmony/Melody only has 8K? Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted August 12, 2015 Share Posted August 12, 2015 That's a phat driver Spice, but it enables the ARM as a coprocessor which is pretty awesome and 29K of ROM is still a ton of source code for a compiled BASIC. That's correct There needs to be a bankswitch driver that makes it work. The driver starts out in ROM, but must be copied into RAM for performance reasons. For DPC+ the driver is 3K, leaving 29K ROM and 5K RAM. The SuperCharger driver get's 6K of the RAM, I suppose the 8K Canal SuperCharger bank switching format could be enabled on Harmony/Melody if the SuperCharger driver does not have to reside in the 8K. Yes, but once you get into nice graphics, 29k get used quite fast. E.g. a 48 pixel, 192 lines graphic (one color, no animation) requires 1152 bytes 10 sprites, 16 lines tall, single line color, 4 frames of animation require up 1280 bytes ... Also, since you can only address 4k at a time, you may have to duplicate some data (or code) Says the programmer who writes awesome ML games in 1K! It works out that 2K batari BASIC games are actually 2K of BASIC source code - the runtime library for the kernel and score modules take up a little over 1K leaving about 700 bytes (if that) for the compiled BASIC program or about 2K of BASIC source code. Quote Link to comment Share on other sites More sharing options...
Mr SQL Posted August 12, 2015 Share Posted August 12, 2015 Yea, for sure... Doing graphics for the Atari must be quite different from the home computers with which I am most familiar... The TI has a character pattern table in the memory map with RAM reserved for data. It would seem that if someone like me wanted to program a simple shooter in bB, 29K would be more than sufficient. Opry99er, the graphics are completely different - the Atari has hardware for racing the electron beam accross the screen and drawing what you see. Because there is virtually no screen buffer there is no video RAM save 20-bits for drawing 1/2 a scanline at a time. This awesome design lets 4K ROM games on the VCS feel like they are 16K or 32K games on a contemporary system, and makes them faster and more responsive bB and vwBASIC abstract the hardware to present a screen buffer with x,y addressable pixels and sprites resembling normal system concepts. 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted August 12, 2015 Share Posted August 12, 2015 That is fascinating... A video display with no VRAM... Quote Link to comment Share on other sites More sharing options...
iesposta Posted August 13, 2015 Share Posted August 13, 2015 Did you mean 256 Byte stack? If not, where's the 256K coming from when the Harmony/Melody only has 8K? Oops. Yes 256 byte stack. Fixed. 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.