Since I found that Chema's request in another post was absolutely sound and useful I had to make sure it was not forgotten.
If you find it important and worth sponsoring, do not hesitate to demonstrate interest by saying so in the issue posted above.
Note that I hesitated to post this on the emulators forum. Feel free to move it if that is more proper.
Your interpretation of this may differ from mine, but it looks like GDB doesn't obtain architecture information from the server, it has to be rebuilt for every architecture you want to debug. E.g. per https://docs.faircom.com/doc/knowledgebase/62424.htm "The gdb must be specially compiled to be aware of the target architecture".
ThomH wrote: ↑Wed Nov 07, 2018 10:42 pm
Your interpretation of this may differ from mine, but it looks like GDB doesn't obtain architecture information from the server, it has to be rebuilt for every architecture you want to debug. E.g. per https://docs.faircom.com/doc/knowledgebase/62424.htm "The gdb must be specially compiled to be aware of the target architecture".
If so, that sounds like a significant impediment?
You are correct in interpreting that a new debugging target needs to be added (via code) to GDB so it can support the 6502 and the Oric "OS" more specifically.
However, this is doable, there are many forks of sourceware.org/git/binutils-gdb on GitHub which precisely aim to add support for new targets (N64, Z-80, etc.).
Moreover, any effort to have 6502 support would benefit a very large retro community of 6502-based machines (I should not have to list them here ).
I am not sure how Visual Studio support of the GDB protocol would be able to deal with new targets though.
Here 65020 is the port on which Oricutron will listen for connection. I used 65020 because it's exactly equal to 10 times 6502, you can use any other free port .
mon6502.dsk or mon6502.tap in the attached file NoICE-debugger-for-Oricutron.zip
This is the debugger core - Start Oricutron and load it.
Start NoICE debugger and use File|Play... to load noice-test.noi from attached file NoICE-debugger-test.zip - you have to unpack the zip file to a working directory.
For everything else follow the video and be creative, if there still problems I'll be glad to help! Enjoy your remote debugger for Oricutron!
What can be done with debugger: I will leave this to the requester of this feature and everyone who is interested to explore and find all possibilities... and why not to write some useful info?
But what can't be done with it: Definitely you can't debug programs which change the IRQ vector!
And at end some additional personal opinions and notes:
The coolest thing is the debugger core - it runs entirely inside Oric i.e. Oricutron doesn't even know what's going on .
After you install NoICE program you can find in NoICE/monitors/ sub-folder the original source of the debugger core.
I "ported" it for Oric and you can find the modified source in the attached file - take a look at it, compare with the original - it's beautiful piece of software, I really like it!
Next, maybe you ask yourself to buy NoICE - you decide - but in my not so humble opinion the price of NoICE for 65(C)02 - $79.95 is too high for the sake of hobbyist and for fun only usage. If someone plans to sale software for Oric in big volumes - maybe it's worth the money . We can ask the author for a 'special' discount for retro maniacs, but I don't believe that we will get something reasonable*. Actually, speaking honestly, I'm ready to give this $80 for the 6502 debugger's core source code which is free, but not for the Windows program which I use with 'wine' under Linux .
Interesting is the debugger protocol - it uses simple 1 byte commands with parameters. You can see the transferred data in above video (in the log window on the right). The commands are:
; Communications function codes.
FN_GET_STATUS = $FF ;reply with device info
FN_READ_MEM = $FE ;reply with data
FN_WRITE_MEM = $FD ;reply with status (+/-)
FN_READ_REGS = $FC ;reply with registers
FN_WRITE_REGS = $FB ;reply with status
FN_RUN_TARGET = $FA ;reply (delayed) with registers
FN_SET_BYTES = $F9 ;reply with data (truncate if error)
FN_IN = $F8 ;input from port
FN_OUT = $F7 ;output to port
;
so, nothing extremely special here ...
As conclusion: I highly recommend to try NoICE just to get the feeling of the remote debugging and make a list with the options which are really useful and which we don't need. Next, obviously the Oricutron's networking sockets are working fine and implementing the debugger's core functionality in the emulator seems pretty easy. Then we can write our (free, open source, portable) remote debugger - maybe good idea is to merge it into the OricExplorer - there are already implemented disassembler, hex dump viewer etc., what do you think?
NoICE-debugger-test.zip: contains: noice-test.s - test source code noice-test - test compiled binary for debugging noice-test.sym - symbol file generated during compilation (not used in debbuging) noice-test.noi - script file to load binary, define symbols and set 6502 registers
(1.19 KiB) Downloaded 459 times
______________________ * interesting for reading are author's thoughts about software pricing here, his opinion sounds a little bit 'sharp' to me, but I fully understand him.
This is indeed nice and I must say it's a great job. But I'm afraid it is not very useful... almost every game will not only change the irq vector, but may have a tight timing, disable them or have little memory left.
Any debug feature should be added to the emulator itself, so memory could be inspected in real time, profiling could be done, breakpoints work, etc.
What I suggested as an easy solution was simply open a socket and receive/send the debbugger commands and output there as if entered through Oricutron's console.