Jump to content
RevEng

7800basic beta, the release thread

Recommended Posts

12 hours ago, batari said:

What would happen if I made a 12-high zone, aside from wasted space? Does it mean the sprites won't work correctly if I tweak the DLL to 12 high zones?

At a minimum, any line in the top portion of the sprite that has an offset in the zone greater than 11 wouldn't appear. I'm pretty sure there would be some additional glitching on the bottom-portion of the sprite too, though I'd need to trace the code to describe the effect in any detail.

 

12 hours ago, batari said:

As for the 12-high pixels for the standard kernel, the only way I can see that could match things up is to use three 8-high 7800 characters stacked vertically for every two playfield pixels high. It shouldn't be that hard to do. A potential issue with this, though, is converting the 48 bytes of playfield data to 288 bytes of character data in 7800basic. It can be helped with a lot of lookup tables and unrolled loops, but still that is a lot of stores. It'll take thousands of cycles to convert that.

If you're willing to update them during the visible screen (there might be perceptible shearing if there are regular updates) you probably have the cycles to do it. With DMA running and a modest 160A screen with double-wide characters you'll have about 10000 6502 cycles leftover.

 

But as you point out, playfield: needs to be converted anyway. It would just be easier to directly use 7800basic alphadata+plotmap. Something like this...

playfield:
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

Could become something like this...

 alphachars '.X'
 alphadata screen1map tileset_blocks
 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
end

; you also need to "plotmap" this map somewhere onto the screen
; and include a PNG graphic called tileset_blocks.png in your code
; with graphics for the 2 characters.

 

