Altirra 3.00 released

[phaeron]

Version 3.00 of my emulator Altirra is now out:

 

http://www.virtualdub.org/altirra.html

 

As usual, thanks to everyone providing feedback on its development. 3.00 is the same as 2.99-test25 except for version and date fixups. Here are the highlights since 2.90:

• Accuracy: Illegal 6502 opcode and 65C816 fixes, VBXE fixes and timing improvements, POKEY serial and keyboard fixes, MIDI parsing fixes.
• Cassette: Turbo decoding support, improved FSK decoding, improved OSD, analysis mode for diagnosing raw tape decoding problems, export tapes back to raw audio.
• Debugger: Faster history engine with more powerful loop/call detector, fixes and enhancements to 65C816 and coprocessor debugging.
• Performance Analyzer: New tracing engine enables visualization of CPU, display, serial bus, disk, and tape activity simultaneously. Capture multi-minute traces and easily match glitched frames with CPU activity without trying to catch the bug as it occurs, or trace an entire disk load to diagnose SIO errors. Automatic thread detection identifies idle and interrupt times within a frame to guide optimization.
• Devices: Browser (B:) device, XEL-CF and Rapidus emulation, VBXE core behavior selection.
• Disk: ATX MFM support, IDE identify command improvements, SCSI timing selection support, filesystem parsing fixes.
• UI: Enhanced high DPI support on Windows 10 version 1703 and up (per-monitor V2) so that dialogs now dynamically scale, full-screen fixes and workarounds.

 

As always, per convention, starting the next test release:

http://virtualdub.org/beta/Altirra-3.10-test1.zip

http://virtualdub.org/beta/Altirra-3.10-test1-src.zip

 

• New unified system configuration dialog to reduce menuitis by combining almost all of the system configuration commands into one big paged dialog. This dialog also now has contextual hover-over help for each option. Most of the commands have now been removed from the menu, but the menu commands are still there and can still be key-bound. This includes sub-pages that used to be separate dialogs, like speed options and devices.
• Reorganized menu and keyboard shortcuts to move some commonly used commands from Alt+Shift+key to just Alt+key, particularly disk and system configuration. You'll need to reset keyboard shortcuts to default to see this, or rebind the commands yourself.
• The profiler is now integrated into the performance analyzer. It's not completely finished, but you can now generate a profile view from either a time range or the entire trace. Toolbar has also been redone.
• Command-line help has been cleaned up so it's no longer an unformatted mass of text shoved into a message box. Obsolete switches have been removed and some formerly undocumented switches are now listed. There are now also /d3d9 and /d3d11 switches.
• There is now an FDCWTDATA logging channel to interpret the Write Track data during a format in full disk emulation mode, making it easier to interpret the track layout used by firmware.
• Default sector interleave for disk images has been updated and there is now an option in the Disk Drives dialog to change the interleave on an existing disk image to several common interleave patterns. This allows using accurate sector timing with high-speed operation without having to reformat disks to get them into proper interleave.

 

[jmccorm]

Just a few days ago, I switched from years of running Atari800 to Altirra. Wow, this really is more powerful!

 

I just wanted to give some feedback as an experienced Atari user who was new to the software and the challenges I ran into. This is just feedback. I'll leave it to you to determine if this is something which can be improved on the software side:

 

1. I didn't find an obvious label for the new START/SELECT/OPTION/RESET/TURBO buttons. This is critical for new users. I wish I didn't have to immediately hunt it down in the Help Contents or the Key Bindings. Also was momentarily confused that the F1 turbo button had to be held down (as opposed to a toggle like on Atari800).

 

2. Full screen (the typical ALT-ENTER function) didn't work for me. It'd put a still image in the upper-left corner of the screen. I had to hunt down the obscure option under Tools -> Option -> Display -> Borderless Mode to get it to work properly.

 

3. I hate to say this, because I know it really is a losing argument, but I think the default NTSC color palette was a little off? I say this with at least a minor level of confidence because I was using RastaConverter with its special altirra palette, yet it was off. I ended up trying some of the NTSC color adjustments in Altirra, but only ended up satisfying what I was seeing by putting Hue Start at -20 and Hue Step at 27.3. Yes, I know, Never The Same Color twice, and this isn't a scientific experiment. But I wanted to at least put that out there.

 

4. I was missing random Pokey sounds here and there on 2.90. It sounds good now on 3.00. Thanks! But I'm noticing right now on the MULE intro screen that there was some static on my right speaker and most audio was on the left (expected) but very rarely, a few seconds of music would spill out the right speaker. Obviously, I have stereo sound enabled on the emulator. I don't know if this is weird behavior limited to MULE itself or a new emulator Pokey issue. It might be a race condition? My system is pegged with two RastaConverters running.

 

5. Pokey's randomness really is 100% deterministic? I was playing MULE, I finished my turn, and after all my input was done, I did a manual save state. All within the computer's turn (no input required), soon after, there was a random event that went bad, so I reloaded the save state. The same random event occurred. The only way around it was to change the timing by hitting SPACE to pause and unpause the game. So I figured that the POKEY's randomness was probably deterministic, but you know, from a player's standpoint, I have to enjoy an actual random POKEY like the Atari800 emulator does. I wonder if other people enjoy randomness, too, when they reload from a saved state?

 

6. When I was doing my manual save states and loads, Atari800 was cool in that my last save name was already populated in the box and ready to go. In Altirra, I have to usually remove my hands from the keyboard to use the mouse to point and click at the filename. It'd be nice if that could be streamlined from a user's perspective. Same thing when loading a disk or booting from an image... I wish I could easily do it with my hands remaining on the keyboard. My workaround is SHIFT-TAB SHIFT-TAB to change to the right focus and then navigating to what I want.

 

7. I might have missed it, but I didn't find any documentation on Console.Holdkeys or how I'm supposed to use it (or, in my case, NOT use it when I accidentally enabled it with an unintended keypress).

 

8. That serial audio noise is really authentic. Annoyingly so. Do you really want to make that the default experience?

 

Again, not necessarily bugs, but I wanted to point out some of the new user challenges. Finally, I just wanted to say: nice job on the disk handling, and especially on the Boot Image functionality. That really makes things easier to use! Clearly exceeds Atari800 and I can't fathom the number of edge cases you must have run into in getting things to work so smoothly. Nice job!

[Mclaneinc]

Grr...If you are talking standard SIO noise or the RF version when SIO audio has been disabled by the program but you still get that 'ghost' sio noise then hands off

 

It is authentic and that's why Avery should leave it as a default, not doing so defeats one of the principles of the emulator, that is that its as close to a real machine at turn on as possible. Maybe Avery will off a hacked disable of the SIO or just Poke 65,0 to silence it or $41 with 0..

 

Paul...

 

Avery will of course do what he likes with his emulator but I'd ask him nicely to leave the SIO alone as default, as said before, when I found Altirra (thanks to Carmel) I was won over simply because it made the SIO noise, I could just feel that if Avery carried on the emulator it would be fantastic and luckily he did and it is..

[TwiliteZoner]

Another great release. Thank you sir.

[serj]

thanks, Avery.
A great release and a Christmas gift.

 

guys.
who can explain what happened to the site?

I can not get here by ordinary means.

I had to use anonymizers.

[Mclaneinc]

No problem getting there from here Sergey, perhaps Mr Putin sees Altirra as too decadent

 

Seriously, no isssues getting to Virtualdubg.org here..

[flashjazzcat]

The system configuration dialog is most welcome.

[Sheddy]

Just a few days ago, I switched from years of running Atari800 to Altirra. Wow, this really is more powerful!

 

I just wanted to give some feedback as an experienced Atari user who was new to the software and the challenges I ran into. This is just feedback. I'll leave it to you to determine if this is something which can be improved on the software side:

 

 

4. I was missing random Pokey sounds here and there on 2.90. It sounds good now on 3.00. Thanks! But I'm noticing right now on the MULE intro screen that there was some static on my right speaker and most audio was on the left (expected) but very rarely, a few seconds of music would spill out the right speaker. Obviously, I have stereo sound enabled on the emulator. I don't know if this is weird behavior limited to MULE itself or a new emulator Pokey issue. It might be a race condition? My system is pegged with two RastaConverters running.

 

If you're maxing out all your cores with Rastaconverter, that's not really Altirra's fault! It needs more CPU than atari800 as it is doing a much more accurate emulation. You could try running it at a higher priority than Rastaconverter so it gets more of a look in on the CPU. Edited December 29, 2017 by Sheddy

[jmccorm]

If you're maxing out all your cores with Rastaconverter, that's not really Altirra's fault! It needs more CPU than atari800 as it is doing a much more accurate emulation. You could try running it at a higher priority than Rastaconverter so it gets more of a look in on the CPU.

 

Right! But this feedback may be something that points to an underlying problem like a race condition that causes the phantom drifting of stereo sounds (also perceived as a light and non-Atari "scratching/crackling" sound on just the right channel) when timings aren't met. Those missed timings can happen even when the host system isn't running at 100%, but where it simply ended up with a thread being a victim of the scheduler. So then the author might want to perform fuzz testing with thread timing to see if there is something there. As well, an author may decide that they want for CPU resource starvation to manifest itself in a different way than it currently does, and have the whole emulator slow down instead.

 

The list of items weren't, "OMG Altirra is horrible" or "OMG why is this happening to me." (Altirra is pretty darn good!) As indicated, it was just feedback for the author to critically evaluate and see if there were things worth chasing down or re-evaluating from a user's perspective. Or ignore.

 

EDITED TO ADD: At the risk of taking the explanation too far, quite a number of hard-to-reproduce Firefox bugs were found and squashed through fuzz testing that intentionally mis-scheduled and/or starved individual threads. This suggests that Altirra has the potential to benefit from a similar test method. Additionally, because we're talking about a mod here (stereo POKEY), there probably isn't a well-documented reference to measure the emulator against, so an observational benchmark becomes slightly more valuable than it might first appear. Chasing down an odd condition under starved resources also has the potential to yield a quality improvement under normal conditions, and I know we've got some auditory purists among us that would enjoy that sort of thing.

 

I appreciate you taking the time to read through my detailed self-explanation here.

Edited December 29, 2017 by jmccorm

[evilmoo]

5. Pokey's randomness really is 100% deterministic? I was playing MULE, I finished my turn, and after all my input was done, I did a manual save state. All within the computer's turn (no input required), soon after, there was a random event that went bad, so I reloaded the save state. The same random event occurred. The only way around it was to change the timing by hitting SPACE to pause and unpause the game. So I figured that the POKEY's randomness was probably deterministic, but you know, from a player's standpoint, I have to enjoy an actual random POKEY like the Atari800 emulator does. I wonder if other people enjoy randomness, too, when they reload from a saved state?

 

 

It is deterministic, but it is also time-dependent. Meaning its value depends on WHEN you read it. Unless you made all the same moves at exactly the same time between game plays, you're going to get a different result.

[jmccorm]

 

It is deterministic, but it is also time-dependent. Meaning its value depends on WHEN you read it. Unless you made all the same moves at exactly the same time between game plays, you're going to get a different result.

 

Back in 1999, I was the first to start a public effort to reverse engineer the source code for the Tempest vector-based arcade game. As part of the effort, I discovered that the POKEY emulation team had already documented a situation where Tempest tested for a very specific pattern in POKEY's randomization as part of a hardware-based copy protection test. I documented that into the source.

 

If you're interested, take a look...

AE1F 78:        SEI:imp    Disable IRQ	 ; This is the start of a very
					 ; clever routine for Tempest
					 ; Pokey chip protection. The
					 ; interrupts are disabled to
					 ; preserve timing. From the
					 ; POKEY chip emulator 4.5 --

 ; 4.5: changed the 9/17 bit polynomial formulas such that the
 ; values required for the Tempest Pokey protection will be found.
 ; Tempest expects the upper 4 bits of the RNG to appear in the
 ; lower 4 bits after four cycles, so there has to be a shift
 ; of 1 per cycle (which was not the case before). Bits #6-#13 of
 ; the new RNG give this expected result now, bits #0-7 of the 9 bit
 ; poly.
					

AE20 AD:CA 60   LDA:abs    $60CA	 ; Randomize A register.
AE23 AC:CA 60   LDY:abs    $60CA	 ; Randomize Y register.
AE26 84:29      STY:zp     Zp RAM 0029
AE28 4A:        LSR:accum  
AE29 4A:        LSR:accum  
AE2A 4A:        LSR:accum  
AE2B 4A:        LSR:accum  
AE2C 45:29      EOR:zp     Zp RAM 0029
AE2E 85:29      STA:zp     Zp RAM 0029
AE30 AD:DA 60   LDA:abs    $60DA	 ; Randomize A register.
AE33 AC:DA 60   LDY:abs    $60DA	 ; Randomize Y register.
AE36 58:        CLI:imp    Enable IRQ
AE37 45:29      EOR:zp     Zp RAM 0029
AE39 29:F0      AND:imm    #F0
AE3B 45:29      EOR:zp     Zp RAM 0029
AE3D 85:29      STA:zp     Zp RAM 0029
AE3F 98:        TYA:imp    Y-->A
AE40 0A:        ASL:accum  
AE41 0A:        ASL:accum  
AE42 0A:        ASL:accum  
AE43 0A:        ASL:accum  
AE44 45:29      EOR:zp     Zp RAM 0029
AE46 8D:1F 01   STA:abs    $011F

How randomness plays out in MULE with Altirra's saved states is interesting. In MULE, with only a few exceptions, random events aren't pre-arranged, but are determined as they play out. If you load a game state that doesn't include user input, under Altirra, it is extremely likely to always play out exactly the same way. Here's an example: [mule-1e.zip attached containing "mule-1e.altstate"]

 

Every time you load it, unless you take action, five seconds later, the same plot of land is "randomly" selected for auction. As we both have mentioned, if you change the timing (by hitting the SPACE bar to pause and then again to unpause), the game will then behave differently and usually select a different plot of land.

 

From a technical perspective, yes, this is correct.

 

At the same time, this can violate a user's perception of randomness. Some users might (knowingly or not) want to see an option in Altirra where the POKEY's randomization is not preserved when loading from a saved state, because in some cases, the future will not change. They want to load a game state, try something different, but not understand why they can't. Worth stating again, other people will see the "deterministic randomness" as the proper behavior and even useful for testing purposes. So this was originally mentioned (in less detail) as a soft-sell for an optional opt-in non-authentic behavior.

 

EDIT: Also worth explicitly stating, under the Atari800 emulator, a game restored from that same state would later result in a completely different plot of land being randomly selected each time. That isn't an exact state restoration, but it was more fun. (One could quickly explore multiple "what-if" scenarios with a simple and very quick state reload.) Ultimately, this issue and other issues like the serial audio humming noise are part of the larger tapestry where one set of users wants authentic behavior, and another set of users wants friendly and/or idealized behavior. Something close to the spirit of this is captured in the Streamlined vs Authentic choice in the First Time Setup.

mule-1e.zip

Edited December 29, 2017 by jmccorm

[Sheddy]

 

Right! But this feedback may be something that points to an underlying problem like a race condition that causes the phantom drifting of stereo sounds (also perceived as a light and non-Atari "scratching/crackling" sound on just the right channel) when timings aren't met. Those missed timings can happen even when the host system isn't running at 100%, but where it simply ended up with a thread being a victim of the scheduler. So then the author might want to perform fuzz testing with thread timing to see if there is something there. As well, an author may decide that they want for CPU resource starvation to manifest itself in a different way than it currently does, and have the whole emulator slow down instead.

 

The list of items weren't, "OMG Altirra is horrible" or "OMG why is this happening to me." (Altirra is pretty darn good!) As indicated, it was just feedback for the author to critically evaluate and see if there were things worth chasing down or re-evaluating from a user's perspective. Or ignore.

 

 

EDITED TO ADD: At the risk of taking the explanation too far, quite a number of hard-to-reproduce Firefox bugs were found and squashed through fuzz testing that intentionally mis-scheduled and/or starved individual threads. This suggests that Altirra has the potential to benefit from a similar test method. Additionally, because we're talking about a mod here (stereo POKEY), there probably isn't a well-documented reference to measure the emulator against, so an observational benchmark becomes slightly more valuable than it might first appear. Chasing down an odd condition under starved resources also has the potential to yield a quality improvement under normal conditions, and I know we've got some auditory purists among us that would enjoy that sort of thing.

I appreciate you taking the time to read through my detailed self-explanation here.

Race condition seems unlikely to me, but then again, this is Windows we're talking about. Certainly worth making sure.

[Heaven/TQA]

Re: M.U.L.E.

 

Sure that it should be totally random?

 

http://bringerp.free.fr/RE/Mule/mule_document.html

[jmccorm]

Re: M.U.L.E.

Sure that it should be totally random?

http://bringerp.free.fr/RE/Mule/mule_document.html

 

I should have quoted that document myself! I've combed over that and the disassembled/commented source code quite a few times. I've also had fun with direct memory manipulation in MULE. (Money cheats and map manipulation are easy and fun.)

 

