MAC-42 Posted December 6, 2014 Share Posted December 6, 2014 Just a small documentation issue I spotted. I wanted to fiddle around with switchreset and saw the following in the documentation: if switchreset True if Reset is pressed. See reboot if you would like to use switchreset to warm boot your game. Alas, there is no information in the docs on RT's site on reboot that I can find. I figured it out, but thought I'd mention it for completion's sake. 1 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted December 6, 2014 Share Posted December 6, 2014 (edited) 2. Yes, you can change the P#C# registers at any time, and the on-screen change happens pretty much immediately.Could this be used to simulate the NES's 8 palettes for sprites and 8 palettes for background by drawing the background characters with one set of 8 palettes, then saving the screen, changing the palettes, and drawing sprites after that? Or would the saved screen still reference the new palettes? Is the 8-palette limitation as limiting as it sounds like it would be? 3. Not really, though maybe with some assembly. Yes, you could use plotmap to do coarse scroll , though you'll need to use plotmap each frame, which is expensive cyclewise.Is this essentially how scrolling must be done on the 7800, or are there tricky, better ways through Assembly? If so, do those ways conflict with 7800basic in ways that make them less/not viable? 4. The overlap will increase the number of sprites in the zone.So if a sprite is overlapping, it counts as a sprite for both zones? 8. In theory, 33255.5 cycles per frame. In reality, MARIA puts the 6502 to sleep when it renders the line buffer, and the stolen time varies depending on the display complexity. Also, plotting things takes up a lot of cycles, so the more objects you plot, the more cycles you eat - it's the main reason the multisprite sample maxes out around 24 sprites.Wait... So the 7800 can only plot 24 sprites on-screen at a time? What's even the point of it having "greater sprite capabilities" than the NES if the NES can handle 64 sprites on-screen at once and the 7800 clocks out at just 24? Or are you referring to 24 sprites per zone if the zone sizes were 4? 10. If there's commonly available hardware to support it, in a supercart style format, I can easily add up to 4096k from the software side. I believe the amount of ROM easily supported by MegaCart is 512k, though I may be corrected on that shortly.Will this change with batari's 7800 board that he's been working on? Also: 11. How does one set the background color that is visible when background tiles have a palette color set to transparent? The existence of the background color is mentioned in the documentation (both RT's and the included 7800basic documentation), but I didn't notice any explanation of how it is set. Edited December 6, 2014 by Cybearg Quote Link to comment Share on other sites More sharing options...
CPUWIZ Posted December 6, 2014 Share Posted December 6, 2014 Will this change with batari's 7800 board that he's been working on? He is not working on a board for production, only a flash cart. The MegaCart can handle up to 1MB, Schmutzpuppe did a digitized demo that is that big. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 6, 2014 Author Share Posted December 6, 2014 Could this be used to simulate the NES's 8 palettes for sprites and 8 palettes for background by drawing the background characters with one set of 8 palettes, then saving the screen, changing the palettes, and drawing sprites after that? Or would the saved screen still reference the new palettes?The saved screen would reference the new palettes. Is the 8-palette limitation as limiting as it sounds like it would be?Not really to me. We're talking about 24 colors (8*3) per screen, and those colors can be changed on the fly. Is this essentially how scrolling must be done on the 7800, or are there tricky, better ways through Assembly? If so, do those ways conflict with 7800basic in ways that make them less/not viable?I've allowed for incorporating less expensive methods, but I still have to write the code. So if a sprite is overlapping, it counts as a sprite for both zones?Sure, but I allowed for that in my "24" estimate. Really it's a higher number, but I need to allow for the overlaps. Wait... So the 7800 can only plot 24 sprites on-screen at a time?No, 7800basic is only able to plot 24 *moving* sprites on-screen. The 7800 is capable of more, but my hands are tied with the most generic approach. (though I have some optimizations planned) Check out Robotron if you want to see more than 24 sprites moving on the 7800. Or Eric Ball's ball demo. What's even the point of it having "greater sprite capabilities" than the NES if the NES can handle 64 sprites on-screen......and only 8 sprites per line. But lets not turn this thread into another of "those" threads. Will this change with batari's 7800 board that he's been working on?He stated a while ago that it's too expensive to produce the 7800 equivalent of a melody board. 11. How does one set the background color that is visible when background tiles have a palette color set to transparent? The existence of the background color is mentioned in the documentation (both RT's and the included 7800basic documentation), but I didn't notice any explanation of how it is set.Seems it's another omission from the manual. I'll add it in. "BACKGRND=" 1 Quote Link to comment Share on other sites More sharing options...
+frankodragon Posted December 7, 2014 Share Posted December 7, 2014 When using plotchars in one bank and the incgraphic "alphabet_8_wide.png", if I have the .png file in the last bank, the plotchars are cryptic. If I put the .png file in bank 1, then all the graphics are screwed up. I do have the "characterset" command before each plotchars but so far nothing has fixed the cryptic letters. I must be missing something. Quote Link to comment Share on other sites More sharing options...
+frankodragon Posted December 7, 2014 Share Posted December 7, 2014 Never mind. I figured it out. It was the alphachars where I had too many "#" before the text. That's why it was cryptic. Quote Link to comment Share on other sites More sharing options...
MobiusAqua Posted December 8, 2014 Share Posted December 8, 2014 I have to admit, this is really cool, and I wanted to thank you for making this, RevEng. I was thinking about learning how to code for the 7800, as I had learned a bit of 6502 machine language from a few threads over on NintendoAge, but the DLs and DLL looked really confusing, at first. There are a few things I'm curious about, if you don't mind my asking: first, I noticed a few of your screenshots of files being compiled, that some of the earlier ones say the graphics block starts at $E000, while every single time I've tried to compile a program, it always says the graphics block starts at $F000. Is there a way to start the graphics block at a different address, or would I need to use bankswitching? And second, is it possible to make games use more than just the 192 pixels in the middle of the screen? I've heard you can use more, like up to 240 pixels, I think? If you know what I mean? Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 9, 2014 Author Share Posted December 9, 2014 Welcome! (and you're welcome.) I noticed a few of your screenshots of files being compiled, that some of the earlier ones say the graphics block starts at $E000, while every single time I've tried to compile a program, it always says the graphics block starts at $F000. Is there a way to start the graphics block at a different address, or would I need to use bankswitching? The graphics block positioning difference you're seeing is due to differing zoneheight being used - $F000 for zoneheight=8, and $E000 for zoneheight=16. There are some special positioning considerations for the graphics blocks (read about "Holey DMA" in the 7800 Software Guide if you care about the arcane details) Because of those positioning limitations, there's nothing to be gained by moving them around. Presently they start out near the end of the ROM, in front of the 7800basic routines. You can only move them forward in the RAM, which would cause them to clash with your BASIC code even sooner. And second, is it possible to make games use more than just the 192 pixels in the middle of the screen? I've heard you can use more, like up to 240 pixels, I think? If you know what I mean? Right now 7800basic games are limited to a vertical resolution of 192, which is what Atari figured was guaranteed to fit on the majority of TVs. There's no theoretical reason why we couldn't go higher, but each additional zone would cost more memory, and the potential loss of compatibility doesn't seem worth the trade-off. Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 9, 2014 Author Share Posted December 9, 2014 Right now 7800basic games are limited to a vertical resolution of 192, which is what Atari figured was guaranteed to fit on the majority of TVs. There's no theoretical reason why we couldn't go higher, but each additional zone would cost more memory, and the potential loss of compatibility doesn't seem worth the trade-off. Ok, Trebor pulled me aside and hit me with a pretty convincing argument for raising the limit to 224. (other consoles of the day using 224, and even some commercial 7800 titles) so I'll look at raising the vertical resolution to 224 for the next release. 5 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted December 10, 2014 Share Posted December 10, 2014 Will this result in a marked decrease in available CPU cycles, memory, etc.? Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 10, 2014 Author Share Posted December 10, 2014 It will result in some, but not marked amount. I'll look at making it a configurable setting. 1 Quote Link to comment Share on other sites More sharing options...
Synthpopalooza Posted December 12, 2014 Share Posted December 12, 2014 224 line res might be a good idea. It might make it easier for me to do my Sky Scraper game with the sprites that Pac-Man-Red designed for me! 2 Quote Link to comment Share on other sites More sharing options...
MobiusAqua Posted December 12, 2014 Share Posted December 12, 2014 I hope it won't make too much of a noticeable difference, but that'll be really cool. It'll be great for the game I'm working on, too. I was curious as to why my own game, Bentley Bear and T:ME Salvo looked letterboxed, yet Frenzy and Donkey Kong XM filled more of the screen. I almost thought there was some secret command. Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 14, 2014 Author Share Posted December 14, 2014 The lastest 7800basic release, beta 0.3 20141213, is now in the first post. Here's the changelog excerpt... fixed bug in 7800sign.c:456 - now uses memmove rather than memcpy. Target and source overlapped. fixed bug which could cause graphics areas in bankswitched roms to not start off cleared. (thanks to frankodragon's report) removed some harmless-but-extraneous *printf arguments. removed var=var+1:inc optimization because it interfered with CARRY. added "memset" command, which sets a block of ram to a particular value. added B&W effect to game pausing, with colorburst-kill. added support code for controller-based RESET (UDL) and SELECT (UDR). added incbanner and plotbanner commands, to import graphics taller than a zone's height. The B&W pausing effect can be seen via real hardware or via the SVN version of MESS. The change should reach the general MESS release later this month. Controller-based RESET and SELECT means that the CPUWIZ dualshock 2 adapter will be able to control select and reset for your 7800basic games without requiring a hardware mod. Hopefully future custom controllers and non-7800basic games will follow the WIZ standard. Other stuff previously discussed in the thread - scrolling, vertical resolution, etc. - is still in the TO DO queue. 4 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted December 14, 2014 Share Posted December 14, 2014 Awesome! Thanks for the update! Other stuff previously discussed in the thread - scrolling, vertical resolution, etc. - is still in the TO DO queue. Are you finding more time to work on things again? Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 14, 2014 Author Share Posted December 14, 2014 I stole a bit of time for this release, but I'm still in a real life crunch. Probably will be for a while. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 14, 2014 Share Posted December 14, 2014 It looks like I caught all of the new changes: randomterrain.com/7800basic.html If anyone finds any mistakes, please let me know. 5 Quote Link to comment Share on other sites More sharing options...
MAC-42 Posted December 14, 2014 Share Posted December 14, 2014 Thanks to both of you for the updates, RT and RevEng. Very much appreciated as always. It's really neat to be able to whip things up and actually see them coming alive, slowly but surely in my case, with such relative ease! (Life permitting, maybe there will be an extremely early version of something to show off for Hanukkah and Christmas. It really won't be that impressive and, of course, it will probably be late knowing my luck. Shouldn't go around making promises, should I? Oh well, I'm on the hook now!) 3 Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 14, 2014 Author Share Posted December 14, 2014 (Life permitting, maybe there will be an extremely early version of something to show off for Hanukkah and Christmas. It really won't be that impressive and, of course, it will probably be late knowing my luck. Shouldn't go around making promises, should I? Oh well, I'm on the hook now!) No pressure at all - I don't expect a lot from people's first efforts, and I completely get the "life permitting" bit - but I'm looking forward to seeing what you've done. 2 Quote Link to comment Share on other sites More sharing options...
Cybearg Posted December 14, 2014 Share Posted December 14, 2014 I don't expect a lot from people's first efforts... But those second efforts better be the most amazing thing ever put to ROM or else you will forever earn Rev's disdain and deep-seated personal disappointment. Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 15, 2014 Author Share Posted December 15, 2014 I guess we'll cross the second efforts bridge when we get past the first efforts. @all: Heads up that the latest version isn't happy with PNG graphics shorter than a zone height. Until the next release, pad out the PNGs so they're at least as tall as a zone. Quote Link to comment Share on other sites More sharing options...
MAC-42 Posted December 15, 2014 Share Posted December 15, 2014 No pressure at all - I don't expect a lot from people's first efforts, and I completely get the "life permitting" bit - but I'm looking forward to seeing what you've done. Actually, this is my third or fourth run at working with 7800basic. Nothing worth mentioning has come of those past efforts, but I've been able to recycle and recode stuff that has ranged from good sprites to really embarrassingly misunderstood stuff. I really have to thank you and everyone who has posted example code for others to look at; it has really helped me get my head back into coding. (I haven't properly programmed since I was a kid monkeying about in BASIC.) But yeah, I'm definitely wouldn't say that my latest effort is going to light the world on fire or that it will be that great. Better to say that it will be good *for me* to crank out something. Gotta start somewhere. 1 Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 15, 2014 Author Share Posted December 15, 2014 Honestly, if people are making stuff for our retro platform and having fun doing it, that's enough for me. 3 Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 20, 2014 Author Share Posted December 20, 2014 A mostly-bugfix 7800basic release, beta 0.3 20141220, is now in the first post. fixed width bug in 160B graphic import, where an extra byte was stored fixed bug where bannerplot would glitch with Y coordinates that weren't multiples of the zone height added XCTRL register hit to the pokey detection routine, to enable XM/Xboard pokey detection fixed bug where plotvalue's buffer had gaps between stored values incgraphic enhanced to allow import of png images shorter than a zone height 4 Quote Link to comment Share on other sites More sharing options...
MobiusAqua Posted December 25, 2014 Share Posted December 25, 2014 <snippity-doo-dah> Notice how the code in any single bank never tries to display an image from another bank? It can't, except for the images in the last bank. (which is always present in the memory map.) Pardon me if this sounds like a weird question, but when you say this, does that mean that, when you're working with ROMs that bankswitch, there's always two graphics blocks available -- the bank you're currently on, and the "last bank"? I figured that the code and graphics swap in and out of work RAM at the same time, rather than separately, but I wasn't sure if you had access to two graphics blocks at any one time, or just the active block. 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.