Newest version of Altirra Basic and manual?

[gozar]

I finally flashed Altirra Basic to my U1M, and I want to play around with it. The latest version of Altirra Basic I could find was 1.48, but I think there is a 1.50 out there somewhere...

 

Is there any documentation on some of the new commands?

[Suppawer]

I have a PDF by Avery (11/29/14)

Altirra Basic.pdf

[flashjazzcat]

Deleted... D'Oh!

Edited March 23, 2016 by flashjazzcat

[flashjazzcat]

Here's the ROM version of 1.50:

 

atbasic_1.50.zip

[gozar]

I have a PDF by Avery (11/29/14)

That's the same one I found.

 

 

Sent from my iPhone using Tapatalk

[flashjazzcat]

Here you go:

 

atbasic.pdf

[+CharlieChaplin]

The newest version of Altirra Basic can always be found... in the Altirra (emulator) topic. Currently its Altirra Basic 1.50.

Alas, the newest docs/PDF for Altirra were written for version 1.41 afaik. I have therefore added/collected a very short info-text in ATASCII on the A8 what changes/enhancements and bugfixes have been made since version 1.40... this text consists mainly of the (collected) comments phaeron wrote in the Altirra topic, whenever he released a new version of Altirra Basic.

 

Besides, I find ATBasic (PDF or XEX or ROM) always a bit confusing/misleading (me thinks of Atari Basic then), therefore I always rename these files to ALTBAS or ALTBASIC (PDF, XEX, ROM) or simply use the version number, e.g. ALT150.XEX for the latest fileversion of Altirra Basic (1.50).

[phaeron]

Here, fresh manual.

 

ATBasic-20160323.pdf

[gozar]

Thanks phaeron! I want to play around the PMG commands.

 

 

Sent from my iPhone using Tapatalk

[serj]

thanks Avery !

your operation is magnificent.

[luckybuck]

Thank you very much Avery! :-)))

[peteym5]

I had been looking at this Altirra Basic, Ubasic, TurboBasic XL, etc, and see people trying to optimize these things to get more speed and free up memory. I had some thoughts of freeing up more space in the memory areas.

 

I had thought about is the token table that has an inverted character for the start of new keyword, can that be compacted with some clever bit manipulation? When it comes to data, I look for unused bits, and think to myself, can the extra bits serve a function. Have each letter in the key word stored as 5 bits, packing 3 letters into 2 bytes. However that will take a separate program to encode that.

 

I am not sure if that RTS jump table trick had been done anywhere with these, but that technique is saving me tons of memory space.

[flashjazzcat]

Trouble with packing your tables so densely is that you end up spending extra time masking and rotating when doing lookups, which might severely impact performance for a fairly slight space gain. Using bit 7 as a string terminator is of course fairly common (and cheap), and as for the RTS "trick": that's been the de-facto indirect jump method on the 6502 for thirty-odd years, so I doubt the author of any of these interpreters is unfamiliar with it.

[phaeron]

The trouble with trying to compact tables is not the extra time, it's the extra code. Remember, the idea is to save space, and any additional code that you add counts against whatever you saved by compacting the table.

 

Let's use some actual numbers. Altirra BASIC's statement name table is 336 bytes in size. 2:3 encoding with 5 bits would drop this to 224 bytes, saving 112 bytes, right? Not so fast. First, you can't store each letter in 5 bits, because remember that an extra bit is used for the terminator. You either need to enlarge the entries to 6 bits, requiring 3:4 encoding, or use a sentinel value instead of a stop bit. There are 82 entries in the table, so the first option gives us 336 - 252 = 84 bytes, while the second gives 336 - 278 = 58 bytes.

 

So let's say we go with 6-bit entries. Well, the next problem is where you're going to get a chance to decompress the entries. In ATBasic, the inner search loop uses X to point to the input buffer and Y to index the table entry, leaving only A to handle character data. That's easy when the characters are stored as bytes, not so easy when you need to shift/mask/combine to reconstruct the letters. Not only that, but the index that was in Y now becomes two indices, because the source byte index and source character index are no longer the same. That means the inner loop has to grow significantly in order to handle the decompression, eating into the savings.

 

Oh, by the way, that only accounts for searching. The same table is also used by the LIST routine that converts tokens back into readable form, so that routine also has to grow in order to handle decompression. There goes some more bytes. Oh yeah, it is legal to use LIST within a running program, so you can't use any page zero locations used by the execution module.

 

Now for the real problem: these same routines are reused for multiple tables. Typically, the same routines are also used for the function name table as well as the statement name table. This is a problem because the function name table uses a lot of special characters which won't fit alongside the letters in 5 bits. That's not the killer, though. The killer is that the routines are commonly also shared for the variable name table, whose format is part of the BASIC binary format and can't be changed while maintaining LOAD/SAVE compatibility. If just one of these table routines has to be unshared because of a format split, it will cancel or even go beyond negating the benefit of trying to compress the table in the first place.

 

Feel free to grab the Altirra BASIC source code and give it a shot, but I assure you, it's not that easy.

 

[Heaven/TQA]

I have to admit that I first totally missed Abasic (is that the acronym?) and used TBasic now since release. But in my latest project on a8 I booted altirra and used Abasic to make some native tables and test. That's what I use TB for.... generating tables, save them and do some tests.

 

Kudos it worked pretty good!

[Heaven/TQA]

Ok... first time I read the manual....

 

2 things missing for me:

 

do:loop (sound stupid but better than goto xxxx)

 

Proc:endproc

 

While:wend (rarely used by me though)

 

But rest is there

 

Bget,bwrite

Bitwise and,or,exor

Hex

[JamesD]

Ok... first time I read the manual....

 

2 things missing for me:

 

do:loop (sound stupid but better than goto xxxx)

 

Proc:endproc

 

While:wend (rarely used by me though)

 

But rest is there

 

Bget,bwrite

Bitwise and,or,exor

Hex

do, while, wend, until... any combo of these would be an improvement