7800basic beta, the release thread

[RevEng]

1 hour ago, Karl G said:

I've been troubleshooting a weird bug in my code, and I think I finally figured out that it's a corner-case bug, or undocumented limitation. It seems that although plotchars can accept more chars than 32, breaking it up into two DLs, it doesn't seem to handle it correctly if the numbers of chars is given in a variable. In my case, I was trying to plot 36 characters, and that worked fine if I hard-coded the number 36, but when 36 was in a variable, it only plotted 4 characters (the remainder after 32 I suppose).

It's an undocumented limitation, at least for now. The present width>32 support is very much a compile-time feature, that adds extra code to only the affected plotchar statement.

 

When I have my hands in the code next I'll see what I can do about expanding it to runtime. I'll also look at some of the other recent feature requests too!

[+Karl G]

Another small (?) feature request: I would love to be able to mix numeric data with alphadata to be able to mark ends of strings or to be able to include characters not in the alphachars string in the case of a full ASCII characterset. I was thinking that maybe this used to work, but the checking for malformed alphadata content got stricter? Anyway, something like this:

 

    alphadata askname text_tileset
    'What is your name?'
    0
end

 

[RevEng]

There's a new v0.33 7800basic release at github. Changes include:

 

• feature: auto-dimensioning of variables added
• feature: alphadata statements can now also contain literal values
• feature: strcpy added for quick population of ram with text strings
• feature: PLOTSPRITE/PLOTSPRITE4 commands can now use variable arguments
• fix: compressed files didn't previously work in folders
• fix: brief hiscore screen glitch could occur
• fix: double snes2atari controlled by first port
• fix: data statement line length being exceeded didn't trigger line length error
• fix: sprite index could fail with very tall and wide tallsprites

 

If I've discussed a fix/change with you and you don't see it above, I haven't forgotten. I'm just a bit short of time these days, and wanted to get these features and fixes out first.

 

I also noticed that in a few weeks 7800basic will have been around for a decade. I guess I need to go eat some cake or something.

[+mksmith]

 

Thanks Mike for your ongoing support of your community tools especially our 7800basic 😁 Wow 10 years congrats and enjoy that cake!

[+Karl G]

26 minutes ago, RevEng said:

I also noticed that in a few weeks 7800basic will have been around for a decade. I guess I need to go eat some cake or something.

An impressive list of changes! And I appreciate you incorporating my suggestions - will be quite handy with the project I'm playing with at the moment.  🙂 

 

And wow ... ten years! So when is the actual day for the decade anniversary? Is it the anniversary of the first public release, or when you started the project?

[RevEng]

Thanks for that guys, and you're welcome Karl!

5 minutes ago, Karl G said:

And wow ... ten years! So when is the actual day for the decade anniversary? Is it the anniversary of the first public release, or when you started the project?

I'm going by the first public 0.1 beta release, which was February 28th, 2014. The first post in this thread was on that day (though it was updated a bit when 7800basic moved to github) I also have an old blog entry about it too. 

[Trebor]

Completely selfish, layman's request to see a 7800basic demo created by a developer or developers that celebrates the 10th Anniversary of 7800basic. 

 

Ideally, it could include a (scrolling/tickertape) list of all the titles - at least the publicly published games and perhaps even demos, that have been created with 7800basic.

[Shannon]

4 hours ago, RevEng said:

There's a new v0.33 7800basic release at github. Changes include:

 

• feature: auto-dimensioning of variables added
• feature: alphadata statements can now also contain literal values
• feature: strcpy added for quick population of ram with text strings
• feature: PLOTSPRITE/PLOTSPRITE4 commands can now use variable arguments
• fix: compressed files didn't previously work in folders
• fix: brief hiscore screen glitch could occur
• fix: double snes2atari controlled by first port
• fix: data statement line length being exceeded didn't trigger line length error
• fix: sprite index could fail with very tall and wide tallsprites

 

If I've discussed a fix/change with you and you don't see it above, I haven't forgotten. I'm just a bit short of time these days, wanted to get these features and fixes out first.

 

I also noticed that in a few weeks 7800basic will have been around for a decade. I guess I need to go eat some cake or something.

 

 

The cake is a lie!  Don't fall for it! 

 

[+Karl G]

The new strcpy is working well for me! One question though: is there any way to sneak in a single quote inside the string if I'm using "alphachars ASCII"? I'm guessing not, but also figured it couldn't hurt to ask.  🙂 

[RevEng]

18 minutes ago, Karl G said:

