Jump to content
IGNORED

7800basic beta, the release thread


RevEng

Recommended Posts

Before I say anything else, I apologize in advance for being such a noob at this. It takes me a while to grasp these concepts. I'm noticing when compiling, some banks are being ignored- instead they're replaced with "Label Mismatch" errors. Is that because the bank has too much code (over 16k)? For me it has been a trial-and-error process of where to declare a bank within the code.

Link to comment
Share on other sites

This post might turn a few heads, but what benefits are there, (besides running programs on a real 7800) if I invest in a dev cart to work with 7800basic?

You might be able to get a POKEY one and then you can play a special version of Donkey Kong PK on your 7800.

Is this what you mean by "benefits"?

You can also load it as any one single game or demo at a time.

If you want to wait, a 7800 Harmony Concerto should play games and stored on an SD card.

Link to comment
Share on other sites

As a programming tool, the only benefit to using a dev cart with 7800basic is you get to ensure that your game works with real hardware, and displays as expected on a TV.

 

Most 7800 emulators aren't particularly faithful when it comes to hardware limitations. The latest MESS now emulates these limitations quite well, but its still a good idea to try your game out on the real deal.

Link to comment
Share on other sites

For me, it's the convenience of hitting F7 in VS, to assemble and sign the binary (not needed BTW, as my BIOS is signed) and then just clicking on "Re-Load" in the transfer program. Advanced features of the software allow for even more control, it will check which bytes in your ROM changed from last upload, then only upload relevant pages to the cart or you can specify which banks get uploaded manually. Why program something onto it, that is already there, right? :)

  • Like 1
Link to comment
Share on other sites

or, you could make one :)

In the theoretical sense of, yes, I could learn Assembly and figure out how to do everything from scratch, giving me the flexibility to implement the feature I've requested myself, or in the practical sense of not knowing Assembly or having a lot of time or inclination to learn lowest-level ASM, and thus being limited to what 7800basic can do out of box? Because if the latter, then I really can't make one.

 

For me, the fun comes from programming the game logic, not the low-level back-end memory architecture sort of stuff, which is why I use tools like 7800basic in the first place.

Edited by Cybearg
  • Like 1
Link to comment
Share on other sites

Has there been a chance for scrolling to be added to 7800basic?

You asked about fine scrolling last week, and I replied there were no updates. :) I'll definitely bump the thread whenever there's a feature update or news to share.

 

To set the timing expectation right, I've just changed houses and have other real life changes on the go. 7800basic will likely be in a holding pattern for at least a couple months while real life gets sorted. After that there are other features to work on before I get to scrolling.

 

Don't plan a project you want to complete soon around upcoming 7800basic features. Unapologetically, the timeline and implementation details of upcoming features is subject to change.

 

 

And would conditional scrolling be possible, so that one can have a GUI that doesn't get scrolled with the rest of the screen?

I have some ideas as to how I'm going to work that out in a general scrolling engine, but the devil is in the details. It should be doable for horizontal scrolling. Vertical scrolling is achieved by manipulating the actual zone locations on the screen, so "should be doable, with limitations" there. i.e. non-moving bits will need to be above or below the scrolling area.

 

 

I hear ya. Just saying there's no hardware support so I don't think RevEng is gonna add that feature. Don't hurt me :)

Eventually it will get added in. Its just a bit tricky, and will be impacted by other enhancements I try to shoehorn in, so its going in later.

  • Like 1
Link to comment
Share on other sites

You asked about fine scrolling last week, and I replied there were no updates. :) I'll definitely bump the thread whenever there's a feature update or news to share.

I think I was asking more in a general sense of curiosity. I didn't have anything specific in mind. Sorry for the bother.

 

Good luck with the move!

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

:) I noticed that was missing from the docs a little while ago, but haven't had a chance to update the docs.

 

Newblock tells 7800basic to stop using the current graphics block and skip to the next one.

 

You might use this as part of graphics arrangement to ensure that character graphics or sprite animation frames go into a common graphics block.

  • Like 1
Link to comment
Share on other sites

For a bankswitched binary, the plot* commands can only reference graphics in the same bank as your drawscreen command or the last bank. Also, if you bankswitch away from the bank with drawscreen, you need to do so only after the visible screen by calling "drawwait" first.

Link to comment
Share on other sites

Does 7800Basic need to be told to go to other banks via labels since it only starts in bank 1 and does not move to other banks unless it's told to?

 

For example:

 (dim codes, etc)

  <incgraphic image>
  <incgraphic image>
  <incgraphic image>
  drawwait

goto __set2 bank2

 bank 2

__set2



  
   newblock
  <incgraphic image>
  <incgraphic image>
  <incgraphic image>
  drawwait

  goto __set3 bank3


bank3

__set3
   newblock
  <incgraphic image>
  <incgraphic image>
  <incgraphic image>
  drawwait

 <game code>
<game code>
<game code>

goto __set4 bank4

 bank 4
__set4

<more game code>
 


Link to comment
Share on other sites

It doesn't go to another bank without being told, either by goto, gosub, or return.

Your example is missing a few different elements, like the object plotting and actual drawscreen command. It may be that you skipped them because it's an example, but I'm suspecting you're missing one of these fundamentals.

Borrowing your example, the skeleton for a bankswitched program would look more like...

 (dim codes, etc)

  <incgraphic imageb1>
  <incgraphic imageb1>
  <incgraphic imageb1>
