You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
FreeBASIC — only the simplest "QB-mode" programs have a chance; anything using modern FreeBASIC features is essentially a full rewrite.
XC=BASIC — near-total rewrite; the only things that survive are algorithmic logic and maybe some variable naming conventions.
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.
Repository owner locked and limited conversation to collaborators on Feb 5, 2026
Activity
mdbergmann commentedon Feb 5, 2026
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,TYPEuser-defined types (ACE has its own struct mechanism but the syntax differs), and of course all the PC-specificSCREENmodes,PALETTE,SOUND/PLAYcommands, andBIOS/INTERRUPTcalls 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 likeSCREENRES,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/PEEKto C64 hardware registers (VIC-II, SID, CIA), 6502-specific inlineASMblocks, 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:
gus0650 commentedon Feb 5, 2026
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 commentedon Feb 5, 2026
Not sure how TYPE really works. But ACE has support for custom types as structs/records.
What does PROC do?
gus0650 commentedon Feb 5, 2026
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 commentedon Feb 5, 2026
In ACE you define a type with:
STRUCT DateStamp LONGINT days LONGINT secs LONGINT ticks END STRUCTThen you declare it, meaning this creates a variable or a pointer:
Then you can access the field via
foo->days = 23or 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+1as 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:
That function pointer you can pass to other subs and INVOKE there.