Altirra 2.90 released

[phaeron]

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

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

 

Now includes CPU history tracing in the Performance Analyzer:

 

 

The CPU history view has been rewritten and adapted for use with the tracing engine. Traces now include a compressed CPU execution history and clicking in the event view will show the execution history at that point, up to a 400K instruction window around it. (The normal CPU history is limited to 128K instructions.) Similarly, selecting an instruction in the CPU history will show the corresponding activity in the event view. This is currently always enabled for now and the trace will consume about 4-9MB/sec depending on how well the trace compresses; in the future the video and CPU history tracing will be optional to allow for longer traces.

 

Fixed an issue with the CPU tracer that prevented some interrupt handlers from showing up properly if executed back-to-back with the RTI from the previous interrupt handler. This particularly affected IRQs serviced immediately after the VBI; these were showing up as extended VBIs rather than the CPU switching to handling the IRQ.

 

Added some polish to the analyzer UI: added horizontal scroll bar, added zoom limits, and extended scale to microseconds. It now uses the same window docking code as the main UI to allow for additional views.

 

Fixed a high-DPI problem on the debug console window, which should no longer show funky font sizes when the DPI scaling factor on the monitor changes.

 

Compiler upgraded to Visual Studio 2017 Update 15.3.1. Had to work around one compiler bug that caused the debug build to crash; we'll see how the release build fares.

 

[tebe]

marvelous

[popmilo]

Best present ever

Thank you !!!

[Mclaneinc]

Happy Birthday Pop

[José Pereira]

Not today his birthday but on the day I married so I never forget. Problem is that I'm no longer and can't have two celebrations on the same day so I just send him a message...

[drac030]

Not sure about test-6, but I remember that this problem was occurring occasionally on test-4 and I can see that it occurs on test-5 too, so it is maybe worth reporting.

 

There are situations when the VBXE blitter, once started, seems to never clear the busy bit. When the program contains a busy loop waiting for that bit to be cleared, it of course hangs. Since I have never seen this problem on the real hardware, I presume that this may be a problem with the VBXE emulation in Altirra.

 

I can observe the problem when testing programs under 80-column display managed by the S_VBXE.SYS driver. The 80-column console under SDX occasionally hangs and the normal operation cannot be recovered without a reset. To be sure, the scenario is that the driver first starts the blitter operation (like to scroll the entire text display up), then it waits forever for clearing the busy bit:

 

(130476:  0,  0) C=9C02 X=2A Y=13 S=D8 P=30 (      )  00:5DC5: B9 40 D6  L5DC5   LDA $D640,Y  [$00:D653] = $02
              B=00 D=0000

The .vbxe command in the debugger gives the following output:

 

XDL enabled:       Yes
XDL active:        No
XDL base address:  $7E140
XDL fetch address: $7E157
Overlay width:     Normal
Overlay mode:      Disabled
Overlay address:   $7FB00
Overlay step:      $0A0
Overlay priority:  $80 | 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 (1 rows left)
Blitter list addr: $7E078
Blitter list cur.: $7E0A2

The "Blitter status" sometimes shows "active (0 rows left)", as I saw on test-4.

 

The "Overlay mode" seems enabled, contrary to what is said here. The XDL seems active.

 

The problem occurs very rarely, i.e. usually everything works as expected.

 

Below is the snapshot of the display saved from the time it crashed.

Edited August 21, 2017 by drac030

[phaeron]

The overlay mode in the .vbxe output is for the current scanline, since it's driven by the XDL. It'll show disabled when you're looking at it in vblank.

 

I'm having trouble reproducing this to diagnose the problem, even with small programs to repeatedly stress the blitter and S_VBXE scrolling routines. When it jams, does it resume if you forcibly halt and restart the blitter ($00, $01 -> $D653)?

[drac030]

I will try that when it occurs next time.

 

