6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Mar 28, 2024 11:55 pm

All times are UTC




Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sat Aug 27, 2022 1:22 pm 
Offline

Joined: Wed Nov 18, 2020 6:44 am
Posts: 6
EDIT:
I made the debugger+emulator. See github repo: https://github.com/alexanderbh/65816-OS



I am writing a multitasking OS for my 65816 breadboard computer and I found the development cycle too slow. Write code, burn ROM, plug in, nothing works, repeat.
I have a scheduler running based on interrupts that switches between tasks. But I could use some insights into the machine when I develop to speed things up.

So my plan is to write a simulator for my 65816 system and then hook it up to the vscode debugger. The simulator i written in Typescript. It is not implementing all the opcodes yet, but that will come.

The debug adapter is working though. Translating between the ProgramCounter and the source files. Stepping, breakpoints, watching symbols, etc.
It appears to process cycles that corresponds to around 10MHz. My breadboard system runs at 12MHz.

My question is: Have anyone else written a debug adapter for their simulator? Or how do you guys debug bigger projects like an OS?


Last edited by bytearray on Tue Feb 06, 2024 6:23 pm, edited 2 times in total.

Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 27, 2022 2:08 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Looks very handy! (For the uninitiated, it seems "Debug Adapter" means something specific in the world of Visual Studio, whereby an external program can interact with the source code debugger. Or something like that...)


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 27, 2022 2:15 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
To answer your question, in part, one way to debug some new and complex code is broadly as you are doing - using a suitably instrumented emulator and do everything in software on your PC.

Another way is to hook up something to your actual hardware to capture what's happening, and possibly to interact with the live system. @hoglet has a 'protocol decoder' project which would probably be a great help in bringing up an '816 OS. See
viewtopic.php?p=91526#p91526
for pointers. (The 6502 version of the decoder includes a 65816 model.)


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 27, 2022 2:37 pm 
Online
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3327
Location: Ontario, Canada
Developing a simulator is a large investment of effort, as you know. And, until it's 100% debugged, it has potential to actually hinder your progress (although of course at other times it will help).

It might be worth applying a comparatively small amount of effort toward improving your original approach. Instead of, "Write code, burn ROM, plug in," you could choose one of the several different ways to send code from a host computer directly into the test system's RAM. This'd still be a boon even if you decide to go ahead with the simulator (and indeed it might be helpful in debugging the latter). Just a suggestion! :)

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 27, 2022 3:08 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Good point! Pasting srecord data down a serial connection is something I’ve done.


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 27, 2022 3:09 pm 
Offline
User avatar

Joined: Fri Aug 03, 2018 8:52 am
Posts: 735
Location: Germany
Yeah i agree with Jefyll.
I also got annoyed of the constant ROM programming on my SBC so i made a small Serial bootloader whichs allows me to load and run programs by simply dragging and dropping a binary file (with a custom header) into some Terminal Software that support file transfer (like TeraTerm).
It was completely worth it as it made developing software a lot easier and faster.

and I don't know how advanced VSCode can be, but i'm sure there is some way to have the IDE hook into the COM Port that your SBC takes up and have it directly upload the program after compiling/assembling it, and then show the Terminal. which would basically mean that you wouldn't need a seperate Terminal software anymore. you just press a button and the IDE will do everything for you.


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 27, 2022 3:23 pm 
Offline

Joined: Wed Nov 18, 2020 6:44 am
Posts: 6
Thanks for the input. The debug adapter part is a protocol that is at least used in Visual Studio Code:
https://microsoft.github.io/debug-adapter-protocol/

I have considered the serial connection to send over new code. It will help on the speed to get code over, but I still have the issue of looking into the system when it is running.

Then I will have to send debugging info back over the serial connection. Things like the list of tasks, their meta data like input and output streams, signals being sent between tasks and so on.

I do a bunch of writing data out to the display. But it still feels like a black box sometimes.
It might be easier when the base of the os in in place and working.

