Altirra 2.50 Final out

[576XE]

And another question.

Is there fdisk2 for mydos with the same interface like fdisk2 for sparta?

[flashjazzcat]

FDISK2 is the old non-APT editor for IDEa and IDE Plus. I didn't write FDISK2; Drac030 wrote that. FDISK on the SDX ROMs (APT) found on my website is the editor I developed. It too works with any DOS - not just SDX.

 

Check the Altirra disk options. Any SIO patching overrides the PBI HDD.

Edited October 16, 2014 by flashjazzcat

[576XE]

Thank you FJC.

 

I cleared all flags from disk and cassette menues but I get only "BOOT ERROR" while MyDOS DOS.SYS and DUP.SYS are on partition.D5: and D5: is bootable.

 

Thank you for explaining of APT Fdisk genezis.

I made all things on real HW but something goes wrong in Altirra.

[phaeron]

Took a look at the way this works... you will need to disable the SIO patch option to boot from a drive other than D1:. The OS doesn't normally support this, so the way IDEPlus does it is to modify the D1: disk read request to D5: without actually handling it. Having SIO patch enabled will prevent this from working because the emulator will intercept the disk request and bypass the IDEPlus firmware, going straight to the D1: disk emulator. Because the request ends up getting sent to D5: instead of D1:, the SIO Override Detection option won't work either, which normally allows PBI disks to function with SIO patch enabled.

[phaeron]

Had inspiration on how to rewrite part of the parser to remove some tables and free up space -- Altirra BASIC 1.1 is attached. Added are the DIR, ERASE, PROTECT, UNPROTECT, DPEEK, and DPOKE keywords from Basic XE, as well as support for hex constants ($D100). Also fixed a nasty bug in the string compare functions with strings bigger than 256 bytes, the parser for the PRINT statement allowing some invalid syntax, and probably something no one cares about, properly listing programs saved out from Atari BASIC with syntax errors in them.

 

atbasic.bin

atbasicx.xex

[+Larry]

Wow! It just keeps getting better and better! And the first real improvements in the 8K Basic version in years and years.

 

Terrific, Phaeron!

 

-Larry

[Mclaneinc]

Thanks Avery, your work is always appreciated!

[itaych]

Hey Avery, I get a crash when trying to remove any breakpoint in the debugger. Run Altirra, F8, Disassembly, F9, F9, boom.

[itaych]

Also, a question about the R: device STATUS call. After performing it I expect to find the number of pending characters in a 16-bit counter at $2eb-$2ec. Can you please put the real value there instead of just 0 for empty or 1 for nonempty? If you're concerned about software that may only read the low byte, it's fine if you cap the value at 255. Thank you!

[+CharlieChaplin]

Had inspiration on how to rewrite part of the parser to remove some tables and free up space -- Altirra BASIC 1.1 is attached. Added are the DIR, ERASE, PROTECT, UNPROTECT, DPEEK, and DPOKE keywords from Basic XE, as well as support for hex constants ($D100). Also fixed a nasty bug in the string compare functions with strings bigger than 256 bytes, the parser for the PRINT statement allowing some invalid syntax, and probably something no one cares about, properly listing programs saved out from Atari BASIC with syntax errors in them.

 

 

Boah!

 

How great is this ! How could you pack all that into just 8kbytes ?!?

Now all I need is some added Autorun-mode (e.g. like in TB XL which automatically runs a program named Autorun.BAS or like in Basic XL Runtime which automatically runs a program named Autorun.BXL), that will run a Basic file automatically -or- just stop with the READY prompt if it is not there (no Error message if the Autorun is missing) and then I have the perfect replacement for Atari Basic even on my XL computers. I already put some Atari Basic games onto various disks with Altirra Basic instead of Atari Basic, because they execute faster under Altirra but otherwise still run fine (which is quite often not the case when running Atari Basic programs under TB XL)...

 

Seeing Altirra Basic, I am quite sure you would have been able to squeeze Turbo-Basic into 16kbytes without the need to use RAM under the OS (only RAM/ROM space from $8000-BFFF). But maybe this could be your next project - create a RAM version (XEX file version) or a ROM version (cart-version) of TB that requires only 16kbytes and gives you 24kbytes free memory. And it will also work with Atari 400/800 or any disk-based DOS version that uses RAM under the OS...

[flashjazzcat]

Surely TBXL is only around 16KB already (14KB under OS, and a few KB in low RAM). That's why it allows nearly 40KB of program space. The only way to make it better would be to fit it into much less than 16KB.

 

In any case: Altirra BASIC is an astounding coding feat.

[+CharlieChaplin]

Surely TBXL is only around 16KB already (14KB under OS, and a few KB in low RAM). That's why it allows nearly 40KB of program space. The only way to make it better would be to fit it into much less than 16KB.

 

In any case: Altirra BASIC is an astounding coding feat.

 

Alas,

 

TB XL is 17.5kbytes in length, approx. 12KB under the OS and approx. 5.5 kbytes in normal RAM ($D000-D7FF, CC00-CFFF and E000-E3FF unused, but $D800-DFFF used; $C000-CBxx used, $E400-FFF1 used and $2080-3628 in use)... so the length of the current version would not fit into 16k RAM or ROM... someone would have to shorten it by 1.5kbytes...

[phaeron]

Breakpoint toggle crash fixed (UI wasn't registering the breakpoints under a group):

http://www.virtualdub.org/beta/Altirra-2.60-test14.zip

http://www.virtualdub.org/beta/Altirra-2.60-test14-src.zip

 

Includes Altirra BASIC 1.2, also attached. Fixes a bug with VNTD not being updated correctly compared to Atari BASIC, fixes a problem with parsing mixed string and numeric expressions, i.e. STR$(A$(0)<A$(1)), and adds support for the BASIC XE RENAME, MOVE, and HEX$ commands.

 

Regarding R: giving one byte at a time -- is this with the emulated R: handler with throttling disabled? I might have an idea what's causing that in that case... the poll code might need to be looped since it isn't getting driven off of a timer.

 

The most annoying issue working on ATBasic is code space -- it's now down to about 25 bytes free. If you look at the commands I added from BASIC XE, you'll notice that I was careful to pick ones that were most useful and small to implement. Why DIR and hex constants first? Because having to go into DOS to see what files are on a disk and accessing memory locations by decimal address is farking annoying. Also, all of the file manipulation commands are implemented by this same routine and so were rather cheap to add:

.proc stFileOp
        lda     op_table-TOK_ERASE,x
        pha
        jsr     evaluate
        jsr     IoSetupIOCB7
        pla
        jmp     IoDoWithFilename

op_table:
        dta     $21,$23,$24,0,$20
.endp

At this point, adding anything new involves "scrunching," which is (a) finding ways to shrink code size to free up bytes, (b) testing the changes, and © fixing all of the bugs introduced by said changes. I need to write more tests.

 

Modifying TBXL is not a project I'm likely to take on -- just disassembling and reversing it would be a large amount of effort. Rewriting it to fit into banked storage would be even more work. Besides, why bother trying to fit into a 16K cartridge? Unless you've got a boatload of 16K cartridges and EPROMs lying around, might as well just burn it onto a big flash cart and be done with it. The way I see it, there's no point in trying to make a 16K banked BASIC at this point when you could go 32K+ and make it even more powerful.

 

atbasic.bin

atbasicx.xex

[atx4us]

This is my favorite thread on the AtariAge forum Thank you very much phaeron!

[576XE]

Hi phaeron,

 

For all of us you give the exclusive breath of modern atari world.

You are perfect.

Thank you.

[Madi]

Hi phaeron

 

I was modifying the Atari APX software "FAMILY FINANCES" when I encountered the error shown in the pictured attached.

The error occurs only when running AtBasic (tested versions: 0.99 p to 1.2).

The error always occur on line 640 and the Entering of file is terminated (the basic MAINMENU is attached in the tokenized form ).

 

The error points at the EXPTOT array. Is it possible that AtBasic interprets it as "EXP= Exponential function" ?

 

 

madi

MAINMENU.zip

[flashjazzcat]

EDIT: You already nailed the issue.

Edited October 20, 2014 by flashjazzcat

[jacobus]

Hi Phaeron

 

My apologies if this has been asked before, but can you provide any information about the SIO patch that you use in the emulator? I have a somewhat unique situation where a program I'm writing works fine under the emulator with the patch enabled, but fails on real hardware (and under Altirra with the patch disabled). The code that fails is a very simple game save (open a file, dump several memory locations (~6.5K), close). I tried executing Hias' Highspeed SIO patch, but it does not solve my issue.

 

thank you!

[phaeron]

Think I have a fix for the function parsing issue, but it needs more testing.

 

The SIO patch for disk access works as follows:

• DSKINV and SIOV are both intercepted, but only in ROM
• DSKINV uses DSCTLN for sector size, but only to resolve a mismatch (for OS-B compatibility)
• Read, write, status, and get PERCOM block commands are accelerated
• If the transfer direction is wrong or the buffer overlaps TIMFLG, the request is not accelerated (yes, someone actually did the latter)
• All audio channels are reset
• SKCTL, CDTMA1, CHKSNT, CRITIC, STATUS, DSTATS, P, and Y are updated before returning

One thing that I think the SIO patch will let you do that doesn't work with actual SIO is to call into it with the I flag set. This will cause SIO to hang. I should probably check for that.

[Irgendwer]

...

works fine under the emulator with the patch enabled, but fails on real hardware (and under Altirra with the patch disabled).

...

 

DLI active which steals to much cycles from SIO (corrupts timing)?

[russg]

Hi phaeron

 

I was modifying the Atari APX software "FAMILY FINANCES" when I encountered the error shown in the pictured attached.

The error occurs only when running AtBasic (tested versions: 0.99 p to 1.2).

The error always occur on line 640 and the Entering of file is terminated (the basic MAINMENU is attached in the tokenized form ).

 

The error points at the EXPTOT array. Is it possible that AtBasic interprets it as "EXP= Exponential function" ?

 

 

madi

Yes, 'EXP' function raises number to base 2. You can't use EXP as the first part of a variable.

Edited October 22, 2014 by russg

[jacobus]

 

DLI active which steals to much cycles from SIO (corrupts timing)?

Yes, that was the problem! Thanks for the tip!

[Madi]

Hi phaeron

 

It looks to me that MAINMENU.LST file has more to reveal.

 

As I had mentioned before, I was modifying the "Home Finances" software for Arabic localizing. I thought it will be easier to use "H" function In Altirra, since I used to "LIST" and ENTER" the files very often ( and view them Memopad, and MS Notepad with Arabic font enabled).

Then I noticed that when ENTERing the file that has been LISTed to H6: will show garbled data only(along with some Arabic phrases) without line numbers.

But when I opened the same file in Memopad, the line numbers and other data structures were shown correctly.

Next, I saved the same file to ATR image and tried to ENTER it. I only got READY, nothing else.

When I copied the file to screen (from DOS) I discovered that Altirra list data with windows/DOS new line number characters (0D - oA).

This solved the puzzle of showing lines in Memopad but get garbled in ATARI. That was because Memopad has the end of line character checked on Windows/DOS

 

Off course, I will continue with the normal List/Enter from disk until solution is obtained

 

madi

 

 

 

 

[phaeron]

H6: through H9: do line-ending translation, so when using them round-tripping isn't guaranteed. Specifically, the translation that Altirra uses is that on read, any CR, LF, CR-LF, or LF-CR line endings are translated to EOL ($9B) and on write $9B is converted to CR-LF. This means that the file will not round trip if CR ($0D) or LF ($0A) characters already exist in the file. This also means you can't exchange files read/written through H6-H9: directly with the disk image, because then you'll only have a one-way conversion and the line endings will be wrong. To avoid problems with files that have such characters, you'll need to use H1-H4: for untranslated file I/O and then a PC-based editor that can handle ATASCII.

 

It's also worth noting that BASIC programs can fail to round-trip through ENTER/LIST even if untranslated I/O is used. One way this can fail is if the BASIC program has been edited to have arbitrary binary data in a string literal. These are stored in tokenized form as length-prefixed, so they can contain arbitrary data in the token stream like quotes and EOLs that won't survive LISTing.

[+Larry]

I thought it would be interesting to compare Altirra Basic to some others with both the "slow" math pack and an improved one. These show the times for Ahl's Simple Benchmark.

 

Atari Rev C XEOS -- 405 sec.

Basic XL XEOS -- 396

Altirra 1.1 XEOS -- 298

Basic XE XEOS -- 51 (uses it's own math pack)

Turbo Basic XEOS -- 42 (uses its own math pack)

 

Atari Rev C FastMath OS -- 117

Basic XL FastMath OS -- 108

Altirra 1.1 FastMath OS -- 79

 

As Phaeron mentioned, the math pack makes a big difference, but still for an 8K Basic, Altirra is something special!

 

-Larry