Altirra 2.90 released

[Keatah]

In comparison, I tried Altirra on a Pentium-M 735 2003/2004 era and it showed 35-40% CPU usage in full-screen. Isn't that nice?

[phaeron]

CPU % by itself doesn't mean much these days as you need to qualify it by how fast the CPU is running -- all modern CPUs downclock whenever they can to save power. That having been said, the CPU in that Lenovo is an Atom (Airmont, to be precise), so that level of CPU usage isn't unusual for the emulator.

 

The stats on that Lenovo are overall pretty terrible, particularly the storage. 32GB is really, really tight for Windows. But what's most interesting to me is that it's a $150 laptop that only weighs 3.15 lbs. I didn't realize that dirt-cheap laptops had gotten that light. My secondary laptop is a 2.7 lb. Dell XPS 13 and I've been spoiled by its lightness.

 

The Pentium M was a great CPU when it came out but these days is a bit long in the tooth; realistic minspec these days is about a Core 2. Even Atoms are in some ways more capable than the Pentium M, since they support a higher ISA level (SSSE3, to be precise, allowing for the infinitely abusable PSHUFB). 30-40% CPU usage is generally higher than you want to be running the emulator at if you can help it; above that you can expect issues with missing vsync lock in windowed mode.

[Keatah]

FWIW:

 

Scanlines cost about 20% on the Pentium-M 735. If I turn them off and lock the clock at 1.7GHz, I can get full-screen CPU utilization down to 15%, sometimes it ticks to 18%. And that's with shitbox integrated Intel "Extreme Graphics 2".

 

If I downclock it to 600 MHz usage goes to about 50%.

 

Left to autothrottle on its own it settles in around 1GHz and 35% usage.

 

All in all I've been rather impressed with this CPU over the years. And it undervolts remarkably well for like-modern-day battery life. From what I understand, the Core2 architecture comes from the Pentium III, as does the Pentium-M. The only thing that's artificially shortening this processor's useful life is the dated instruction set and the legacy motherboard to which it is plugged into.

Edited September 2, 2017 by Keatah

[+MrFish]

All in all I've been rather impressed with this CPU over the years. And it undervolts remarkably well for like-modern-day battery life. From what I understand, the Core2 architecture comes from the Pentium III, as does the Pentium-M. The only thing that's artificially shortening this processor's useful life is the dated instruction set and the legacy motherboard to which it is plugged into.

 

And the fact that it's only a single core processor.

[ClausB]

This Lenovo has 64GB flash. It was on sale at BB a few weeks ago. It's good enough for Altirra and Stellarium and YouTube.

 

Edit: ... and AtariAge.

Edited September 2, 2017 by ClausB

[+DrVenkman]

My Core i7 laptop runs Star Raiders in Altirra full-screen (with high quality NTSC artifacting and scanlines) at about 5.8% CPU usage. Of course my CPU is just piddling along about 1.8 Ghz (it can clock to 3.9GHz without tweaking the BIOS) and it's using the integrated Intel HD graphics processor, rather than the GTX1070.

 

Anyway, I have never really used Altirra full-screen before, certainly not on this machine. It flat-out does not work with Direct3D 9. I had to enable Direct3D 11 to get it to work. Interestingly, if I enable OpenGL only, I can do full-screen with scanlines and CPU usage drops to about 4.5%.

 

Thanks, Avery.

[Madi]

Hi phaeron

 

The Cave Runner game (cassette) does not load in Altirra x64 2.99 test 1 to 7.

The game loads and runs normally on Altirra x64 2.90 test 35 and earlier.

It looks a if the "Turbo Enabled" option is always on even if it is not selected.

 

 

Caverunner(1983)(English Software)(UK).zip

 

madi

[Mclaneinc]

From listening to it I don't know how it works?

 

The load sound is dropping out all over the place, did you make this cas image yourself as I've never seen a dump anywhere as a .cas

 

I've just thrown loads of cas files at Altirra and all load and sound like they should..

 

Just tried Altirra 2.90 beta 34 and it does not work for me, reset the settings and everything...

 

Have you been sniffing your socks again?

Edited September 3, 2017 by Mclaneinc

[Madi]

From listening to it I don't know how it works?

 

The load sound is dropping out all over the place, did you make this cas image yourself as I've never seen a dump anywhere as a .cas

 

I've just thrown loads of cas files at Altirra and all load and sound like they should..

 

Just tried Altirra 2.90 beta 34 and it does not work for me, reset the settings and everything...

 

Have you been sniffing your socks again?

The Cassette game image was kindly provided by Fred_M :

Link: http://atariage.com/forums/topic/265012-help-to-get-atarimuseumnl-software-collection-available-to-the-community/page-4?do=findComment&comment=3838562

 

The Turbo Enabled function was introduced in Altirra v2,99 release as you are aware.

Basic has to be enabled to run the game. Although the publisher requested that it should be only run under 400-800 computers, I ran it successfully under XL OS with built-in Basic is enabled under Altirra x64, v2.90 test 35.

