QBASIC compatibility

[gus0650]

hello, can you comment on how ACE is suitable for porting code from XC=BASIC and FreeBASIC?

[mdbergmann]

I have no idea. :)

This is what Claude had to say about it.

QBasic → ACE/AmigaBASIC: This is the most promising path since both descend from Microsoft BASIC. AmigaBASIC was derived from Microsoft's Mac BASIC, and QBasic from the GW-BASIC/QuickBASIC line — cousins in the same family. Core constructs like FOR/NEXT, WHILE/WEND, IF/THEN/ELSE, GOSUB/RETURN, SUB/FUNCTION, DEF FN, DIM, PRINT, basic string functions (LEFT$, RIGHT$, MID$, CHR$, ASC, etc.), and math functions will generally carry over. However, QBasic has things ACE/AmigaBASIC lack or handle differently: SELECT CASE, DO/LOOP, TYPE user-defined types (ACE has its own struct mechanism but the syntax differs), and of course all the PC-specific SCREEN modes, PALETTE, SOUND/PLAY commands, and BIOS/INTERRUPT calls have no direct equivalent. ACE supports AmigaBASIC's sequential file I/O, subprograms, DEF FN, and shared library calls, but its control flow and feature set is rooted in what AmigaBASIC offered circa 1985-87, which predates QBasic (1991). So a QBasic program that sticks to "classic" BASIC structures ports reasonably well, but anything using QBasic's more modern control flow or PC hardware access needs rewriting.

FreeBASIC → ACE/AmigaBASIC: Harder. FreeBASIC is substantially more advanced than QBasic — it adds pointers, operator overloading, namespaces, proper OOP constructs, THREADCREATE, inline ASM for x86, C-library interop, and many other features that have absolutely no counterpart in ACE. Even its "QB compatibility mode" (-lang qb) produces code that relies on features beyond what ACE supports. You'd essentially need to strip a FreeBASIC program down to its most basic procedural core — and even then, things like SCREENRES, IMAGECREATE, MULTIPUT, or GFXlib2 calls are all FreeBASIC-specific. Only the most vanilla BASIC logic would transfer.

XC=BASIC → ACE/AmigaBASIC: This is the hardest port despite both being Commodore-ecosystem languages. XC=BASIC's syntax was designed to be similar to QuickBASIC and CBM BASIC, but it's deeply tied to 8-bit idioms — direct POKE/PEEK to C64 hardware registers (VIC-II, SID, CIA), 6502-specific inline ASM blocks, byte-level data types optimized for 8-bit registers, and Commodore KERNAL calls. The memory model, screen handling (TEXTAT, character screen memory), sprite setup via hardware registers, and entire I/O philosophy are completely alien to AmigaBASIC/ACE's approach of calling AmigaOS libraries for windows, screens, and graphics. You'd be rewriting almost everything except perhaps the most abstract game logic or math.

In practical terms, the portability ranking to ACE would be:

1. QBasic — best compatibility, especially for programs using basic control structures, string handling, math, and sequential file I/O. Expect to rewrite screen/graphics/sound and some control flow.
2. FreeBASIC — only the simplest "QB-mode" programs have a chance; anything using modern FreeBASIC features is essentially a full rewrite.
3. XC=BASIC — near-total rewrite; the only things that survive are algorithmic logic and maybe some variable naming conventions.

[gus0650]

thank you, that is very informative.

TYPE and PROC are two commands i cannot do without. SWITCH CASE is nice to have. the rest, is unimportant.

[mdbergmann]

Not sure how TYPE really works. But ACE has support for custom types as structs/records.
What does PROC do?

[gus0650]

TYPE is basically like a struct in C afaik. what is the Ace equivalent?

PROC in Xc-Basic is somewhat equivalent to SUB in QB it seems

i need to look into those comparisons some more

[mdbergmann]

In ACE you define a type with:

STRUCT DateStamp
  LONGINT days
  LONGINT secs
  LONGINT ticks
END STRUCT

Then you declare it, meaning this creates a variable or a pointer:

DECLARE STRUCT DateStamp foo
DECLARE STRUCT DateStamp *bar

Then you can access the field via foo->days = 23 or so.

Seems the PROC is a FUNCTION/PROCEDURE.
This is a SUB in ACE, or actually since it's AmigaBASIC you can have function definition like DEF FN add1(x) = x+1 as a one-liner as well.

But ACE also has SUB pointers (or function pointers) that you can pass around. I just extended this to be able to implement callback mechanisms or higher-order functions like:

SUB adder&(a&, b&) INVOKABLE
  adder& = a + b  ' return
END SUB

add3& = BIND(@adder, 3)   ' create new function pointer with 3 as first parameter (currying)
PRINT INVOKE add3&(5)     ' will print 8

That function pointer you can pass to other subs and INVOKE there.