With the simulator I will have to also implement the 6522 for my SPI and I need to simulate the RA8875 as I use that as my display.
It is a big task but I am okay with that. This is a project for life.


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 27, 2022 4:50 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8114
Location: Midwestern USA
Dr Jefyll wrote:
Instead of, "Write code, burn ROM, plug in," you could choose one of the several different ways to send code from a host computer directly into the test system's RAM.

That's precisely how I developed the SCSI driver and four-channel UART driver for my POC units. I use the S-record output feature of the Kowalski assembler to pass code over to the POC unit. It is a convenient and surprisingly-quick way to handle the write/assemble/test/debug cycle, especially when the code being tested has the potential to crash the machine—something that happened frequently during the earlier stages of SCSI development. :shock:

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 27, 2022 5:03 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8114
Location: Midwestern USA
bytearray wrote:
I have considered the serial connection to send over new code. It will help on the speed to get code over, but I still have the issue of looking into the system when it is running.

For that, you need a machine language monitor. Since you are experimenting with the 65C816, may I recommend Supermon 816?

Quote:
Then I will have to send debugging info back over the serial connection. Things like the list of tasks, their meta data like input and output streams, signals being sent between tasks and so on.

You could set up multiple serial I/O (SIO) paths so you can run code and debug at the same time. Motorola S-records are good for that purpose and are entirely reliable on a hard-wired SIO connection without having to resort to an error-checking protocol, such as XMODEM (which is woefully obsolete, but still useful in some cases).

Quote:
I do a bunch of writing data out to the display. But it still feels like a black box sometimes. It might be easier when the base of the os in in place and working.

Welcome to the wacky world of bare metal development. Unfortunately, it's neither easy or painless. However, with the right development tools and a functioning SBC on which to test, it's not as difficult as it might seem.

Quote:
With the simulator I will have to also implement the 6522 for my SPI and I need to simulate the RA8875 as I use that as my display.

It seems you may be putting the wagon before the horse. The first step, if I were doing this, would be to build 65C816 hardware that is capable of hosting a test environment. That will enable you to test pieces of code in a predictable and repeatable way. Any simulator is a complicated thing to write. The 65C816's internal behavior has a lot of little twists and turns that will make it even more complicated. So, yes, this will likely be a long-term project that will keep you out of the bars on Saturday night. :D

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 27, 2022 6:19 pm 
Offline

Joined: Sun Oct 03, 2021 2:17 am
Posts: 114
I use the Mesen-SX disassembler and debugger. It still has problems with source debugging. I would use this tool if it could connect to super nintendo emulators.


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 27, 2022 8:04 pm 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1392
Location: Scotland
bytearray wrote:
Or how do you guys debug bigger projects like an OS?


Probably not the answer you're after but I use PRINT, or a variant.

The multi-tasking in my BCPL OS is written in '816 asm, but it's fairly simple - an interrupt handler sets a flag every 10mS and the bytecode interpreter checks for the flag being set on every jump bytecode and if it's set then it does a task switch which involves traversing a linked-list, changing the stack and global pointers and bytecode PC as required and another BCPL task takes over.

(This idea isn't new - it's implemented in the microcode of the Inmos Transputer).