I noticed one more thing: the issue basically occurs when exiting from xless.com (an early version of this program is here: http://atariage.com/forums/topic/255228-spartados-x-448/?p=3824154). I currently have no idea what could cause the issue, as I said, when it occurs next time, I will try to gather more data (like the contents of the RAM which is supposed to contain the blitter list, for example).

Edited August 23, 2017 by drac030

[phaeron]

Whelp, still no luck on the VBXE issue, but:

 

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

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

• Stability fixes to history views.
• History search optimized (sprintf is sloooowwww).
• VBXE: Overlay priority is now properly reset to $FF at the top of the XDL.
• VBXE: Fixed regression in reporting blitter line count remaining (was reporting full line count). Now also reports cycle delta and cycles to finish if within a scanline.

[Mclaneinc]

I know the built in SAP player is not suitable for certain load addresses and SAP types but for some reason it does not recognise this as a SAP file?

 

The said SAP does play on Sap Player 2.0

 

More for seeing why its not recognised than getting Altirra to play it..

Orient.sap.txt

[+MrFish]

I know the built in SAP player is not suitable for certain load addresses and SAP types but for some reason it does not recognise this as a SAP file?

 

The said SAP does play on Sap Player 2.0

 

More for seeing why its not recognised than getting Altirra to play it..

 

It won't play using the ASAP plug-in for foobar 2000 either.

[baktra]

I know the built in SAP player is not suitable for certain load addresses and SAP types but for some reason it does not recognise this as a SAP file?

 

The said SAP does play on Sap Player 2.0

 

More for seeing why its not recognised than getting Altirra to play it..

 

In a way, the SAP file is corrupted, because it uses inconsistent line separators in the text portion. ASAP doesn't like it.

Attaching "fixed" version that works with ASAP-based players such as mmSAP . The word fixed is in double quotes, the SAP file format description does not define what the line separators should be.

Orient_fixed.zip

Edited August 24, 2017 by baktra

[Mclaneinc]

Thank you Baktra....

 

Express work

[phaeron]

 

In a way, the SAP file is corrupted, because it uses inconsistent line separators in the text portion. ASAP doesn't like it.

Attaching "fixed" version that works with ASAP-based players such as mmSAP . The word fixed is in double quotes, the SAP file format description does not define what the line separators should be.

 

The file format description in ASAP does require CR/LF, though it notes that other players may not. Altirra currently strictly validates line endings. This file is strange because of the one line with the uncommon CR-only ending, an apparent mistake.

[baktra]

Oh yes, ASMA/Docs/Sap.txt really prescribes CR/LF.

[NSonic]

Altirra load cassette system INJEKTOR ??????

 

Video Youtube example Load Tape Injektor Atari.

 

 

 

Forum : http://www.atariware.cl/aw/foro/viewtopic.php?f=14&t=2974

[Madi]

Altirra load cassette system INJEKTOR ??????

 

 

Forum : http://www.atariware.cl/aw/foro/viewtopic.php?f=14&t=2974

There are several JPG and PNG images were blocked by ESET NOD32 antivirus and blacklisted by chrome.

Example: http://invader.vtrbandaancha.net/INJEKTOR/Injektor_Cover.png

madi

[Mclaneinc]

All went ok here on Firefox and Zone Alarm but the CD 2 just shows 44byte cda tracks, maybe I'm looking at it the wrong way?

[baktra]

.nrg isn't exactly the best format for sharing compact disc images.

[phaeron]

Context would be nice....

 

It's a CD audio disc containing tape recordings. Found a program called smokenrg-1.0.c to convert it to WAV files and readable labels. Let me just say now, I have no intention of supporting audio CD images.

 

The recordings consist of a one-sector boot loader in plain FSK followed by turbo encoded data. It can't be traditional turbo encoding because POKEY's shift register is used to decode it at about 4000 baud, which means that 0 and 1 bits have to have the same duration. This one is interesting because there doesn't seem to be an obvious signal from the computer to switch between the encodings -- either the tape recorder automatically detects the mode somehow or the turbo encoding is somehow backwards compatible with FSK encoding (!). Regular FSK uses 4KHz and 5.3KHz while the turbo encoding produces 2-4KHz. There's a fair amount of info on this website (Spanish):

 

http://www.retrogames.cl/foro/viewtopic.php?f=34&t=5340

 

The circuit in the tape recorder apparently has two digital logic chips (dual D flip flop and quad XOR), along with a bunch of analog components. Haven't seen a schematic, but based on those chips and the waveform I'm suspecting it uses Manchester encoding. That's not difficult to decode, but figuring out how it also handles the FSK decoding is the tricky part. There's apparently also weird wiring together of the CLOCK OUT and DATA OUT lines, but since there's no CLOCK IN connection I'm guessing that's only for writing. Reading is done in normal SKCTL=$13 mode, so POKEY isn't sending out a clock during that time.

 

The guys who wrote the software loader must have been paranoid about reverse engineering because it has an incredible amount of unnecessary illegal opcode abuse for such a small amount of code:

0390: AD 00 C0          LDA $C000    [$C000] = $11
0393: DF 02 D2          DCP AUDF2,X  [$D301]
0396: 8F 00 C0          SAX $C000    [$C000]
0399: FF 02 D2          ISB AUDF2,X  [$D301]
039C: FF 92 02          ISB TXTCOL+1,X [$0391]
039F: EE 97 03          INC $0397    [$0397]
03A2: D0 EC             BNE $0390
03A4: C8                INY
03A5: F0 08             BEQ $03AF
03A7: C0 CD             CPY #$CD
03A9: D0 DF             BNE $038A
03AB: A0 E0             LDY #$E0
03AD: D0 DB             BNE $038A
03AF: DF 02 D2          DCP AUDF2,X  [$D301]

That's an OS-to-RAM copy routine.

 

[drac030]

When it jams, does it resume if you forcibly halt and restart the blitter ($00, $01 -> $D653)?

It occurred for me again, on test-6, so I am now able to answer this question: yes, it does resume normal operation after that.

 

This time the jam happened in TBXL, in circumstances which looked like fairly easy to reproduce. But the issue did not occur again.

 

From the information displayed by the debugger, it looks like the blitter list has been fetched in its entirety (there are three BCBs there, IIRC). And "active (1 rows left)" as usual, and as usual waiting ad infinitum for clearing the busy bit.

 

I also managed to crash the debugger. Will send you the crash dump via PM.

[baktra]

Context would be nice....

 

It's a CD audio disc containing tape recordings. Found a program called smokenrg-1.0.c to convert it to WAV files and readable labels. Let me just say now, I have no intention of supporting audio CD images.

 

The recordings consist of a one-sector boot loader in plain FSK followed by turbo encoded data. It can't be traditional turbo encoding because POKEY's shift register is used to decode it at about 4000 baud, which means that 0 and 1 bits have to have the same duration. This one is interesting because there doesn't seem to be an obvious signal from the computer to switch between the encodings -- either the tape recorder automatically detects the mode somehow or the turbo encoding is somehow backwards compatible with FSK encoding (!). Regular FSK uses 4KHz and 5.3KHz while the turbo encoding produces 2-4KHz. There's a fair amount of info on this website (Spanish):

 

http://www.retrogames.cl/foro/viewtopic.php?f=34&t=5340

 

The circuit in the tape recorder apparently has two digital logic chips (dual D flip flop and quad XOR), along with a bunch of analog components. Haven't seen a schematic, but based on those chips and the waveform I'm suspecting it uses Manchester encoding. That's not difficult to decode, but figuring out how it also handles the FSK decoding is the tricky part. There's apparently also weird wiring together of the CLOCK OUT and DATA OUT lines, but since there's no CLOCK IN connection I'm guessing that's only for writing. Reading is done in normal SKCTL=$13 mode, so POKEY isn't sending out a clock during that time.

 

The guys who wrote the software loader must have been paranoid about reverse engineering because it has an incredible amount of unnecessary illegal opcode abuse for such a small amount of code:

That's an OS-to-RAM copy routine.

 

 

 

Your suspicion is correct. INJEKTOR is using machester coding. A gift from suppawer is attached - INJEKTOR decoder.

injektor2xex.rar

[Suppawer]

INJEKTOR decoder by xt5 (www.retronia.cl)

[phaeron]

It occurred for me again, on test-6, so I am now able to answer this question: yes, it does resume normal operation after that.

 

This time the jam happened in TBXL, in circumstances which looked like fairly easy to reproduce. But the issue did not occur again.

 

From the information displayed by the debugger, it looks like the blitter list has been fetched in its entirety (there are three BCBs there, IIRC). And "active (1 rows left)" as usual, and as usual waiting ad infinitum for clearing the busy bit.

 

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).

 

INJEKTOR decoder by xt5 (www.retronia.cl)

 

Unfortunately, this supports FSK and turbo by decoding blocks and seeing which mode produces blocks with valid checksums. The original circuit can't possibly have done that; it must have a more immediate way of knowing which mode to use, or a decoding strategy that doesn't require that decision.

[ClausB]

Finally tried Altirra on a new $150 W10 laptop (Lenovo 100S-14IBR). It takes about 40% CPU to do Star Raiders at 60 fps full screen with scan lines on. Beautiful, just beautiful!