BBC Basic: @% control variable in ABC compiler

Hi all,

I’m working on compiling my BBC Basic code in ABC. Have worked through error, I can get the code to compile but am struggling to understand the differences between how the interpreter and ABC handle the @% variable when used to format screen output. I’m using both the general and exponent formats as laid in the 2017 BBC Basic ref manual. I’m aware ABC handles these differently and have checked the ABC ref manual on this but honestly finding it a bit cryptic and hard to follow – if anyone has any (really simple!) examples to demonstrate it that’d be great :)

Thanks!

You are right that there are significant differences in the way that the complier and interpreter handle STR$.

I gave up and used a simpler concept of just displaying intergers and where required writing my own code to display real values as shown in this simple example ^{See line 122} which displays the CPU temperature in the Switcher Tasks display.

It gives the same result whether it is interpeted or compiled and run as a module.

    5 REM >Examples.CPU-Temp
    5 REM {MODULE TITLE my_module}
    5 REM {MODULE VERSION 1.0}
    5 REM {MODULE TYPE APPLICATION}
    5 REM {MODULE COMMAND Null}
    5 REM {MODULE HELP Prints a nice greeting}
    5 REM {MODULE MEMORY = 16384}
    5 REM {MODULE 32BIT}
    5 REM {NEWHEAP}
   20
   30 REM Read CPU Temperature and 'display' in the Switcher Tasks list
   40
   50 REM Version A.2022   01-05-2022
   60
   70 ON ERROR REPORT: PRINT " at line ";ERL: END
   99
  100 end%=FALSE
  102 DIM version% 100
  110 delay%=1000
  112 SYS "Portable_ReadSensor",0,0,0 TO old_temp%
  114 @%=&1000A00
  120 DIM taskid% 8, q% &100
  122 task$=STR$((old_temp%-2730) DIV 10)+"."+STR$((old_temp%-2730) MOD 10)+"'C  "
  130
  140 DIM buffer% 256, buffer2% 256, time_block% 8, time_buffer% 64, format_string% 64
  150 $format_string%="%W3, %DY %M3 %CE%YR %24:%MI:%SE"+CHR$(0)
  240
  250 $taskid%="TASK": DIM wmsg% 8: !wmsg% = &400C2: wmsg%!4 = 0
  260 SYS "Wimp_Initialise", 310, !taskid%, task$, wmsg% TO ,task_id%: our_task%=task_id%
  270 mask%=%11111110110110000
  380
  390 WHILE NOT end%
  400  tn%=FN_timenow
  410  SYS "Wimp_PollIdle",,q%,tn%+delay% TO reason%
  420  CASE reason% OF
  430    WHEN 0:     PROC_idle
  440    WHEN 17,18: PROC_message
  460  ENDCASE
  470 ENDWHILE
  490 END
  500
  510 DEF FN_timenow
  520    LOCAL A%
  530    SYS "OS_ReadMonotonicTime" TO A%
  540 =A%
  550
  660 DEF PROC_idle
  720    SYS "Portable_ReadSensor",0,0,0 TO new_temp%
  722    IF new_temp%<>old_temp% THEN SYS "Wimp_CloseDown",our_task%,!taskid%:       GOTO 70
  740 ENDPROC
  810
  820 DEF PROC_message
  830   IF (q%!16=0) THEN end%=TRUE
  910 ENDPROC
  912

It needs the line numbers because of the GOTO which refreshes the screen.

It needs the line numbers because of the GOTO which refreshes the screen.

I’m not even going to…

…okay, I lie. I’m absolutely going to…

While I’m not anti-GOTO (after all, a branch in assembler is one!), I tend to think that if you’re using GOTOs in your program, you either grew up with a Spectrum or you’re doing something wrong.

GOTO 70, eh? So, each time you’re DIMming, well, everything. Over and over. How do you not leak 1012 bytes each time? (if you check the value of END, it should be slowly growing)

Interesting abuse of the Wimp, too. ;)

If you look into what’s actually going on, Switcher (task manager) is a separate task that picks up on messages broadcast by the Wimp itself for when tasks start up and quit. We can leverage make use of this mechanism for a cleaner approach than continually killing and ressurecting the task.

This example will report the current value of the ticker (TIME in BASIC) every second.

DIM task% 8, buffer% 256

$task% = "TASK"
SYS "Wimp_Initialise", 310, !task%, "Ticker is ...?", 0 TO , thdl%

finished% = FALSE

WHILE NOT finished%
  SYS "Wimp_PollIdle", 0, buffer%, TIME+100 TO reason%

  CASE reason% OF
    WHEN     0 : REM Null event
                 REM Fake an initialise with our task handle
                 buffer%!0  = 256   : REM Cop out, just say it's 256 bytes
                 buffer%!4  = thdl% : REM Our task handle
                 buffer%!8  = 0     : REM (my ref)
                 buffer%!12 = 0     : REM Your ref (0 = an original)
                 buffer%!16 = &400C2: REM Message_TaskInitialise
                 buffer%!20 = 0     : REM CAO, but it's not important
                 buffer%!24 = HIMEM-&8000 : REM Slot size
                 $(buffer%+28) = "Ticker is "+STR$(TIME)+CHR$(0)
                 SYS "Wimp_SendMessage", 17, buffer%, 0

    WHEN 17,18 : REM User Message (Recorded)
                 IF (buffer%!16 = 0) THEN finished% = TRUE
  ENDCASE
