kenames99 Posted February 19, 2020 Share Posted February 19, 2020 17 hours ago, phaeron said: To expand on suppawer's point, this is actually how it's stored File attached. dbghelp.txt 77.02 kB · 19 downloads thanks Phaeron! Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 22, 2020 Author Share Posted February 22, 2020 http://www.virtualdub.org/beta/Altirra-3.90-test27.zip http://www.virtualdub.org/beta/Altirra-3.90-test27-src.zip Fixes a bug with the emulator not persisting mounted disks across runs when they come from a .zip file with non-ASCII characters in the filename. AltirraOS bumped to 3.14, fixes only in the 65C816 version. Sysdev device (@:) no longer returns bogus data, fixed a crashing issue in the screen editor, and added a workaround for slow boot with SpartaDOS X 4.48 (it expects to be able to read mainline A/X/Y registers from the stack from the VBI handler in native mode). A few 65C816 fixes to both the main '816 emulator and to Veronica, mostly corner case direct page wrapping bugs but also a bug with WDM being a 1-byte instead of 2-byte instruction. To give you an idea of how bizarrely inconsistent the '816 is: (dp) wraps within the direct page when reading the high address byte in emulation mode, except if DL > 0, except for PEI (dp) which always crosses pages. (dp,X) in emulation mode wraps within the direct page when reading the low address byte, except when DL > 0, but always wraps in emulation mode when reading the high byte. Which means that if D=$0001 and X=$FF, LDA ($FF,X) reads the address from $01FF and $0100. (dp),Y in emulation mode wraps within the direct page when DL = 0 and crosses pages for DL > 0, for both low and high address bytes. Which means that (dp,X) with X=0 and (dp),Y with Y=0 can read different addresses. [dp] and [dp],Y always cross pages, period. Fortunately, none of this crazy affects 6502/65C02 code executing with default D=0 or in native mode. 10 Quote Link to comment Share on other sites More sharing options...
drac030 Posted February 23, 2020 Share Posted February 23, 2020 23 hours ago, phaeron said: added a workaround for slow boot with SpartaDOS X 4.48 (it expects to be able to read mainline A/X/Y registers from the stack from the VBI handler in native mode). Thank you for the update. But I do not quite get this comment above: unless I am forgetting something, SDX only handles interrupts on its own when the OS ROM is switched off. And even then the native mode interrupt vectors should point to an RTI (during boot at least), in SDX 4.48 this instruction is located at $0A0B. Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 23, 2020 Author Share Posted February 23, 2020 27 minutes ago, drac030 said: Thank you for the update. But I do not quite get this comment above: unless I am forgetting something, SDX only handles interrupts on its own when the OS ROM is switched off. And even then the native mode interrupt vectors should point to an RTI (during boot at least), in SDX 4.48 this instruction is located at $0A0B. This is true when SDX has switched on RAM under OS, but this case is a timing loop run late in the boot cycle with the OS ROM enabled. VVBLKI is revectored to a special routine that captures the current values of the timing loop and then effectively does a longjmp() out of the VBI handler directly back to mainline code by resetting the stack pointer. 17136:256: 85 | C=E58F X=--02 Y=--FF S=01F3 B=00 D=0000 P=B0 (N MX ) | 00:064C: BA TSX 17136:256: 87 | C=E58F X=--F3 Y=--FF S=01F3 B=00 D=0000 P=B0 (N MX ) | 00:064D: 8E C3 06 STX $06C3 17136:256: 91 | C=E58F X=--F3 Y=--FF S=01F3 B=00 D=0000 P=B0 (N MX ) | 00:0650: 78 SEI 17136:256: 93 | C=E58F X=--F3 Y=--FF S=01F3 B=00 D=0000 P=B4 (N MX I ) | 00:0651: A2 58 LDX #$58 17136:256: 95 | C=E58F X=--58 Y=--FF S=01F3 B=00 D=0000 P=34 ( MX I ) | 00:0653: A0 06 LDY #$06 17136:256: 97 | C=E58F X=--58 Y=--06 S=01F3 B=00 D=0000 P=34 ( MX I ) | 00:0655: 6C 82 00 JMP ($0082) 17136:256:102 | C=E58F X=--58 Y=--06 S=01F3 B=00 D=0000 P=34 ( MX I ) | 00:65D9: AD 0B D4 LDA VCOUNT 17136:256:106 | C=E580 X=--58 Y=--06 S=01F3 B=00 D=0000 P=B4 (N MX I ) | 00:65DC: C9 70 CMP #$70 17136:256:108 | C=E580 X=--58 Y=--06 S=01F3 B=00 D=0000 P=35 ( MX I C) | 00:65DE: D0 F9 BNE $65D9 + Last 3 insns repeated 1731 times 17137:224: 10 | C=E570 X=--58 Y=--06 S=01F3 B=00 D=0000 P=37 ( MX IZC) | 00:65E0: 8E 22 02 STX VVBLKI 17137:224: 14 | C=E570 X=--58 Y=--06 S=01F3 B=00 D=0000 P=37 ( MX IZC) | 00:65E3: 8C 23 02 STY VVBLKI+1 17137:224: 18 | C=E570 X=--58 Y=--06 S=01F3 B=00 D=0000 P=37 ( MX IZC) | 00:65E6: A9 00 LDA #$00 17137:224: 20 | C=E500 X=--58 Y=--06 S=01F3 B=00 D=0000 P=37 ( MX IZC) | 00:65E8: AA TAX 17137:224: 22 | C=E500 X=--00 Y=--06 S=01F3 B=00 D=0000 P=37 ( MX IZC) | 00:65E9: A0 03 LDY #$03 17137:224: 24 | C=E500 X=--00 Y=--03 S=01F3 B=00 D=0000 P=35 ( MX I C) | 00:65EB: C8 INY 17137:224: 27 | C=E500 X=--00 Y=--04 S=01F3 B=00 D=0000 P=35 ( MX I C) | 00:65EC: D0 FD BNE $65EB + Last 2 insns repeated 252 times 17137:236: 30 | C=E500 X=--00 Y=--00 S=01F3 B=00 D=0000 P=37 ( MX IZC) | 00:65EE: E8 INX 17137:236: 32 | C=E500 X=--01 Y=--00 S=01F3 B=00 D=0000 P=35 ( MX I C) | 00:65EF: D0 FA BNE $65EB 17137:236: 36 | C=E500 X=--01 Y=--00 S=01F3 B=00 D=0000 P=35 ( MX I C) | 00:65EB: C8 INY 17137:236: 39 | C=E500 X=--01 Y=--01 S=01F3 B=00 D=0000 P=35 ( MX I C) | 00:65EC: D0 FD BNE $65EB + Last 2 insns repeated 246 times 17137:248: 8 | C=E500 X=--01 Y=--F7 S=01F3 B=00 D=0000 P=B5 (N MX I C) | 00:65EB: C8 INY - NMI interrupt (VBI) 17137:248: 18 | C=E500 X=--01 Y=--F8 S=01EF B=00 D=0000 P=B5 (N MX I C) | 00:C99B: DC 59 02 JML [$0259] 17137:248: 24 | C=E500 X=--01 Y=--F8 S=01EF B=00 D=0000 P=B5 (N MX I C) | 00:CA72: 8B PHB 17137:248: 27 | C=E500 X=--01 Y=--F8 S=01EE B=00 D=0000 P=B5 (N MX I C) | 00:CA73: 4B PHK 17137:248: 30 | C=E500 X=--01 Y=--F8 S=01ED B=00 D=0000 P=B5 (N MX I C) | 00:CA74: AB PLB 17137:248: 35 | C=E500 X=--01 Y=--F8 S=01EE B=00 D=0000 P=B5 (N MX I C) | 00:CA75: 0B PHD 17137:248: 40 | C=E500 X=--01 Y=--F8 S=01EC B=00 D=0000 P=B5 (N MX I C) | 00:CA76: F4 00 00 PEA $0000 17137:248: 47 | C=E500 X=--01 Y=--F8 S=01EA B=00 D=0000 P=B5 (N MX I C) | 00:CA79: 2B PLD 17137:248: 54 | C=E500 X=--01 Y=--F8 S=01EC B=00 D=0000 P=B5 (N MX I C) | 00:CA7A: C2 10 REP #$10 17137:248: 58 | C=E500 X=0001 Y=00F8 S=01EC B=00 D=0000 P=A5 (N M I C) | 00:CA7C: DA PHX 17137:248: 62 | C=E500 X=0001 Y=00F8 S=01EA B=00 D=0000 P=A5 (N M I C) | 00:CA7D: 5A PHY 17137:248: 66 | C=E500 X=0001 Y=00F8 S=01E8 B=00 D=0000 P=A5 (N M I C) | 00:CA7E: E2 30 SEP #$30 17137:248: 69 | C=E500 X=--01 Y=--F8 S=01E8 B=00 D=0000 P=B5 (N MX I C) | 00:CA80: 4B PHK 17137:248: 71 | C=E500 X=--01 Y=--F8 S=01E7 B=00 D=0000 P=B5 (N MX I C) | 00:CA81: F4 6A C6 PEA $C66A 17137:248: 76 | C=E500 X=--01 Y=--F8 S=01E5 B=00 D=0000 P=B5 (N MX I C) | 00:CA84: 08 PHP 17137:248: 79 | C=E500 X=--01 Y=--F8 S=01E4 B=00 D=0000 P=B5 (N MX I C) | 00:CA85: 2C 0F D4 BIT NMIST 17137:248: 83 | C=E500 X=--01 Y=--F8 S=01E4 B=00 D=0000 P=77 ( VMX IZC) | 00:CA88: 10 03 BPL $CA8D 17137:248: 86 | C=E500 X=--01 Y=--F8 S=01E4 B=00 D=0000 P=77 ( VMX IZC) | 00:CA8D: 48 PHA 17137:248: 89 | C=E500 X=--01 Y=--F8 S=01E3 B=00 D=0000 P=77 ( VMX IZC) | 00:CA8E: A3 0D LDA $0D,S 17137:248: 93 | C=E5B5 X=--01 Y=--F8 S=01E3 B=00 D=0000 P=F5 (NVMX I C) | 00:CA90: 83 02 STA $02,S 17137:248: 97 | C=E5B5 X=--01 Y=--F8 S=01E3 B=00 D=0000 P=F5 (NVMX I C) | 00:CA92: DA PHX 17137:248:100 | C=E5B5 X=--01 Y=--F8 S=01E2 B=00 D=0000 P=F5 (NVMX I C) | 00:CA93: 5A PHY 17137:248:103 | C=E5B5 X=--01 Y=--F8 S=01E1 B=00 D=0000 P=F5 (NVMX I C) | 00:CA94: 8D 0F D4 STA NMIRES 17137:248:107 | C=E5B5 X=--01 Y=--F8 S=01E1 B=00 D=0000 P=F5 (NVMX I C) | 00:CA97: 6C 22 02 JMP (VVBLKI) 17137:248:112 | C=E5B5 X=--01 Y=--F8 S=01E1 B=00 D=0000 P=F5 (NVMX I C) | 00:0658: 68 PLA 17137:249: 2 | C=E5F8 X=--01 Y=--F8 S=01E2 B=00 D=0000 P=F5 (NVMX I C) | 00:0659: 8D 4B 0B STA $0B4B 17137:249: 6 | C=E5F8 X=--01 Y=--F8 S=01E2 B=00 D=0000 P=F5 (NVMX I C) | 00:065C: 68 PLA 17137:249: 10 | C=E501 X=--01 Y=--F8 S=01E3 B=00 D=0000 P=75 ( VMX I C) | 00:065D: 8D 4A 0B STA $0B4A 17137:249: 14 | C=E501 X=--01 Y=--F8 S=01E3 B=00 D=0000 P=75 ( VMX I C) | 00:0660: 68 PLA 17137:249: 18 | C=E500 X=--01 Y=--F8 S=01E4 B=00 D=0000 P=77 ( VMX IZC) | 00:0661: 8D 49 0B STA $0B49 17137:249: 22 | C=E500 X=--01 Y=--F8 S=01E4 B=00 D=0000 P=77 ( VMX IZC) | 00:0664: AE C3 06 LDX $06C3 17137:249: 27 | C=E500 X=--F3 Y=--F8 S=01E4 B=00 D=0000 P=F5 (NVMX I C) | 00:0667: 9A TXS Quote Link to comment Share on other sites More sharing options...
drac030 Posted February 23, 2020 Share Posted February 23, 2020 (edited) This is the SIO.SYS driver measuring the CPU speed, indeed. But something is busted here, as this code is not supposed to be executed in native mode. I just checked (65C816+AltirraOS+SDX 4.48), and it seems to run in emulation mode: 1746:208:101. 6 | A=FF:8F X=02 Y=FF (N ) | 00:064C: BA TSX 1746:208:101. 8 | A=FF:8F X=F3 Y=FF (N ) | 00:064D: 8E C3 06 STX $06C3 1746:208:102. 0 | A=FF:8F X=F3 Y=FF (N ) | 00:0650: 78 SEI 1746:208:102. 2 | A=FF:8F X=F3 Y=FF (N I ) | 00:0651: A2 58 LDX #$58 1746:208:102. 4 | A=FF:8F X=58 Y=FF ( I ) | 00:0653: A0 06 LDY #$06 1746:208:102. 6 | A=FF:8F X=58 Y=06 ( I ) | 00:0655: 6C 82 00 JMP ($0082) 1746:208:102.11 | A=FF:8F X=58 Y=06 ( I ) | 00:70A7: AD 0B D4 LDA VCOUNT 1746:208:105. 0 | A=FF:68 X=58 Y=06 ( I ) | 00:70AA: C9 70 CMP #$70 1746:208:105. 2 | A=FF:68 X=58 Y=06 (N I ) | 00:70AC: D0 F9 BNE $70A7 + Last 3 insns repeated 693 times 1746:223:113. 4 | A=FF:70 X=58 Y=06 ( IZC) | 00:70AE: 8E 22 02 STX VVBLKI 1746:223:113. 8 | A=FF:70 X=58 Y=06 ( IZC) | 00:70B1: 8C 23 02 STY VVBLKI+1 1746:224: 0. 0 | A=FF:70 X=58 Y=06 ( IZC) | 00:70B4: A9 00 LDA #$00 1746:224: 0. 2 | A=FF:00 X=58 Y=06 ( IZC) | 00:70B6: AA TAX 1746:224: 0. 4 | A=FF:00 X=00 Y=06 ( IZC) | 00:70B7: A0 03 LDY #$03 1746:224: 0. 6 | A=FF:00 X=00 Y=03 ( I C) | 00:70B9: C8 INY 1746:224: 0. 8 | A=FF:00 X=00 Y=04 ( I C) | 00:70BA: D0 FD BNE $70B9 + Last 2 insns repeated 252 times 1746:224:106.10 | A=FF:00 X=00 Y=00 ( IZC) | 00:70BC: E8 INX 1746:224:107. 0 | A=FF:00 X=01 Y=00 ( I C) | 00:70BD: D0 FA BNE $70B9 1746:224:107. 3 | A=FF:00 X=01 Y=00 ( I C) | 00:70B9: C8 INY 1746:224:107. 5 | A=FF:00 X=01 Y=01 ( I C) | 00:70BA: D0 FD BNE $70B9 + Last 2 insns repeated 255 times 1746:225:100. 7 | A=FF:00 X=01 Y=00 ( IZC) | 00:70BC: E8 INX + Last 514 insns repeated 23 times 1746:247: 70. 3 | A=FF:00 X=19 Y=00 ( I C) | 00:70BD: D0 FA BNE $70B9 1746:247: 70. 6 | A=FF:00 X=19 Y=00 ( I C) | 00:70B9: C8 INY 1746:247: 70. 8 | A=FF:00 X=19 Y=01 ( I C) | 00:70BA: D0 FD BNE $70B9 + Last 2 insns repeated 123 times - NMI interrupt (VBI) 1746:248: 11. 0 | A=FF:00 X=19 Y=7C ( I C) | 00:C17D: 2C 0F D4 BIT NMIST 1746:248: 15. 0 | A=FF:00 X=19 Y=7C ( V IZC) | 00:C180: 10 03 BPL $C185 1746:248: 18. 0 | A=FF:00 X=19 Y=7C ( V IZC) | 00:C185: 48 PHA 1746:248: 21. 0 | A=FF:00 X=19 Y=7C ( V IZC) | 00:C186: D8 CLD 1746:248: 23. 0 | A=FF:00 X=19 Y=7C ( V IZC) | 00:C187: DA PHX 1746:248: 26. 0 | A=FF:00 X=19 Y=7C ( V IZC) | 00:C188: 5A PHY 1746:248: 30. 0 | A=FF:00 X=19 Y=7C ( V IZC) | 00:C189: 8D 0F D4 STA NMIRES 1746:248: 35. 0 | A=FF:00 X=19 Y=7C ( V IZC) | 00:C18C: 6C 22 02 JMP (VVBLKI) 1746:248: 39. 2 | A=FF:00 X=19 Y=7C ( V IZC) | 00:0658: 68 PLA 1746:248: 39. 6 | A=FF:7C X=19 Y=7C ( V I C) | 00:0659: 8D 4B 0B STA $0B4B 1746:248: 39.10 | A=FF:7C X=19 Y=7C ( V I C) | 00:065C: 68 PLA 1746:248: 40. 2 | A=FF:19 X=19 Y=7C ( V I C) | 00:065D: 8D 4A 0B STA $0B4A 1746:248: 40. 6 | A=FF:19 X=19 Y=7C ( V I C) | 00:0660: 68 PLA 1746:248: 40.10 | A=FF:00 X=19 Y=7C ( V IZC) | 00:0661: 8D 49 0B STA $0B49 1746:248: 41. 3 | A=FF:00 X=19 Y=7C ( V IZC) | 00:0664: AE C3 06 LDX $06C3 1746:248: 41. 7 | A=FF:00 X=F3 Y=7C (NV I C) | 00:0667: 9A TXS Edited February 23, 2020 by drac030 typo 1 Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 23, 2020 Author Share Posted February 23, 2020 22 minutes ago, drac030 said: This is the SIO.SYS driver measuring the CPU speed, indeed. But something is busted here, as this code is not supposed to be executed in native mode. I just checked (65C816+AltirraOS+SDX 4.48), and it seems to run in emulation mode: Looking into it deeper, it's an issue with an earlier memory detection routine at $39F5, which leaves the CPU in native mode if no linear RAM is detected. The bug seems to be fixed in SDX 4.49c. I might back out part of the changes, then, as it seems that your '816 OS leaves the CPU in native mode while invoking (VVBLKI) while mine is switching to emulation mode first. 00:39F5: 64 32 STZ BUFRLO 00:39F7: 64 33 STZ BUFRHI 00:39F9: 64 34 STZ BFENLO 00:39FB: 18 CLC 00:39FC: FB XCE 00:39FD: A2 00 LDX #$00 00:39FF: 64 00 STZ $00 00:3A01: E6 34 INC BFENLO 00:3A03: A7 32 LDA [BUFRLO] 00:3A05: 49 FF EOR #$FF 00:3A07: 87 32 STA [BUFRLO] 00:3A09: C7 32 CMP [BUFRLO] 00:3A0B: D0 0A BNE $3A17 00:3A0D: 24 00 BIT $00 00:3A0F: 08 PHP 00:3A10: 49 FF EOR #$FF 00:3A12: 87 32 STA [BUFRLO] 00:3A14: 28 PLP 00:3A15: 10 07 BPL $3A1E 00:3A17: E8 INX 00:3A18: E0 FE CPX #$FE 00:3A1A: 90 E3 BCC $39FF 00:3A1C: B0 2E BCS $3A4C <--- bypasses SEC/XCE 00:3A1E: A5 34 LDA BFENLO 00:3A20: 8D 6B 0D STA $0D6B 00:3A23: A0 00 LDY #$00 00:3A25: A7 32 LDA [BUFRLO] 00:3A27: 49 FF EOR #$FF 00:3A29: 87 32 STA [BUFRLO] 00:3A2B: C7 32 CMP [BUFRLO] 00:3A2D: D0 18 BNE $3A47 00:3A2F: 24 00 BIT $00 00:3A31: 30 14 BMI $3A47 00:3A33: 49 FF EOR #$FF 00:3A35: 87 32 STA [BUFRLO] 00:3A37: A5 33 LDA BUFRHI 00:3A39: 69 07 ADC #$07 00:3A3B: 85 33 STA BUFRHI 00:3A3D: D0 E6 BNE $3A25 00:3A3F: C8 INY 00:3A40: E6 34 INC BFENLO 00:3A42: E8 INX 00:3A43: E0 FE CPX #$FE 00:3A45: 90 DE BCC $3A25 00:3A47: 8C 6C 0D STY $0D6C 00:3A4A: 38 SEC 00:3A4B: FB XCE 00:3A4C: 20 6B E4 JSR INTINV 00:3A4F: 58 CLI 00:3A50: 60 RTS Quote Link to comment Share on other sites More sharing options...
drac030 Posted February 24, 2020 Share Posted February 24, 2020 27 minutes ago, phaeron said: Looking into it deeper, it's an issue with an earlier memory detection routine at $39F5, which leaves the CPU in native mode if no linear RAM is detected. The bug seems to be fixed in SDX 4.49c. Ah, yes, the infamous 4.48 bug. Yes, it has been fixed within a week or something. Everything is okay then. 29 minutes ago, phaeron said: it seems that your '816 OS leaves the CPU in native mode while invoking (VVBLKI) while mine is switching to emulation mode first Yes. It is of course debatable, which approach is better, there are pros and cons in both (executing interrupts in emulation mode is probably better in terms of backward compatibility, executing them in native mode spares new programs switching to and fro and avoids hassle when the program running in native mode has relocated the stack outside the $01xx), the point is to keep the system environment consistent so that program(mer)s know what to expect. 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 26, 2020 Share Posted February 26, 2020 Wow... Avast antivirus has added Altirra to it's quiet mode definitions. 1 Quote Link to comment Share on other sites More sharing options...
Keatah Posted February 26, 2020 Share Posted February 26, 2020 Anti-virus companies often take things too far. Too far to the point of making your system annoying to use. Especially for hobbyists and enthusiasts. FWIW I've tried a/v products in the past, and always ended up removing them. Quote Link to comment Share on other sites More sharing options...
jamm Posted February 26, 2020 Share Posted February 26, 2020 9 hours ago, Rybags said: Wow... Avast antivirus has added Altirra to it's quiet mode definitions. Avast should be avoided anyway. https://www.vice.com/en_us/article/qjdkq7/avast-antivirus-sells-user-browsing-data-investigation 4 Quote Link to comment Share on other sites More sharing options...
tmp Posted February 27, 2020 Share Posted February 27, 2020 i'm playing with the custom device functionality and i noticed that i'm getting doubled requests to device server on reads if the instruction is being stepped which is problematic in my scenario i'm assuming it's because altirra is "prefetching" the value at the moment i get to the instruction to display stuff like this (108805: 68, 26) A=FF X=00 Y=01 S=F9 P=33 ( ZC) 0778: AD 20 D5 LDA $D520 [$D520] = $00 the second request is when the instruction is actually executed is it possible to somehow disable this? (closing console isn't enough) thanks Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 28, 2020 Author Share Posted February 28, 2020 9 hours ago, tmp said: i'm playing with the custom device functionality and i noticed that i'm getting doubled requests to device server on reads if the instruction is being stepped which is problematic in my scenario i'm assuming it's because altirra is "prefetching" the value at the moment i get to the instruction to display stuff like this (108805: 68, 26) A=FF X=00 Y=01 S=F9 P=33 ( ZC) 0778: AD 20 D5 LDA $D520 [$D520] = $00 the second request is when the instruction is actually executed is it possible to somehow disable this? (closing console isn't enough) You probably need to implement debug reads for your custom device. Internally, Altirra has an alternate code path for issuing reads without side effects so that the debugger can inspect memory without affecting state. In a custom device, this is done either with the debug_script member of a scripted read handler or the debug_read_byte handler in the network server. This is also used by some acceleration features to do pre-checks before committing to accelerating an operation. 1 Quote Link to comment Share on other sites More sharing options...
tmp Posted February 28, 2020 Share Posted February 28, 2020 thanks, i'll try that Quote Link to comment Share on other sites More sharing options...
phaeron Posted March 12, 2020 Author Share Posted March 12, 2020 http://www.virtualdub.org/beta/Altirra-3.90-test28.zip http://www.virtualdub.org/beta/Altirra-3.90-test28-src.zip AltirraOS updated to 3.25 with a fix for screen memory corruption above RAMTOP. Percom AT-88 emulation support. (This will not work for AT88-S1PD or AT88-SPD firmware... but if you have one of those I am keenly interested.) 6809 emulation fixes for TST direct and CWAI instructions and with interrupt nesting in history traces. Fixed a bug with bogus FDC interrupts from Force Interrupt commands that was breaking the AT-88. Custom device updates: .atdevice format rewritten because I couldn't stand JSON anymore. It is now completely script format based, which means no more goofy workarounds for quoting and hex constants and being able to write inline scripts naturally. Any existing .atdevice scripts will have to be rewritten. Spec and samples have been updated. Added support for conditional script compilation, which allows debug read and non debug read handlers to use the same script with annotations. 10 5 Quote Link to comment Share on other sites More sharing options...
cRc_atari Posted March 15, 2020 Share Posted March 15, 2020 The "dlist" command does not display properly. Quote Link to comment Share on other sites More sharing options...
phaeron Posted March 15, 2020 Author Share Posted March 15, 2020 1 hour ago, cRc_atari said: The "dlist" command does not display properly. The dlist/.dlist command dumps the display list from the hardware display list pointer, in ANTIC's DLISTL/DLISTH registers. The location you've identified is the OS SDLSTL/SDLSTH shadow for those registers. A difference between these two can occur for several reasons: The display list has already partially been executed for the frame. The OS VBLANK routine has not yet loaded new values for SDLSTL/SDLSTH into the hardware, or OS VBLANK stage 2 is not running because of the I flag or CRITIC. You've managed to scramble the display list execution by changing the HSCROL register at the wrong time with horizontal scrolling enabled. The latter is the most likely case given the above screenshot. Use the .dlhistory command to dump the per-scanline display list history and identify where the display list is breaking. 2 Quote Link to comment Share on other sites More sharing options...
cRc_atari Posted March 15, 2020 Share Posted March 15, 2020 thanks, the .dlhistory works correctly Quote Link to comment Share on other sites More sharing options...
phaeron Posted March 17, 2020 Author Share Posted March 17, 2020 http://www.virtualdub.org/beta/Altirra-3.90-test29.zip http://www.virtualdub.org/beta/Altirra-3.90-test29-src.zip AltirraOS updated to 3.26 with a fix for end character corruption when drawing lines in GR.0 (which was fallout from another fix for drawing lines in GR.0). 5 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted March 19, 2020 Share Posted March 19, 2020 @phaeron perhaps '.caslogdata' be made consistent with other toggle settings and use 'on' and 'off' parameters (e.g. '.tracecio') so that entering the command shows the state rather than toggles it? Quote Link to comment Share on other sites More sharing options...
phaeron Posted March 20, 2020 Author Share Posted March 20, 2020 17 hours ago, Wrathchild said: @phaeron perhaps '.caslogdata' be made consistent with other toggle settings and use 'on' and 'off' parameters (e.g. '.tracecio') so that entering the command shows the state rather than toggles it? That command is actually pretty old and I'd rather remove it instead -- does the CASDATA logging channel work for what you're doing? Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted March 20, 2020 Share Posted March 20, 2020 7 hours ago, phaeron said: does the CASDATA logging channel work for what you're doing? I was initially looking to help out on this thread but then it sounds as if the OP's issue is more in the wav2cas stage than using Altirra. Enabling the '.caslogdata' gives the extra detail: CAS: Reading block[82] = 20 (pos = 161.861s) So whether you'd actually ever see an error within block I'm not sure? Whereas the following line always appears: CAS: Completed read with status 01 to buffer $03FD; control=FA, position=161.88s (cycle 5173633), baud=599.45s, checksum=B1 Is there a way to disable that? Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 20, 2020 Share Posted March 20, 2020 (edited) Firmware doesn't appear to necessarily inherit the 'set as default' property when the default firmware is removed or the default flag is not explicitly set. I just set Rapidus up for testing purposes and was tearing my hair out trying to figure out why I couldn't get the Rapidus menu to come up until I realised I'd forgotten to set the 'default' flag on the 'Altirra Rapidus Bootstrap 65816 PBI Firmware (internal)' entry under 'Rapidus Core PBI Firmware'. I had previously (erroneously) attached the flash ROM to that node instead of under 'Rapidus Flash Firmware'. Realising my mistake, I attached the ROM file to 'Rapidus Flash Firmware' and set the default flag, but forgot to do the same on the internal core firmware entry (even though it was the only core firmware component once I had detached the external ROM). It wouldn't work until I remembered to do that. Edited March 20, 2020 by flashjazzcat typo Quote Link to comment Share on other sites More sharing options...
phaeron Posted March 21, 2020 Author Share Posted March 21, 2020 (edited) http://www.virtualdub.org/beta/Altirra-3.90-test30.zip http://www.virtualdub.org/beta/Altirra-3.90-test30-src.zip Firmware loader now falls back to next available firmware if the default firmware for a type has been removed. Removed .caslogdata debugger command and improved the CASDATA and CASDATA2 logging channels to compensate. 19 hours ago, Wrathchild said: I was initially looking to help out on this thread but then it sounds as if the OP's issue is more in the wav2cas stage than using Altirra. Enabling the '.caslogdata' gives the extra detail: CAS: Reading block[82] = 20 (pos = 161.861s) So whether you'd actually ever see an error within block I'm not sure? No, you will never see an error within a block. The only error that can be detected within a block is a framing error, and the logging doesn't report that until the end of the block. Within a data block, the only checkable bits are the start and stop bits, and even only the stop bit is checkable because asynchronous reception takes any '0' bit as a start bit. The only way any error in the data bits can be detected is through the checksum, and that doesn't have the ability to identify the location of the errors. The CASDATA logging channel reports this same data identically ("lfe casdata"), though it also reports some additional spew. I've split that off into a new CASDATA2 channel and also improved the CASDATA logging so it is the same between the accelerated and non-accelerated paths. "lfe casdata" should now show the same data that .caslogdata did. Quote Whereas the following line always appears: CAS: Completed read with status 01 to buffer $03FD; control=FA, position=161.88s (cycle 5173633), baud=599.45s, checksum=B1 Is there a way to disable that? "lfd cas" will disable this logging channel, which is enabled by default. However, the CAS logging channel is also where the .caslogdata output goes, so disabling this channel will nullify that option. The CAS logging channel also reports block read errors when C: acceleration is enabled. 14 hours ago, flashjazzcat said: Firmware doesn't appear to necessarily inherit the 'set as default' property when the default firmware is removed or the default flag is not explicitly set. I just set Rapidus up for testing purposes and was tearing my hair out trying to figure out why I couldn't get the Rapidus menu to come up until I realised I'd forgotten to set the 'default' flag on the 'Altirra Rapidus Bootstrap 65816 PBI Firmware (internal)' entry under 'Rapidus Core PBI Firmware'. I had previously (erroneously) attached the flash ROM to that node instead of under 'Rapidus Flash Firmware'. Realising my mistake, I attached the ROM file to 'Rapidus Flash Firmware' and set the default flag, but forgot to do the same on the internal core firmware entry (even though it was the only core firmware component once I had detached the external ROM). It wouldn't work until I remembered to do that. Fixed. The firmware itself isn't marked as default, there's a pointer per type that points to the default firmware for that type. The bug was that it wasn't verifying if the default firmware still existed before trying to use it; now it should fall back. Edited March 21, 2020 by phaeron #*$ auto-emoji 6 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted March 21, 2020 Share Posted March 21, 2020 4 hours ago, phaeron said: Fixed. The firmware itself isn't marked as default, there's a pointer per type that points to the default firmware for that type. The bug was that it wasn't verifying if the default firmware still existed before trying to use it; now it should fall back. Wow - that was fast. Thanks so much Avery. Quote Link to comment Share on other sites More sharing options...
RSA Posted March 27, 2020 Share Posted March 27, 2020 Altirra is a fenomenal piece of work. Even the reference manual is gold. Any chance of open sourcing the code? 1 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.