7800basic beta, the release thread

[+Karl G]

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?

[RevEng]

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.  

[+Karl G]

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.  

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

 

    if !ShipEatenBit5{5} then playsfx sfx_thrust

 

[RevEng]

Thanks!

[beoran]

I think it would be easier if 78000basic would accept any indexed png, not just 4bits per pixel ones. I like to use an editor that doesn't support 4 bits per pixel, and if I understand the source code of the compiler correctly, it converts the png to 8 bits per pixel anyway before processing.

 

https://github.com/7800-devtools/7800basic/issues/8

[RevEng]

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.

[+Karl G]

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.

[+Random Terrain]

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?

 

[RevEng]

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.

[+Karl G]

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.

[RevEng]

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

 

[+Karl G]

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.

[RevEng]

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

[+Karl G]

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

 

[RevEng]

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.

[+Karl G]

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.

 

 

[RevEng]

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.

[+Karl G]

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.

[RevEng]

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.

[+Karl G]

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.

[+littaum]

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.

[+Karl G]

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. 

[+mksmith]

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 😁

[+Muddyfunster]

11 minutes ago, mksmith said:

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

I'm not beta testing that...  

[+Karl G]

So, I know this is a bit beyond the scope of what 7800BASIC was intended for, but I'm looking for some coding advice related to how I am using 7800BASIC. 

 

As I mentioned before, I'm working on an interactive BASIC interpreter. To implement a break, I check for the break condition from a routine called from the top and bottom screen routines. If a break condition is detected (e.g. reset key), I perform the break by outputting a break message, doing some cleanup, and finally resetting the stack to $FF and jumping back to Main.

 

Anyway, my break method works fine, and I haven't detected any issues. It occurs to be though that it means that I never return from the top or bottom screen routines if a break occurs, and so there's never any rti. Since I'm dumping the stack, does this not matter, or do I need to rethink my approach?