Search the Community
Showing results for tags 'tbxl'.
Found 6 results
-
Hi! After a little exchange with @drac030 about the version of TBXL that I hacked for @mr-atari and now included with LiteDOS, I decided to cleanup the sources and automate the relocatable generation. And then, I spent a little time to fix the most notable bugs and finally do a proper release. The source is available from https://github.com/dmsc/turbo-dis and the binaries can be downloadd from https://github.com/dmsc/turbo-dis/releases/tag/v2021.11.06. Also, the source can conditionally assemble to the original version published on HappyComputer, all original code is there. Note that I don't have plans on working on this on the future, but if anyone wants to modify it further - there are a lot of optimization potential there - you can take from there. Now, copied from the README file over github: Fixed Bugs This version has fixes for a few interpreter bugs present in all standard TurboBasic XL versions: When adding or deleting lines when inside a FOR loop, the runtime stack is not correctly adjusted, for example this program: 10 ? "START" 20 FOR J=0 TO 10 25 ? "J=";J 30 IF J=5 THEN DEL 10,10 40 NEXT J 50 END The interpreter exits the FOR on the iteration 5, instead of counting up to 10. A bug with the parsing of IF statements without ENDIF, the end of statement is incorrectly checked. This is an example program: 10 ? 1;1;1;1;1;1;1;1;1;1;1;1;1;1;1;1;1;1;1:? 1;1;1;1;1;1;1;1;1;1;;;;;;:IF 1 20 ENDIF If you remove one ";", the program runs correctly, but as shown it prints "ERROR 12". In the PRINT statement, if the last token printed ends in $12 or $15, for example a CONTROL-R or CONTROL-U character on a string, the interpreter omits the new-line at the end, as it incorrectly assumes that the statement ended in a "," or ";". This program shows the problematic statements: 20 ? "LINE 1:x" : REM Ok, prints a new-line at end 30 ? "LINE 1:─" : REM BUG, does not print the new-line 40 ? "LINE 1:▄" : REM BUG, same as above 60 ? "LINE 1:";1.23456713 : REM OK, prints a new-line at end 50 ? "LINE 1:";1.23456712 : REM BUG, does not print the new-line 70 ? "LINE 1:";1.23456715 : REM BUG, same as above Detection of PAL/NTSC. The original TurboBasic XL assumes PAL ANTIC for the TIME$ function and the TIME$= statement, this means only 50 jiffies per second, so the functions return an incorrect value in NTSC computers. This version includes code at startup that counts the number of scan-lines in a screen to detects the ANTIC type. If NTSC is detected the code is changed to return the correct values assuming 60 jiffies per second. Note that both values are not exact, the real values are 49.86 and 59.92 jiffies per second in PAL and NTSC respectively, but for the intended usage the given values are close enough. Relocation This TBXL version relocates itself to the lowest address posible, by reading MEMLO and copying the code at low address to just above the value. This gives more memory to the BASIC programs, depending on the DOS version. This currently works for any MEMLO address lower than $3000. Have Fun! turbo-basic-20211106.zip tbasic.atr
- 31 replies
-
- 27
-
-
-
Similar to @phoney's question here, but in TBXL not FB. I have a menu disk I wrote in TurboBasic XL, and I'd like to cleanly launch executables (tiny, self-contained bootable .xex-es) from it. I'm using `BRUN`, and running into crashing and obvious memory loading issues. I've looked through De Re Atari, but the Atari memory map is still a bit of an eldritch art to me, so forgive me. Is there a more solid way of doing this, that doesn't crash? (specifically, these seem to crash when a key is pressed after they execute. I tried it in both A8MXa and Altirra, cofigs attached; don't have real hw to try it on). I think the underlying issue is that these expect a clean system to boot into, not to be loaded from TBXL; so is there a way to make this work better, like load it into a different part of memory, or reset memory to default before loading it? I've set up a Gr.8 screen and PMG in my menu, both of which use a bunch of RAM, so... I attached my current menu disk effort as an ATR for testing along with the basic file. Any ideas? Note I also tried a different way or executing the entries, which worked even less well: REM the old fragile basic executable loader way (even more fragile): xex$(len(xex$)+1)=chr$(155) poke 5534,0 poke 5535,192 x=adr(xex$) y=int(x/256) poke 853,y poke 852,x-256*y x=USR(ADR(["hL~)~{bbar}"])) atascii23 compo menu - ntsc version.atr atascii23 compo menu - ntsc version.bas
-
Similar to @phoney's question here, but in TBXL not FB. I have a menu disk I wrote in TurboBasic XL, and I'd like to cleanly launch executables (tiny, self-contained bootable .xex-es) from it. I'm using `BRUN`, and running into crashing and obvious memory loading issues. I've looked through De Re Atari, but the Atari memory map is still a bit of an eldritch art to me, so forgive me. Is there a more solid way of doing this, that doesn't crash? (specifically, these seem to crash when a key is pressed after they execute. I tried it in both A8MXa and Altirra, cofigs attached; don't have real hw to try it on). I think the underlying issue is that these expect a clean system to boot into, not to be loaded from TBXL; so is there a way to make this work better, like load it into a different part of memory, or reset memory to default before loading it? I've set up a Gr.8 screen and PMG in my menu, both of which use a bunch of RAM, so... I attached my current menu disk effort as an ATR for testing along with the basic file. Any ideas? Note I also tried a different way or executing the entries, which worked even less well: REM the old fragile basic executable loader way (even more fragile): xex$(len(xex$)+1)=chr$(155) poke 5534,0 poke 5535,192 x=adr(xex$) y=int(x/256) poke 853,y poke 852,x-256*y x=USR(ADR(["hL~)~{bbar}"])) atascii23 compo menu - ntsc version.atr atascii23 compo menu - ntsc version.bas
-
I'd like to introduce my latest project: Altirra Extended BASIC, a Turbo-Basic XL compatible interpreter implemented in a banked MaxFlash 1Mbit cartridge. Often when I need to do testing on the physical hardware I just end up using BASIC when the speed and control of assembly isn't needed, as I can just type in the program instead of hooking up the tether to upload one. Problem is, Atari BASIC is missing useful features like hex values, and the Altirra BASIC cartridge is packed like a can of sardines, so I couldn't add anything substantial there. Thus, the idea came to take Altirra BASIC and split it across cartridge banks so that it could be expanded. At the same time, experience had shown that much of the BASIC XL subset wasn't that useful due to the small pool of people who had used it and could run it, but with the extra space I could implement a far more expansive and available language: Turbo-Basic XL. Therefore, once I had gotten the interpreter reorganized into a banked cart, it was then possible to begin reversing TBXL's token format and reimplementing the extended language. Details: Uses a MaxFlash 1Mbit (128KB) cartridge. I chose this cartridge type because of its address-based banking mechanism, which turned out to be faster than data-based banking. Figuring out a usable long jump mechanism was a big obstable to getting this off the ground. Also, I have one of these carts and it's fairly widely emulated in the mega-carts. Currently 7 8K banks are used, 6 of which are split with a 4K shared bank and a 4K variable bank, and the last one being a special full bank for the help system. Half the cartridge is thus currently unused. Unlike Turbo-Basic XL, Altirra Extended BASIC does not occupy memory at MEMLO or memory under the OS ROM. This means that its memory layout is closer to Atari BASIC and it will run on a 400/800, even with 16K. Some TBXL programs are incompatible because they hardcode addresses in the $A000-BFFF range which Altirra Extended BASIC occupies. ATXBasic is binary compatible with Turbo-Basic XL 1.5 save files. However, this means that it is not binary compatible with Altirra BASIC's BASIC XL subset. Conflicting token values, couldn't do both. Some statements like LOMEM have been relocated to new token values above TBXL's. The AltirraOS math routines have been hoisted into the cartridge and reworked for speed. They are not necessarily as fast as TBXL's yet -- haven't touched division or transcendentals yet -- but it should be in competitive range overall. The OS math pack is not used so results are consistent between OSes. I implemented as much of the Turbo-Basic XL language as I could find documented or tokens for, and tried to match TBXL's behavior when it diverged from Atari BASIC, such as the ON statement. One deliberate incompatibility: TIME$ uses the accurate frame rates for NTSC and PAL, no way I was going to use hardcoded 50.0Hz. There is also a built-in help system, which I plan to fill out QBasic-style -- mainly because I am tired of turning away from the Atari to look up OS and hardware addresses. Writing the help directly is a pain, though, so it only has two pages right now. Need to write a help compiler. Preliminary docs are attached, though I still need to edit some old stuff from Altirra BASIC that needs to be changed. All that being said, I could use help testing the TBXL subset. I have a large collection of Atari BASIC programs and have already gotten my classic test suite working (Nazz, SpyPlane, Quadrato, Escape from Epsilon, Valiant, Jenny of the Prairie, etc.) but I have very few TBXL programs. I'd like to get the TBXL subset more solid before jumping into more optimizations or adding more commands, and with Altirra BASIC the community was very good at pointing stuff I didn't know about Atari BASIC. One lengthy TBXL program I've gotten running is Rocket Rescue -- that was fun to fix (PAINT leaks, ugh). atxbasic.bin atxbasic.pdf
- 76 replies
-
- 25
-
-
Just getting into TBXL 1.5 (NTSC DOS 2.x built-in), so far, haven't noticed a big difference between it and BASIC XE in terms of speed, if any. Anyways, 1 thing I did notice is more 'normal RAM' available, which is good, but [EXTEND] command no longer works. How do I access that with TBXL ? My 1200XL has the 256K RAMBO if that matters. Thanks !
-
Pajaki, pajaki (Spiders, Spiders): http://www.atari.org.pl/forum/viewtopic.php?pid=204445#p204445 Download (atr): http://www.freespace.com.au/filehosting/887885
-
- 2
-
-
- Turbo BASIC
- TBXL
- (and 1 more)
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord