7800basic beta, the release thread

[RevEng]

As far as 7800basic goes, that approach should be fine. There's the possibility that interrupts may happen, so you just need to make sure your top/bottom routines don't do anything that would stomp on your break handling routine.

[Mord]

On 11/29/2021 at 7:49 PM, mksmith said:

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

 

On 11/29/2021 at 7:57 PM, Muddyfunster said:

I'm not beta testing that...  

 

Same. My power bill is high enough as it is.

 

 

[RevEng]

Ok, I dropped a new 7800basic release at github. Changes include...

 

• includes support for png files with more than expected colors. (thanks beoran!)
• bug fix for "loadrombank"
• bug fix for playsfx. (this one is pretty hard to trigger, which is why it's gone unnoticed)
• data for sound effects can now change their frame-rate mid-sound.
• updates to the 160b index-import order. (if you have a legacy project that uses 160B, you may wish to hang on to the old 7800basic, in case the new one forces you to reorder the 160B indexes)

[+Karl G]

7 hours ago, RevEng said:

data for sound effects can now change their frame-rate mid-sound.

That one is likely to be very handy.

[RevEng]

1 hour ago, Karl G said:

That one is likely to be very handy.

Yeah agreed. Actually, it's already come in handy. Necessity is the mother of invention.  

 

There's two cases for this that I see. The regular one, where you have part of the sound naturally changing more quickly in some parts than others. An alternative case, is where use it for a long delay before the sound. (or in the middle)

[+Random Terrain]

17 hours ago, RevEng said:

data for sound effects can now change their frame-rate mid-sound.

 

Should there be a new example box below this new paragraph showing how it's done?

 

Quote

If you want to change the frames-per-chunk mid-sound, you can do so by adding in a chunk with values $00, $20, followed by a value for the new frames-per-chunk.

 

[RevEng]

Yeah, probably. It looks like I goofed in that doc anyway - in the docs it should have listed $10 for that middle value, not $20.  Serves me right for putting together a release in the wee hours. 

 

I've updated the github releases with an updated doc, that has the correction and an example.

 

 

[+Random Terrain]

32 minutes ago, RevEng said:

Yeah, probably. It looks like I goofed in that doc anyway - in the docs it should have listed $10 for that middle value, not $20.  Serves me right for putting together a release in the wee hours. 

 

I've updated the github releases with an updated doc, that has the correction and an example.

 

 

 

Thanks. Updated:

 

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

[+Random Terrain]

On 11/14/2021 at 1:10 PM, Random Terrain said:

I got a question in an e-mail:

 

 

 

On 11/14/2021 at 1:45 PM, RevEng said:

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.

 

In case it's helpful, I got this related e-mail today:

 

Quote

Hello. I believe I may have found a solution for the Paddle Controller read issue. In "STD_ROUTINES" and after paddle0update, If INPT0 or INPT1 is triggering the negative flag (>127) it branches to  skippaddle0setposition. If not, program then does a STY paddleposition0 or STY paddleposition1. A few lines after skippaddle0setposition, there is LDA  paddleposition0, and Subtracts "#TIMEOFFSET."  If the INPT0 or INPT1 trips the negative flag, it will continuously subtract "#TIMEOFFSET" from the stored paddleposition0 or  paddleposition1. My solution was to change it to something that looks like this: 

paddleport0updateloop
  lda INPT0
  bmi skippaddle0setposition
  tya
  sec
  sbc #TIMEOFFSET
  sta paddleposition0
skippaddle0setposition  
  :
  :
  ldy INTIM
  cpy #TIMEOFFSET
  bcs paddleport0updateloop
     lda #%10000110
     sta VBLANK 

Quote

I removed the second sec SBC #TIMEOFFSET. I figure It is better for me to share this with you. 

 

 

[RevEng]

Good submission!

 

There's a problem with the solution as presented. The additional work inside the loop allows one paddle to make the resolution for the other paddle coarser, since the loop takes significantly longer when one of the the paddle position is being operated on. I'll need to find a solution without that issue, but highlighting the problem is helpful.

[+Karl G]

It's probably a longshot, but I thought I'd ask if anyone has made a 16 width by 8 tall font for use with 320 modes? I've stretched the atascii font for that purpose, but I just thought I'd ask in case someone has made something that makes use of the higher resolution.

[goldPseudo]

I was trying to debug a friend's code and found what appears to be a bug in the compiler when dealing with fixed point values.

 

In particular, if you try adding a whole number (no decimal) to a fixed point value, the assembly code fails to load the initial value into the accumulator before adding to it. This means the operation works on whatever just happens to be in the accumulator at the time (i.e. the results of a previous operation), leading to undefined behaviour.

 

To demonstrate, I wrote and compiled the following simple program:

    dim fpv = a.b
    dim byte = c
    
    byte=byte+2
    fpv=fpv+2
    fpv=fpv+2.0

Compiling this as normal resulted in the following assembly:

.L00 ;;  dim fpv  =  a.b

.L01 ;;  dim byte  =  c

.
 ;; 

.L02 ;;  byte = byte + 2

	LDA byte
	CLC
	ADC #2
	STA byte
.L03 ;;  fpv = fpv + 2

	CLC
	ADC #2
	STA fpv
.L04 ;;  fpv = fpv + 2.0

	LDA b
	CLC 
	ADC #0
	STA b
	LDA fpv
	ADC #2
	STA fpv

As you can see, at .L02 the compiler handles the operations properly; it loads the previous variable into the accumulator (LDA byte) and then performs the addition and stores the result (STA byte).

At .L03, the initial LDA call is missing: The operation in this case works on whatever's in the accumulator at the time, which happens to be the "byte+2" result from the previous operation, which result is then stored in fpv (STA fpv).

At .L04, where I add "2.0" instead of "2" so as to force the operation to act as a fixed point operation, everything is again handled properly: It loads the accumulator (LDA b, the "decimal" part of the variable), adds nothing to it, stores the result back in b (STA b), then loads the accumulator with a new value (LDA fpv, the "whole" part of the variable), adds two, and stores the result (STA fpv).

 

In layman's terms, this means that instead of "fpv = fpv + 2", what I end up with is "fpv = byte + 2" which...is not what I want.

 

I originally found this error in v0.9 of 7800basic (Windows 64-bit), but it's still there after upgrading to v0.19 (which afaik is the current version).

Edited May 15, 2022 by goldPseudo
add details for version of compiler

[RevEng]

Thanks for the report, and the work-around!

[+Random Terrain]

I thought needing to add the decimal point (with a zero) was a feature, not a bug when dealing with fixed point values?

[+TwentySixHundred]

It's been that way as long as i can remember and thought it was user error. bBasic is also the same IIRC. It can catch the developer off guard when not paying attention.

 

Personally i always thought the error was caused by the compiler not knowing where to store the value, as there is no decimal point to differentiate of the two variables.

[saxmeister]

On 4/10/2022 at 10:53 AM, Karl G said:

It's probably a longshot, but I thought I'd ask if anyone has made a 16 width by 8 tall font for use with 320 modes? I've stretched the atascii font for that purpose, but I just thought I'd ask in case someone has made something that makes use of the higher resolution.

One like this?

 

This code and this font should make it work for you. It's not beautiful, but it has a "fantasy" feel to it. It's a stretched version of the Krull font, although some of the characters weren't drawn for the game yet (J, Q, X, Z).

  displaymode 320A
  set zoneheight 8
  set doublewide off

  incgraphic atascii_320A_16x8.png 320A 1 0
  characterset atascii_320A_16x8

  BACKGRND=$00

  clearscreen

  rem **set the letters represent each graphic character **
  alphachars '@ABCDEFGHIJKLMNOPQRSTUVWXYZ '

  rem **set the palette color for this text - $0F - white **
  P0C1=$0F : P0C2=$0F : P0C3=$0F

  plotchars 'THIS IS MY TEXT' 0 0 0 extrawide
  drawscreen

Main
  goto Main

 

 

Edited May 16, 2022 by saxmeister

[+Random Terrain]

Got this question in an e-mail today:

 

Quote

I have a game that I am attempting to put together. It runs great in emulation during testing, but when I submit to be beta tested by others on real hardware, I am getting reports that the game randomly pauses. Now, I do not know if they are using a joystick that is tripping more than two joystick pins when moving around. Could this soft pause and reset on controller be causing the issue, even if the game is joystick only and someone is using different controllers? I just sent them another image to try that includes "Changecontrol" to trackball followed by joystic inside a routine that is never called. Also, who is selling these controllers with Pause and Reset on the controller? I have never seen one of these. 

 

[RevEng]

If the joystick the person is using is sending contradicting positions, then sure, maybe it's triggering the soft pause/reset detection. It would be the first report of this behaviour I've received. It would take 3 directions jammed simultaneously to achieve this. (Reset=L+D+U, Select=R+D+U)

 

The same joystick sending contradictory directions will also cause issues with other games, soft-pause or not. Some games will just take one direction preferentially, some will lock up movement, and others will do weird things. (e.g. U+D, L+R, U+D+R with combat 2600 moves the tank extra fast. L+R with Commando 7800 allows you to move right while strafing downwards.)

 

So far the soft-switch functionality is there for diy controllers. I have a project planned that will use it, but it may be some time before I get to it.

[RevEng]

Heads up that I dropped a new v0.20 7800basic release at github. Changes include...

• pokey support for fixed address chip, without auto-detection.
• initial snes controller support.
• added "set deprecated" support for old 160b index-import order.
• bugfix: multiply by 154 hang.
• bugfix: symbols ending in _[7800basic statemnt]
• bugfix: max symbols exceeded now triggers an error.

 

I think there's a few misc bugfixes in there too that didn't get documented.

 

The main reason for putting this release out was to get pokey *without auto-detection* support in everybody's hands, since auto-detection is causing a bit of heartache with some hardware.

 

I'll be putting up a wiki page on the snes2atari adapter soon... just a lot of stuff on my plate at the moment.

 

There's some bankset and RMT support in the code, but I'm still working out the kinks on those, so they're not documented or supported yet. The code isn't active if you're not trying to use those features, so it shouldn't impact anything.

[+Random Terrain]

So set pokeysound [on|off] is replaced with set pokeysupport [on|off|$450|$800|$4000].

 

I'm guessing that I should leave set pokeysound in the index for people who might be looking for it. (It will jump to set pokeysupport.)

[RevEng]

The "set pokeysound" was actually never a supported keyword, but rather a typo. It should have read "set pokeysupport", which I fixed in the manual. Other parts of the manual already had the correct "set pokeysupport", as did the sample program.  

 

Since it never worked, I don't think there's a reason to keep a reference to the typo around anywhere.

[+Random Terrain]

5 minutes ago, RevEng said:

The "set pokeysound" was actually never a supported keyword, but rather a typo. It should have read "set pokeysupport", which I fixed in the manual. Other parts of the manual already had the correct "set pokeysupport", as did the sample program.  

 

Since it never worked, I don't think there's a reason to keep a reference to the typo around anywhere.

 

Does that mean inline pokeysound.asm needs to be changed to inline pokeysupport.asm?

[RevEng]

1 hour ago, Random Terrain said:

Does that mean inline pokeysound.asm needs to be changed to inline pokeysupport.asm?

Nope. The modules is named pokeysound.asm. There isn't a 1:1 correspondence with "set" names and assembly modules.

[+Random Terrain]

I went over it about 4 times and I think I got all the changes:

 

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

[RevEng]

Thanks for that!