Jump to content
IGNORED

7800basic beta, the release thread


RevEng

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?

Link to comment
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

 

Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

  • 2 months later...

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?

 

Link to comment
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

 

  • Like 1
  • Thanks 1
Link to comment
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

 

Link to comment
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.

Link to comment
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
Link to comment
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
Link to comment
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 4
Link to comment
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
Link to comment
Share on other sites

  • 4 weeks later...

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?

Link to comment
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...