The new strcpy is working well for me! One question though: is there any way to sneak in a single quote inside the string if I'm using "alphachars ASCII"? I'm guessing not, but also figured it couldn't hurt to ask.  🙂 

Not presently. When I get a chance I'll look at adding an escape character... getting the preparser to go along with it may take some doing.

[+Random Terrain]

16 hours ago, mksmith said:

 

That's exactly how I eat cake. I make a group of people watch as I eat the whole cake by myself, starting from their side so they won't miss a thing. I also wash down the cake with tears that I extract from their eyes using a series of tubes.

 

 

HTML version of the 7800basic Guide has been updated:

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

 

If anyone notices any mistakes, please let me know.

[TwentySixHundred]

Hi Mike,  so i am getting this error when trying to add another large mother t-rex sprite.

 

segment: "GAME" 4000                    vs current org: 4111
   stack allowance: 22 nested subroutines.
   the canary is situated at: $1d2
   stack allowance: 22 nested subroutines.
   the canary is situated at: $1d2

banksetrom.asm (294): error: Origin Reverse-indexed.

 

I am guessing this is an overflow/space issue?

 

Edit: Think i answered my own question. After shuffling the sprite into another bank that has more space it compiles. Not leaving me with much left in all the banks so i am going to have to make a sacrifice somewhere as i have a few other smaller sprites to add 🤔

[The V-Man]

Is there currently a way to use plotsprite to grab a sprite from RAM @ $4000 to $7fff?  I know I can make a small change to the statements.c code function plotsprite and I've been able to compile it, but I have not been able to create a EXE from it to test it.  Just wondering if anyone else needed such a capability.

[RevEng]

9 hours ago, The V-Man said:

Is there currently a way to use plotsprite to grab a sprite from RAM @ $4000 to $7fff? 

Yes and no.

 

As you probably know by now, 7800basic's plotsprite depends on a bunch of dasm variables that incgraphic creates, which hold things like the address of the sprite graphic, graphic mode, sprite width, etc. The main impediment to plotting arbitrarily from a ram location is the lack of those defined variables.

 

Right now 7800basic supports generating those variables and pointing them to ram from a "set dumpgraphics" dumped assembly file. The main use case is using sprites with graphics that have been decompressed to ram. The same process could be used to generate variables for other use cases, like copying a sprite from rom to ram for live modification, but admittedly "set dumpgraphics" is a less than ideal workflow for this case, since you have bunch of extra steps to do every time you add a new ram sprite.

 

