Altirra 2.60 released

[phaeron]

Help+Reset entry into new Ultimate BIOS appears broken.

 

Thought I had that sorted. Try now:

http://www.virtualdub.org/beta/Altirra-2.70-test25.zip

http://www.virtualdub.org/beta/Altirra-2.70-test25-src.zip

 

Originally I had planned to just make raw mode do the full keyboard scan, but that turned out to be too annoyingly slow (you can outtype POKEY's keyboard scan!). Therefore, the raw mode cheats a little bit and triggers keyboard interrupts immediately without waiting for scan delays. The downside is that sometimes all these little fibs are contradictory, like when you have a key that doesn't require Shift on the host keyboard mapped to one on the Atari keyboard that does.

 

Saying truth, this was the reason for me to download the new version, as I wanted to remap the F-keys in a way that I find more convenient (i.e. F1 = F1, F2 = F2, F3 = F3, F4 = F4, F5 = HELP, F6 = START, F7 = SELECT, F8 = OPTION and F12 = RESET). But remapping the Reset key does not seem possible, unless I am missing something.

 

Reset, along with the rest of the function keys, are mapped in Tools > Keyboard Shortcuts instead. It's a bit weird, but the Atari keyboard by itself was too big to just throw into the same mix.

 

today I encountered a somehow strange DIR behaviour or incompatibility of the DIR command between TB XL and Altirra Basic.

 

TurboBasic XL uses different token values than Basic XL/XE for extended commands, so even though the DIR commands look the same, they are only source compatible and not binary compatible. Since Altirra BASIC uses the Basic XL/XE token values, this means bad things will happen if you exchange .BAS files with extended commands between it and TBXL.

 

[everklear]

• Input: The entire keyboard mapping is now customizable in Input > Keyboard, including the previously hardcoded F2/F3/F4/F6 bindings. Note that it's a lot of work to rebind the whole keyboard, but there is an Import/Export option to make this a bit easier to deal with once you get a setup you like. The default keyboards use a mix of virtual key and character bindings so as to not end up completely scrambled on a non-US-English keyboard, but using virtual keys for everything is fine if you only have one keyboard layout.

Noooooooooooo!

I just finished playing through Ultima III about a week ago with the ever so awkward (and yet manageable) ] / ' \ key combination.

 

But seriously, that's a great feature, thanks for all the work you put in.

[everklear]

Many (if not most) of the times when I change the focus from Altirra to any other program and then return to it about an hour later (more or less), the display remains freezed, but it is posible to hear the keyclicks if type something. To solve this problem, I only need to minimize the window and immediately restore it... then the screen is refreshed and the typed letters are visible.

I've observed this too. Another workaround is to pause/unpause with F9.

[flashjazzcat]

Thought I had that sorted. Try now...

All good by the looks of it. Thanks!

[drac030]

Reset, along with the rest of the function keys, are mapped in Tools > Keyboard Shortcuts instead. It's a bit weird, but the Atari keyboard by itself was too big to just throw into the same mix.

 

This worked indeed, thanks.

[phaeron]

Think I found the cause of the display jams -- try this version:

http://www.virtualdub.org/beta/Altirra-2.70-test26.zip

http://www.virtualdub.org/beta/Altirra-2.70-test26-src.zip

 

One fix specific to D3D9, one not. Using 3D APIs to draw 2D is such a pain....

[Keatah]

Can someone point out a game that needs this feature enabled?

 

Non-linear Mixing:

Emulates the effective mixing curve of the hardware, which causes the output of two voices to be lower than the sum of their volume levels. This is needed for some effects and also causes some compression of the output.

 

I seem to have a louder more harsh sound with it enabled, and was wondering if it is toggling on-off correctly. When disabled it seems to produce a slightly smoother sounding sound, softer in volume, less harsh.

 

Note, this is not specific to any one version. But rather an observation and tweaking question.

[Farb]

Hi Phaeron,

 

I didn't see this asked before in this thread so -- any chance of implementing copy protection dongle support for original titles like Leader Board and Paperclip?

 

Here is some info on the Leader Board one:

 

http://atariage.com/forums/topic/179125-leaderboard-for-atari-8-bit/page-1?do=findComment&comment=2239981

[Kyle22]

It may be as simple as adding a new selection under Input -> Portx -> Dongle -> pot value and Input -> Portx -> Dongle -> stick value. Possibly have some presets for known values, with the option of allowing the user to enter their own values for unknown dongles.

[Keatah]

What about when the program sends different signals to the dongle? You still have to simulate the logic in the dongle.

[fujidude]

How many dongles were there anyway? I seem to remember one with I think Batteries Included Paperclip. Maybe it was something else. What programs used dongles?

[Kyle22]

What about when the program sends different signals to the dongle? You still have to simulate the logic in the dongle.

Well, if a program sends signals to the dongle, it's usually simple. Some of the more recent parallel port dongles for the IBM / Windows machines were very complicated, but I have never seen anything that bad on the Atari8.

 

Maybe a simple "dongle definition file" or similar to describe the logic in the dongle... It wouldn't be too difficult to make a program that sends all possible values from the PIA to the dongle, and reads the PIA and pot inputs back again and notes the changes (if any) for the particular dongle.

 

In other words, send it all possible combinations of input, and read all possible combinations of output.

Edited September 11, 2015 by Kyle22

[fujidude]

If there aren't that many dongle titles out there, it might be easier to just crack the software to not need the dongle. In fact, I bet that has already been done.

[phaeron]

Can someone point out a game that needs this feature enabled?

 

Non-linear Mixing:

Emulates the effective mixing curve of the hardware, which causes the output of two voices to be lower than the sum of their volume levels. This is needed for some effects and also causes some compression of the output.

 

I seem to have a louder more harsh sound with it enabled, and was wondering if it is toggling on-off correctly. When disabled it seems to produce a slightly smoother sounding sound, softer in volume, less harsh.

 

No games that I know of, but some demos will lose particular music effects without it, and digi-sounds in development may sound clearer than they should. The sound output will be cleaner without it because the output will be linear, but POKEY's output is not linear -- it saturates when the volume levels are high.

 

The emulation of this is still imperfect though as the actual behavior on the device has a frequency-dependent component that is not emulated. Electrical Engineer I am not....

 

I didn't see this asked before in this thread so -- any chance of implementing copy protection dongle support for original titles like Leader Board and Paperclip?

 

Not too difficult, although currently Devices can't access all of the joystick port inputs. I'm not sure it's a good idea to have a "Paperclip dongle" device, though. Probably not in the cards unless enough dongles are out there to make a more generic dongle device useful.

 

Amusingly, this particular one looks like it could be defeated by an Amiga mouse just in just the right position on the desk.

Edited September 11, 2015 by phaeron

[+CyranoJ]

Pretty sure Leader Board's dongle just held down two opposing directions on the joystick. Think it was LEFT+RIGHT, but it was a long time ago.

Edited September 11, 2015 by CyranoJ

[Farb]

Probably not in the cards unless enough dongles are out there to make a more generic dongle device useful.

 

Thus far I'm only aware of Paperclip and Leader Board. I saw references to a HomePak one but the user manual doesn't mention it.

Edited September 11, 2015 by Farb

[+rdemming]

I didn't see this asked before in this thread so -- any chance of implementing copy protection dongle support for original titles like Leader Board and Paperclip?

 

Speaking of copy protection, it would be cool to have a LensLok emulator build-in into Altira as well. There is already a stand-alone LensLok emulator (includes the source for inspiration ) but starting an extra program and drawing a bounding box around the graphics pattern is still a pain (filtering and scaling influence the readability). When integrated I suppose Altira must be able to find the graphics pattern automatically and decode it instantaneously.

 

I think there are only three (or five if you count the trilogy as three) Atari games that use LensLok (Jewels of Darkness Trilogy, Price of Magic and Fighter Pilot) so it won't be used much. But since I couldn't find any cracked versions of Jewels of Darkness and Price of Magic it would actually be a useful feature

 

Robert

 

 

P.S. Many thanks to Phaeron for creating and actively maintaining Altira

[Farb]

 

