Altirra 2.50 Final out

[+MrFish]

it suddenly pauses during game play at random times and will only un pause when START is pressed, also there's a spurious line on the screen at times during play.

 

The pauses aren't random. The round ends when any player gets six hits/strikes, shown by the color-filled circles. "Start" initiates the next round and point totals stay active. The author has stated this on the forums here somewhere previously.

 

I don't know about the lines. I've noticed the problem playing it on Altirra before. I thought it was ok when I tried it on real hardware when this version was first released, but I could be remembering wrong.

 

It's been a few years now; I'd love to see an updated release.

Edited September 8, 2014 by MrFish

[phaeron]

How can the cartridge option be used from the commandline?

I am trying to start a program from WUDSN. I Use the D5xx Parameters in the program, but the cardridge has to be

a) build up to a multi 8k file (which I can do by myself via a small program) (Cardridge can be any like AtariMax or The!Cart)

b) send to Altirra the filename for testing/debugging.

 

Where can I look for the Altirra command line options for this?

 

Run altirra /? to get a list of command-line parameters. Passing the cart is easy -- just specify its name. To specify the mapper. use /cartmapper with the number from the .CAR file format.

[flashjazzcat]

Passing the cart is easy -- just specify its name. To specify the mapper. use /cartmapper with the number from the .CAR file format.

Wish I'd known this earlier. I've been using the UI to manually select and map a cart ROM after compiling - hundreds of times.

Edited September 9, 2014 by flashjazzcat

[Mclaneinc]

Too much beta testing Centron 3D....

[TheEditor]

phaeron,

 

Thanks for the information about the multiple instances of the /disk switch, works perfectly. The one thing I did notice about the command line switched is you cannot set the 130xe as a machine and also cannot control things like Ultimate1mb being active in the program when running from the command line. Are you going to add switches for all the options in the future?

[Keatah]

I'd like to see a command line to switch/load custom palettes or sets of color settings.

[phaeron]

phaeron,

 

Thanks for the information about the multiple instances of the /disk switch, works perfectly. The one thing I did notice about the command line switched is you cannot set the 130xe as a machine and also cannot control things like Ultimate1mb being active in the program when running from the command line. Are you going to add switches for all the options in the future?

 

/hardware:130xe should work.

 

The problem with having command line switches for all this stuff is that it gets unwieldy really fast, so currently swapping INI files is the only way to do this. I'll think of something.

[TheEditor]

yea, I can see where it would get complicated. I will give it some thought too and if I think of anything I will let you know. I am known for thinking outside the box to come up with solutions that make the complicated more mundane.

Edited September 12, 2014 by TheEditor

[phaeron]

Small update:

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

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

 

• Fixes to ATBasic and AltirraOS so the ten-liners disk works. Sadly, this makes the ATBasic startup banner a bit uglier.
• Fixed a bug in ATBasic where the ADR() and LEN() functions worked in expressions but failed in PRINT, due to a type flag not being changed properly.
• DOS 3 filesystems can now be explored and created. (Yeah, I know. Think of it this way: now you have even less reason to have to actually boot DOS 3.)
• Improved autoselection of hook page for emulated H/R: devices. If the BlackBox or MIO are in the device tree, the emulator will now auto-switch the hook page to $D7xx. Still need to figure out what to do if all three D1/D6/D7 pages are used, though.
• MIO bank switching should now be more accurate for unusual banking modes.
• Added another disk emulation mode that sends data at a consistent 57.6Kbaud rate, like would be seen with an SIO2PC cable. This is because I had to debug an issue recently with a DOS that had a high-speed SIO routine that failed at this rate, and PC serial ports are more able to send back-to-back bytes than contemporary disk drives.

 

kernelxl.rom

atbasic.bin

[bfollett]

• Fixes to ATBasic and AltirraOS so the ten-liners disk works. Sadly, this makes the ATBasic startup banner a bit uglier.

Wow, I'm shocked you accommodated that ridiculously programmed auto-boot menu loader. Must have been painful.

 

Bob

[phaeron]

Nah, wasn't that bad. Just had to edit a string in ATBasic and copy two bytes back on the tail end of CIO. It's just more annoying that there's so much code out there relying on unspecified behavior. I wouldn't have bothered if it were just the loader but it looked like one of the problems was actually from the DOS on that disk.

 

Small update:

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

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

 

Host device menu option is now checked when H: is enabled. Rewrote the hook page code to be much better at dodging hardware device windows -- it now knows about all of the devices instead of just VBXE/BlackBox/SIDE, and can also use more windows. The possible windows, in priority order, are now $D6xx, $D7xx, $D1xx, $D5xx, and last ditch, $D340-D37F. The hook page is now also disabled entirely if it is not needed (H:, emulated R:, P:, and enhanced E: all disabled).

[MaPa]

Hi.. I think I found some bug or maybe it's another strange behaviour of ATARI but... when I set DMACTL to 0 and have set PAL video system it works as I expect. But when I set NTSC video system, then it still fires DLI's even when DMACTL is zero (remembers last DLIST instruction).

[phaeron]