For some reason, the Cassette boot record interfere with loading under Altirra x64 v2.99 test 1 and upward releases (turbo code?).

 

Of course, there is a working around to this. After the cas first record is loaded, quickly press RESET and type CLOAD. Pressing F1 key, will accelerate loading. Once the READY prompt shows, just type RUN. The game will load data and then run normally.

 

Oh, Mclaneinc I am too old for that.

 

madi

[Mclaneinc]

Ah, I missed the BASIC, so yes it does indeed load on older versions, my apologies..

 

I'm sure its an easy fix for Avery (well I hope it is), I'd bet he's beavering away at emulating that loader from a few posts back....But take that as a wild guess on my part, I have no idea what he really is doing, he's a busy guy...

Edited September 3, 2017 by Mclaneinc

[drac030]

Could you upgrade to test-7? It has additional info in the .vbxe command output that will indicate when the emulator thinks that the blit will end. I'm betting that this value is off by a large amount and would like an example of what that is.

 

It also has some stability improvements to the history view that you'll want, though it won't affect the situation you ran into (trace too long).

You are right. It happened again, the blitlist was this:

 

$7E08D:
  Source: $00000 Xinc=+0 Yinc=+0
  Dest:   $7EC01 Xinc=+2 Yinc=+160
  Size:   80 x 24
  Masks:  AND=$00, XOR=$05, COLL=$00
  Zoom:   1 x 1
  Patt:   disabled
  Mode:   0 (Copy)

This looks like a CLS. The .vbxe output:

 

XDL enabled:       No
XDL active:        No
XDL base address:  $7E140
XDL fetch address: $7E140
Overlay width:     Normal
Overlay mode:      Disabled
Overlay address:   $00000
Overlay step:      $000
Overlay priority:  $FF | 00 00 00 00
MEMAC Window A:    $00 | $0000-$0FFF -> $00000 - Disabled
MEMAC Window B:    $9F | $7C000 - CPU only
Blitter IRQ:       disabled, asserted
Blitter status:    active (0 rows left) (stopping in 894027186 cycles)
Blitter list addr: $7E08D
Blitter list cur.: $7E0A2

To be sure, I waited the indicated number of cycles (it is something like 8 minutes, 40 seconds) and after that time the system resumed the operation.

 

When it crashed, some 6-7 seconds elapsed before I hit F8. If I can guess something, the counter may start from a value like $36000000.

 

Some other things I noticed while clicking around in test-7:

 

a) the "Verifier" returns false positives such as JSR $5426 and the like, when PORTB=$0d - in fact it may be e.g. SPARTA.SYS (or any other code loaded to the ext RAM) calling itself (PB.7=0 does not necessarily mean that the SELF TEST ROM is banked in).

 

b) AltirraOS: the CKEY value $03E9 is reverse than in the XL OS. But I guess the very reason why the cassette boot routine does not read the CONSOL register directly (which IIRC it was doing in the 400/800 OS) is to provide a cartridge a method of preventing (or even forcing) the boot from the tape: between the time the CKEY is set and the time when it is read, the system makes a call to the cartinit. Therefore it may be advisable to do EOR #$01 before STA CKEY, just as the XL OS does.

Edited September 4, 2017 by drac030

[phaeron]

Hi phaeron

 

The Cave Runner game (cassette) does not load in Altirra x64 2.99 test 1 to 7.

The game loads and runs normally on Altirra x64 2.90 test 35 and earlier.

It looks a if the "Turbo Enabled" option is always on even if it is not selected.

 

caverunner.png

 

Caverunner(1983)(English Software)(UK).zip

 

madi

 

Not turbo related. The reason for this problem:

 

• The tape conversion is bad and contains a small 0.3ms space tone glitch at the beginning of the tape in an FSK block. Very old emulators can't interpret these blocks and will ignore them.
• Altirra 2.99-test uses a higher data sampling rate (31KHz vs. 15KHz) and this is allowing the OS to see this glitch as a false start bit. If you turn on C: acceleration it'll load because the cassette accelerator has protection against false sync bytes.

Hex edit offset 16 ($10) in the CAS image from $03 to $00 to kill the glitch.

[phaeron]

http://www.virtualdub.org/beta/Altirra-2.99-test8.zip

http://www.virtualdub.org/beta/Altirra-2.99-test8-src.zip

 

