matosimi Posted September 9, 2013 Share Posted September 9, 2013 Hi, i'm currently using atari800winplus4.1 which is quite outdated. I would like to switch to altirra, but I cannot use its debugger - i dont know how to. I also cannot get used to monitor commands and i hate when command window losts focus. is there any guide how to effectively use debugger in altirra with its unique features? i just found CHM file with brief description, but I would need something better, screen based... ideally video based. do we have something like that already? Quote Link to comment Share on other sites More sharing options...
carmel_andrews Posted September 9, 2013 Share Posted September 9, 2013 Are you doing all your games dev. work via emulation then or splitting it via emulation and real hardware Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 9, 2013 Share Posted September 9, 2013 You could check out the youtube tutorials on WUDSN by Peter Dell (Jac!). I don't recall if they cover source-level debugging with Altirra, but they might. Quote Link to comment Share on other sites More sharing options...
phaeron Posted September 10, 2013 Share Posted September 10, 2013 This depends a lot on the type of debugging you are doing. Regarding the focus issue, I'd be interested in what scenarios you're seeing focus loss in. Also, make sure you're using a recent version, 2.30 or 2.40-test. I'm afraid I don't have tutorial videos, but here's a dump of tips: General The debugger has built-in help. Use [.help] to get a list of commands and [.help command] to get help on a specific command. Essential keyboard shortcuts: F8 (run/stop), F10 (step over), F11 (step into) In the command line, Up/Down accesses command history, Shift+Up/Down scrolls the output portion, and Enter repeats last command with continuation. Newer versions of the debugger support tabs; use View > Reset Window Layout if you have the old layout, and you should get the new, more compact default layout with stacked Registers/Disassembly/History. You can manually stack tabs by dragging them and hovering over the center of a docking diamond. If you are running Altirra through WINE, reset the font in Debug > Options > Font. It's supposed to be a monospace font, but WINE lacks one of the standard fonts. The default radix is mixed, which allows bare hex except in an expression: 10 = $10 = (16). Use [.base dec] or [.base hex] to force a different radix. Create a text file called startup.atdbg in the program dir if you have favorite commands you want to run on startup. Assemble/run setup If you are using MADS, build labels (-t) and a listing (-l). .lab and .lst files with the same name as an .xex will automatically get picked up if you start the .xex from the emulator. You really want labels loaded. If you are loading the executable from DOS, use the .loadsym command to manually load labels and listings. The /singleinstance command-line switch is very useful as it forces reuse of an already running instance of the emulator, regardless of the setting in Options. It allows a batch file to build the program and automatically launch it in the existing debugger without restarting it, keeping history and settings. If you have data files, consider using virtual disk mounting to avoid having to constantly rebuild a disk image. This is done through the [F] button in the Disk Drive dialog in versions through 2.20, and the right arrow drop-menu in 2.30+. The virtual disk driver monitors for file changes and will automatically update the virtual disk when a host file changes. You can also use the host device (H:) for this, if you are using CIO. When using MADS with a listing file loaded, you can automatically set conditional breakpoints through comments that begin with ;##ASSERT and ;##TRACE. Examples: [;##TRACE "dy = %d" db(deltar)] and [;##ASSERT dw(oldadr) >= dw(savmsc)]. TRACEs print out info using .printf syntax, and ASSERTs stop if the condition is false. These will show up in [bl] output if they were picked up correctly. 6502 debugging (immediate) Use [t] or F11 to step by one instruction, [o] or F10 to step over one instruction (skips calls and interrupts), and [g] to continue execution. Use [r] to get your bearings without looking at the Register window or to change registers: [r pc $0600]. Use [a8] to set aliases to match most Atari800 debugger commands. Use [.help a8] to see the mappings from Atari800 commands to Altirra commands. To set a breakpoint, use [bp address]. [bl] lists breakpoints, and [bc] clears breakpoints (by index, not address). The index is shown in [bl] output or when you set the breakpoint, i.e. "Breakpoint 0 set at address $A000." Use [bc *] to clear all breakpoints. To set a data breakpoint on an address, use [ba]. For instance, [ba r vcount] will set a read breakpoint on VCOUNT, and [ba w d300 L100] will break on any writes into the PIA region. To set a conditional breakpoint, use [bx "condition"]. This can be either a PC or a data breakpoint: [bx "write=irqen and pc>$c000 and (value&8)"] will fire when the OS enables the serial output complete interrupt. Breakpoints can automatically execute a list of commands when they fire, separated by semicolons. This is most useful in conjunction with the .printf command: [bp siov ".printf \"SIO request from $%04X\" (pc); g"]. The set tracepoint [bt] command makes this easier in 2.40-test. [k] dumps the call stack, if you want to know what called the current routine (or more precisely, where it will return to). To modify memory, use [e]: [e 4000 00 01 03]. To display memory, use db (display byte). There are also dw (word), dd (doubleword), df (decimal float), da (ATASCII string), and di (INTERNAL string). If you only want to view one byte or word, and particularly if you want to see decimal, use [? db(address)] or [? dw(address)]. [ln] does a lookup from address to symbol. [?] evaluates an expression. Useful for checking out state, and very useful when you're bad at math or just need a dec/hex conversion. [.vectors] dumps out a list of OS and CPU vectors. [.bank] and [.pia] show the memory banking and PIA state, respectively, and are useful for debugging extended memory usage bugs. Extended addressing syntax also allows the debugger to access xmem directly even if it isn't banked in: [db x:$8000]. [.map] shows the status of all memory layers. It's most useful to tell when you've accidentally enabled BASIC or the self-test ROM, or forgot to disable a cartridge. When debugging a program that takes over the whole machine, use [.unloadsym kerneldb] to unload the OS kernel database symbols so you don't see OS symbols where low page zero is reused. Quick-assemble small code fragments with [a address]. Type one line of asm at a time and hit Enter alone to end. It's useful to enable System > CPU > Stop on BRK instruction. 6502 debugging (deferred) Enable instruction-level history (System > CPU > Record instruction history). This enables the History debug pane, which is extremely useful for telling what happened after the fact. It has a tree-view that collapses loops, subroutine calls, and interrupts, making it easier to tell what's going on. I spend most of the time in the Console and History panes. For monitoring values over a long period of time and that correspond to on-screen activity, on-screen watches can be useful: [wb/ww] to watch a byte or word by address, and [wc] to clear. For instance, you can watch horizontal and vertical position values this way. Note that these only update once a frame. Path tracing can be useful to find out what the active regions of a program are. It is enabled either in CPU Options or with [.pathrecord on], and modified by the other path commands; executed code can be dumped with [.pathdump]. Another use for it is to find the exit path that responds to an input: use [.pathclear] to reset the path history, let the emulation run for a while to capture the loop path, then enable [.pathbreak on] and hit the joystick button or START to find out what responds to those buttons. 6502 optimization Profile View (Debug > Profile > Profile View) will show which portions of a program are using the most CPU time. Click on a header button to re-sort, and double-click on an entry to see annotated disassembly. The History window can also be used to assess performance: right click on the entry to a block and select [set Timestamp Origin], then right-click again and select [Timestamp Format > Show Cycles]. Every instruction in the history will then show when it relatively started in machine cycles. You can also use [Timestamp Format > Show Unhalted Cycles] to show how many CPU cycles were taken, ignoring DMA. Audio [.pokey] dumps POKEY state. Enable the audio monitor (Audio > Audio Monitor) to visually see what POKEY's audio channels are doing. Toggle individual audio channels with Ctrl+Alt+[1-4] to isolate squawking channels. BASIC [.basic] shows the current BASIC pointers and the memory taken by each region. [.basic_vars] dumps out all variables. [.basic_dumpline] dumps out a tokenized BASIC line by address. When running, i.e. not stopped in the debugger, shift+hover over an error message will translate the error code. Character I/O (CIO) [.tracecio on] will log all calls made to OS CIO, decoding parameters for some of them. It's most useful for figuring out what commands a program is issuing to DOS. The debug display (Debug > Window > Debug Display) can show you what is on the OS screen when your program crashes before ANTIC+GTIA have drawn it. [.ciodevs] dumps out all character devices registered in HATABS. [.iocb] dumps out the I/O control blocks. Disk I/O / SIO For sector-level access, enable the DISKCMD and HOOKSIO logging channels ([lfe diskcmd] / [lfe hooksio]). The debugger will then log which sectors are being read, and if regular OS SIO is being used, the SIO patch hook will also print out addresses. There are other useful logging channels: [lfl] to list. For hardware-level access, use [.traceser on] to get a dump of what bytes are going in and out of the serial port registers and whether overruns/underruns are happening. [bs sector] will fire a breakpoint when a particular disk sector is read. [.sio] dumps out the disk control block (DCB), which contains the current SIO request. [.diskdumpsec] will dump out a raw disk sector. You can explore the contents of any mounted DOS 2 or SpartaDOS disk by selecting Arrow -> Explore on a drive in the Disk Drives dialog. Files can then be dragged out of the Disk Explorer into the host filesystem. Graphics The display window will show the current beam position on screen as a yellow line, immediately below the beam position. [.antic] dumps ANTIC state, and [.gtia] dumps GTIA state. The go until scanline [gs] command is very useful for debugging graphics glitches. Typically I do [gs 240] or so until the glitch appears on-screen, then use the History window and the display list history to figure out what happened. The [gs] command automatically runs a full frame if you give it the vertical position that the beam is already on, so you can just spam it by alternating Up/Enter until a broken frame comes up. When execution is stopped, shift+hover over the display window will indicate beam position and display list activity for a point on screen. The display list history (.dlhistory) shows what ANTIC has executed. It's useful for telling whether something is going wrong with the display list. Conditional breakpoint expressions can include the horizontal and vertical beam position (hpos/vpos), so it's possible to have the debugger break when a DLI runs late or at the wrong time: [bx "pc=addr and vpos != 100"]. (2.40-test only) If your display list is glitching out when trying HSCROL tricks, enable Debug > Verifier > Abnormal playfield DMA. This will cause a break into the debugger when playfield DMA goes haywire when HSCROL is hit at the wrong time. Expansion hardware VideoBoard XE: [.vbxe] for general status, [.vbxe_bl] to dump a blitter command list, [.vbxe_xdl] to dump the extended display list, and [.vbxe_traceblits] to log blits. Ultimate1MB: [.ultimate] to dump status, [.ds1305] to dump real-time clock status. SIDE: [.ds1305] to dump real-time clock status. MyIDE/SIDE/IDEPlus: [.ide] to dump IDE status, [.ide_dumpsec] to dump out a sector, and [.ide_rdsec]/[.ide_wrsec] to do DMA to and from CPU memory. 17 Quote Link to comment Share on other sites More sharing options...
matosimi Posted September 10, 2013 Author Share Posted September 10, 2013 phaeron, thanks for comprehensive info... I don't know if this info is also on your web, but I believe it would be good to put it there, or maybe link this post... for future. I develop games entirely in emulator, i don't even test them on real hw personally, because i'm to lazy to get my 800xl out of closet and connect everything together, so I let other people to test real hw compatibility and I'm very happy there is still somebody who has no problem with performing such tests. I use PSPAD editor with my own highlighter settings for MADS, it provides quick keystrokes for compilation and run. It has also quite big undo buffer. quick bookmarks (alt+arrows) and some other great functions. Tried WUDSN, but it did not glamor me. I highly utilize macros, procedures and locals in MADS - that makes my code very well readable (at least for me), so no need to put huge IDE over it. i would need to study what altirra brings in terms of debugging, but it looks pretty good. These are functionalities i use for debugging (mainly in a800win monitor): - display memory contents - disassemble memory - fill memory - process 1 instruction - trace (very rarely) - setpc=$xxxx (set program counter) - breakpoints at addresses - if i need to define exception, i put "dta 2" into code, which is CIM - crash immediately. I learned this from bob!k few years ago when we talked about debugging at one of Forever demoparties. I believe thats all, quite basic stuff. If I understood correctly, altirra contains real debugger which uses labels and listing file - I will definitely look into this, it could really simplify bughunting. I would suggest to add 1 more optional debugger window that will contain only buttons for step into, step over and continue - maybe silly request, but I would appreciate it. Quote Link to comment Share on other sites More sharing options...
Creature XL Posted September 10, 2013 Share Posted September 10, 2013 phaeron, thanks for comprehensive info... I don't know if this info is also on your web, but I believe it would be good to put it there, or maybe link this post... for future. I develop games entirely in emulator, i don't even test them on real hw personally, because i'm to lazy to get my 800xl out of closet and connect everything together, so I let other people to test real hw compatibility and I'm very happy there is still somebody who has no problem with performing such tests. I use PSPAD editor with my own highlighter settings for MADS, it provides quick keystrokes for compilation and run. It has also quite big undo buffer. quick bookmarks (alt+arrows) and some other great functions. Tried WUDSN, but it did not glamor me. I highly utilize macros, procedures and locals in MADS - that makes my code very well readable (at least for me), so no need to put huge IDE over it. i would need to study what altirra brings in terms of debugging, but it looks pretty good. These are functionalities i use for debugging (mainly in a800win monitor): - display memory contents - disassemble memory - fill memory - process 1 instruction - trace (very rarely) - setpc=$xxxx (set program counter) - breakpoints at addresses - if i need to define exception, i put "dta 2" into code, which is CIM - crash immediately. I learned this from bob!k few years ago when we talked about debugging at one of Forever demoparties. I believe thats all, quite basic stuff. If I understood correctly, altirra contains real debugger which uses labels and listing file - I will definitely look into this, it could really simplify bughunting. I would suggest to add 1 more optional debugger window that will contain only buttons for step into, step over and continue - maybe silly request, but I would appreciate it. Altirra can do all this. Useful features you surely need (at least occasionally): - break-points at data access (read/write variables or registers) - multiple memory view windows - complete history of executed instruction (exact cycle in raster line) - conditional break-points (e.g. only stop at addr when X-register is >5) - profiler! 1 Quote Link to comment Share on other sites More sharing options...
matosimi Posted September 10, 2013 Author Share Posted September 10, 2013 (edited) I played a with altirra debugger a bit and I must admit it is GREAT! however i still don't know how to set program counter (PC)... it was SETPC=2400 in a800win. or how to set A,X,Y registers (SETA, SETX, SETY). Update: MaPa told me to use command "r"... so its: r pc 2000 <=> setpc=2000 r a 3f <=> seta=3f I also played with those labels, nice stuff, but i use quite long names for procedures and instructions do not look properly aligned in disassembler window - is it possible to change tabsize there? see: about that window focus... when I entered "g" in command line, I expected Display window to get focus... until next break that would change focus back to console window... Edited September 10, 2013 by matosimi Quote Link to comment Share on other sites More sharing options...
Rybags Posted September 10, 2013 Share Posted September 10, 2013 Breakpoints by address/range and type of access are extremely useful. Forget about using illegal instructions to force a crash, only to have to change back into NOP once you're done. I just use something like: BIT $D700 Then all you need is to set a trap for access to that address. When done, just unset the trap. Of course a good idea is to remember to remove all such debugging aids once the program is ready to release in the wild. It took some getting used to, maybe some weeks/months but once you're up to speed the Altirra system exceeds all others in speed and ease. Still, I would have liked the debugger to be a closer match to the commands in Atari's AsmEd cart but you can't have everything. Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 10, 2013 Share Posted September 10, 2013 thanks for all explanations... I am the one who mainly used the "a8" command in Altirra... but since for my latest projects I am nativly in debugger. So good to hear from others how to use best the built in features. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 10, 2013 Share Posted September 10, 2013 Totally missed the tabbed debugger display until now: thanks Avery. Wanted to see this for a long time - much better. Quote Link to comment Share on other sites More sharing options...
carmel_andrews Posted September 11, 2013 Share Posted September 11, 2013 (edited) Phaoron...An idea about your debugger How about a sub program call a 'load simulator', that works for tape (cas), disk (atr/x/dcm etc), executables (com/xex/exe) and cartridge (rom/car/bin), the idea is that as the program is loading it prints out or saves the data for that IO operation (whether it be disk, tape or cartridge) to computer memory for the entire time you use that tape/disk or cart image It will also tell the user any possible run or init addresses it comes across the way that the load similator will work is that it uses a section of PC memory as a blank Atari memory region (i.e. it does'nt contain any screen ram or any data above the user memory area (BFFF) so that the load similator can view where in memory the data is loading or has loaded, which would be ideal for programs that 'hard load' data above the user memory area (BFFF) and also for cartridges that load data in different areas of memory (i.e. those that have more then 16k) You could work the program to work with Atari programs that use a maximum of 320k (since there's very little programs that use more then 320k) since the load simulator will allow you to inspect bank switched memory as well and also tell the user what area/bank of bank switched memory a particular loaded or loading data has gone to The idea here is that it will let the user convert data from cartridge to disk or disk to executable or tape to disk or executable etc (since the sub program will let you save data as a binary file (atari dos compatible) and using the variosu binary to tape or disk/cart programs convert the file to a tape or disk or disk/tape menu or even cartridge Only thing is ofcourse this will only work for programs that don't alter the code/data on the disk or tape/cartridge that is loaded into memory (so therefore, programs like say operation blood, international karate, bounty bob etc, the data on the disk/tape image you don't be able to use since it doesn't correlate to what is loaded in memory but using the memory dump feature and also the run/init feature you will still be able to convert that data back into a binary file) Edited September 11, 2013 by carmel_andrews Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted September 11, 2013 Share Posted September 11, 2013 The sort of person looking to do what you say would be more than able to use the debugger to find all that.. Quote Link to comment Share on other sites More sharing options...
matosimi Posted September 11, 2013 Author Share Posted September 11, 2013 Uff, i've read phaeron's tips several times. but i always find something cool there... I also feel ashamed, because he also pointed out how to change registers there, but i overseen it before. its mainly because his post contains so many information so one can hardly handle it... anyway, i was surprised that Watch window supports my labels, thats really great, but I dont know what expression returns value of address/label I put into Watch window. (when i write just $C0, i get 192($C0) , but i would like to get value stored in $C0). Could anybody help me with this? Command line switch /singleinstance is GREAT - all windows remain preserved (watches, debug, memory). also .unloadsym kerneldb is very nice, it unloads "osrom" zeropage labels... which is handy when my app uses osrom for itself. 1 Quote Link to comment Share on other sites More sharing options...
matosimi Posted September 11, 2013 Author Share Posted September 11, 2013 (edited) MaPa helped me to solve "watches mystery" tonight... again solution is provided in .help, but not directly. it was not obvious... so watch windows serve like expression evaluator (calculator). in order to display value of address, i.e. $c0, you have to add line db $c0 into watch window. since it evaluates expressions, you can combine them like db $c0 + db $c1 that will obviously return sum of values on addresses $c0 and $c1. you can also display item of indexed array when index value is i.e. on address $a0 with expression db ($c0 + db $a0) - this will return value of address $c0 -> $1bf depending of value stored on $a0. Edited September 11, 2013 by matosimi 1 1 Quote Link to comment Share on other sites More sharing options...
Creature XL Posted September 12, 2013 Share Posted September 12, 2013 MaPa helped me to solve "watches mystery" tonight... again solution is provided in .help, but not directly. it was not obvious... so watch windows serve like expression evaluator (calculator). in order to display value of address, i.e. $c0, you have to add line db $c0 into watch window. since it evaluates expressions, you can combine them like db $c0 + db $c1 that will obviously return sum of values on addresses $c0 and $c1. you can also display item of indexed array when index value is i.e. on address $a0 with expression db ($c0 + db $a0) - this will return value of address $c0 -> $1bf depending of value stored on $a0. Just to add the obvious: dw (expr) displays the 16 bit value - useful for pointers Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 17, 2013 Share Posted September 17, 2013 is there any possibility with WUDSN/MADS to compile and run Altirra, labels loaded, os labels unloaded without any manual entering commands? Quote Link to comment Share on other sites More sharing options...
matosimi Posted September 17, 2013 Author Share Posted September 17, 2013 (edited) is there any possibility with WUDSN/MADS to compile and run Altirra, labels loaded, os labels unloaded without any manual entering commands? i believe so, i did not tested it, but phareon wrote this in general part of tips: Create a text file called startup.atdbg in the program dir if you have favorite commands you want to run on startup. -so you can put unload command there. all other stuff you require can be achieved just by correct compile command and run command of your IDE. Edited September 17, 2013 by matosimi Quote Link to comment Share on other sites More sharing options...
phaeron Posted September 18, 2013 Share Posted September 18, 2013 You can also create basename.atdbg next to basename.xex. Typically in this file you'll want queue commands to run when the RUN entry point is hit: .onexeclear .onexerun .unloadsym kerneldb Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 18, 2013 Share Posted September 18, 2013 And I need that to do for every source file separate? Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted September 18, 2013 Share Posted September 18, 2013 I guess startup.atdbg will be enough? Quote Link to comment Share on other sites More sharing options...
+Cafeman Posted December 29, 2019 Share Posted December 29, 2019 BUMP of this thread which I just found and read. Need help getting through Altirra debug commands. I used to use Atari800Win a lot more , so even though I've been using Altirra for 2 years now, I am still clumsy with the debug. I want to set a breakpoint in some code when a certain bank is activated. I am having no success at figuring out the syntax for a conditional breakpoint. How can I store a breakpoint if the memory location $A6 (in zero page) = the value of #$1B, for example? I tried stuff like this: bx $A6 = #$1B didn't get accepted bx $A6 = $1B get error message that condition is always false (of course) bx "$A6 = #$1B" didn't get accepted and others... I looked around and I was unsuccessful at finding samples that would have explained Altirra's syntax for Conditional Breakpoint -- help requested! Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 29, 2019 Share Posted December 29, 2019 6 minutes ago, Cafeman said: I was unsuccessful at finding samples that would have explained Altirra's syntax for Conditional Breakpoint To get a full explanation with examples, type: .help bx I'd use: bx "write = $A6 and value = $B1" There may be other shorthand ways of accomplishing the same thing of which I'm unaware. Quote Link to comment Share on other sites More sharing options...
+Cafeman Posted December 29, 2019 Share Posted December 29, 2019 Thank you! I didn't even know I could ".help bx" for more info. I entered that but it is not breaking. Could that be because the value of #$1B is getting into $A6 by the stmt "inc $a6" , and not by a STA ? EDIT - never mind that question, I should have been checking for #$1A - and the breakpoint activated when that happened. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted December 29, 2019 Share Posted December 29, 2019 5 minutes ago, Cafeman said: Could that be because the value of #$1B is getting into $A6 by the stmt "inc $a6" , and not by a STA ? No: read-modify-write instructions will trigger it too. If you typed it right and the breakpoint is not being tripped, the memory location presumably doesn't contain the target value. Quote Link to comment Share on other sites More sharing options...
phaeron Posted December 29, 2019 Share Posted December 29, 2019 The syntax for conditional breakpoint expressions is the same as evaluate command (?) -- use ".help ?" to get the operators. The bx command given by flashjazzcat is the best way to get what you want, as the emulator will turn it into a conditional memory write breakpoint. This traps when the location is written and checks if the value matches. You can see that the emulator has split the expression if you use the "bl" command to dump the breakpoint list. In recent versions you can actually directly set a breakpoint to test the value of the memory location: bx "db($A6) = $B1" ...but this is slow, as it has no event to trigger on and thus the debugger will give you a warning that it will be running this check every instruction. Also, note that if what you are actually trying to do is trap when code in a specific bank is being executed, recent versions of Altirra have shortcut syntax for this: "bp EF'4100" => break execution at PC=$4100 for bank when PORTB=$EF, and for an AtariMax cart, "bp t:$02'A000" stops at $A000 for bank $02 (write $D502). 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.