7800basic beta, the release thread

[+darryl1970]

On 11/21/2020 at 7:03 PM, TwentySixHundred said:

Awesome update Mike!

 

Many great new features, however im really excited about variables for width and height parameters.

 

Going to have some fun playing around with this ?

I agree! I am excited about the new high score features. Part of the "thrill" for me is watching the high score increment with my score (or my friend's). "hiscoreload" has made that possible.

 

I like that the high score functionality is present in the absence of a high score cart. Even if the scores aren't saved after power-down, entering initials adds to the arcade experience.

 

[+Karl G]

I needed an ascii font that was 16 pixels tall instead of 8, so I converted one from PDCurses. The font is in the public domain, so I thought I'd share it here, too, in case anyone needs the same.

 

 

Edit: I'm not sure how to make this a download link instead of a thumbnail.

 

[RevEng]

2 hours ago, Karl G said:

I needed an ascii font that was 16 pixels tall instead of 8, so I converted one from PDCurses. The font is in the public domain, so I thought I'd share it here, too, in case anyone needs the same.

That turned out pretty well! If you're cool with it, I'll include it in the 7800basic sample graphics.

 

There are some minor issues with chroma artifacting and the lowercase m and w letters, and maybe the ends of the uppercase K...

 

 

...the colors are more muted in photo than in real life. This 320 mode artifacting with be seen with composite/rf output, and won't be present with emulation or s-video output mods.

 

Normally you can diminish artifacting by doubling up pixels, which may work for the K ends. That's not possible for the m and w, so I think you might want to minimize the length of the middle line. Presently the w has a shorter line than the m, and as a result w is less distracting.

 

All of this is fine tuning suggestion, and I'm not taking away from your great job here. ?

 

Here's a quick little "font check" program I threw together, which I think is handy to check for any potential issues when designing fonts.

 

fontcheck.bas fontcheck.bas.a78 fontcheck.bas.bin

[+Karl G]

By all means feel free to include it along with any tweaks that you wish to make to it. I figured there might be others who would find 16 height ASCII font handy.

 

[+Karl G]

Since it's possible others will get confused by this too, I thought I'd share a quick word to the wise: if you are returning from a gosub back to a fixed bank, then "return otherbank" will cause a crash. You need to use "return thisbank" or just "return" instead. 

[+Karl G]

So, I have a possibly frivolous feature request, but I'll make it anyway just in case. ?

 

I would personally find it quite handy to have a command that allowed for a single line of ASM code without having to use an ASM block. I like the idea for ease of use and to make the code look neater. I think it would be most useful for executing macros, but probably could be useful for a number of cases. E.g.:

 

    asmline SET_POINTER MyPointer, my_data

 

[RevEng]

It's not a bad idea, with the benefit that one could use it in an if...then, but there might have some issues with dasm syntax within the preparser. (an asm+end clause overrides the usual basic preparser) I'll have a look next time I'm in the source, to see how cleanly it might work.

[ZippyRedPlumber]

I want to implement the jump/flap mechanics from the Joust source code for my platformer, how can I achieve this? @RevEng

[RevEng]

I don't have a pat answer here... analyse the joust source code and see what it does, and copy what that code is doing into your code, is the short answer. The longer answer is for me to do it for you, which isn't what you asked. I don't see any helpful answer between those two.

 

I'd personally just implement the same gravity+flap idea without trying to copy it, as there's nothing particularly special about it. Assuming you want to do a physics sim, you need to have fixed point variables for the object's x and y position and velocity. Each frame the object's velocity variable, whatever the value is, gets added to it's position. If you want to implement gravity, then you add some constant value to the y velocity variable. If you want to implement a flap, then you subtract some larger value from the y velocity variable, whenever the fire button is pressed.

 

There's a bit more code you'll want to likely add, because you'll probably want to nullify or negate the velocity values depending on certain object state. (e.g when the object is standing on a platform, or if you want the object to bounce) but those are the basics.

 

The spacephysics sample program may give you some ideas about how to deal with velocity and position in this kind of sim, though it's not directly applicable to your gravity+flap request.

[+darryl1970]

I was reading the concept of setting the .a78 header to trigger YM sound in Pac-Man 40th. It got me thinking. Are there settings in 7800 Basic to set the headers?

 

I am assuming that setting pokeysound to on sets the Pokey header. Is that correct?

 

Is there a setting that will change the name of the game from "My Game", so I do not have to manually do that?

 

Is there Yamaha functionality at this time, or is that something that would just require additional asm files?

 

-- Darryl

[RevEng]

 

3 hours ago, darryl1970 said:

Are there settings in 7800 Basic to set the headers?

 

I am assuming that setting pokeysound to on sets the Pokey header. Is that correct?

Yes. Like the pokeysound example, there are other statements that affect the header, like "set romsize".

 

3 hours ago, darryl1970 said:

Is there a setting that will change the name of the game from "My Game", so I do not have to manually do that?

Dragonfly is literally the first platform to use this feature of the header, so the majority of assembly games didn't bother. Taking that queue, I didn't put dev time into it, though I may add this in some future release now that Dragonfly is using it.

 

That said, 7800basic includes a program called "7800header". If you run this with an a78 filename (or bin filename) as an argument, it will give you an easy-to-drive menu that allows you to modify/add a header with whatever support you like, including the embedded name.

 

3 hours ago, darryl1970 said:

Is there Yamaha functionality at this time, or is that something that would just require additional asm files?

I released tracker tools, namely dmf2asm and xmym tracker. The dmf2asm package includes YM2151 examples for both 7800basic and assembly. So one can add YM2151 music relatively easily to basic and asm games. (you need to learn how to steer the Deflemask tracker, of course, which has it's own learning curve)

 

Given a limited YM2151 audience, I'm not planning on spending dev time on additional YM2151 features. The current level of support was a big lift.

 

[RevEng]

7800basic v0.17 is now available at the github releases page.

 

Here's what's new since the v0.16 release...

• support for including and using hiscore.asm in a temporary bank
• increased maximum number of 8.8 variables to 500.
• added the "sizeof" statement, which shows the size of a 7800basic routine or data structure at compile time
• default background color set to black
• added "drawhiscores player2joy1" to be used when your 2 player mode shares the joy1 stick.
• hi-score game name or difficulty strings can now display the ' character, by using " in the string
• added "hiscoreclear" so a game can clear out it's hi-score entry.
• added a basic hi-score example to the sample directory

Enjoy!

[+mksmith]

Very nice thanks Mike!

[+Random Terrain]

Next time you do an update, should this:

 

Quote

It should be mentioned that in the 7800 architecture, to accomplish plotting a banner “N” zones tall, 7800basic actually plots “N” sprites. This should be taken into consideration for games that are already be pushing the sprite limites.

 

be changed to this?

 

Quote

It should be mentioned that in the 7800 architecture, to accomplish plotting a banner “N” zones tall, 7800basic actually plots “N” sprites. This should be taken into consideration for games that are already pushing the sprite limits.

 

HTML version updated:

 

https://www.randomterrain.com/7800basic.html

[RevEng]

Yup. Thanks! 

[+Muddyfunster]

Not sure if I found a bug or I have a problem with my code.

 

I was trying to do a box collision between the ship and an element, the element being 32px wide 16px deep.

if boxcollision(ship_x_hi,ship_y_hi,14,13,mytempx,mytempy,32,16) then do stuff

This wouldn't work, it seemed to ignore the first 16 pixels of the target check.  I had to split it into 2x 16x16 checks instead.

 

 if boxcollision(ship_x_hi,ship_y_hi,14,13,mytempx,mytempy,16,16) then do stuff
   mytempx=mytempx +16
 if boxcollision(ship_x_hi,ship_y_hi,14,13,mytempx,mytempy,16,16) then do stuff

This worked as intended.

[+Karl G]

15 minutes ago, Muddyfunster said:

Not sure if I found a bug or I have a problem with my code.

 

I was trying to do a box collision between the ship and an element, the element being 32px wide 16px deep.

Probably a matter of the width being too wide, since the boxcollision doc says, "Boxcollision may fail if your width values [are] much larger than typical sprite widths, due to 6502 math overflow."

[RevEng]

The boxcollision sample uses pretty much the same dimensions, without issues. Was one of the objects positioned partially off-screen?

[+Muddyfunster]

11 minutes ago, RevEng said:

The boxcollision sample uses pretty much the same dimensions, without issues. Was one of the objects positioned partially off-screen?

Nothing was offscreen and that's what confused me, the box_collision sample was 32,16 also and I have a slightly smaller other sprite at 14,13. If part was offscreen I could understand it getting a bit upset.

 

I thought my positioning variables were off, so I hardcoded the actual values in to test it in the engine, same result, no collision on the first 16 pixels from the left.  Once I split the collision check into 2 checks, it's fine.

 

Further investigation :

 

Here's the funny thing. The issue with 32pixel wide collision box only occurs on the first sprite of that type. If I add 3 in a line starting at 0 so they are positioned 0,32,64 then only the first 16 pixels of first sprite are ignored, rest are fine. I can consistently reproduce it. There must be something influencing the check or one of the variables elsewhere.

 

My code chunk in full.

 if lava=false then goto skip_lava_col_w2
 for var69 = 1 to max_lava_chunks
 mytempx = lava_x[var69] 
 mytempy = lava_y[var69]
  if boxcollision(ship_x_hi,ship_y_hi,14,13,mytempx,mytempy,32,16) then player_explode = true
 next
skip_lava_col_w2

I'll investigate some more to make sure nothing is contaminating the positioning vars or anything.

 

 

[RevEng]

7800basic v0.18 is now available at the github releases page.

 

Whats new, compared to v0.17:

• User interrupts and DMA enable were made a little kinder and gentler. Interrupts now won't trigger until you've completed a drawscreen or page flip.
• New options added to the 7800header menu.

The main purpose of this release is to make it impossible to create boot-time race-conditions between your main code and the interrupt. If you don't know what that means and you use interrupts, you should probably update.

 

[+Random Terrain]

I don't see a PDF. Does that mean there are no changes to the text?

[RevEng]

Late night work, and it looks like I forgot to actually attach the binaries to the release. Just as well, as I was able to fix a small bug, which caused an issue when you didn't use interrupts.

 

@Random Terrain the binaries at the github release page now are in place, and have the pdf in them. There was one small update to the user-interrupt section.

[+Karl G]

So, possibly a dumb question, but - am I assuming correctly that screen elements that get restored via a restored screen are drawn before those done in code, so therefore would appear below the latter if they overlap? So, e.g. characters on the screen saved and restored would appear below sprites drawn via plotsprite. My question is, is there any good way of drawing something under restored tiles instead so that the tiles would cover the drawn sprite?

[RevEng]

Yeah, not really a good clean way to do that. The plot* commands build the underlying display lists that Maria parses, and it does them in object order.

 

You could kind of get away with what you're talking about by plotting 2 off-screen hidden sprites in every zone wherever you need them, and then manually replace them with something like "under the hood", but it's kind of ugly.

 

If it's for minor z-masking, you can try plotting another copy of the underneath-object over top of the sprite you want to block. I tried this out a while back, with success. It's a bit complicated too, but less under-the-hood.

 

occlude.bas.bin occlude.bas.a78 occlude.bas

 

[+Random Terrain]

On 3/14/2021 at 2:43 PM, RevEng said:

There was one small update to the user-interrupt section.

 

Added:

 

https://www.randomterrain.com/7800basic.html#set_crashdump