Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by mobluse

  1. On 4/2/2021 at 7:10 PM, Snickers11001001 said:

    Reading the description of the 'bug' that is the subject of this thread, it occurs precisely because of the same shortfalls of the c64 collection mechanism that cause it to be slow and problematic.   So putting in the better garbage collection from Plus4/C128 should both negate the bug and vastly improve GC in general.   Focusing on fixing the 'long standing' bug alone while staying with the crappy C64 style GC would, in my view, be an exercise in esoterica rather than productive use of coding efforts.

    Putting in the better GC of C128 would not help since the bug is also in C128: "I found this bug in all versions of Commodore BASIC, that I investigated, VIC-20, C64, C128, C65, MEGA65." https://c65gs.blogspot.com/2021/03/guest-post-from-bitshifter-fixing.html

    • Like 1

  2. I developed RatBAS2 in order to generate large BASIC v.2 programs from C-like source code:

    RatBAS2 is similar to RatFOR (Rational Fortran). I discovered that RatFOR could be used to generate BASIC since it is similar to Fortran 66 and modern RatFOR has a disabled Fortran 66 mode that I could enable.

    RatBAS uses only IF...GOTO, but BASIC does have FOR...NEXT loops, ON...GOTO, GOSUB, and ON...GOSUB also. Unfortunately the program that turns a program in BASIC with labels into BASIC with line numbers doesn't handle the ON... constructs. FOR... NEXT is probably faster than using IF...GOTO.

  3. I think VAL() should work for hexadecimal numbers and not only for decimal as it does now.

    should print: 268435455.

    I believe it would not be too difficult to implement since the code already exists for converting numbers in code.

    works now, and types: 268435455.

    Especially now when HEX$() exists in the next prerelease (-39). HEX$() converts without $ as prefix, but I think that's OK since $ could be added easily if one wants. It's also similar to how it works in other BASICs, e.g. GW-BASIC: http://www.antonis.de/qbebooks/gwbasman/hexs.html

    In GW-BASIC HEX$() also works for negative numbers, e.g. HEX$(-32768) is "8000", but negative numbers doesn't currently work with X16 BASIC HEX$().

    I don't think it's necessary to implement VAL() for binary numbers, even though BIN$() exists, but if one did they should probably have % as prefix, e.g. %101.

    FreePascal uses the same prefixes:

  4. 1 hour ago, AndyMt said:

    I'm in the process of updating Brixx and Invaderz to the new emulator and ROM. I want them to be compatible with R38 and R39 - but how can I detect which version the PRG is running?

    I know I can detect if I'm running in the emulator:
        read $9FBE/$9FBF, must read 0x31 and 0x36

    This doesn't seem to be the version, just an indicator that the software is running on the emulator. Is there an official way to detect ROM/emulator version? I found different solutions, but none seemed officially supportet. Like reading $FF80 or $FFFA etc.

    What's the best approach there?

    "The KERNAL version can be read from location $FF80 in ROM. A value of $FF indicates a custom build. All other values encode the build number. Positive numbers are release versions ($02 = release version 2), two's complement negative numbers are prerelease versions ($FE = $100 - 2 = prerelease version 2)." - https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md

    • Like 1
    • Thanks 1

  5. There is a flow control command in Applesoft BASIC that might be good to have in X16 BASIC:

    Removes one address from the return stack, i.e. converts last GOSUB into a GOTO.

    POP could be useful in more advanced BASIC programs. Maybe this could be solved using POKE, but it would be easier with a BASIC command, and then more old Applesoft BASIC programs could run on Commander X16. I did find two programs that uses POP:


  6. On 3/5/2021 at 8:39 PM, Nero said:

    As I was hoping to 're-learn' BASIC not too long ago, I was planning on porting one of those old 'book games' into BASIC. Actually began doing that in an old Apple II emulator, since it was the computer I learned BASIC on, but now I'm more or less inclined to do it in the X16's emulator and see what happens. I have never even seen a real C64 in my life, let alone programmed in one. Is there any place where I can check the differences between Applesoft's and X16's/Commodore's BASIC? Or... is there any practical difference? Sorry for the newbness, but we gotta start somewhere 😛

    In VIC20, C64, and X16 BASIC the AND, OR, and NOT operators are bitwise, but in Applesoft they are logical/boolean. 3=3 is -1 in X16 etc., but 1 in Applesoft. STR$(7) has an extra space for sign in X16 etc., but not in Applesoft. Applesoft is described here: https://www.calormen.com/jsbasic/reference.html
    X16 BASIC is the same as C64 BASIC (CBM BASIC v.2), but with enhancements: https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md

  7. I could load the C128 program X16C128W70.PRG (above) in x16emu from the host file system using LOAD"X16C128W70.PRG" and LOAD"X16C128W70.PRG",8 but not using LOAD"X16C128W70.PRG",8,1. I've not tried to LOAD from SD card.

    Also I do not get the text "SEARCHING...
    LOADING FROM $..." but only "READY."

    Maybe you have a different release than 38 or this is how it looks when you load from an SD card.

    Anyway, I think loading should work in Commander X16 as in Commodore computers, because that is what most people expect and know how to handle.

  8. What do you mean would happen with the three line program where one line is skipped by linking in the cases ,8 and ,8,1 and x16emu -prg?

    I have two programs 3LINES.PRG and 3LINES2.PRG. The last is the hacked version where line 1 links to line 3.

    x16emu -prg 3LINES2.PRG
    and LIST gives two lines, but LOAD with ,8 and ,8,1 gives three lines in both x16emu and x64 from VICE.

    It seems that the program is repaired with both ,8 and ,8,1.


  9. There are pointers to the next line in the BASIC lines, but the computer doesn't know what it is loading and updates the pointers anyway, but one can probably fix that by having the machine code after the last line of the program.

    I think I can solve the original problem anyway by using SYS to set screen with to 40 characters in X16 and C128:
    POKE 780,0:SYS 65375

    https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md#function-name-screen_set_mode

    I could use screen/$FFED to get the rows and columns, but that doesn't seem to work on C128 - tested in x128 and x128 -80col:
    SYS 65517:R=PEEK(782):C=PEEK(781)

    BTW screen_set_mode in C128 is slightly different than in X16 since in C128 it switches between two different physical screens with different screen dimensions AFAIK. In the x128 emulator you have to switch screen manually in the configuration menu.


    But it works in xpet and x64 if I change the two start bytes in the C128 file (X16C128W70.PRG) to the correct address for the computers, respectively, and load as machine code with e.g.:
    x64 -autoload X16C128W7064.PRG
    That uses:
    load "X16C128W7064.PRG",8,1

    It also works if I load using:
    LOAD "X16C128W7064.PRG",8,1
    in x16emu.

    That would mean that if you load with ',1' it also changes the pointers, but that would make it difficult to load machine code in C64, since LOAD would change the two bytes after a 0, but I've never heard that is a problem. Does the LOAD"*",8,1 detect if it is a BASIC or machine code program, and try not to modify pointers if it is machine code?

    Also if people write machine code assuming -prg doesn't change the code, then they might not be able to run the program from within x16emu or the real computer.

  11. It seems the load address of BASIC programs in X16 is the same as in C64 i.e. $0801, because I saved a program from x16emu and used hexdump in Linux.

    I can LOAD "X16C128W70.PRG" inside x16emu, but when I use
    x16emu -prg X16C128W70.PRG,0801
    it only loads the first line. Strange! xvic, x64, xplus4 in VICE doesn't have this problem. It is possible to load the C128 program in xpet if I hack the start address to $0401 using hexcurse in Linux:
    xpet -autoload X16C128W70PET.PRG

    There is a new video about loading in Commodore type computers: LOAD"*",8 vs. LOAD"*",8,1 on the Commodore 64 from 8-Bit Show And Tell.


  12. This difference on $FFF6=65526 could be used, but I stick to 65534 so far.

    Initially I was thinking about type-in programs or programs imported from text, but this could work for tokenized programs if SCREEN and GRAPHIC had the same token.

    10 IF NOT PEEK(65534)=35 THEN GOTO 30
    20 SCREEN 0
    30 IF NOT PEEK(65534)=23 THEN GOTO 50
    40 GRAPHIC 0

    A worse matter is that I have not succeeded to load a tokenized C128 program into x16emu even if it only contains PRINT instead of SCREEN/GRAPHIC. If I do, it's only an empty program. Tokenized BASIC programs should be portable between Commodore type computers such as Commander X16, I think, provided they use the same tokens. I can load a tokenized C64 program into x16emu. I include programs generated by petcat in Linux that is included with VICE 3.4 (in my case).
    p=x16c128 ; cat $p.bas | awk '{print tolower($0)}' | petcat -w2 -o $p.prg
    cp x16c128.prg X16C128W2.PRG
    p=x16c128 ; cat $p.bas | awk '{print tolower($0)}' | petcat -w70 -o $p.prg
    cp x16c128.prg X16C128W70.PRG

    Both programs can be loaded and run in xvic, x64, x128, and x128 -80col (from VICE), but only X16C128W2.PRG loads in x16emu.

    x16emu -prg X16C128W2.PRG
    x128 -80col -basicload -autoload X16C128W2.PRG
    In the case with C128 and 80 columns one has to enter VICE configuration and switch screen.

    X16C128W2.PRG X16C128W70.PRG x16c128.bas

  13. How can I detect that it is Commander X16 BASIC that my BASIC program runs in and not a Commodore BASIC? Preferably an official way that doesn't change with ROM releases. If there are more models of Commander with different capabilities they should also be possible to detect.

    In Commodore BASIC this is done using PEEK(65534) which gives 72 for C64, 23 for C128, 253/255 for C+4 and C16, and 114 for VIC20. In X16 this was 35 when I tested, but I don't know if that can change.

    I try to write BASIC programs that work on X16, C64, C128, and VIC20 (and perhaps GW-BASIC on IBM PC, MMBasic on Maximite, Applesoft BASIC on Apple II etc.). I want to set character width to between 20 and 40 (SCREEN 0) and similar colors, but have to do it in different ways depending on computer, but to have one version for each computer is a maintenance problem. The type of calculation program I'm writing doesn't demand much of the hardware.

    10 IF NOT MODEL$="X16" THEN GOTO 30
    20 SCREEN 0
    30 IF NOT MODEL$="C128" THEN GOTO 50
    40 GRAPHIC 0

  14. Fuzix (a Unix like OS for 8 bit computers) has lately become popular due to that Fuzix now supports the Raspberry Pi Pico $4 microcontroller.

    I searched for Fuzix implementations for Commodore 64, but there is none, but Commodore is mentioned here:

    Fuzix exists for some 6502 based system, but the Fuzix developers thought the floppy disk drives for Commodore were too slow, but Commander's SD card might be fast enough. Also commander has 2 MB RAM maximum, but C64 could have 2 MB RAM using REU.

    It might be interesting for someone to port Fuzix to Commander X16.

    I found some video demonstrating Fuzix on a ZX Spectrum: 


  15. I tested this:


    10 SCREEN 0
    20 POKE $9F2A,32
    30 POKE $9F2B,32
    40 POKE $386,20
    50 POKE $387,15
    60 N=0
    70 PRINT N;
    80 N=N+1
    90 GOTO 70

    but it skips some numbers each third line when printing 4-digit numbers. I think line wrap and the screen editor should work as normal in 20x15 text mode.

  • Create New...

Important Information

Please review our Terms of Use