7 replies to this topic

[Heaven/TQA]

while starting developing again stuff and using Altirra as lead emulator I was wondering if I can avoid opening multiple instances of Altirra? in fast dev cycles like change bit here and bit there reassemble and launch I get multiple Altirra running... is there any way to simply open and reboot the already running version like it was done with Atari800win Emu?

[JAC!]

Not yet, but I already requested this feature from phaeron for the same reason.
"I'm looking at implementing this. The tricky part is that some of the existing options like /resetall depend on the init state and aren't as easy to implement on a running program, but I should be able to find a way around that."

Under Unix it's more simple, because you can use a shell script with ps/kill.

[phaeron]

Sorry, forgot to mention this. 2.00-test36 and above have support for single instance mode. It's an option in preferences, and it can be overridden from the command line with /singleinstance and /nosingleinstance. 2.00-test45 and above allow relative paths with single instance launch.

[1NG]

I love Altirra and I like that it is getting better and better. And the documentation brought with it about the Atari is really superb.
I can´t wait to use the new cool stuff like breakpoints directly from WUDSN (instead of an illegal opcode) in a stable release.

Edited by 1NG, Fri Oct 28, 2011 5:29 AM.

[Heaven/TQA]

uj... break point and back into IDE? that would be cool...

[JAC!]

>uj... break point and back into IDE? that would be cool...
In fact I find source in the emulator much more useful.
When you look at today IDEs, they all switch to some kind of "Debugging Perspective" once you really hit a breakpoint.
This perspective then contains stack, memory, variables, breakpoints, ...

Does that remind you of something :-)
So in fact Altirra is nothing else than what the kids today would call the debugging perspective.
As long as you can see the source there, it what you really need.

Apart from this, Eclipse of course offers remote (inter process) debugging features.
But to use them, you would have to support all debugging facilities via remote calls in the emualtor.
C.f. http://download.orac...hitecture.html.
Vice C64 Emulator has some of that, but is specific for the emulator.
Therefore I'll stick with the idea of the IDE as the bining part between Source/Compiler/Emulator.

[1NG]

As I mentioned breakpoints I thought of the feature of setting a breakpoint in the WUDSN IDE and see it in Altirra when debugging.
Fully integrated IDE has not much more to offer then the good cooperation of WUDSN and Altirra.
In Visual Studio it is possible to alter the source code while the debugger remains running. This is a very cool feature but with breakpoints (and even better conditional breakpoints) it is near to the integration. Maybe the same is possible in cooperation too, if the current state is saved (stack, registers and memory of variables) and restored after recompiling.

We are still speaking of developing 8 Bit which is and was a lot harder on the real machine. It has become way easier since I used WUDSN/Altirra/Mads for the Atari. Still developing software remains a lot of work. It is often said: Easy to understand but difficult to master. So everything that helps is welcome! (That’s one small step for man… one… giant leap for atari developing )

[phaeron]

Visual C++'s Edit and Continue feature depends on several capabilities that are difficult or impossible with 6502 assembly language:

• Every single function call goes through a jump table called the Incremental Link Table (ILT) that allows the linker to revector calls to a new version of a function. This is perfectly fine for a Win32 program. It's less tolerable for a DLI routine.
  
• The toolchain and debugger are in control of code relocation and can allocate and place new code as needed, whereas code is assembled at a fixed address on the Atari and there is usually no spare memory for expansion.
  
• Win32 code is generally immutable. Self-modifying code is very handy on a 6502.
  
• EnC doesn't support many important scenarios, particularly changes to global/static data. 6502 code uses static storage much more heavily since its stack indexing support is poor compared to modern CPUs. I gave up on EnC a long time ago as it simply didn't work most of the time for the code that I write (and it really bloats the pdbs).

I've thought about some sort of limited "reload XEX in place" function, but any self-modifying code or preinitialized mutable data makes that hard and the kinds of changes you could do with it would be very limited. Changes to constants you can just do in the debugger.

IDE remote debugging support is possible but the sheer amount of effort required to get that working is staggering. Pushing the debugger interface over RPC isn't the problem; the problem is the large portions of the debugger that would have to be reimplemented in the IDE platform itself, such as the disassembler. It would be very cool, but I doubt anyone will want to do it on top of an existing full-fledged IDE like Eclipse or Visual Studio. I've seen and worked with the IDebugEngine interfaces in Visual Studio and it's much more complex than what Altirra has internally.

The main limitation to elevating Atari debugging capabilities is the limited symbolic debugging information available from compilers and assemblers. So far I haven't succumbed to temptation yet, but I've been tempted to write my own assembler as the symbolic debugging information produced by the current assemblers ranges from insufficient to nonexistent, and I could do a lot more if I had information like the address ranges for procedures and which labels corresponded to addresses vs. constants, or even type information for data.

BTW, for fun, assemble this in MADS with listing (-l) enabled, and run it in Altirra's debugger:

	org	 $2000

main:
	nop

	;##TRACE "VDSLST = $%x" dw(vdslst)
	lda	#0

	;##ASSERT a > 0
	jmp	*

	run	main