Altirra 3.00 released

[Mclaneinc]

My pleasure...

 

As said the first set came from user Serj on here with his pictures, there's been additions since but only the odd one or two so don't expect updates that often..

 

I just keep it up to date for me and if any one needs them they are there...

[Docwiz]

My pleasure...

 

As said the first set came from user Serj on here with his pictures, there's been additions since but only the odd one or two so don't expect updates that often..

 

I just keep it up to date for me and if any one needs them they are there...

 

 

Also, I have another question. When I load *.BIN files such as Donkey Kong JR for example, it doesn't detect the cart and it won't load, even if I force it to 8 or 16K. The floppy just continues to boot and it won't load the cart.

If I remember back to my Atari days. If you put in a cart and reboot, that cart should be loaded over anything on Disk, but that's not happening on the emulator.

[Mclaneinc]

I think you maybe are mistaking /remembering it for the Multi cart that's made an appearance on the forum in the last day, also I'm not 100% sure of the OS boot order, I THINK a DOS disk (if the drive is on) still takes over from a cart until loaded, not sure, maybe certainly carts instantly run from certainly set vectors etc..

 

One for the techies on here..

Edited June 25, 2018 by Mclaneinc

[phaeron]

Cartridges have precedence over disk boot on the Atari. The cartridge gets first crack to initialize itself and then tells the OS whether it should proceed with disk boot or not. This is mainly for cartridges that use DOS, though.

 

Cartridge boot behavior on Altirra should be similar to the real hardware since it is mostly an OS thing. There are a couple of exceptions. The first is that a few cartridges will bypass themselves if certain keys are held on startup, particularly AtariMax menu based cartridges. For these you may have to toggle the emulator's internal BASIC enable, which holds Option for you on startup. This is why "Option" shows up on the side, to remind you that this is happening.

 

The second is that certain devices can silently interfere with cartridge boot if not set up properly. For instance, adding one of the IDE interfaces with built-in SpartaDOS X without actually flashing SDX to it can cause this issue, because the device's SpartaDOS X cartridge emulation overrides the cartridge, and then the SDX emulation doesn't do anything because it hasn't been programmed with an SDX cartridge image. Thus, it can help to go through the Devices list and clean out all the stuff you aren't using, as well as turning off Ultimate1MB.

 

Finally, long shot, but -- make sure your cartridge is actually for the 8-bit computer. BIN files don't have any unique markings to identify them, so it's easy to accidentally give it some other kind of image. The emulator tries to detect accidental use of Atari 2600 cartridges since that was a common mistake.

[Docwiz]

I think you maybe are mistaking /remembering it for the Multi cart that's made an appearance on the forum in the last day, also I'm not 100% sure of the OS boot order, I THINK a DOS disk (if the drive is on) still takes over from a cart until loaded, not sure, maybe certainly carts instantly run from certainly set vectors etc..

 

One for the techies on here..

 

Sorry, I am using the Altirra Emulator and I can't seem to load a BINARY (BIN) file. When you load a cartridge it asks what kind of cartridge it is. Normally, I don't know what type these carts are. It doesn't give any options. It's just blank.

Then I try to load it and it doesn't load.

[Docwiz]

Cartridges have precedence over disk boot on the Atari. The cartridge gets first crack to initialize itself and then tells the OS whether it should proceed with disk boot or not. This is mainly for cartridges that use DOS, though.

 

Cartridge boot behavior on Altirra should be similar to the real hardware since it is mostly an OS thing. There are a couple of exceptions. The first is that a few cartridges will bypass themselves if certain keys are held on startup, particularly AtariMax menu based cartridges. For these you may have to toggle the emulator's internal BASIC enable, which holds Option for you on startup. This is why "Option" shows up on the side, to remind you that this is happening.

 

The second is that certain devices can silently interfere with cartridge boot if not set up properly. For instance, adding one of the IDE interfaces with built-in SpartaDOS X without actually flashing SDX to it can cause this issue, because the device's SpartaDOS X cartridge emulation overrides the cartridge, and then the SDX emulation doesn't do anything because it hasn't been programmed with an SDX cartridge image. Thus, it can help to go through the Devices list and clean out all the stuff you aren't using, as well as turning off Ultimate1MB.

 

Finally, long shot, but -- make sure your cartridge is actually for the 8-bit computer. BIN files don't have any unique markings to identify them, so it's easy to accidentally give it some other kind of image. The emulator tries to detect accidental use of Atari 2600 cartridges since that was a common mistake.

 

I have a 130XE setup as a Rambo and I have a 1030 modem attached to the R: and I have an XF551 disk drive and a 1050 as well as Printer and H: set up. The same binaries I was able to load without problem on Atari800win, will not work on this emulator. I load the cart and it comes up with no options and they won't boot. These are games mind you in binary format.

[phaeron]

