Altirra 4.00 released

[TheRaven81]

Using Altirra 4.01 - the 1 and 2 number keys in the top row do not work entirely for some reason now? If I simply press them, to try and type the numbers 1 or 2, then it doesn't work. They DO work to produce the symbols ! and @ if I hold shift and press them. Holding Ctrl, 1 does nothing, 2 produces a short buzz sound. 

I stepped back a few versions to check - 4.00 has the same problem, but in 3.91 the aforementioned keys work as they should. So I'm not sure what the problem is with version 4.x .   

Edited December 1, 2022 by TheRaven81
Additional info

[Ricky Spanish]

On 11/21/2022 at 10:57 PM, _The Doctor__ said:

maybe on the additions.atr included in the download....

I'll check that out, thanks !

[Mclaneinc]

6 minutes ago, Ricky Spanish said:

I'll check that out, thanks !

If you look at my post directly under the quoted one it tells you a bit of extra info..

[Ricky Spanish]

5 hours ago, Mclaneinc said:

If you look at my post directly under the quoted one it tells you a bit of extra info..

Thanks. I thought there was a more recent version ?

 

[phaeron]

10 hours ago, TheRaven81 said:

Using Altirra 4.01 - the 1 and 2 number keys in the top row do not work entirely for some reason now? If I simply press them, to try and type the numbers 1 or 2, then it doesn't work. They DO work to produce the symbols ! and @ if I hold shift and press them. Holding Ctrl, 1 does nothing, 2 produces a short buzz sound. 

I stepped back a few versions to check - 4.00 has the same problem, but in 3.91 the aforementioned keys work as they should. So I'm not sure what the problem is with version 4.x .   

Odd. The only change to the keyboard handling between 3.91 and 4.00 was that the default keyboard shortcut for toggling audio channels was changed from Ctrl+Alt+1-4 to Alt+Shift+1-4. But that shouldn't affect typing the keys normally, nor would it only affect 1 and 2 without also affecting 3 and 4.

 

Try disabling all input maps on all four controller ports, to rule out one of them stealing the keys, and in keyboard options (Configure System > Peripherals > Keyboard), switch to one of the built-in Natural or Direct layouts instead of Custom, to rule out issues with a stale custom keyboard layout.

 

[TheRaven81]

1 hour ago, phaeron said:

Odd. The only change to the keyboard handling between 3.91 and 4.00 was that the default keyboard shortcut for toggling audio channels was changed from Ctrl+Alt+1-4 to Alt+Shift+1-4. But that shouldn't affect typing the keys normally, nor would it only affect 1 and 2 without also affecting 3 and 4.

 

Try disabling all input maps on all four controller ports, to rule out one of them stealing the keys, and in keyboard options (Configure System > Peripherals > Keyboard), switch to one of the built-in Natural or Direct layouts instead of Custom, to rule out issues with a stale custom keyboard layout.

 

 

I've been using the Natural layout for as long as I have been using Altirra(started at 3.20, so not really that long ago), so I don't know where or how this symptom occurred. I can still produce a 1 or a 2 if I use the keys on the Numpad, so there's that as a workaround I guess.

[phaeron]

33 minutes ago, TheRaven81 said:

I've been using the Natural layout for as long as I have been using Altirra(started at 3.20, so not really that long ago), so I don't know where or how this symptom occurred. I can still produce a 1 or a 2 if I use the keys on the Numpad, so there's that as a workaround I guess.

Use System > Hold Keys For Reset and see if 1 and 2 show up on the right side when you press them.

[+gnusto]

You could see if this is anything configuration related at all by launching Altirra from the command line with "Altirra64.exe /portabletemp", then use File->Attach Special Cartridge, select basic (you'll get built in Altirra basic). Then you can type and do keyboard stuff interactively with a "clean" copy of Altirra. If that works, well it's got to be something in your config, somewhere.

[TheRaven81]

1 hour ago, phaeron said:

Use System > Hold Keys For Reset and see if 1 and 2 show up on the right side when you press them.

Nothing. The red box showed up that said "Press keys to hold on next reset:", but nothing happened when I pressed 1 or 2.

 

 

1 hour ago, gnusto said:

You could see if this is anything configuration related at all by launching Altirra from the command line with "Altirra64.exe /portabletemp", then use File->Attach Special Cartridge, select basic (you'll get built in Altirra basic). Then you can type and do keyboard stuff interactively with a "clean" copy of Altirra. If that works, well it's got to be something in your config, somewhere.

OK - did what you said, and now they DO work, so now to figure out where in the config lies the problem. 🤔

[TheRaven81]

Quote

so now to figure out where in the config lies the problem. 🤔

Found it. "Tools > Keyboard Shortcuts" - Right at the top under "Bound commands:" were the 2 offenders. "File.QuickLoadState" was set to 1, and "File.QuickSaveState" was set to 2. 
I removed them and now it's working fine. Somehow I don't remember setting that up at all, but it's quite possible I did and forgot? (maybe the consequence of finally getting old haha)

 

So, I apologize for the confusion, but thank you for your help.

[mirao]

Just hit a strange issue with value in DLIST produced by the debugger's command ".antic".
If I boot Atari 800XL to self test, run debugger (F8), run ".antic", continue (F8), break again (F8), run ".antic", continue (F8) etc., I'm getting various values in DLIST:

Sometimes I get correct value "5134" (equals value in SDLSTL), but sometimes incorrect one, e.g. "5147", "514C" etc.. (though SDLSTL still contains $5134)

Is it normal? 

Update: Also start of dlist produced by ".dumpdlist" changes

Edited December 6, 2022 by mirao

[phaeron]

6 hours ago, mirao said:

Just hit a strange issue with value in DLIST produced by the debugger's command ".antic".
If I boot Atari 800XL to self test, run debugger (F8), run ".antic", continue (F8), break again (F8), run ".antic", continue (F8) etc., I'm getting various values in DLIST:

Sometimes I get correct value "5134" (equals value in SDLSTL), but sometimes incorrect one, e.g. "5147", "514C" etc.. (though SDLSTL still contains $5134)

Is it normal? 

Update: Also start of dlist produced by ".dumpdlist" changes

It takes a bit of understanding of the way the display list works in ANTIC to understand what's going on here.

 

Unlike some other display controllers, ANTIC doesn't remember the start of the display list. It only remembers the current display list address that it's going to fetch the next display list instruction from. This is ANTIC's equivalent to the 6502's PC. DLISTL and DLISTH are the registers that contain the low and high bytes of this address. This is why the .antic command reports a different address -- when you stop the debugger mid-screen, ANTIC is in the middle of processing the display list. SDLSTL/SDLSTH do always contain the start of the display list, but those are OS shadow variables and not hardware registers. They also effectively don't exist if the OS VBI handler has been disconnected.

 

This behavior is also why DLISTL and DLISTH should ordinarily only be written during vertical blank, since that's the only time where it's guaranteed that the display list is frozen and will restart cleanly afterward. Writing DLISTL and DLISTH mid-frame to try to switch the screen doesn't set the display list address for the next frame, it changes the display list address immediately. In the best case, this just results in one frame of corrupted display, due to the next screen starting mid-frame or running random memory as a display list. But there are worse issues that can happen with DLIs running at the wrong times and in the wrong order that can potentially crash a game. There are also pathological cases involving vertical scrolling since the vertical scroll state carries across VBLANK, and can lead to the display list getting stretched out beyond 240 lines and persistently displaying wrong. Thus, it's a lot safer to only write DLISTL or DLISTH in vertical blank, or use SDLSTL/SDLSTH to have the OS write DLISTL/DLISTH for you.

 

Similarly, the .dumpdlist command only shows the remainder of the display list from the current position since it starts from the DLISTL/DLISTH pointers. You can tell it another address to use, or supply dw(sdlstl) to use the OS pointer. The command doesn't try to determine the current starting address for the display list because there are lots of ways this can fail, such as the display list having been partially changed mid-frame, or the display list not being terminated, or the display list having a JVB instruction to an address that's actually wrong because it's always preempted by DLISTL/DLISTH writes in the VBI. Thus, the debugger errs on the side of making sure it's never lying to you.

 

If you want to see what ANTIC actually executed, then .dlhistory is the command that you want. It will show the log of display list entries that were executed even if they've already been overwritten in memory.

 

[mirao]

15 hours ago, phaeron said:

 

If you want to see what ANTIC actually executed, then .dlhistory is the command that you want. It will show the log of display list entries that were executed even if they've already been overwritten in memory.

 

Yeah, that shows executed display list with SDLSTL as a start point always. And I forgot that DLIST register exists.
Also ".dumpdlist dw(SDLSTL)" is the stuff I needed to see.

Thank you very much.

[mirao]

When I paste a text into Debugger console, a command that was prepared in console is overwritten by pasted text.
E.g. if I type "db", then copy an address (e.g. 505B) in Disassembly view (Ctrl + C) and paste it at the end of "db" (Ctrl + V), I get "5064" instead of "db 5064"

Or is it an issue in Wine only?

[phaeron]

5 hours ago, mirao said:

When I paste a text into Debugger console, a command that was prepared in console is overwritten by pasted text.
E.g. if I type "db", then copy an address (e.g. 505B) in Disassembly view (Ctrl + C) and paste it at the end of "db" (Ctrl + V), I get "5064" instead of "db 5064"

Or is it an issue in Wine only?

This is strange. I'm not seeing this, but I might not be doing the same steps. How are you activating the console command line window to paste, are you clicking in it or using the keyboard (Alt+2)? Also, is the text getting auto-selected after activation and before paste?

[mirao]

13 hours ago, phaeron said:

This is strange. I'm not seeing this, but I might not be doing the same steps. How are you activating the console command line window to paste, are you clicking in it or using the keyboard (Alt+2)? Also, is the text getting auto-selected after activation and before paste?

I'm clicking into the console. I'm selecting a text by holding left mouse button and moving to the right.

See the video.
 

[Mclaneinc]

Works fine here using the traditional Crtl C and Crtl V combinations, I can pretype the db into the console window and then ctrl+C the address from the dissasembly window, and  then Ctrl+V address into the console, hit return and it does what it should do.

 

Just in case, the db isn't highlighted before you do the paste of the address? is it?

 

If it is then the paste will erase the db, I type db and a space then paste the address.

Edited December 11, 2022 by Mclaneinc

[mirao]

1 hour ago, Mclaneinc said:

Just in case, the db isn't highlighted before you do the paste of the address? is it?

 

If it is then the paste will erase the db, I type db and a space then paste the address.

No, it wasn't that case, the text cursor was placed after "db" and "db" wasn't highlighted.

Are you running Altirra on Windows?

[Mclaneinc]

Yes I am, Windows 10 to be exact, I know you are running under Wine but I have no real experience of that OS.

 

It does seem to sound like a mixed OS situation, but if anyone can sort it (as long as it's not a specific Wine needed fix), Phaeron can..

[dmsc]

Hi!

On 12/11/2022 at 10:10 AM, mirao said:

No, it wasn't that case, the text cursor was placed after "db" and "db" wasn't highlighted.

Are you running Altirra on Windows?

 

It is a problem with Wine, pasting to the debug command window clears the text. Should be reported to the wine developers.

 

Have Fun!

[mirao]

18 hours ago, dmsc said:

It is a problem with Wine, pasting to the debug command window clears the text. Should be reported to the wine developers.

https://bugs.winehq.org/show_bug.cgi?id=54182

[phaeron]

https://www.virtualdub.org/beta/Altirra-4.10-test28.zip
https://www.virtualdub.org/beta/Altirra-4.10-test28-src.7z

• Adds preliminary support for ELF/DWARF5 debugging symbols emitted by LLVM-MOS. For this to work you need to build with -g and have the .elf file available for the debugger to load. Only functions and line number info are currently supported; locals are not currently supported as there are issues with LLVM-MOS not emitting location information for them.
• The debugger now supports showing source lines in disassembly view. This relies on having a source window open to pull the source lines from; otherwise, it will just show the filename and line number.
• Fixed a bug with parsing of ##BANK annotations in MADS list files -- the first digit of decimal bank numbers was dropped. Hex bank numbers were OK.
• Added support for copying text as hex and copying/pasting control symbols as Unicode, and fixed a bug where sometimes text was not properly fetched from the clipboard as Unicode.

 

[mirao]

17 hours ago, phaeron said:

The debugger now supports showing source lines in disassembly view. This relies on having a source window open to pull the source lines from; otherwise, it will just show the filename and line number.

Very useful, thanks. Maybe line numbers could be displayed in a source file too - at the begin of line, if enabled by user.

 

I noticed an issue if I step over a macro instruction in a source file.

E.g. have this state:

Debugger console logs

( 36:159,108) A=0A X=20 Y=26 S=F9 P=33 (    ZC)  060C: A9 34             LDA #$34

 

Now if I press F10 once, I would expect this log

( 53: 84, 11) A=0A X=20 Y=26 S=F9 P=33 (    ZC)  060C: A9 34             LDA #$34
( 53: 84, 13) A=34 X=20 Y=26 S=F9 P=31 (     C)  060E: 8D 07 D4          STA PMBASE   [$D407]
( 53: 84, 17) A=34 X=20 Y=26 S=F9 P=31 (     C)  0611: A9 00             LDA #$00

but I'm getting

( 53: 84, 11) A=0A X=20 Y=26 S=F9 P=33 (    ZC)  060C: A9 34             LDA #$34
( 53: 84, 17) A=34 X=20 Y=26 S=F9 P=31 (     C)  0611: A9 00             LDA #$00

 

It works well in a disassembly view where F10 must be pressed twice to get the above state (two real instructions in one macro instruction).

[Thelen]

19 hours ago, phaeron said:

The debugger now supports showing source lines in disassembly view. This relies on having a source window open to pull the source lines from; otherwise, it will just show the filename and line number.

That sounds interesting, hope to try that soon!

Thanks for the updates!

[phaeron]

2 hours ago, mirao said:

Now if I press F10 once, I would expect this log

( 53: 84, 11) A=0A X=20 Y=26 S=F9 P=33 (    ZC)  060C: A9 34             LDA #$34
( 53: 84, 13) A=34 X=20 Y=26 S=F9 P=31 (     C)  060E: 8D 07 D4          STA PMBASE   [$D407]
( 53: 84, 17) A=34 X=20 Y=26 S=F9 P=31 (     C)  0611: A9 00             LDA #$00

but I'm getting

( 53: 84, 11) A=0A X=20 Y=26 S=F9 P=33 (    ZC)  060C: A9 34             LDA #$34
( 53: 84, 17) A=34 X=20 Y=26 S=F9 P=31 (     C)  0611: A9 00             LDA #$00

 

It works well in a disassembly view where F10 must be pressed twice to get the above state (two real instructions in one macro instruction).

The console window only displays the next instruction to execute, not a running log of every instruction executed. You'll also see instructions skipped even in assembly mode when stepping over JSRs or interrupts. For an actual log of instructions executed, use the History View or history command (h).

 

21 minutes ago, Thelen said:

That sounds interesting, hope to try that soon!

It's highly dependent upon the quality of line number information. Unfortunately, the line number info from LLVM-MOS seems to be pretty disappointing even at -Og, as it has problems with emitting large sections of code at line 0 compared to normal Clang:

 

https://gcc.godbolt.org/z/bWKb65ncv

 

Haven't tried it with cc65 output, though it should work better as IIRC that compiler's code generation is more straightforward. Probably not too useful with straight asm as most things will just map 1:1.