I think there are only three (or five if you count the trilogy as three) Atari games that use LensLok (Jewels of Darkness Trilogy, Price of Magic and Fighter Pilot) so it won't be used much. But since I couldn't find any cracked versions of Jewels of Darkness and Price of Magic it would actually be a useful feature

 

I'm sorry if this is straying too far off-topic but I just dumped an original Jewels of Darkness disk recently and didn't see any LensLok protection. It's in the preservation torrent if you want to check it out.

[+rdemming]

 

I'm sorry if this is straying too far off-topic but I just dumped an original Jewels of Darkness disk recently and didn't see any LensLok protection. It's in the preservation torrent if you want to check it out.

 

The version I pointed to on AtariMania has the LensLok protection in place. Did you try to type "RESTORE"? It won't ask for the LensLok when starting the game but it will when you try to load a saved game.

I will try the version in the preservation torrent later this weekend.

 

Robert

[Roydea6]

 

SDX44X FIND command causes a recoverable crash.

 

[flashjazzcat]

Capture.PNG

 

SDX44X FIND command causes a recoverable crash.

That's not an emulator crash, but a software crash and suggests an issue with SDX or some resident driver. Appears to have crashed while reading the SIDE HDD, in fact, so if you can send your set up over or open the debugger and see at which point the crash occurred it'd be super helpful.

[serj]

Avery, you're doing a excellent emulator altirra 7 years.

let me ask.
In your opinion, how accurate in percentage emulated Atari and its components (ANTIC, GTIA, POKEY, CPU) ?

very interesting to learn.

Edited September 11, 2015 by serj

[Roydea6]

That's not an emulator crash, but a software crash and suggests an issue with SDX or some resident driver. Appears to have crashed while reading the SIDE HDD, in fact, so if you can send your set up over or open the debugger and see at which point the crash occurred it'd be super helpful.

But, this does not happen on real hardware and not remembered on previous [EMU] tests.

 

And I have never use the debugger before and just now tried and failed.

[phaeron]

In your opinion, how accurate in percentage emulated Atari and its components (ANTIC, GTIA, POKEY, CPU) ?

 

It's hard to say, because percentages imply something quantifiable. Emulation accuracy is hard to quantify. That having been said:

 

CPU:

Excellent, haven't seen a CPU emulation related failure in a long time. Some behaviors of unstable instructions may not be emulated faithfully, but that tends not to be an issue because coders necessarily avoid unstable instructions. I suspect there may be some very corner case interrupt timing issues remaining. The NES emulation authors have done some interesting research into this -- I tested and emulated correct CLI+SEI and CLI+RTI timing a while ago, but there are some other combinations not tested. 65C816 is less well tested, but I've improved it significantly since being able to test on the Veronica cartridge. The SNES emulation folks have done some very deep investigations of 65C816 behavior as well, but their analyses tend to be a bit harder to find and more related to the screwy multi-clock environment of the SNES.

 

ANTIC:

Excellent. Haven't seen an ANTIC-related issue in a whlie, but I do know of some corner cases that break under Altirra. Abnormal playfield DMA patterns are very close but can differ from real hardware, and the emulator cheats on WSYNC in a way that's detectable in bizarre circumstances (playfield DMA aimed at undriven address).

 

GTIA:

Very good. The main issue here is there are roughly two kinds of systems out there with regard to GTIA behavior with certain kinds of mid-screen changes, particularly PRIOR-based. Altirra emulates one mode ("XL") but not the other ("XE"). The difference here is that unlike the ANTIC issues, for which I might be the only one who has noticed, these GTIA issues have been hit in the wild and burned coders that only tested on one kind of machine.

 

POKEY:

Good. Timing and noise patterns are generally highly accurate, but two-tone and two-tone mode have some corner case timing issues I haven't tracked down. In particular, I've seen cases where using the low timer of a 16-bit pair can be off by one cycle compared to real hardware, which results in glitching or lack of glitching when playing PWM audio. The analog output path is also poorly understood and modeled. Also, POTs are undermodeled... I just found out that at least on my 800XL, the pot counters can count to 229 instead of 228 with fast pot scan enabled. Yay.

 

PIA:

Excellent. Recent versions fully support PIA interrupts, which was the last part generally neglected (it didn't matter anyway without supporting device emulation like 1030 / BlackBox / R-Verter). The bleeding-edge test versions even emulate floating pins on port B, which is basically useless but I threw in there for completeness. Pulse modes may be inaccurate but I'm not sure there's any way it can matter with the currently emulated devices.

 

Memory:

Excellent. Not that there's much to be missing here in the first place, but Altirra supports both accurate floating bus emulation and power-up memory patterns, which actually do matter. A few copy protected games will not boot without the former, and lack of emulation of the latter has burnt a few demo coders (y'all need to stop reading uninitialized memory). Occasionally I find a few oddball cases where the memory mapping is not quite correct, usually involving the CCTL area in $D5xx -- R-Time 8 didn't float high bits properly for a while, and U1MB + SIDE overlap wasn't emulated at first.

 

AFAIK there isn't an emulator currently that supports one of the aliased memory configurations, where one of the extended bank settings aliases against main memory. Haven't seen anyone missing this yet (it's kind of a lame hardware design anyway).

 

Disk:

Good. Remaining issues with higher-density disks and DOSes have been ironed out and timing is closer than it was. (At one point I was comparing an audio recording of Jenny of the Prairie booting on a real 1050 against the emulator.) The main area that's missing here is accurate emulation of enhanced disk drives like the Happy 810. Atari emulators get away with high-level emulation of disk drives because none of Atari's drives allow code uploads, which meant that the 8-bit had none of the crazy stuff seen on the C64's 1541, or even on the Atari ST. Still, I don't know of a 8-bit emulator that actually allows running custom drive firmware code. Also, with the recent preservation efforts we're uncovering disks again that we currently have no way to emulate.

 

Tape:

OK. Reading is reasonably accurate, although no turbo currently. Writing is not supported. It's difficult to get excited about emulating something that takes 10 minutes to test, generates megabytes of diagnostic data per run, and sounds like nails on a chalkboard.

 

Input:

OK. The emulator supports a good collection of controllers, but PC inputs don't always translate well to 8-bit inputs and there's a lot of room for improvement. In particular, PCs don't have a good rotary input that's satisfactory for emulating a paddle -- analog sticks are still pretty poor at it, even with the tweaks I tried recently. Paddle noise is also absent -- it's not enough to convey in words how annoying that was. Unfortunately, the paddles I fished out of my box of 2600 crap aren't just noisy, they're actually bad (huge dead spots in the pots), so they're not a good reference.

 

Video:

Good. At least with my own emulator I was able to get my pet peeves addressed, which is that, no, not every Atari in the world is PAL and, no, NTSC pixels are not square. NTSC high artifacting is competitive at this point but PAL high artifacting needs another pass. Accurate monitor rendering isn't supported, but honestly, I don't remember TVs being that bad (or maybe our TV was good and I sat farther back). Latency is still a problem but low-latency rendering with 3D APIs is also an exercise in utter frustration.

 

Devices:

Good. Those with a modem or serial port fetish should be mostly good by now, although as some have pointed out, there's a conspicuous absence of printers and plotters.

 

But, this does not happen on real hardware and not remembered on previous [EMU] tests.

 

And I have never use the debugger before and just now tried and failed.

 

Can you help by narrowing down the setup a bit, such as seeing what earlier version of the emulator did work, or simplifying the config.sys and system configuration? For the latter, I would try knocking the memory config down to 64K stock in the U1MB BIOS, as we've seen some issues with extended memory and specific SDX tools. There's not much for anyone to go on in that screenshot since we can't even see the full command that was run. As fjc noted, this is a crash within the emulation, so tracking down the ultimate cause has to start from the software side and could be on that side. Failures to reproduce on real hardware aren't necessarily definitive, especially when uninitialized extended memory or timing are in play.

[flashjazzcat]

Think I found the cause of the display jams -- try this version:

http://www.virtualdub.org/beta/Altirra-2.70-test26.zip

http://www.virtualdub.org/beta/Altirra-2.70-test26-src.zip

 

One fix specific to D3D9, one not. Using 3D APIs to draw 2D is such a pain....

Left Altirra open for several hours on the Windows machine while I was doing other stuff (having reverted back to D3D9 in display options) and didn't notice the display going white at all.