phaeron Posted August 21, 2017 Author Share Posted August 21, 2017 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. 11 Quote Link to comment Share on other sites More sharing options...
tebe Posted August 21, 2017 Share Posted August 21, 2017 marvelous Quote Link to comment Share on other sites More sharing options...
popmilo Posted August 21, 2017 Share Posted August 21, 2017 Best present ever Thank you !!! Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted August 21, 2017 Share Posted August 21, 2017 Happy Birthday Pop Quote Link to comment Share on other sites More sharing options...
José Pereira Posted August 21, 2017 Share Posted August 21, 2017 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... Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 21, 2017 Share Posted August 21, 2017 (edited) 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 Quote Link to comment Share on other sites More sharing options...
phaeron Posted August 22, 2017 Author Share Posted August 22, 2017 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)? Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 23, 2017 Share Posted August 23, 2017 (edited) 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 Quote Link to comment Share on other sites More sharing options...
phaeron Posted August 24, 2017 Author Share Posted August 24, 2017 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. 5 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted August 24, 2017 Share Posted August 24, 2017 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 Quote Link to comment Share on other sites More sharing options...
+MrFish Posted August 24, 2017 Share Posted August 24, 2017 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. Quote Link to comment Share on other sites More sharing options...
baktra Posted August 24, 2017 Share Posted August 24, 2017 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted August 24, 2017 Share Posted August 24, 2017 Thank you Baktra.... Express work Quote Link to comment Share on other sites More sharing options...
phaeron Posted August 26, 2017 Author Share Posted August 26, 2017 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. Quote Link to comment Share on other sites More sharing options...
baktra Posted August 26, 2017 Share Posted August 26, 2017 Oh yes, ASMA/Docs/Sap.txt really prescribes CR/LF. Quote Link to comment Share on other sites More sharing options...
NSonic Posted August 30, 2017 Share Posted August 30, 2017 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 Quote Link to comment Share on other sites More sharing options...
Madi Posted August 30, 2017 Share Posted August 30, 2017 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 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted August 30, 2017 Share Posted August 30, 2017 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? Quote Link to comment Share on other sites More sharing options...
baktra Posted August 30, 2017 Share Posted August 30, 2017 .nrg isn't exactly the best format for sharing compact disc images. Quote Link to comment Share on other sites More sharing options...
phaeron Posted August 31, 2017 Author Share Posted August 31, 2017 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. Quote Link to comment Share on other sites More sharing options...
drac030 Posted August 31, 2017 Share Posted August 31, 2017 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. Quote Link to comment Share on other sites More sharing options...
baktra Posted August 31, 2017 Share Posted August 31, 2017 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 2 Quote Link to comment Share on other sites More sharing options...
Suppawer Posted August 31, 2017 Share Posted August 31, 2017 INJEKTOR decoder by xt5 (www.retronia.cl) Quote Link to comment Share on other sites More sharing options...
phaeron Posted September 1, 2017 Author Share Posted September 1, 2017 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. Quote Link to comment Share on other sites More sharing options...
ClausB Posted September 1, 2017 Share Posted September 1, 2017 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! 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.