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 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 by saxmeister