I'd need to see an example. If you're getting a blank cartridge type dialog then it typically means you don't have a raw cartridge image that .BIN would usually indicate, it's some other kind of file.

[Docwiz]

Also, how do I turn off the floppy drives wiout pulling them out of the configuration? I have tried turning them to "OFF", but that just seems to take the disk out.

[phaeron]

That turns off the drives for standard emulation. For full drive emulation you must remove them from the Devices tree.

 

There seems to be an issue with people unnecessarily using full drive emulation lately. Generally, you should not use the full drive emulation under Devices for most uses, as it just makes the emulator use more CPU and disables some acceleration and assistance features in the emulator. The Atari disk drive protocol is a high-level protocol and doesn't need full drive emulation to run software as other contemporary drives like the C-1541. The cases where full drive emulation is needed are when running very specialized software for specific custom drives, such as the Happy drive copier software. You also need to pay a lot more attention to disk compatibility with the full drive emulators -- none of them will read a megadisk image, for instance.

[Docwiz]

That turns off the drives for standard emulation. For full drive emulation you must remove them from the Devices tree.

 

There seems to be an issue with people unnecessarily using full drive emulation lately. Generally, you should not use the full drive emulation under Devices for most uses, as it just makes the emulator use more CPU and disables some acceleration and assistance features in the emulator. The Atari disk drive protocol is a high-level protocol and doesn't need full drive emulation to run software as other contemporary drives like the C-1541. The cases where full drive emulation is needed are when running very specialized software for specific custom drives, such as the Happy drive copier software. You also need to pay a lot more attention to disk compatibility with the full drive emulators -- none of them will read a megadisk image, for instance.

 

Yep, that seems to be the issue here. So, if I want to fully emulate an XF551 drive, would I not need those devices? I guess I am having a hard time understanding what's going on here.

 

I suppose that regular 1050 is by default without any devices being added in.

[phaeron]

The disk drives are all actually little computers, but the Atari drives -- 810, 1050, XF551 -- are all hardcoded. They have a simple set of commands and you can't override or add new ones from the computer. This makes it easy to completely emulate them without the computer being able to tell the difference. Some of the third-party drives or modded drives are different, you can actually load and run programs on them. That's how the Happy copy software works, for instance. No way to handle that without actually running the second computer in the drive, which is what the full drive emulator in Altirra does.

 

By default, Altirra's standard drive emulation is set to Generic profile, which emulates a super drive that is a superset of what most drives can do with regular commands. This supports reading, writing, and formatting of all disk formats and a US Doubler compatible high speed mode. You can change the emulation profile by the drop down at the bottom of the Disk Drives dialog to select a more specific drive to target. For instance, if you choose 810, you'll get 810 drive sounds and speeds, and it won't read anything but a single density (90K) disk. Select 1050, and you get 1050 sounds and timings, and support for enhanced and double density, but no disks bigger than that. And so on. Typically one of the generic modes is best unless you're running a specific DOS made for certain disk drives or testing specific high-speed modes.

 

The XF551 specifically is not particularly interesting to emulate in full mode unless you're testing a custom modded firmware like HyperXF. In stock configuration it's a pretty plain drive supporting SD/ED/DD/DDSD, with no special commands for scanning tracks or doing custom formatting. In fact, the only real thing you get from emulating the actual firmware is accurate emulation of a super annoying bug of the actual hardware where the XF551 refuses to switch densities properly unless you boot off of a double density disk. I've opted not to emulate that behavior in the standard drive emulator's XF551 profile because it's such a pain.

[Docwiz]

The disk drives are all actually little computers, but the Atari drives -- 810, 1050, XF551 -- are all hardcoded. They have a simple set of commands and you can't override or add new ones from the computer. This makes it easy to completely emulate them without the computer being able to tell the difference. Some of the third-party drives or modded drives are different, you can actually load and run programs on them. That's how the Happy copy software works, for instance. No way to handle that without actually running the second computer in the drive, which is what the full drive emulator in Altirra does.

 

By default, Altirra's standard drive emulation is set to Generic profile, which emulates a super drive that is a superset of what most drives can do with regular commands. This supports reading, writing, and formatting of all disk formats and a US Doubler compatible high speed mode. You can change the emulation profile by the drop down at the bottom of the Disk Drives dialog to select a more specific drive to target. For instance, if you choose 810, you'll get 810 drive sounds and speeds, and it won't read anything but a single density (90K) disk. Select 1050, and you get 1050 sounds and timings, and support for enhanced and double density, but no disks bigger than that. And so on. Typically one of the generic modes is best unless you're running a specific DOS made for certain disk drives or testing specific high-speed modes.

 