ENDWHILE

SYS "Wimp_CloseDown"
END

Hey all,

Thanks for your input! Will look at a workaround if need be, but unforunatly the program does a fair bit of floating point math, so if I can figure out how to master @% in ABC it’d be really neat, both for this and the next thing I want to work on too :)

Here’s what’s going on – it’s a procedure for calculating the density of gases under pressure when diving. Dm% and EAD% values I’ve set to display as no more than two digits and are expressed as integers in any case, but kgm3_GAS is a float that needs to be displayed to three decimal places.

There’s a few other similar procedures within the program that need the same sort of setup.

 DEF PROC_density_NTP : REM ** Calculates gas density on NTP model

      Dm% = 3 : REM ** Depth starts at 3m

      atm_GAS = (f_O2*NTP_dO2*1.01)+(f_He*NTP_dHe*1.01)+(f_N2*NTP_dN2*1.01) : REM ** Air density at 1 BAR

      Y%=11 : REM ** Setting Y axis for tabulation

      REM ** Setting up screen and tabulating results
      PROC_Splash
      PRINT "Density calculated for breathing gas blend of  - O2: ";O2%;"% He: ";He%;"% N2: ";N2%;"%"
      PRINT ''
      PRINT "      Depth      |      Breathing Gas      |      Equiv. Air      |"
      PRINT "       (m)       |     density (kg/m3)     |   density depth (m)  |"
      PRINT "==================================================================="

      REPEAT

      Dbar = (Dm%/10)+1 : REM ** Extracting depth in BAR
      kgm3_AIR = (0.21*NTP_dO2*Dbar)+(0.79*NTP_dN2*Dbar) : REM ** Air density at depth
      kgm3_GAS = (f_O2*NTP_dO2*Dbar)+(f_He*NTP_dHe*Dbar)+(f_N2*NTP_dN2*Dbar) : REM ** Breathing gas density at depth
      EAD% = (kgm3_AIR/atm_GAS*10)-10 : REM ** Equiv. air depth for breathing gas density

      @%="G2.0" : PRINT TAB(8,Y%); Dm%
      @%="F1.3" : PRINT TAB(28,Y%); kgm3_GAS
      @%="G2.0" : PRINT TAB(54,Y%); EAD%

      Dm% = Dm%+3
      Y% = Y%+1
      UNTIL Y%=40

      ENDPROC

If you look into what’s actually going on,

Good Grief. I know what is going on.

The program was written as a simple proof of concept for
– writing a compilable module in Basic
– evaluating the use of @% with STR$ in !ABC
– without the hassle of creating windows.

This example will report the current value of the ticker (TIME in BASIC) every second.

On my Pi 4 it fails on the 3rd line and has nothing to do with @% in !ABC.

I know what is going on.

I meant with respect to how Switcher manages application names, as was clearly explained in the following text.

On my Pi 4 it fails on the 3rd line

Copy-paste error. The DIM at the top needs to be changed from “taskid” to “task”. Cosmetic change, but still a cock up. ;)

GOTO 70, eh? So, each time you’re DIMming, well, everything. Over and over. How do you not leak 1012 bytes each time?

Good Question. But, the complied version has not failed yet.

I’m working on compiling my BBC Basic code in ABC.

The first question is “Why?”. ;-)

What is worth the pain of converting to the bastard language that is ABC BASIC?

I admit there are some time-critical tasks that might benefit, but are yours those sort of programs?

I’m using both the general and exponent formats as laid in the 2017 BBC Basic ref manual. I’m aware ABC handles these differently and have checked the ABC ref manual on this but honestly finding it a bit cryptic and hard to follow

Forget about the BASIC manual – ABC uses ‘@%’ very differently. AFAIK you have to set ‘@%’ as an integer, and cannot as a string.

Even so, I am puzzled by your use of ‘@%’ in the example routine, along with ‘;’, and I wondered what you wanted to achieve. I get the fixed places for the float, but why constrain the general format for the integers? And that ‘;’ left-aligns numbers, which seems weird. ;-)

Perhaps for ABC

@%=&0A0A0A @%=0A030A

As I last did anything with ABC decades ago, all of this may be an old man’s ramblings, so treat with care. ;-)

But, the complied version has not failed yet.

As I last did anything with ABC decades ago,

Until very recently, the language support predated RiscPC extensions to BASIC.

Perhaps for ABC @%=&0A0A0A @%=0A030A would work.

Thanks, Steve – that put me on the right track. Also, made me read the ABC manual section again and I did manage to decrypt it a bit this time :) yay!