If you have something that fits another use case better (and doesn't break existing functionality) feel free to pass on the updated source code!

[TwentySixHundred]

3 hours ago, RevEng said:

The same process could be used to generate variables for other use cases, like copying a sprite from rom to ram for live modification

I have to admit this is one feature i wish existed, probably more to play around with, out of curiosity. However i do recall at some stage wanting the ability to copy sprites to RAM, then alter the values on the fly but cannot remember exactly why 🤔

[The V-Man]

@RevEng My thought was to do this:

 

rem ** display sprite from original position in ROM
plotsprite  bg_top 0 x y 0

rem ** copy and display from original ROM position to same position at $4000 in RAM
rem ** So $8600 would become $4600
memcpy $4000 $8000 12288
plotsprite  bg_top*0 0 x y 0

rem ** copy and display from original ROM position to same position in RAM at $4000 + offset*4096
rem ** So $8600 would become $5600 in this example
memcpy $5000 $8000 12288
plotsprite  bg_top*1 0 x y 0

 

So in statements.c i was going to see if I could add this code to accommodate the above example.

 

void plotsprite (char **statement, int fourbytesprite) // appx line number of 1416 in statements.c
{
	assertminimumargs (statement, "plotsprite", 4);

	// add following code
    int len = strlen(statement[2]);
    int ram = -1;
    if (statement[2][len-2] == '*')
    {
        if ((statement[3][len-1] >= '0') && (statement[3][len-1] <= '3'))
            ram = (statement[2][len-1] - 48) * 16;
        else
            ram = 0;
        statement[2][len-2] = 0; // make this the end of the string to continue normal operation of statement[2]
    }
    // end of added code  
  
    // appx line 1480 before adding the code above
    printf ("    lda #>%s\n", statement[2]);
    
    // add following code
    if (ram>=0)  // modify the hi-byte of the address before storing in temp2
    {
        printf ("    and #$3F ; convert hi-byte address @ 16k boundries from $8000+ or $c000+ to $4000+ \n"); 
        printf ("    ora #$40\n");
        if (ram > 0)
        {
            printf ("    clc\n");
            printf ("    adc #%d ; add # of 4k blocks to offset graphic position\n", ram);
        }
    }
    // end of added code
  
    printf ("    sta temp2\n\n");
    // etc....

 

Edited May 14 by The V-Man

[The V-Man]

@RevEngAnother thought could be to use '@' instead of '*' to make it easier to read.

 

rem ** use to access sprites beginning at $4000:
plotsprite  bg_top@4 0 x y 0

rem ** instead of my first idea of:
plotsprite  bg_top*0 0 x y 0



rem ** use to access sprites beginning at $5000:
plotsprite  bg_top@5 0 x y 0

rem ** instead of my first idea of:
plotsprite  bg_top*1 0 x y 0

 

Then the statements.c code could be this: 

 

void plotsprite (char **statement, int fourbytesprite) // appx line number of 1416 in statements.c
{
	assertminimumargs (statement, "plotsprite", 4);

	// add following code
    int len = strlen(statement[2]);
    int ram = 0;
    if (statement[2][len-2] == '@')
    {
        if ((statement[3][len-1] >= '4') && (statement[3][len-1] <= '7'))
            ram = (statement[2][len-1] - 48) * 16;
        else
            ram = 4 * 16;
        statement[2][len-2] = 0; // make this the end of the string to continue normal operation of statement[2]
    }
    // end of added code  
  
    // appx line 1480 before adding the code above
    printf ("    lda #>%s\n", statement[2]);
    
    // add following code
    if (ram>0)  // modify the hi-byte of the address before storing in temp2
    {
        printf ("    and #$3F ; convert hi-byte address @ 16k boundries from $8000+ or $c000+ to $4000+ \n"); 
        printf ("    clc\n");
        printf ("    adc #%d ; add # of 4k blocks to offset graphic position\n", ram);
    }
    // end of added code
  
    printf ("    sta temp2\n\n");
    // etc....

 

Totally your call if you like the ideas.

Edited May 15 by The V-Man

[Jess Ragan]

On 11/1/2023 at 3:23 PM, Gemintronic said:

 

Now all we need is RevEng Paint!  You lose a life each time you try and place a note the TIA can't handle.  Very challenging!

So a video game version of this?

 

 

[RevEng]

37 minutes ago, The V-Man said:

@RevEngAnother thought could be to use '@' instead of '*' to make it easier to read.

[...]

Totally your call if you like the ideas.

Yep, I like this iteration of the idea. Great job!

 

I'll get it in as part of the next release, which shouldn't be too long.

[+mksmith]

This sounds great!  I played a while ago with packing images (with dumpgraphics) & then unpacking them into ram.  I built a custom trimmed macro (based on the 7800basic code) to plot sprites from a provided ram pointer (in this case all images are a fixed size so I could cheat a little knowing it was all the same). Mike you plotted sprites from ram in PETSCII yeah?

 

As we've seen with modern c64 games, compressed data is also a great process for the 7800 and with most of the features built-in to 7800basic now (thanks Mike!) it would be rude not to use it!  I have nearly finished rebuilding RobotsRumble which uses un-compressing for tiled maps (that is a little tricky as you need the underlying display code) and tileset gfx but once you get a feel for the process it works great. 

[RevEng]

13 minutes ago, mksmith said:

Mike you plotted sprites from ram in PETSCII yeah?

Yeah, though it was very much under the hood at that time, as it was prior to the graphics dumping additions.

 

PETSCII was pretty much the rough prototype for dumpgraphics, RMT, four byte sprites, and SNES2ATARI. Probably more that I'm forgetting.

[SlidellMan]

Mike, it has been a while since I checked on 7800Basic, and I have to say that it has gotten better since last year.

[TwentySixHundred]

So a quick question about 7800basic that i don't think warrants a new thread topic. I am wondering if it's possible to use the 7800's stack? Much the same as when using it with DPC+ in bB, or is that because the DPC+ makes this possible?

 

I know it's not necessary like under the constraints of bB's limited RAM, so it's more out of curiosity 😁

[RevEng]

Yeah, the 6502 stack is already in use - the user variables var0 to var99 use stack memory, and 7800basic grabs some of it too for variables. The rest is used for typical stack functionality, like saving the return address when you do a gosub.

 

The bB DPC+ stack is actually the ARM processor's stack, not the 6502 stack. That's why it's a bit more cumbersome to use, compared to regular ram.

[TwentySixHundred]

Thanks for the rundown Mike, makes sense now. Earlier i was watching some 6502 videos and curious as to how we could use the stack in bB. Explains why it's only possible with DPC+ 😊👍