• Prevent wraparound on VBXE blitter timer if blitter not used for 20 minutes.
• CKEY polarity reversed in AltirraOS and now also cleared after cassette boot. Note that AltirraOS always uses the XL/XE address of CKEY while the debugger uses the 800 address; I need to resolve this at some point.
• Performance analyzer can now toggle CPU insn, video, and BASIC tracing.
• Added CIO/SIO code tracing, though I'm not sure if I'll keep it (it can't see direct put calls).
• The debugger now uses write symbols for read/modify/write and illegal store instructions, i.e. INC IRQEN instead of INC IRQST.

Regarding the verifier: currently the verifier and the profiler are unable to deal with memory overlays, including extended memory. This is because they work on CPU addresses and can't tell when layers have been swapped in and out during execution, so they will be confused by the memory aliasing. Fixing this requires tracking the changes to the memory map and the virtual-to-physical address translations, which I haven't figured out an efficient way to do yet.

[baktra]

It would appear that enhanced support for cassette emulation is like opening the Pandora's box. Once opened, one is flooded with problems to solve and with cassette images to fix.

I salute phaeron for his relentlessness.

[Shannon]

In some ways that may not be a bad thing. It will force cassette images to be checked and verified better which is ultimately better in terms of preservation.

[ijor]

I have problems building the new versions. Didn't you forget to publish "traceviewerToolbar.png"? Or it is supposed to be generated somehow by the build?

Also there is a minor issue. Your build utility requires VS version 15.3.1, but I have 15.3.3. Now that VS is not being offered to download as a DVD or ISO anymore, it is (almost) impossible to get exactly the same build of the compiler. It's easy to fix the build batch for the different version. But seems to me that it shouldn't bother with a subpoint release difference?

Edited September 5, 2017 by ijor

[ijor]

Extracted the missing PNG file from the executable resource and I can see it's the file "traceviewer.svg" converted. Don't know if the build is supposed to perform the conversion or you are distributing the wrong file.

[phaeron]

Sorry, yes, it is the exported version of traceviewer.svg. Both are supposed to be in the source archive, but the converted version got dropped by the packaging script. The PNG version is manually exported from SVG via Inkscape. I've attached it here.

 

As for the Visual Studio version, I put that check in to prevent accidental building of the program with the wrong version of Visual Studio. This is mostly to prevent using the wrong version entirely, but it has also caught some unintended minor version changes -- one of the VS2015 updates covertly also upgraded the VS2013 compiler. Checking the update sub-version is not easy because the compiler doesn't reflect it, only the build number of the compiler itself. There has even been a case where the VC++ build numbers were not monotonic by time....

 

For the most part minor upgrades are OK, but 15.3 is actually a notable counterexample as it has a nasty bug that broke the debug builds of the emulator and that I had to work around. Older versions of the emulator will crash with a stack overflow if built in Debug in VS2017 15.3.x. I've been waiting for a fix before upgrading the compiler again and before using the new language features enabled by 15.3. You don't need to edit the batch file to allow different compiler versions; just run it with /anyvc to bypass the version check.

 

[drac030]

• 
  
  • • Prevent wraparound on VBXE blitter timer if blitter not used for 20 minutes.
    • CKEY polarity reversed in AltirraOS and now also cleared after cassette boot. Note that AltirraOS always uses the XL/XE address of CKEY while the debugger uses the 800 address; I need to resolve this at some point.

 

Excellent, thank you. I noticed two more things:

 

1) when writing files from the emulated Atari side to the PC side via PCLink, the timestamps are not preserved on the destination, even though the client side sends them (the timestamps) to the server. Could it be fixed?

 

2) when XE hardware type is enabled and IDE+ is "inserted", the only cartridge slot available in the real hardware is the IDE+ cartridge slot. When a cartridge is inserted into it, the internal SDX (provided that it is not disabled with the switch) has a priority over the cartridge, i.e. when the system is entering the PBI initialization, the SDX ROM should be present in the $A000-$BFFF. It seems it is not the case in the Altirra, e.g. I select "Attach cartridge", then at the time of the PBI init this cartridge is active in the respective address space instead of the IDE+ internal SDX ROM. This causes problems with booting the system with a cartridge inserted: one has to hold START, then enable SDX in the menu, then hit ^X to get the system start. Could you fix it?

 

Thanks in advance.

Edited September 6, 2017 by drac030

[Suppawer]

Hi phaeron.

I have an issue (Win 7 and Win Xp):

 

1- eduCAS.rar
F8
bp $2F5B

AltirraCrash1.rar

2- Any binary:
Debug->Options->Break at EXE Run Address

AltirraCrash2.rar

[Madi]

Hi phaeron.

I have an issue (Win 7 and Win Xp):

 

1- eduCAS.rar

 

Works fine. No basic XL-XE OS 2 and 3, Windows 10

madi

[Mclaneinc]

same here. all ok

[Estece]

Hi Phaeron.

Thanks for creating such great emulator ,atirra basic and hardware manual

Keep up the excellent work!!!

With debugging enabled can i have a switch to display atascii or internal code in memory window and other switch to change row width from 1 to 48 or 64?

For example in laser demo there is text in internal screen code at address $8070 and i can't see it or i don't know how to use such excellent debugger.

Can You show me the correct way or a link where i can read how to do it?

[+MrFish]

Can You show me the correct way or a link where i can read how to do it?

 

I have some documentation for Altirra's debugger here: Emulate: Altirra

[phaeron]

Will look at the IDE+2 and PCLink issues. I know what's going on with the crashes and will have them fixed next version -- they occur when the history view populates only one instruction from empty, especially if you just turned on CPU history.

 

As for viewing INTERNAL, try the 'dbi' command or use the debug display.