Altirra 2.50 Final out

[snicklin]

Another nice feature would be able to specify multiple.ini files on a command-line or the icon properties. This way we could select different configurations almost instantly. Because, currently, I swap and rename .ini files, it works, but it isn't elegant.

 

You could create multiple .ini files and after creating each one, give it a new name.

 

Then write several batch scripts which just run a "copy" command which copies the files to the default filename and then runs Altirra.

 

Yes, it'd be nicer if it was built it, but the above solution is easy to attain.

[Keatah]

I'm doing that now. And I (manually) do the reverse when updating or tweaking a config.

[mr-atari]

Nice change to a enhanced system-configuration.

I tried 2.60_test3 today, can't use my custom_Roms. (myide-][ etc)

I can find them, add, but can't use them.....

MyIDE-][ cartridge emulation, seems not working too.

Also my BB.ROM does not seem to boot with ATOS.

Switched back to 2.50_final.

I'll wait for the next test :-)

[Mclaneinc]

Black Box or Bounty Bob?

[mr-atari]

BlackBox, both original and 2.16

 

[Madi]

[flashjazzcat]

That means SDX is trying to save the BASIC environment to a nonexistent path. Since the hard disk is enabled, have a look for a CONFIG.SYS which defines the $BASIC environment variable. You may find it points to the nonexistent drive 1.

[Roydea6]

 

An example of setting the $BASIC variable with an autoexec.bat file..

 

Also if you load a RAMDISK then SDX will apply the $BASIC variable.. if not over written by the config.sys or autoexec.bat..

Edited August 14, 2014 by rdea6

[Keatah]

I think this emulator finally restored my "faith" and interest in the 8-bit lineup. Not that I ever lost it in the first place. I mean to say it supports so many things and does so many things right that it's loads of fun experimenting with software and mathematical stuff, like the "Archimedes Spiral" graph shown earlier. But it's not really an "Archimedes Spiral" - look it up. It's a simple 2-function Surf plot. Or Surface/Mesh plot.

 

 

[Keatah]

I remember seeing a pic of Archimedes Spiral in a magazine (Creative Computing?) but don't recall seeing the program or ever running it until a while ago (mostly in turbo and pressing key to kill attract mode at least 5 times).

 

The challenge is there just asking to speed it up... it could probably be improved 20% just by rearranging and compacting the program lines.

 

I recall getting 30-40 percent boost on my Apple II when I used TASC or Einstein Compiler on things like that Surface plot. If I compacted and concatenated lines (via Beagle Bros. COMPACT), the interpreted version didn't go faster, but the compiled version seemed to gain another 5% or so in speed. Compact, concatenate, reduce variables, compile! Yeah baby! Does anyone know if there is a similar compiler/compactor product for the Atari 8-bit?

 

I don't believe there's much more speedup you can do in BASIC without some pre-computation or replacement of the math routines.. It is what it is. But to get what I think is the fastest rendering via interpreted BASIC:

 

1- Select the 21MHz 65C816

2- Turn on warp speed (obviously)

3- Select Accelerated Floating Point on the Firmware sub-selection dropdown

 

It is number 3 that gave a good boost on the Apple II, a whole new set of routines instead of what's in the stock ROM.

 

And in thinking about this. I think I have another feature request (if it's not hidden somewhere).. The ability to turn off Attract Mode.

Edited August 15, 2014 by Keatah

[Keatah]

I think, for the time being, I'll be sticking with the registry settings way of doing things and stuff. I've been playing with importing and exporting settings since XP came on the scene and I have my system backed up, so no risk of disaster from a botched edit.

 

Currently it isn't a big deal to click on a "settings" icon that is a xxxxxx.REG file and have it dump a config right into the registry. It's less tedious than playing with batch files and copying over the single-allowed altirra.ini file. Doing things this way also affords the ability to combine and merge settings from other configurations too. And if I want to make them more permanent for posterities sake and the future, I can just export some or all of the VirtualDub.org Key and archive them away. This seems to be the easiest method with the least amount of work on my part. Meaning mouse movements and # of files. And my xxxxxx.REG files don't change unless I want them to.

 

I mostly like custom configs for some controllers, color settings, and keymaps. I've been doing this with Altirra since the early 1.x versions.

Edited August 15, 2014 by Keatah

[Madi]

1. CPU Options .. 6502 / 652C, 65C02 and 65C816 (1.79MHz)

 

2. CPU Options .. 65C816 (3.58MHz) and faster modes.

No effects on performance was noted. Only screen is distorted. !!

[Keatah]

Back in the day I always kinda sorta wondered what some of our 8-bit machines would be like with a faster CPU. Just the CPU mind you. Well today you can discover just

 

With CPU set at 3.58 MHz or higher I noted progressively smoother animation of the 3D particles in Star Raiders' explosions, e.g. when asteroids or ships are getting blown away. The hyperwarp is also smoother and slightly faster. Otherwise the game plays as it should.

 

Now on Ballblazer, with the CPU set at 10.74 Mhz or higher I get stupid smooth animation and near perfection in the grid scrolling. The game is totally playable and proceeds at the same rate as a standard 400/800 would. This is really something and I believe the original programmers of the game would have liked it to play this smooth; but due to the hardware limitations of the day it wasn't possible.

 

Talk about emulators not being as good as the real thing. Pffaggghhhh! That's hogwash. You have the option to play it like it was, with choppy scrolling. OR you can "upgrade" the specification and play it as it was intended to be played.

 

And this is all on a Pentium III with ISA soundcard and AGP 2x graphics.

 

Of course some games have artifacts at speed which aren't present in normal configuration. Whether this is an emulator fault, or if it would happen in a real Atari I don't know.

 

And some games are ridiculously fast, that's to be expected.

Edited August 18, 2014 by Keatah

[phaeron]

Alright, took a bit, but here's a new test release:

 

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

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

 

Notable changes:

• Overhauled the firmware UI a bit. When adding new firmware, the UI now asks for the type rather than relying on the selected category. CRC32 is also displayed for convenience.
• Fixed some issues with relative firmware paths. Note that any firmware detected under the program directory will be stored as a relative path, so if you are running Altirra in registry mode (non-portable) and have both instances scan the same folder under one of the instance's program folder, you can get duplicate entries. Don't do that.
• There is now an option to select default firmware per category. This allows multiple firmware images to be switched for types other than OS/BASIC without having to manually swap around paths.
• Added OS-B PAL to ROM autodetect list.
• Reworked BlackBox firmware handling so that both types of 16K ROMs are supported (1.xx) and 32K ROMs are now also supported (2.xx). The issue with 16K ROMs is that there are images with two different bank orderings out there, one with PBI device $01 at offset 0 and another with device $01 at offset $0800. This is now detected and adjusted for so that either order will work.
• Fixed BlackBox button handling. It was wired straight to IRQ but is now routed through the VIA.
• SCSI READ CAPACITY and IDENTIFY commands are now supported, so PARK.COM and HDFMT.COM now work.
• Device tree now saves, i.e. Computer -> BlackBox -> Hard Disk. Remember that you need to select the BlackBox entry to add the Hard Disk under it.
• /portablealt:<path> now launches portable mode with a different INI file. This needs to be specified each time, though.
• ATBasic updated to 0.96, now with fix for immediate mode repeat bug (also attached).

Regarding some questions:

• ATBasic auto-repeat: Afraid I'll have to decline, for a couple of reasons. First, IMO the BASIC interpreter shouldn't enforce this since it's a user setting that may already have been changed. Second, doing this requires detecting the XL/XE OS, which will take additional code space.
• U1MB 65C816 visual glitch: This is due to DLI timing issues. Display list interrupts have very specific timing requirements that can easily be violated by a CPU accelerator. Accelerators vary widely in the strategy for dealing with this, if at all. One thing, though: if you're seeing this, it probably means you have the fast shadowed ROM enabled, and that's probably not realistic for U1MB which would be on the chip bus.

atbasic.bin

[serj]

errors have not disappeared, furthermore added new problems.

moved the old ini file to the folder new version of the emulator, clicked "scan" and reappeared doubles ways.

BIOSes if placed in a separate folder, no errors occur.

button "remove" does not delete old records.
when re-entering the settings, old records remain in their original locations.

button "clear" does not remove the entry from the settings.

I have a suggestion that the buttons are "clear" and "remove" only work with the registry, but do not brush settings in *.ini file.

also there is an error in the user interface is, the buttons are shifted upwards.

I recorded a video with the work in the new beta version.

Edited August 24, 2014 by serj

[Madi]

Writing memory to disk using Altirra:

.writemem SAKODA $CC00 $01FF

or .writemem D1:SAKODA $CC00 $01FF

 

 

ALTIRRA V2.5:

Altirra> .writemem SAKODA $CC00 $01FF

Wrote CC00-CDFE to SAKODA

The file is saved but not to the disk. It is saved to the Desktop.

ALTIRRA V2.6 (TEST 3 AND 4):

Altirra> .writemem SAKODA $CC00 $01FF

Length parameter required.

error returned.

[flashjazzcat]

ALTIRRA V2.6 (TEST 3 AND 4):

 

Altirra> .writemem SAKODA $CC00 $01FF

Length parameter required.

 

error returned.

Bloody Hell: I was trying to get .writemem to work the other day and gave up. I assumed I was using the wrong syntax.

[MaPa]

.writemem SAKODA $cc00 L$1ff

[flashjazzcat]

.writemem SAKODA $cc00 L$1ff

"Invalid numeric argument: L$1FF" (Altirra 2.50).

[MaPa]

Forgot to quote text. It was meant for that "Length parameter required." error in Altirra 2.60. SOme Altirra versions require the L paramater, in other you have to avoid it.. strange but true

Edited August 24, 2014 by MaPa

[Mclaneinc]

Hi Avery, just found a rare but odd situation when adding a BASIC CLOAD game via command line, as you may know I'm helping Starwindz with the Gamebase thing so everything has to be done by command line. In order to make it user friendly we are trying to cut out any technical user input per the way stuff was loaded on a real Atari with Tape and Basic. Every other media has a self running way bar the CLOAD.

 

Would an 'injected' RUN"CLOAD be possible via command line, there's the /RUN for BASIC stuff but it seems its not for tapes.

 

As always I simply ask if its possible, if its way too much work etc etc then just say no, its rare a Basic CLOAD game would have no disk versions, in this case it just so happens that Avlon Hills Galaxy seems to only exist as a CLOAD tape.

 

And as said in the Gamebase thread, thanks for adding that cheat file by command line option..Just saw it..

 

Edit:

 

I see there's a [no] option before it like many command line bits but it seems its not a real option in this case?

 

cheats - yes

nocheats - no

 

Typo?

 

And a last request, I'm going through the cheats that are around in a8t format and its clear some were either for different versions or not properly tested so I'm looking to go back to what I did in the day and make some cheats, would it be possible to have a description label for the address so it can be called Life or whatever, it would help if I make multiple cheats for a game a user could just enable what they want and at least know what the cheat is doing?

 

Again, its a mere request, if you think its worth it I'll be happy, if its too silly then I'm still happy as the emulator is superb..

Edited August 24, 2014 by Mclaneinc

[Madi]

Forgot to quote text. It was meant for that "Length parameter required." error in Altirra 2.60. SOme Altirra versions require the L paramater, in other you have to avoid it.. strange but true

 

Altirra 2.5

Altirra> .writemem SAKODA $cc00 L$1ff

Invalid numeric argument: L$1ff

Altirra> .writemem SAKODA $cc00 $1ff

Wrote CC00-CDFE to SAKODA

-------------------------------------

Altirra 2.6 (test 3 and 4)

Altirra> .writemem SAKODA $cc00 $1ff

Length parameter required.

Altirra> .writemem SAKODA $cc00 L$1ff

Wrote CC00-CDFE to SAKODA

Nothing mentioned about the "L" in .help . Need to be updated.

Edited August 24, 2014 by Madi

[Madi]

Edit: Sorry... Duplicated

Edited August 24, 2014 by Madi

[MaPa]

I have Altirra 2.60 test 2 here and in the help the L is mentioned.

 

Altirra> .help .writemem
.writemem    Write memory to disk

  Write a block of memory to a file on disk.

    .writemem <path> <xaddress> L<length>

 

Edited August 24, 2014 by MaPa

[phaeron]

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

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

• Fixed bug in portable registry that prevented deleting/clearing firmware entries.
• Fixed bug in ATOS that was breaking PBI-based CIO devices.
• Implemented 6551 ACIA on Black Box -- no serial/modem connection yet, however, just loopback.
• Added main Black Box DIP switch block.

I got the Black Box R: device working far enough to being able to handle loopback with BobTerm. There is one thing I haven't been able to figure out, though, which is that the R: device locks up on open if I clear the RAM with $FF on power-up instead of $00. This looks like it might be an uninitialized variable issue in the BB ROM, but I'm not sure.

 

Yes, as also indicated in the detailed change list in the program, the .writemem command was changed to require the L prefix, consistent with other commands. Remember that the .writemem command writes to the host disk, not the emulated disk. There are no debugger commands that write files to the emulated disk, although the UI can (explore disk). This has to be done with care anyway as it can easily confuse DOS and corrupt the disk if done at the wrong time.

 

For BASIC CLOAD, you should be able to handle that via key injection, i.e. /type "cload~ run~". You'll also want /nocasautoboot /siopatch, however.

 

There is a /nocheats switch, which takes no arguments. However, it's superfluous unless you're hitting an instance that's already running, because the cheats aren't automatically saved -- a new instance will always start with an empty cheats list.