The XF551 specifically is not particularly interesting to emulate in full mode unless you're testing a custom modded firmware like HyperXF. In stock configuration it's a pretty plain drive supporting SD/ED/DD/DDSD, with no special commands for scanning tracks or doing custom formatting. In fact, the only real thing you get from emulating the actual firmware is accurate emulation of a super annoying bug of the actual hardware where the XF551 refuses to switch densities properly unless you boot off of a double density disk. I've opted not to emulate that behavior in the standard drive emulator's XF551 profile because it's such a pain.

 

Thank you! Great explanation and I got everything running now.

[_The Doctor__]

The persistent density was in theory to accommodate copy protected software to a degree. If the DOS is aware or has a patch in the boot sector, The drive will switch density after the reset is sent, which could be in the boot sector btw... Sparta XF boot patch etc.... For a while no one understood that or even had a DOS that would switch density on boot..They would load single density sparta.. then get a double density directory and then put a double density boot disk in... it would boot they were all happy... next day turn on drive and computer and it wouldn't boot... When finally understood thereafter was a patch and it could then boot every time.

DOSXE also worked and switched densities no problem but booted slow... Never understood why to wait so long to transition to high speed in that version of DOS...

Edited June 28, 2018 by _The Doctor__

[phaeron]

Persistent density is fine. What's dumb is that the XF551 doesn't do density re-detection on boot sectors or on a missing sector error. That guarantees that when the drive is in single density and you stick in a MyDOS-formatted double density disk after already booting DOS that it will fail by repeatedly trying to read sector 361 from track 13, sector 23 in enhanced density mode.

[Docwiz]

Persistent density is fine. What's dumb is that the XF551 doesn't do density re-detection on boot sectors or on a missing sector error. That guarantees that when the drive is in single density and you stick in a MyDOS-formatted double density disk after already booting DOS that it will fail by repeatedly trying to read sector 361 from track 13, sector 23 in enhanced density mode.

 

Well, I didn't know that back in the day when I bought one. ;-p

On a more serious note (as if that's possible), is it possible to have you talk to the guys from Antic Podcast to give an interview?

 

I would love to see some detailed interviews with Atari 8-bit emulator authors to give their perspective on classic Atari computers.

Your emulator is probably the best on any platform, but I would like to hear from you as well as many others doing the hard work.

[+slx]

Unless there are any considerations I'm overlooking, I suggest adding the controller mapping for paddles on a Stelladaptor(-II) according to this thread to the standard mappings.

 

While it's not hard to replicate once you find it, you need to find it first

 

Thanks for this great emulator, phaeron!

[darwinmac]

I would also like to see paddle mapping added as standard in Altirra. I have written documentation on how to create the mapping, but it would be more convenient if it was included.

 

Bob C

Edited June 29, 2018 by darwinmac

[Heaven/TQA]

Avery please check your PM here.... I run into an issue with VBXE...

[Docwiz]

I would also like to see paddle mapping added as standard in Altirra. I have written documentation on how to create the mapping, but it would be more convenient if it was included.

 

Bob C

 

Yes please!

[256 colors]

Is there any chance of a good net-play feature at some point?

I know on the Atari800WinPlus it was possible to do four player games of M.U.L.E with crappy kaillera

[tebe]

where Altirra saves its configuration?

 

i change HighMemory (16MB) -> 4MB, exit from config, enter again, and 16MB is restored

 

p.s.

Altirra 3.10 test 30 (32bit, 64bit)

[Mclaneinc]

Saves cfg to either HKEY_CURRENT_USER\Software\virtualdub.org\Altirra in the registry or if its set to portable its in an altirra.ini in the root where Altirra is..

 

Be careful of having multiple Altirra's open as if you change it in one window, save it and then the other instance of Altirra is open and its not got that change in it then it will save the cfg of the way that version is running at the time. You can just have one version only by going to tools, Options and STARTUP and tick that box..

 

There are other things like temporary profiles that might avoid this but that is a general help...

Edited July 1, 2018 by Mclaneinc

[Keatah]

Try using multiple configs in separate folders. Or assigning a custom-named .ini file in the windows' command prompt or "target" in the shortcut - for simultaneous use.

 

When saving the .ini file, it would save in the folder it ran from, or use the custom-name of the custom .ini file. And each instance would remain separate.

 

The commonality of the two methods is they don't use the registry. Registry is good for only one instance.

 

The difference between the two methods is a matter of personal tastes and organization styles.

Edited July 1, 2018 by Keatah

[_The Doctor__]

ss stated that altirra is saving .car files as .bin can that be confirmed?

load a bin and it saves it with the header attached but still saves as bin when it should be car...

[+DrVenkman]

ss stated that altirra is saving .car files as .bin can that be confirmed?

load a bin and it saves it with the header attached but still saves as bin when it should be car...

 

When you save the cart firmware, it give you the option to save it as a raw cartridge image, or a cartridge image with header. When you choose the "with header" option, Altirra uses the correct .car extension.