Commander X16

BASIC has three uses:

1. Small programs that don't require speed.  Classic "business simulation" games from the 1970s.  Some PETSCII games like Lunar Lander.

--> Ambitious programs like Temple of Apshai can be written, but we're better off doing them in something other than BASIC.

2. Prototyping, as you mentioned.

3. Batch scripting.  In other words, as the pseudo shell command interpreter for Commodore machines.

 

On 9/29/2021 at 12:43 PM, Ju+Te said:

Whatever language I would use for developing serious software for the X8/16 hardware using a PC (even if it is just assembler) - it would be very cool to have some kind of hardware debugger available that allows me to step through the commands (in the language I use), see all the registers and memory contents. I had a disassembler and debugger on my 8-bit machine - without them I would not have been able to write that much code.

There's two things for the X16.  First, there's a built-in machine language monitor.  Second, the emulator has a debugger.  Third, there's a rather nicely featured assembly development environment that's .. well I thought it was in Downloads, but perhaps not.

Would it technically be possible to have a debugger work on the 6502, e.g. by setting an ultra short timer that fires an interrupt after having executed one command?

On 9/30/2021 at 9:36 AM, Ju+Te said:

Would it technically be possible to have a debugger work on the 6502, e.g. by setting an ultra short timer that fires an interrupt after having executed one command?

The simple method of step debugging without hardware support is to inject a BRK opcode immediately following the statement being executed. The BRK handler then  pulls the CPU state off the stack and replaces the original opcode. Obviously, your debugger needs to know the length of each opcode, but any decent debugger includes a disassembler, so the step debugger can look that up in the disassembler's opcode length table.

 

 

 

 

So this won't work for debugging the ROM?

PS: Sorry for having hijacked this thread.

On 9/28/2021 at 3:21 PM, rje said:

Yes, I'm old and distracted.



I guess I have to be talking about compiling and/or interpreting on the hardware.



Which is kind of moot:  I find it very hard to think of a reason to write code directly on these machines.



(1) Batch-like coding, e.g. testing something or launching something else.



(2) There doesn't appear to be a #2.



I had thought that perhaps some filtering could be done on the X16.  E.G. an AWK-like program that sifts file contents.



Not sure.



 

#2 Coding on a system that doesn't have a web browser to distract you from programming.

#3 Tinkering with hardware without an other system compile / transfer / test / edit / other system compile ... loop

On 9/30/2021 at 9:33 AM, rje said:

There's two things for the X16.  First, there's a built-in machine language monitor.  Second, the emulator has a debugger.  Third, there's a rather nicely featured assembly development environment that's .. well I thought it was in Downloads, but perhaps not.

Are you thinking of this environment? - https://sites.google.com/view/x16asmenv/home

The roadmap suggest that it will be in the ROM for the shipping version.





 

On 9/30/2021 at 12:41 PM, Ju+Te said:

So this won't work for debugging the ROM?



PS: Sorry for having hijacked this thread.

THAT topic is worth hijacking this thread for.

 

The emulator has a debug console.  So... potentially... you might be able to use it to debug the ROM.  In fact I betcha that's what was used to debug the emulator as it was being written, so to speak.

 

So for instance, I could monkey with the ROM -- say, replace a KERNAL routine with one of the open source ones -- then fire up the emulator.  I *think* I would be able to TEST that KERNAL routine by inspecting memory with the debugger after that routine is called -- some of them are called when the system starts up, and some I'd have to set up and trigger myself (probably with a little C program).

 

In fact one might could write a little C program that can run a test suite on the KERNAL.

 

Maybe?

On 10/19/2021 at 1:41 PM, rje said:

So for instance, I could monkey with the ROM -- say, replace a KERNAL routine with one of the open source ones -- then fire up the emulator.  I *think* I would be able to TEST that KERNAL routine by inspecting memory with the debugger after that routine is called -- some of them are called when the system starts up, and some I'd have to set up and trigger myself (probably with a little C program).

Do you really need to mess with the ROM? IIRC you can changes some vectors in page 02 or 03 to use your own API rather than the Kernel. 

Actually what I was thinking of is testing the Open ROM.  I guess there’s no piecewise way of doing that.