That behavior is correct. Turning off display DMA via DMACTL bit 5 doesn't kill the display list entirely -- it simply causes the last fetched display list instruction to repeat indefiinitely, sans LMS. This means that if you stop display list DMA on a mode line with DLIs enabled you will get a lot of DLIs.

[MaPa]

OK.. so I had just luck with PAL that the write to DMACTL occurs on nonDLI line.

[bfollett]

I've been toying with Altirra Basic now for a couple of weeks and I have to say how impressed I am with the speed improvements over Atari Basic, but I think from a practical standpoint you would have to come up with some kind of compiler / runtime library set up. Otherwise any program written with AT Basic would require someone to have an Altirra Basic cartridge. Not a big deal for the emulator, but kind of a killer for real hardware. I'm not so sure all that many users have the ability to burn cartridges. Have you given any thought to a pseudo compiler/runtime library that would allow the Altirra basic programs to run without the cartridge present?

Thanks,

Bob

[flashjazzcat]

Surely you can just compile them with any of the existing Atari BASIC compilers, since Altirra BASIC uses 100 per cent compatible files?

[Mclaneinc]

But won't he lose the speed then without having a version of the ALTbasic running?

[flashjazzcat]

Compiled programs do not require an interpreter.

[Mclaneinc]

Doh...Oh well, I've learnt a new thing today

Edited September 15, 2014 by Mclaneinc

[phaeron]

Altirra BASIC is a plain 8K ROM, so it can be soft-loaded into any computer with 48K RAM. No physical cartridge needed.

 

Unless you've got a massive program that just simply can't fit when compiled, there's no advantage to using ATBasic over one of the existing compilers, as it's trivial for a compiled program to outrun an interpreter. For most programs, the overhead of executing tokens and converting infix expressions to postfix dominates execution time. The MMG compiler, for instance, rewrites all tokens as inline JSRs and converts expressions to register-based evaluation form.

 

Now, it's probable that a cross-compiler running on a modern compiler would run circles around the Atari-based compilers, as it could do flow analysis and do much stronger optimizations like identifying constant variables and integer loops. Writing one, though, is left as an exercise for the reader.

[phaeron]

I've been spending too much time on Altirra BASIC as it is, but I realized a couple of days ago that it was doing more work than it needs to with the value stack, because two of the eight bytes for each entry are unnecessary. In addition, splitting the value stack into a pair of stacks with even/odd bytes would save some pointer manipulation. As it turns out, these changes were beneficial in code size as well as speed, and freed up enough room to unroll a couple more loops.. ATBasic 0.99 is attached, which should be about 5-10% faster on control-flow heavy workloads. Also fixed a bug in the SOUND statement, which wasn't resetting SKCTL and thus audio channels 3+4 weren't always coming through.

 

atbasic.bin

[flashjazzcat]

Loving this... fascinating to watch Altirra BASIC being continually optimised and showing Atari BASIC a clean pair of heels.

[greblus]

Loving this... fascinating to watch Altirra BASIC being continually optimised and showing Atari BASIC a clean pair of heels.

 

One more thing worth to mention is that without your uflash it wouldn't be that easy to test it on real hardware . All of these new developments are truly amazing and kudos to all of you Atari Gurus out there!

[phaeron]

Found a bug in the DIM statement code and ended up rewriting part of it... ATBasic 1.0-rc1 is attached. This freed up enough space that I went and fixed all the places where ATBasic wasn't properly checking for out of memory errors, including DIM statements, LOAD, and in the parser. APPMHI is now also set so that the GRAPHICS statement can't overwrite the program, and fixed a bug where FRE(0) was three bytes lower than it should have been on start.

 

Stupid BASIC trick of the day: it is possible in Atari BASIC to run out of memory in the parser while trying to add a statement from immediate mode or ENTER and resume program execution via TRAP. Also, for some reason, it doesn't allow arrays bigger than 32K in size, a limitation which I didn't bother emulating.

 

A rather nasty bug that I fixed was that some programs SAVEd by Atari BASIC rev.B wouldn't load back in to Atari BASIC after being resaved by Altirra BASIC. This is because rev.B has a bug where it adds 16 bytes to the argument stack every time it saves, and more importantly, Atari BASIC assumes that the argstack size is 256 bytes whenever it LOADs or SAVEs, resulting in junk at the end of the file. ATBasic doesn't have either of these bugs, and it saved a file shorter than Atari BASIC expects. ATBasic now adjusts the argument stack size on SAVE to fix any BASIC program with this problem. I've already found two commercial programs with this problem (Jenny of the Prairie and MECC Elementary Biology).

 

atbasic.bin

[phaeron]

Fixed ATBasic parser so that invalid line numbers throw error 3. This has, of course, nothing to do with the evil purpose I just discovered for this error of invoking the TRAP line without hitting the immediate line.

 

With this, I declare Altirra BASIC at 1.0 because it is an important milestone for every program to hit 1.0 at some point, also known as Actually Finishing Something. V1.0 is attached.

 

Of course, this requires 1.0 source code, which is embedded in Altirra's source, so here's test-12. This also includes a fix to the 6502-based R: device to flush out the output buffer on exit. The emulated R: device was already doing this.

 

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

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

 

 

atbasic.bin