Jump to content
IGNORED

Altirra 3.20 released


phaeron

Recommended Posts

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.

 

  • Like 10
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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 by drac030
typo
  • Like 1
Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

  • Thanks 1
Link to comment
Share on other sites

  • 2 weeks later...

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.

 

 

  • Like 10
  • Thanks 5
Link to comment
Share on other sites

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.

 

  • Like 2
Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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?

 

Link to comment
Share on other sites

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 by flashjazzcat
typo
Link to comment
Share on other sites

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 by phaeron
#*$ auto-emoji
  • Like 6
  • Thanks 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...