If we're totally evaluating it at a purely logical level, and talking about abstract gameplay in general, then no, it isn't totally random. It is conditionally random! That guy has really done a great job of converting the code back into a set of human-readable rules and conditions.

 

In the context of restoring a saved state mid-game and seeing what happens next, the calculation of the random event (which parcel to select for auction) is something that happens after the provided saved state file is loaded, and not before (the saved state does not contain anything which specifically selects the parcel which is about to be auctioned five seconds later).^{*-See note below.}

 

This is demonstrated by arranging a similar set of circumstances in the Atari800 emulator. This is also demonstrated under Altirra by loading the save state and hitting the space bar twice (in order to take advantage of the pause/un-pause feature built into MULE, while the POKEY continues every CPU cycle to update the register which is later used by MULE's auction and parcel selection decision). So only when we halt the game so the POKEY can run for some additional cycles, we see a different outcome unfold. Otherwise, we don't get a uniquely random event after the restored state. (There could also be other rare exceptions like an interrupt coming in, and I am assuming that we're sticking with NTSC timing, but the general rule holds true.)

 

EDIT: Slightly related, earlier I mentioned having fun with memory manipulation in a live game of MULE. Here are some of my quick (inexact and incomplete) notes on that, if anyone is interested.

 

.

INTERESTING MULE IN-GAME MEMORY LOCATIONS:

b000 - [to B000 + 45] Owner of each map square [player 0-3, FF=unowned or store]

b328 - Order of player 1 [0-3]  [human if single player]  00 = first [weakest], 03 = last [strongest]
b329 - Order of player 2 [0-3]
b32a - Order of player 3 [0-3]
b32b - Order of player 4 [0-3]

b212 - # of food in the store
b213 - # of energy in the store
b214 - # of smithore in the store
b215 - [ # of crystite in the store ]
b216 - # of mules in the store

b2c0 - money [from a single live player game]
b444 - also money [from a single live player game]
0091 - number of properties currently up for auction [while inside an auction]
00D3 - Map time left on timer

.

 

* - If someone wanted to be very literal, they could argue that the saved state DOES contain which parcel will be selected, but only indirectly and not as part of the game's variables, because preserving and restoring the POKEY's state acts as a stored seed for randomization. That's ultimately the issue at hand: the conflict between an exact technical behavior being correct while at the same time violating a user's perception and/or expectation of random behavior. Or potentially the programmer's intent on the exact moment a random decision would be locked-in.

 

It could also be that the Atari800 emulator saves and restores the POKEY's state just like Altirra, and the POKEY emulation is perfect, yet Atari800's emulation never manages to deliver a consistent number of CPU cycles before the random number is pulled from the POKEY, so that is what makes the parcel selection decision random and matching a user's expectation of randomness.

 

This perception is unique because in the real-world, next to nobody has been exposed to an exact system state restoration. The model which most human minds will pull in is of loading a saved game state (which is different, but that's where the brain goes). That then creates the expectation that if the game is programmed for something random to be determined then and there, that something different and random will actually happen as if they loaded from a game's save point.

Edited December 29, 2017 by jmccorm

[+slx]

Thanks for this Christmas present!

 

Can Altirra load >10K Firmware / OS for 400/800 emulation? I am trying to test the attached 16K OS file consisting of 4K Omnimon 800, 2K of empty space, 2K of Fastchip and 8K of Newell OS N. While all of this runs perfectly in XL mode and a 10K file with Fastchip and OS N only runs in 400/800 mode, the 16K firmware is apparently not loaded at C000 in 400/800 modes. There is an "option" field in the firmware definition dialog but it is not accessible.

 

 

16K Firmware with Omnimon 800, Fastchip and OS N: OSNFastOmni.bin

 

10K Firmware with Fastchip and OS N: OSNFast.bin

 

 

[jmccorm]

3. I hate to say this, because I know it really is a losing argument, but I think the default NTSC color palette was a little off? I say this with at least a minor level of confidence because I was using RastaConverter with its special altirra palette, yet it was off. I ended up trying some of the NTSC color adjustments in Altirra, but only ended up satisfying what I was seeing by putting Hue Start at -20 and Hue Step at 27.3. Yes, I know, Never The Same Color twice, and this isn't a scientific experiment. But I wanted to at least put that out there.

 

This post contains the full details of how I arrived at those tweaks to the Altirra 2.80 NTSC default palette. I've provided this so that you can judge for yourself if this is a valid issue or something else is going on.

 

As I was working on this, I noticed that an option was missing. Once I've set my default palette, I'm able to export and save it. Cool! Then I played around with a few other settings, decided to go back to what I had set, and... wait a second. It doesn't offer an option for me to save my settings as a preset? I mean, I can use that same screen to select one of the other presets, but to get back to where I was, I have to load the closest preset, and then alter the settings by hand in the System -> Video -> Adjust Colors options.

 

Maybe I'm missing something.

 

EDIT: It may just be that the most recent copy of RastaConverter is bundled with the older Altirra 2.50 NTSC palette, and so it generates an image with slightly wrong colors? When I set Altirra to use its 2.50 NTSC palette, it still is a little off (particularly in the blues/greens) and is far less saturated, but closer than viewing it in Altirra with its default 2.80 NTSC palette.

 

EDIT2: Nope. I exported the Altirra 2.80 NTSC palette and told RastaConverter to use it. It was even worse. One of these two programs seems to have a palette problem? Oddly enough, the Atari800 emulator got it right without any adjustments needed.

Edited December 29, 2017 by jmccorm

[phaeron]

1. I didn't find an obvious label for the new START/SELECT/OPTION/RESET/TURBO buttons. This is critical for new users. I wish I didn't have to immediately hunt it down in the Help Contents or the Key Bindings. Also was momentarily confused that the F1 turbo button had to be held down (as opposed to a toggle like on Atari800).

Cold and Warm Reset are on the system menu with F5 and Shift+F5. That's not enough?

 

As for the rest, they aren't on the menu because they don't have useful menu options, and I don't want to pollute the menu with commands that aren't usable as menu options. The help file already explains the keyboard layout; I'm not going to add neon signs for users that can't get even that.

 

2. Full screen (the typical ALT-ENTER function) didn't work for me. It'd put a still image in the upper-left corner of the screen. I had to hunt down the obscure option under Tools -> Option -> Display -> Borderless Mode to get it to work properly.

What version of Windows and emulator were you using (I assume 3.00 for the latter)?

 

3. I hate to say this, because I know it really is a losing argument, but I think the default NTSC color palette was a little off? I say this with at least a minor level of confidence because I was using RastaConverter with its special altirra palette, yet it was off. I ended up trying some of the NTSC color adjustments in Altirra, but only ended up satisfying what I was seeing by putting Hue Start at -20 and Hue Step at 27.3. Yes, I know, Never The Same Color twice, and this isn't a scientific experiment. But I wanted to at least put that out there.

 

Beating a dead horse, I'm afraid. Altirra's default is tuned for an average system on a modern monitor so that anything you make in the emulator in NTSC has a reasonable chance of looking similar on actual hardware as others will see it. Older displays deviate from this but aren't consistent, so there is a separate profile for the relatively popular 1702 monitor and beyond that you can tune it. Various people have written huge polemics about how their favorite game doesn't display the right colors according to some anecdotal memory from 30 years ago and that's not enough to set global defaults.

 

4. I was missing random Pokey sounds here and there on 2.90. It sounds good now on 3.00. Thanks! But I'm noticing right now on the MULE intro screen that there was some static on my right speaker and most audio was on the left (expected) but very rarely, a few seconds of music would spill out the right speaker. Obviously, I have stereo sound enabled on the emulator. I don't know if this is weird behavior limited to MULE itself or a new emulator Pokey issue. It might be a race condition? My system is pegged with two RastaConverters running.

That's a ridiculous case, sorry. Altirra needs to keep latency down for responsiveness and it can't do that reasonably in an environment where you have the CPU loaded down with two other CPU-heavy processes. Once CPU contention gets so high that audio buffers underflow and wrap getting artifacts like this isn't surprising, nor would addressing that issue really help since the audio stream is already broken anyway. Best I can suggest is to increase the audio buffering in audio options.

 

5. Pokey's randomness really is 100% deterministic? I was playing MULE, I finished my turn, and after all my input was done, I did a manual save state. All within the computer's turn (no input required), soon after, there was a random event that went bad, so I reloaded the save state. The same random event occurred. The only way around it was to change the timing by hitting SPACE to pause and unpause the game. So I figured that the POKEY's randomness was probably deterministic, but you know, from a player's standpoint, I have to enjoy an actual random POKEY like the Atari800 emulator does. I wonder if other people enjoy randomness, too, when they reload from a saved state?

Yes, POKEY's random number generator is 100% deterministic in the number of cycles passed since it was last reset.

 

6. When I was doing my manual save states and loads, Atari800 was cool in that my last save name was already populated in the box and ready to go. In Altirra, I have to usually remove my hands from the keyboard to use the mouse to point and click at the filename. It'd be nice if that could be streamlined from a user's perspective. Same thing when loading a disk or booting from an image... I wish I could easily do it with my hands remaining on the keyboard. My workaround is SHIFT-TAB SHIFT-TAB to change to the right focus and then navigating to what I want.

I'm not sure what you mean, since Altirra already populates file dialogs with the filename you last used it with....

 

7. I might have missed it, but I didn't find any documentation on Console.Holdkeys or how I'm supposed to use it (or, in my case, NOT use it when I accidentally enabled it with an unintended keypress).

It says "press keys to hold on next reset" on screen when you use it, so it already explains what to do, and activating it again clears it.

 

8. That serial audio noise is really authentic. Annoyingly so. Do you really want to make that the default experience?

 

Altirra's purpose is to emulate the actual behavior of the actual computer. Ataris beep during disk loads. If you find that annoying, then either turn on the disk patch so the load completes as fast as possible or go emulate another computer instead.

 

Right! But this feedback may be something that points to an underlying problem like a race condition that causes the phantom drifting of stereo sounds (also perceived as a light and non-Atari "scratching/crackling" sound on just the right channel) when timings aren't met. Those missed timings can happen even when the host system isn't running at 100%, but where it simply ended up with a thread being a victim of the scheduler. So then the author might want to perform fuzz testing with thread timing to see if there is something there. As well, an author may decide that they want for CPU resource starvation to manifest itself in a different way than it currently does, and have the whole emulator slow down instead.

 

Sorry, don't care about audio artifact issues when the system is running under ridiculous load like that, and slowing down the emulator would be even worse.

 

At the same time, this can violate a user's perception of randomness. Some users might (knowingly or not) want to see an option in Altirra where the POKEY's randomization is not preserved when loading from a saved state, because in some cases, the future will not change. They want to load a game state, try something different, but not understand why they can't. Worth stating again, other people will see the "deterministic randomness" as the proper behavior and even useful for testing purposes. So this was originally mentioned (in less detail) as a soft-sell for an optional opt-in non-authentic behavior.

No. This would deliberately break defined hardware behavior to change game behavior, which I am not going to add as a default option. Altirra emulates the computer. If someone wants that behavior, they can make a MULE emulator.

[jmccorm]

No.

 

Smackdown! 0 for 8!

Hey, I do at least appreciate the quick response.

 

Regarding the full-screen issue, you're right. Gone in 3.00 under Windows.

Edited December 29, 2017 by jmccorm

[Keatah]

Does the new menu structure require less keystrokes (or mouse actions) to navigate it?

[tschak909]

ok, somehow I missed it, what is the B: (browser) device?

 

-Thom

[Mclaneinc]

Altirra's purpose is to emulate the actual behavior of the actual computer. Ataris beep during disk loads. If you find that annoying, then either turn on the disk patch so the load completes as fast as possible or go emulate another computer instead.

 

 

:thumbsup:

 

As much as I detest emoticons they serve my purpose this time.....Thank you Grand Jedi for keeping the Force strong...

 

 

 

[+DrVenkman]

ok, somehow I missed it, what is the B: (browser) device?

 

-Thom

 

That's a good question. More importantly, how do you use it?

 

[evilmoo]

 

That's a good question. More importantly, how do you use it?

10 OPEN #1,8,0,"B:"
20 PRINT #1;"http://www.google.com/"
30 CLOSE #1

Maybe?

[+DrVenkman]

10 OPEN #1,8,0,"B:"
20 PRINT #1;"http://www.google.com/"
30 CLOSE #1

Maybe?

 

 

Heh. It opens a browser on the host computer ... Fun.

[+DrVenkman]

The system configuration dialog is most welcome.

 

AMEN! I love the functionality and accuracy of Altirra's emulation and all the devices that can virtually added to the system to better emulate everyone's unique combination of hardware, but the menu system could be difficult to navigate at times. The "one stop shop" for everything is exceedingly handy.

 

Thanks, Avery!