mainloopb1
  clearscreeen
  plotsprite imageb1
  plotsprite imageb1
  plotmap imageb1
  drawscreen
  drawwait
  if playerlevel=2 then goto __set2 bank2
  [game logic]
  goto mainloopb1


 bank 2

__set2

  <incgraphic imageb2>
  <incgraphic imageb2>
  <incgraphic imageb2>
mainloopb2
  clearscreeen
  plotsprite imageb2
  plotsprite imageb2
  plotmap imageb2
  drawscreen
  drawwait
  if playerlevel=3 then goto __set3 bank3
  [game logic]
  goto mainloopb2

 bank 3

__set3

  <incgraphic imageb3>
  <incgraphic imageb3>
  <incgraphic imageb3>
mainloopb1
  clearscreeen
  plotsprite imageb3
  plotsprite imageb3
  plotmap imageb3
  drawscreen
  drawwait
  if playerlevel=4 then goto __set4 bank4
  [game logic]
  goto mainloopb3

[...]

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

Link to comment
Share on other sites

In the theoretical sense of, yes, I could learn Assembly and figure out how to do everything from scratch, giving me the flexibility to implement the feature I've requested myself, or in the practical sense of not knowing Assembly or having a lot of time or inclination to learn lowest-level ASM, and thus being limited to what 7800basic can do out of box? Because if the latter, then I really can't make one.

 

For me, the fun comes from programming the game logic, not the low-level back-end memory architecture sort of stuff, which is why I use tools like 7800basic in the first place.

Maybe one of the 7800 programming gurus can make an ASM sub routine that deals with scrolling and the you could import that into your 7800 basic program..since there is a way of importing assembly into 7800 basic.

 

It will of coarse have to be generic in that the programmer who wants to use it would have to pass values to the sub routine to work with.

Link to comment
Share on other sites

I remember when programming the psounds for Shatneroids, the only way I stopped a sound was when the player hit another enemy. Is there a way without using a large data statement to enable a sound for a second then turn off? For instance when an enemy hits the player:

 if boxcollision (xpos,ypos,16,16,blueleft_a_x,blueleft_a_y,8, then score1=score1-50:goto __psound_a


__psound_a

   psound 0,200,8,15:goto __skip_psound_a
   
__skip_psound_a

Just this code plays the sound even if there's no boxcollision. If I add another psound statement to quiet the sound, it just cancels it all out without even playing it.

Link to comment
Share on other sites

If you're wanting any register change to last for more than an instant but less than forever, you need to have a variable to do that.

 

e.g.

 dim pscount=z
 if boxcollision (xpos,ypos,16,16,blueleft_a_x,blueleft_a_y,8, then score1=score1-50:pscount=2:goto __psound_a

  goto __skip_psound_a
__psound_a
   psound 0,200,8,15:goto __skip_psound_a
__skip_psound_a
  if pscount>0 then pscount=pscount-1:if pscount=0 then psound 0,0,0,0
  [...]
  • Like 1
Link to comment
Share on other sites

A few questions:

 

1. When a tileset is imported with incgraphic, can the palette, or the ordering of the colors, be changed on the fly during the game's operation (for instance, to create palette swaps of the same sprite/character)? Is there any way to have a separate set of background palettes from sprite palettes, like the NES has, or is the 8 palette limit hardware-based?

 

2. Can the colors for a palette be changed on the fly during the game's operation (see above)? If so, are those changes reflected immediately during drawscreen, or does the screen have to be re-written to reflect the changes?

 

3. When using sdata, can the pointer be moved in the opposite direction in order to handle a scrolling screen that moves left or right? If not natively, then what about through manipulation of the sdata pointer? Or is that basically unnecessary with the plotmap command?

 

4. If I understand correctly, a screen zone is the zone height in pixels, either 8 pixels high or 16 pixels high, correct? So vertically aligning sprites to get a taller sprite should never really affect the number of sprites in a single zone, then. What about if a sprite overlaps the boundary of two zones?

 

5. Can the additional ram in a RAM romsize mode be used for sprites or tile definitions that are held in RAM, allowing them to be modified on the fly?

 

6. Although tiles in 160A/B modes are 4 pixels wide unless some options are set, what is the width of sprites in that and other modes?

 

7. Do RAM-based tile maps take up extra memory of the 1.5K available (or the banks of 16K if using a RAM romsize), or is that memory usage factored into the estimates of 126 variables + 1.5K memory?

 

8. How many cycles are actually available for development as compared to batariBasic? I know that the cycles of bB can run out very fast, and I assume that 7800 takes far more cycles as it's doing a lot more complicated stuff. Or is that extra work largely off-loaded to MARIA?

 

9. What is the purpose of using tsound instead of setting registers directly? Is there some advantage?

 

10. Will ROM sizes higher than 512 eventually be possible?

Edited by Cybearg
Link to comment
Share on other sites

1. Sure. You just change the palette # argument that you're using with the plotsprite command. You can also supply it a variable for the palette.

 

2. Yes, you can change the P#C# registers at any time, and the on-screen change happens pretty much immediately.

 

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.

 

4. The overlap will increase the number of sprites in the zone.

 

5. In theory, sure. You need to keep in mind how MARIA expects to see the sprite data formatted, with each line of data being spread out on separate pages.

 

6. Any multiple of 4, up to 128 pixels wide. (32*4)

 

7. RAM based maps can vary in size, or not be used at all in some games. I haven't preallocated storage for them. It's up to you to carve out the map out of your memory.

 

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.

 

9. No advantage. Its a familiar sound interface for those who grew up with one of the available Basics on the Atari 8-bit computers.

 

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.

Link to comment
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...