Jump to content
RevEng

7800basic beta, the release thread

Recommended Posts

47 minutes ago, RevEng said:

Looking at this, it appears that a multi-line statement with end doesn't play nice when it's part of an if...then. It trips up the preprocessor, which prematurely ends the program.

 

I think this one is just going to be a documented limitation for now. Multi-line statements in a single-line if...then is going to be clumsy anyway, from a syntax perspective. Maybe at some point I'll take a whack at adding a blockif statement.

Are you referring to my issue? I couldn't find a case of me using a multi-line statement as part of an if...then. Do you mean the playsfx command?

Share this post


Link to post
Share on other sites

Oops. I misunderstood the initial report, and took it as sfx data in the if...then. Since the list output was interrupted, I didn't get clued in.

 

Thanks for clarifying. Back to the drawing board. :D 

  • Like 1

Share this post


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

Oops. I misunderstood the initial report, and took it as sfx data in the if...then. Since the list output was interrupted, I didn't get clued in.

 

Thanks for clarifying. Back to the drawing board. :D 

Gotcha. In the source I sent you, the offending line is this one:

 

    if !ShipEatenBit5{5} then playsfx sfx_thrust

 

Share this post


Link to post
Share on other sites

Thanks for the contribution - It's been merged into master. There's a few other issues I'm working on, after which I'll put out a binary release.

  • Like 3

Share this post


Link to post
Share on other sites
Just now, RevEng said:

Thanks for the contribution - It's been merged into master. There's a few other issues I'm working on, after which I'll put out a binary release.

That's great to hear! It will also help when using ImageMagick to batch convert images.

  • Like 2

Share this post


Link to post
Share on other sites

I got a question in an e-mail:

 

Quote

I am having some issues with trying to develop a game with a trackball option. When set to trackball mode and plugged into the system, moving the trackball causes the game to reset and start again, or do the same with pause. I thought it was restricted to v0.18, but it also happens to programs compiled on other versions. It is the CX-22 Trackball it supports?

 

Share this post


Link to post
Share on other sites

Asked and answered at the 7800basic github. @peteym5 needs to actually use the trackball anywhere his code, and the issue will go away. The trackball generates illegal joystick directions, which interferes with the soft-pause/reset functionality. Using the trackball will disable the soft-pause/reset.

  • Like 1

Share this post


Link to post
Share on other sites

What is the "proper" way to call an assembly routine from BASIC? It looks like when I do a goto/gosub, it prepends "0." to the name of the symbol.

Share this post


Link to post
Share on other sites

It prepends a dot... not sure why dasm reports "0." in the output though.

 

7800basic and bB do this to any goto/gosub destination so that "line numbers" will be valid labels. (dasm doesn't accept symbols that begin with digits)

 

What I do is just give the assembly routine a dot-prepended label, so 7800basic will be happy to go there directly. Actually, usually I just give it two names, so I don't have to bother typing the dot if I go there from assembly too... 

 

  gosub myasmroutine
  rem [stuff]
  
 asm
.myasmroutine
myasmroutine
  ; [stuff]
  rts
end

 

  • Thanks 1

Share this post


Link to post
Share on other sites

Does setting a paddlerange only consume CPU time when a port is configured to use the paddle controller? Just making sure in the case where paddle controllers are an option, but not required.

Share this post


Link to post
Share on other sites

Yep, it only uses the CPU time when a paddle is the active control.

  • Thanks 1

Share this post


Link to post
Share on other sites

Speaking of paddles, I was having an issue in my current project where paddleposition0 would contain cycling values once I moved the paddle to a position above the maximum value that could be read. I only had the issue in my current project, and I wasn't able to recreate it in a smaller example. I don't know what is "special" about my project to trigger it, but I did figure out how to fix it, at least.

 

In std_routines.asm, I modified the code to call the SETTIM64T routine before writing to VBLANK to charge the caps instead of after as it had before. I have only tested the fix on a7800 thus far:

 

paddleport0update
 ifconst PADDLE0SUPPORT
  lda #0 ; use PADDLE timing
  jsr SETTIM64T ; INTIM is in Y
  lda #6
  sta VBLANK ; start charging the paddle caps

 

Share this post


Link to post
Share on other sites

There's a bit of jitter inherent in paddle controllers, since they work in a polling loop that competes for 6502 time with Maria's DMA. I do some position smoothing, which works wonders, but if you have heavy/irregular DMA in a particular zone you may still get jitter at certain positions.

 

I think in your case the heavy/irregular zone in question happened to line up with the paddle position near the extreme, and rearranging the timer setting location basically moved the jitter spot to somewhere less noticeable.

Share this post


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

There's a bit of jitter inherent in paddle controllers, since they work in a polling loop that competes for 6502 time with Maria's DMA. I do some position smoothing, which works wonders, but if you have heavy/irregular DMA in a particular zone you may still get jitter at certain positions.

 

I think in your case the heavy/irregular zone in question happened to line up with the paddle position near the extreme, and rearranging the timer setting location basically moved the jitter spot to somewhere less noticeable.

It doesn't look like a case of jitter to me, at least. Here's a video taken from a7800 that shows the cycling that I tried to describe. I also print the hex value of paddleposition0 right above the bottom line for reference. Moving in the range from 0 up to my paddle range (220) worked flawlessly, but nudging it one step above that caused the cycling shown in the video until it is moved back within the set range. I also observed the problem on real hardware previously, but I don't have a video of that.

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Ah, I see. 220 is a lot, and certainly beyond what I tested. I'm thinking that your paddle scan is getting interrupted by the NMI at the bottom of the screen. Maybe.

Share this post


Link to post
Share on other sites

It also happens in the same way if I set it to 110, though. Like I said, though, I can only reproduce the problem with this specific app, so if my "fix" isn't of general interest, then that's fine, too.

Share this post


Link to post
Share on other sites

Well, the fix has the issue that under some circumstances (dma heavy near the top of the screen) the 0 value will be unattainable. I'm also not sure it's a general problem, instead of some unexpected interaction.

Share this post


Link to post
Share on other sites

Yeah; well I suppose it's here for reference in case anyone else encounters the issue, and otherwise probably not worth digging into too deeply in the meantime until then.

  • Thanks 1

Share this post


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

Yeah; well I suppose it's here for reference in case anyone else encounters the issue, and otherwise probably not worth digging into too deeply in the meantime until then.

You never know when someone developing a game in the year 2035 will run into the same problem and encounter this thread to get an idea of what is going on.

  • Like 1

Share this post


Link to post
Share on other sites
13 minutes ago, littaum said:

You never know when someone developing a game in the year 2035 will run into the same problem and encounter this thread to get an idea of what is going on.

In the year 2035, 7800BASIC will do infinite loops in 5 seconds, and will be able to make games by itself. 

  • Haha 3

Share this post


Link to post
Share on other sites
On 11/26/2021 at 3:02 AM, Karl G said:

In the year 2035, 7800BASIC will do infinite loops in 5 seconds, and will be able to make games by itself. 

I'm looking forward to hooking on the helmet @RevEng and have it dump straight out into code 😁

Climate Change Earth GIF by GIPHY Studios Originals

  • Haha 3

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