Things like pfpixel and pfread would require updates to pokechar and peekchar. (pfpixel/pokechar would need a different setup for the playfield though, as you'd need RAM based characters)

 

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, Karl G said:

I had thought that the standard kernel had 16 scanline high blocks, not 12. The play area is 88 double scanlines high, so (88*2) / 11 playfield rows = 16

 

At any rate, doing 11 rows of characters with 16 scanline high zones for the playfield would leave one zone below that to do the score and the equivalent of pfscore bars for a total of 192 scanlines.

Yep, you are right! I thought it was 16, but I opened up a bB game last night and went through the scanlines in the Stella debugger. For some reason I counted 12 lines. Today, with the same game, it is clearly 16. I have no idea how that happened.

 

Anyway, 16 makes it a TON easier for sure.

Share this post


Link to post
Share on other sites
4 hours ago, RevEng said:

At a minimum, any line in the top portion of the sprite that has an offset in the zone greater than 11 wouldn't appear. I'm pretty sure there would be some additional glitching on the bottom-portion of the sprite too, though I'd need to trace the code to describe the effect in any detail.

 

If you're willing to update them during the visible screen (there might be perceptible shearing if there are regular updates) you probably have the cycles to do it. With DMA running and a modest 160A screen with double-wide characters you'll have about 10000 6502 cycles leftover.

 

But as you point out, playfield: needs to be converted anyway. It would just be easier to directly use 7800basic alphadata+plotmap. Something like this...

playfield:
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

Could become something like this...

 alphachars '.X'
 alphadata screen1map tileset_blocks
 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
end

; you also need to "plotmap" this map somewhere onto the screen
; and include a PNG graphic called tileset_blocks.png in your code
; with graphics for the 2 characters.

 

Things like pfpixel and pfread would require updates to pokechar and peekchar. (pfpixel/pokechar would need a different setup for the playfield though, as you'd need RAM based characters)

 

So just to clarify, is the font data in ROM or RAM, and are the characters (the X and .) in ROM or RAM?

Share this post


Link to post
Share on other sites

[edit - beat by Karl, but something odd seems to have happened to his post.]

 

The font graphic data is in ROM, imported into the correct place and format via the incgraphic command.

 

In the example I used, the character strings are in ROM. The RAM version of my example is nearly the same, except you dim a buffer "dim charbuffer=$2200" and use "memcpy screen1map charbuffer 288" (or whatever the size is) to populate it, and then plotmap the "charbuffer" ram buffer instead of the "screen1map" rom.

Share this post


Link to post
Share on other sites

I found a bB demo from the RT site that includes playfield pixel destruction, and converted it to 7800Basic. I didn't delete any of the old code, but I put comments with the tag "7800Basic" before any code I added or commented-out with a brief explanation for the change. The source zip contains the original bB example (ex_sprite_with_missile_and_pfpixel_destruction.bas) and the converted version for 7800Basic (bb7800.78b).

 

Obviously for such a trivial case, it would have probably been easier to rewrite it, but it may serve as a useful example of the dynamic RAM "playfield", and some of the other changes that are needed for a bB project.

 

Original bB example:

ex_sprite_with_missile_and_pfpixel_destruction_bas.thumb.png.eded34ba18750e3def266ef94ac1fc6a.png

 

Converted 7800 version:

1125830927_ScreenShot2021-04-09at10_30_09AM.thumb.png.96dd17f7a2f2ad388f34e82b99ba5619.png

 

ROMs:

ex_sprite_with_missile_and_pfpixel_destruction.bas.bin

bb7800.78b.a78

 

Source zip:

bb7800.zip

  • Like 2

Share this post


Link to post
Share on other sites

On the subject of porting from bB, and also because it would be useful on its own, how feasible would it to be to add a feature to 7800Basic that would allow a user function to be run each visible zone? I was thinking it would be handy for updating e.g. a palette color or the background color for each zone.

Share this post


Link to post
Share on other sites

Arbitrary user-interrupts (other than the current near-top, near-bottom, and offscreen ones) aren't planned in the near future. An NMI color change interrupt needs minimal overhead to be reliable - otherwise, adding more dma increases the chance of the color change not taking effect until the next scanline, to the point where the heaviest DMA limits can cause a miss in the most minimal color change code.

 

I may change this in the future if I take on an NMI handling rewrite, but honestly I have a few different pieces I'd like in place before I consider that, to avoid painting myself into a corner.

  • Like 2

Share this post


Link to post
Share on other sites
On 4/10/2021 at 8:20 PM, RevEng said:

Arbitrary user-interrupts (other than the current near-top, near-bottom, and offscreen ones) aren't planned in the near future. An NMI color change interrupt needs minimal overhead to be reliable - otherwise, adding more dma increases the chance of the color change not taking effect until the next scanline, to the point where the heaviest DMA limits can cause a miss in the most minimal color change code.

 

I may change this in the future if I take on an NMI handling rewrite, but honestly I have a few different pieces I'd like in place before I consider that, to avoid painting myself into a corner.

RevEng
Can you see any way to "draw" on the screen effectively with Maria by manipulating the bitmap drawing?  
Like how would one approach drawing the missiles in Missile Command? 

Share this post


Link to post
Share on other sites
3 hours ago, fultonbot said:

RevEng
Can you see any way to "draw" on the screen effectively with Maria by manipulating the bitmap drawing?  
Like how would one approach drawing the missiles in Missile Command? 

The quick answer to arbitrary bitmap drawing is to use RAM-backed sprites. Basically you have a series of sprites that cover the screen and point at different segments of RAM, and you have line drawing routines that update that RAM. There isn't an easy way to do this in 7800basic right now. @SmittyB's Plink game uses pretty much this technique for dynamic backgrounds, though it's not doing full-screen bitmaps. (they repeat vertically)

 

That said, I don't think Missile Command actually needs bitmap display, if you just limit the number of angles the missiles can come in at. (The 2600 version doesn't pull off arbitrary angles either, and the missile aspect of the game compares very well to the arcade). Given that approach, you can just draw the missile segments with sprites. (pulling this off quick enough would likely require the Under The Hood technique)

Share this post


Link to post
Share on other sites
24 minutes ago, RevEng said:

The quick answer to arbitrary bitmap drawing is to use RAM-backed sprites. Basically you have a series of sprites that cover the screen and point at different segments of RAM, and you have line drawing routines that update that RAM. There isn't an easy way to do this in 7800basic right now. @SmittyB's Plink game uses pretty much this technique for dynamic backgrounds, though it's not doing full-screen bitmaps. (they repeat vertically)

 

That said, I don't think Missile Command actually needs bitmap display, if you just limit the number of angles the missiles can come in at. (The 2600 version doesn't pull off arbitrary angles either, and the missile aspect of the game compares very well to the arcade). Given that approach, you can just draw the missile segments with sprites. (pulling this off quick enough would likely require pre-the Under The Hood technique)

I think I'll try the 2nd method for the fun of it.

 

  • Like 1

Share this post


Link to post
Share on other sites

The title screen in Plink does use a full-screen bitmap for the cyan, but even with the monochrome 320A mode the CPU time is a noticeable limiting factor to how much can be drawn in one frame.

There are plenty of optimisations that can be made over what I did in Plink, and I think somebody could make a version of Missile Command with this technique, but there would have to be some clever compromises somewhere to make it playable at any real speed.

There's a lot of potential in bitmapping, but I'd say it's best limited to things where frame rate isn't important.

  • Like 2

Share this post


Link to post
Share on other sites

Possibly a dumb question, but why do 48K games compile to produce a 32K bin file? In this particular case, if I change it to actually be a 32K game, it doesn't have enough space.

 

Edit: Nevermind. Wrong file.

Share this post


Link to post
Share on other sites

I checked Danger Zone which is a 48K ROM, both the A78 and BIN are 48K.

 

I think you might have found the Tardis compiler Karl :D 

  • Haha 2

Share this post


Link to post
Share on other sites
6 minutes ago, Muddyfunster said:

I checked Danger Zone which is a 48K ROM, both the A78 and BIN are 48K.

 

I think you might have found the Tardis compiler Karl :D 

Or I was looking at a different version of my game. Oops. Looks like my 48K game is actually 48K, after all.

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.

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