Jump to content
RevEng

7800basic beta, the release thread

Recommended Posts

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. :)

  • Like 1

Share this post


Link to post
Share on other sites

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 by Cybearg

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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="
  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 5

Share this post


Link to post
Share on other sites

It will result in some, but not marked amount. I'll look at making it a configurable setting.

  • Like 1

Share this post


Link to post
Share on other sites

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. :-D

Share this post


Link to post
Share on other sites

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.

  • Like 4

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

I stole a bit of time for this release, but I'm still in a real life crunch. Probably will be for a while.

Share this post


Link to post
Share on other sites

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. :lol: Shouldn't go around making promises, should I? Oh well, I'm on the hook now!)

  • Like 3

Share this post


Link to post
Share on other sites

(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. :lol: 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. :)

  • Like 2

Share this post


Link to post
Share on other sites

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. :ponder:

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

Honestly, if people are making stuff for our retro platform and having fun doing it, that's enough for me. :thumbsup:

  • Like 3

Share this post


Link to post
Share on other sites

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
  • Like 4

Share this post


Link to post
Share on other sites

<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.

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...