Mclaneinc Posted May 12, 2017 Share Posted May 12, 2017 Good man, you did your home work..Makes it easier for Avery / Phaeron... Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 13, 2017 Share Posted May 13, 2017 Thanks Avery. Tested with revised VBXE core detection in U1MB BIOS using reduced bit toggling iterations and it works well. Quote Link to comment Share on other sites More sharing options...
solo/ng Posted May 15, 2017 Share Posted May 15, 2017 Once again thank you Phaeron for profiling csv export. It actually helped us to improve game performance around 1000 cycles per gameLoop iteration (and its not over yet). We used it for our TimePilot A8 port. 4 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted May 15, 2017 Share Posted May 15, 2017 Thank you solo etc, lovely port... Quote Link to comment Share on other sites More sharing options...
phaeron Posted May 17, 2017 Author Share Posted May 17, 2017 Update: http://www.virtualdub.org/beta/Altirra-2.90-test34.zip http://www.virtualdub.org/beta/Altirra-2.90-test34-src.zip Abnormal playfield DMA detection fix for Hijack!. POKEY fixes for high-pass timing and deferred linked timers. 1.79MHz linked was actually also off by three cycles, but hard to detect. Two-tone fixes will have to wait as I'm seeing anomalies on the real hardware that I can't explain yet (two timers at the same period and clock react differently depending on init order). Fixed .logopen writing files with the wrong line ending. Fixed loop detection issues in history view with 6809 coprocessors. Hi phaeron, did you read my private message? Yes, I did, but I haven't gotten around to looking at the icons. 13 Quote Link to comment Share on other sites More sharing options...
Keatah Posted May 17, 2017 Share Posted May 17, 2017 Oh yeh babycakes and hot dogs! Another little tune-up to my virtual Atari 800. And an issue I want looked into. It may or may not be an Altirra glitch. This disk image will not load if the CPU is set to run 3 MHz or faster on Atari 800 w/OSB. All CPUs will load it at 1.79 MHz though. It happens pretty much right away before the intro animation. And if you wait a while it says LOAD ERROR. It also behaves that way on earlier versions too. So yeh, I dunno. It's something I've been meaning to ask about for a long time. It isn't specific to the 2.90 test series Ballblazer (1985)(Lucasfilm)Tournament Certified.atr --- I just discovered if I turn off "Shadow ROMs in fast RAM" I can get it to work at 3.58 MHz and 7.14 MHz. But 10.7, 14.28, 17.90, and 21.48 still continue to fail. This still on Atari 800 OSB. Moving up to a 65XE/130XE I can get it working 10.7 and 14.28, but still not 17.90 or 21.48. Not that I want to play at that speed or anything. All the other BallBlazer/BallBlaster images seem to load fine at any speed. If it's just the way it is then it's just the way it is! Quote Link to comment Share on other sites More sharing options...
DocFlareon Posted May 17, 2017 Share Posted May 17, 2017 Has anyone started serious work to build a port of Altirra that will build on a *nix system? WINE is nice and all, but I would like to avoid using too many compatibility layers. Right now, I'm using Atari800, but it's been nearly a year since the last code change, and I'm looking for the most accurate Atari 8-bit environment for my Linux machine. 2 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted May 17, 2017 Share Posted May 17, 2017 Thanks for the fix release Phaeron..Hope you find the audio anomaly... Quote Link to comment Share on other sites More sharing options...
phaeron Posted May 18, 2017 Author Share Posted May 18, 2017 And an issue I want looked into. It may or may not be an Altirra glitch. This disk image will not load if the CPU is set to run 3 MHz or faster on Atari 800 w/OSB. All CPUs will load it at 1.79 MHz though. It happens pretty much right away before the intro animation. And if you wait a while it says LOAD ERROR. It also behaves that way on earlier versions too. So yeh, I dunno. It's something I've been meaning to ask about for a long time. It isn't specific to the 2.90 test series Ballblazer (1985)(Lucasfilm)Tournament Certified.atr This is due to a bug in the LucasArts custom disk loader that just happens to work at normal 1.79MHz speed. The issue is that the loader uses the serial output complete IRQ instead of serial output ready to queue bytes for transmission. This would be fine except that there is a quirk in POKEY where up to one bit cell time can pass from the time that a write to SEROUT occurs and when serial output complete IRQ turns off. This causes the CPU to immediately re-enter the IRQ handler to try to handle the serial output complete IRQ. At normal speed, the CPU is slow enough that by the time it actually checks for the serial output complete IRQ, it's already turned off: 11393: 39: 85 | A=23 X=A0 Y=27 ( I C) | BE90: 8D 0D D2 STA SEROUT 11393: 39: 93 | A=23 X=A0 Y=27 ( I C) | BE93: 4C 90 BF JMP $BF90 11393: 39: 99 | A=23 X=A0 Y=27 ( I C) | BF90: A5 81 LDA $81 11393: 39:102 | A=00 X=A0 Y=27 ( IZC) | BF92: 10 09 BPL $BF9D 11393: 39:105 | A=00 X=A0 Y=27 ( IZC) | BF9D: 68 PLA 11393: 39:109 | A=01 X=A0 Y=27 ( I C) | BF9E: 40 RTI 11393: 40: 14 | A=01 X=A0 Y=27 ( I C) | C02C: D8 CLD 11393: 40: 16 | A=01 X=A0 Y=27 ( I C) | C02D: 6C 16 02 JMP (VIMIRQ) 11393: 40: 23 | A=01 X=A0 Y=27 ( I C) | BF6B: 48 PHA ;Re-enter IRQ handler because of SEROC 11393: 40: 35 | A=01 X=A0 Y=27 ( I C) | BF6C: A9 20 LDA #$20 11393: 40: 43 | A=20 X=A0 Y=27 ( I C) | BF6E: 2D 0E D2 AND IRQST 11393: 40: 59 | A=20 X=A0 Y=27 ( I C) | BF71: D0 0B BNE $BF7E 11393: 40: 65 | A=20 X=A0 Y=27 ( I C) | BF7E: A9 08 LDA #$08 11393: 40: 69 | A=08 X=A0 Y=27 ( I C) | BF80: 2D 0E D2 AND IRQST ;Check SEROC 11393: 40: 77 | A=08 X=A0 Y=27 ( I C) | BF83: D0 0B BNE $BF90 ;Oops! No IRQs. 11393: 40: 83 | A=08 X=A0 Y=27 ( I C) | BF90: A5 81 LDA $81 11393: 40: 89 | A=00 X=A0 Y=27 ( IZC) | BF92: 10 09 BPL $BF9D 11393: 40: 95 | A=00 X=A0 Y=27 ( IZC) | BF9D: 68 PLA 11393: 40:101 | A=01 X=A0 Y=27 ( I C) | BF9E: 40 RTI However, with an accelerator, the CPU is fast enough that it can manage to catch the serial output complete IRQ in time, and queue the second byte too early: 6483:258: 25.11 | A=00:52 X=00 Y=00 ( I C) | 00:BE73: 8D 0D D2 STA SEROUT 6483:258: 28. 0 | A=00:52 X=00 Y=00 ( I C) | 00:BE76: 18 CLC 6483:258: 28. 2 | A=00:52 X=00 Y=00 ( I ) | 00:BE77: 65 31 ADC CHKSUM 6483:258: 28. 5 | A=00:83 X=00 Y=00 (NV I ) | 00:BE79: 69 00 ADC #$00 6483:258: 28. 7 | A=00:83 X=00 Y=00 (N I ) | 00:BE7B: 85 31 STA CHKSUM 6483:258: 28.10 | A=00:83 X=00 Y=00 (N I ) | 00:BE7D: E6 32 INC BUFRLO 6483:258: 29. 4 | A=00:83 X=00 Y=00 (N I ) | 00:BE7F: D0 02 BNE $BE83 6483:258: 29. 7 | A=00:83 X=00 Y=00 (N I ) | 00:BE83: 68 PLA 6483:258: 29.11 | A=00:00 X=00 Y=00 ( IZ ) | 00:BE84: A8 TAY 6483:258: 30. 1 | A=00:00 X=00 Y=00 ( IZ ) | 00:BE85: 4C 90 BF JMP $BF90 6483:258: 30. 4 | A=00:00 X=00 Y=00 ( IZ ) | 00:BF90: A5 81 LDA $81 6483:258: 30. 7 | A=00:00 X=00 Y=00 ( IZ ) | 00:BF92: 10 09 BPL $BF9D 6483:258: 30.10 | A=00:00 X=00 Y=00 ( IZ ) | 00:BF9D: 68 PLA 6483:258: 31. 2 | A=00:01 X=00 Y=00 ( I ) | 00:BF9E: 40 RTI 6483:258: 36. 0 | A=00:01 X=00 Y=00 ( I C) | 00:C02C: D8 CLD 6483:258: 39. 0 | A=00:01 X=00 Y=00 ( I C) | 00:C02D: 6C 16 02 JMP (VIMIRQ) 6483:258: 43. 2 | A=00:01 X=00 Y=00 ( I C) | 00:BF6B: 48 PHA 6483:258: 43. 5 | A=00:01 X=00 Y=00 ( I C) | 00:BF6C: A9 20 LDA #$20 6483:258: 43. 7 | A=00:20 X=00 Y=00 ( I C) | 00:BF6E: 2D 0E D2 AND IRQST 6483:258: 45. 1 | A=00:20 X=00 Y=00 ( I C) | 00:BF71: D0 0B BNE $BF7E 6483:258: 45. 4 | A=00:20 X=00 Y=00 ( I C) | 00:BF7E: A9 08 LDA #$08 6483:258: 45. 6 | A=00:08 X=00 Y=00 ( I C) | 00:BF80: 2D 0E D2 AND IRQST 6483:258: 47. 0 | A=00:00 X=00 Y=00 ( IZC) | 00:BF83: D0 0B BNE $BF90 6483:258: 47. 2 | A=00:00 X=00 Y=00 ( IZC) | 00:BF85: 8D 0E D2 STA IRQEN 6483:258: 49. 1 | A=00:00 X=00 Y=00 ( IZC) | 00:BF88: A9 08 LDA #$08 6483:258: 49. 3 | A=00:08 X=00 Y=00 ( I C) | 00:BF8A: 8D 0E D2 STA IRQEN 6483:258: 51. 0 | A=00:08 X=00 Y=00 ( I C) | 00:BF8D: 4C 69 BE JMP $BE69 6483:258: 51. 3 | A=00:08 X=00 Y=00 ( I C) | 00:BE69: C6 D7 DEC $D7 6483:258: 51. 8 | A=00:08 X=00 Y=00 ( I C) | 00:BE6B: 30 1B BMI $BE88 6483:258: 51.10 | A=00:08 X=00 Y=00 ( I C) | 00:BE6D: 98 TYA 6483:258: 52. 0 | A=00:00 X=00 Y=00 ( IZC) | 00:BE6E: 48 PHA 6483:258: 52. 3 | A=00:00 X=00 Y=00 ( IZC) | 00:BE6F: A0 00 LDY #$00 6483:258: 52. 5 | A=00:00 X=00 Y=00 ( IZC) | 00:BE71: B1 32 LDA (BUFRLO),Y 6483:258: 52.10 | A=00:25 X=00 Y=00 ( I C) | 00:BE73: 8D 0D D2 STA SEROUT Robust serial output routines have to wait until either serial output ready has asserted or serial output complete has deasserted before loading another byte. Until then, SEROUT hasn't been loaded into the output shift register yet, and loading another byte just overwrites the first one. In this case, this causes only four bytes of the command frame to be sent, the drive sits patiently waiting for the fifth byte, and the SIO operation times out. It might have a chance at recovering on the retries if it weren't for the routine also issuing the first byte off of the VBI routine, so the timing ends up being the same on all the retries too. Oops. As for why turning off the ROM shadowing helps, that's because you're moving the ROMs from fast memory to chip memory. This forces the CPU to run at 1.79MHz when executing from the OS ROM. However, the accelerator is able to run at full speed in the loader in fast RAM, so at higher CPU speeds it still gets into the IRQ handler fast enough to fail. This is a generic setup which is common to accelerators; any CPU accelerator retrofitted onto existing hardware has to work with a partition between the original slow bus and the accelerated CPU bus, and any accesses that aren't on or shadowed on the fast bus slow down the accelerator CPU. Any hardware on the slow bus that can't be shadowed like a funky bank-switching cartridge or a PBI device ROM kills accelerator performance when accessed, because the accelerator can't make the slow hardware run at accelerated speeds. This is also why Altirra doesn't have an option to toggle RAM speed -- the accelerator's CPU would get slowed down so often it'd barely be faster than stock. 8 Quote Link to comment Share on other sites More sharing options...
Keatah Posted May 18, 2017 Share Posted May 18, 2017 Much appreciated! Quote Link to comment Share on other sites More sharing options...
antrykot Posted May 19, 2017 Share Posted May 19, 2017 (edited) POKEY fixes for high-pass timing and deferred linked timers. 1.79MHz linked was actually also off by three cycles, but hard to detect. Two-tone fixes will have to wait as I'm seeing anomalies on the real hardware that I can't explain yet (two timers at the same period and clock react differently depending on init order). Thank you. Edited May 19, 2017 by antrykot Quote Link to comment Share on other sites More sharing options...
Atari_Ace Posted May 22, 2017 Share Posted May 22, 2017 Hi Avery, While running the BASIC listing of Planetary Defense from ANALOG #17, I found that it fails to run correctly in Altirra BASIC 1.54. The program, like most of the ANALOG assembly language games, validates the DATA statements for malformed data and missing lines. To catch the latter issue, it uses DATALN=PEEK(183)+PEEK(184)*256 to find the current DATA statement line (so it can detect missing DATA lines), but Altirra BASIC puts this variable at 196,197. It seems for compatibility it could be moved (it's somewhat documented, as it appears in Appendix 11 of Mapping the Atari, Revised Edition). A simple test program that prints 1000 in Atari BASIC but prints 0 in Altirra BASIC. 40 RESTORE 1000 60 DATLIN=PEEK(183)+PEEK(184)*256 70 ? DATLIN 1000 DATA X Change line 60 to 60 DATLIN=PEEK(196)+PEEK(197)*256 and it prints 1000. 4 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted May 25, 2017 Share Posted May 25, 2017 Is anyone else still seeing the emulator display disappearing on a second monitor and not coming back until Altirra is dragged onto the first monitor after a system wake-up? Using Windows 10 64-bit here with a GeForce 210. 1 Quote Link to comment Share on other sites More sharing options...
phaeron Posted May 30, 2017 Author Share Posted May 30, 2017 Update:http://www.virtualdub.org/beta/Altirra-2.90-test35.ziphttp://www.virtualdub.org/beta/Altirra-2.90-test35-src.zip Fixes a regression with beam positions sometimes not being reported in the debugger. Fixes a bug with the new confirmation on exit dialog not locking down the parent window. This is a release candidate for 2.90; I've been shunting all further changes to another branch. While running the BASIC listing of Planetary Defense from ANALOG #17, I found that it fails to run correctly in Altirra BASIC 1.54. The program, like most of the ANALOG assembly language games, validates the DATA statements for malformed data and missing lines. To catch the latter issue, it uses DATALN=PEEK(183)+PEEK(184)*256 to find the current DATA statement line (so it can detect missing DATA lines), but Altirra BASIC puts this variable at 196,197. It seems for compatibility it could be moved (it's somewhat documented, as it appears in Appendix 11 of Mapping the Atari, Revised Edition). Oh look, another bad programming practice enabled by Mapping the Atari. What a shock. I'll tweak this for the next version. For anyone who hasn't figured it out yet, Mapping the Atari is great at documenting lots of internal variables that you are not supposed to use and if you do will cause your software to break on custom setups. A great example is this entry in the XL/XE revised version: 128,129 80,81 LOMEMPoints to 7676 ($$1DFC). ...which is so amazingly wrong I don't know where to begin. If you are looking for information on system variables, start with the Atari OS Manual first. 8 Quote Link to comment Share on other sites More sharing options...
mr-atari Posted May 30, 2017 Share Posted May 30, 2017 Thanks for the update :-) I found this quirk, while testing/debugging MyBIOS: "" The option "solid-state" or "spinning platter" for PBI/BlackBox seems broken. It does not matter what I tick, both seems to result in emulated "solid-state" (fast) When I do the same for the MyIDE-II harddrive, it works OK."" Cheers, Sijmen. Quote Link to comment Share on other sites More sharing options...
phaeron Posted May 30, 2017 Author Share Posted May 30, 2017 The option "solid-state" or "spinning platter" for PBI/BlackBox seems broken. It does not matter what I tick, both seems to result in emulated "solid-state" (fast) More like not implemented, but yes, confirmed. The issue is that the device speed setting is stored in a common block device layer that both the IDE and SCSI emulation layers are built on top of, but only the IDE layer uses the device speed setting. BlackBox and MIO use the SCSI layer, which doesn't implement the delay based on this setting. I'll fix this post-2.90. 3 Quote Link to comment Share on other sites More sharing options...
Atari_Ace Posted May 30, 2017 Share Posted May 30, 2017 Oh look, another bad programming practice enabled by Mapping the Atari. What a shock. I'll tweak this for the next version. For anyone who hasn't figured it out yet, Mapping the Atari is great at documenting lots of internal variables that you are not supposed to use and if you do will cause your software to break on custom setups. The publication of the Atari BASIC Sourcebook made the distinction between the internals and the publics at best vague, so you can't completely fault Mapping the Atari (although I agree it does seem to encourage too much dubious usage). ANALOG started using this trick in issue 10, March 1983, which predates the revised Mapping the Atari and (probably) the Sourcebook, so this was either discovered through disassembly or perhaps privately disclosed. I looked over the Altirra BASIC and Atari BASIC zero page locations and found a few other 'compatibility' candidates. The other variables you've placed in compatible locations (STOPLN, ERRSAV, PTABW, RADFLG) at least were documented in the Atari BASIC Reference Manual. These can only be moved if you're trying to maximize compatibility, which you can argue for and against in equal measure. dataoff (DATAD) => $B6 dataln (DATALN) => $B7, $B8 errno (ERRNUM) => $B9 exTrapLine (TRAPLN) => $BC, $BD Quote Link to comment Share on other sites More sharing options...
phaeron Posted May 30, 2017 Author Share Posted May 30, 2017 If you are trying to feed me info from the Atari BASIC source code, please stop. Altirra BASIC needs to be completely independent of the Atari BASIC copyright and doing so will put that in jeopardy. 3 Quote Link to comment Share on other sites More sharing options...
Shannon Posted May 31, 2017 Share Posted May 31, 2017 /clean room mode "on" Atari is watching! 1 Quote Link to comment Share on other sites More sharing options...
fujidude Posted May 31, 2017 Share Posted May 31, 2017 /clean room mode "on" Atari is watching! I doubt it, by why take the chance. Quote Link to comment Share on other sites More sharing options...
Starman Posted May 31, 2017 Share Posted May 31, 2017 @phaeron, Is it possible to dump printer output to a file? In another thread, there was talk about printing in Altirra, but it won't work if we don't at least have access to printer output. Quote Link to comment Share on other sites More sharing options...
phaeron Posted May 31, 2017 Author Share Posted May 31, 2017 @phaeron, Is it possible to dump printer output to a file? In another thread, there was talk about printing in Altirra, but it won't work if we don't at least have access to printer output. Not currently, but I'll work on that. Altirra's printer innards are a bit hokey right now -- a mix of 820 SIO-level emulation and CIO-level P: emulation. I'd need to separate those out so you can add the correct printer emulation path through the device tree, if for no other reason than to keep the 820 emulation from spewing garbage out during the print spooling. Though, that's not exactly inaccurate, if my memories of parallel port dot matrix printers are accurate (which include the aggravation of aligning pin-feed paper and then dealing with 10 pages of garbage because you turned on the printer too late). Quote Link to comment Share on other sites More sharing options...
morelenmir Posted May 31, 2017 Share Posted May 31, 2017 /clean room mode "on" Atari is watching! They watch and they are always here... Quote Link to comment Share on other sites More sharing options...
Keatah Posted June 1, 2017 Share Posted June 1, 2017 They watch and they are always here... What makes you say that? Quote Link to comment Share on other sites More sharing options...
morelenmir Posted June 1, 2017 Share Posted June 1, 2017 (edited) What makes you say that? 'We Watch and We are Always Here' is the motto of the Talamasca in Anne Rice's Lestat stories. They were pretty much the inspiration for 'The Watchers Council' in Joss Whedon's vampire shows. I always trot it out when someone warns me about big brother! Edited June 1, 2017 by morelenmir Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.