I have asm level print routines that can dump the (bcpl) registers and inside my ('816 asm) OS there is a RAM dump command. That's all I've used.

Also this principle: Typing is no substitute for thinking. - Kemney & Kurtz; BASIC; 1964.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 27, 2022 10:48 pm 
Offline

Joined: Sat Feb 19, 2022 10:14 pm
Posts: 147
I modified Py65, a 6502 emulator, for the 65816. I posted about it a while back. It's pretty complete but only runs at about 500 kHz equivalent on my tablet PC (a bit faster on my desktop). I pretty much do all of my development on it now. I sometimes run it in VSCode to take advantage of its debugging capabilities.

Edit: btw - thanks for the DAP link. From it I learned that I can connect the VSCode debugger to my already running emulator. This speeds up debugging since starting my emulator in the VSCode debugger is very slow.


Top
 Profile  
Reply with quote  
PostPosted: Sun Sep 04, 2022 4:48 pm 
Offline

Joined: Sat Feb 19, 2022 10:14 pm
Posts: 147
Thanks again for posting this. It took me about a day to convert the core part of my Python 65816 emulator to Typescript and kludge it into Microsoft's Mock-Debug extension. It only has basic debug functionality so far, but the 65816 is fully modelled. It's a much better debugging experience than debugging the Python emulator as this links directly to the source listing. Here's a sample shot:
Attachment:
debug.png
debug.png [ 250.54 KiB | Viewed 6535 times ]


Top
 Profile  
Reply with quote  
PostPosted: Sat Sep 10, 2022 8:13 pm 
Offline

Joined: Wed Nov 18, 2020 6:44 am
Posts: 6
tmr4 wrote:
Thanks again for posting this. It took me about a day to convert the core part of my Python 65816 emulator to Typescript and kludge it into Microsoft's Mock-Debug extension. It only has basic debug functionality so far, but the 65816 is fully modelled. It's a much better debugging experience than debugging the Python emulator as this links directly to the source listing. Here's a sample shot:


That is awesome @tmr4. I started with the mock-debug extension as well. It is a really nice experience to work with my 65816 code this way. I have found several bugs that I would not have found debugging on my hardware. Because I can follow the code step by step and inspect the stacks and memory and so on.

My 65816 simulator is complete. And I added a 6522 VIA as well for my SPI communication. The 6522 is talking SPI with my simulated RA8875 display chip. I added a custom webview to my debug extension that my simulator updates when SPI bytes come in on the Memory Write register on the RA8875.

Thanks for your input above guys about validating on real hardware. I have the hardware running and it is working. I could not have made the simulator without verifying the results look like in real life.

But this debugging experience is just so nice. I have an interrupt driven scheduler (VIA timer) that switches between multiple tasks. Saves the registers, switches the Stack and Direct page to the active task, all that. And being able to just break at any point is amazing. Since I got this running in the simulator I have made a lot of progress. Progress that would have taken me weeks of evenings doing on the real device. Both because of the ROM burning but also because I can put a breakpoint and just step through my code. Verifying that it does what I imagined.

Here are some updated pics of the debug adapter. The numbers being written out is 5 different tasks running in "parallel" writing out their task id. Next up is the input bar below the screen will trigger my (working) PS/2 interrupt handler which reads the scan codes and puts it in the input stream given to the task running my shell app.

PS: The simulator is, by complete chance, running almost at the same speed as my breadboard implementation, which is running at I think 12MHz. The simulator is just running as fast as it can so it is by pure luck it is in the same ball park. It is nice because the task switching and printing to the display is almost 1-1 in terms of execution speed.

PPS: My wife zones out when I try to explain why it is fun to do this. I hope you guys will understand.


Attachments:
File comment: My simulated 6522 and RA8875.
Screenshot from 2022-09-10 22-18-11.png
Screenshot from 2022-09-10 22-18-11.png [ 995.12 KiB | Viewed 6426 times ]
Screenshot from 2022-09-10 21-56-22.png
Screenshot from 2022-09-10 21-56-22.png [ 642.17 KiB | Viewed 6426 times ]
Screenshot from 2022-09-10 21-54-59.png
Screenshot from 2022-09-10 21-54-59.png [ 266.67 KiB | Viewed 6426 times ]
Top
 Profile  
Reply with quote  
PostPosted: Sat Sep 10, 2022 9:56 pm 
Offline

Joined: Sat Feb 19, 2022 10:14 pm
Posts: 147
Looks good! I agree that debugging in an integrated debugger, with an active link to the source code is a superior experience. For me, a good debugger is essential. I wouldn't have developed my Forth operating system without one.

I'm also adding interrupt capability for a VIA and ACIA. Good idea on the custom webview. Right now, I'm just dumping output to the console. It's not really satisfying, but is enough to verify that things are working as expected.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 24 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: