Current best option for debugging on actual hardware?
-
bbmario
- DCEmu Freak
- Posts: 88
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Wed Feb 05, 2014 5:58 am
- Has thanked: 9 times
- Been thanked: 3 times
Current best option for debugging on actual hardware?
I've been using emulators to run/debug my code, but I feel that I'm ready to start debugging on actual hardware. What are the best current solutions for that right now?
-
BlueCrab
- The Crabby Overlord
- Posts: 5693
- Joined: Mon May 27, 2002 11:31 am
- Location: Sailing the Skies of Arcadia
- Has thanked: 10 times
- Been thanked: 70 times
- Contact:
Re: Current best option for debugging on actual hardware?
Well, there are more options these days, depending on how you really want to set up your debugging and how much money you're willing to spend...
The classic options are to obtain a BBA, Lan Adapter, or Coder's Cable and use dcload-ip or dcload-serial. These options give you the ability to upload binaries right from your PC to the Dreamcast and to have a terminal to see output from printf() or similar functions. Unfortunately, finding one of these pieces of hardware is potentially a difficult and expensive proposition... If you're handy with a soldering iron and don't mind opening up your console, you could potentially rig up your own coder's cable substitute (either in the classic RS-232 variety or with a more modern USB-Serial converter board that operates at 3.3v signal levels). Another option if you don't mind soldering is potentially getting an Atomiswave Communication Cartridge and wiring up an adapter to plug it into your Dreamcast -- but this isn't really all that much cheaper these days than just buying an actual BBA if you look carefully for them.
Another option is to get a serial port SD Card adapter and to put your binaries on it and load them via something like DreamShell. This still gives you the ability to do things like log debugging output to a file or something on the card and read it back on a PC, which isn't quite as convenient as doing things with dcload, but still gives you most of the benefits of that option with a much lower price point (unless you're willing to solder a USB-Serial device, like I mentioned above).
If you have something like a GDEmu (or USB-GDROM or MODE device), you can of course build ISO images of your code and put them directly on the card/drive attached to the device and run them just like any other image. However, without something like one of the earlier options, you're not going to be able to easily see any printf() output unless you build extra functionality into your code to do it.
Failing all of that (or if you're really not looking to spend any money and happen to have a bunch of CD-Rs laying around) is to do what I did when I first started doing Dreamcast stuff -- burn a multisession CD-R with your binary and assets on it and use another CD with DemoMenu or something similar to load the binary off of it. Using a multisession CD lets you at least replace the data without having to use a new disc each time (I was often able to do upwards of 30 test binaries before having to replace the CD-R with a new one), but you're not going to be able to get any debugging output from printf() or similar without the extra work mentioned up above.
There's also the option if you happen to have an HKT-0120 DevKit laying around of using that... But I'm assuming you probably don't and wouldn't be willing to shell out the money for one. Considering how rare they are these days online and how they really don't offer that much over using dcload for homebrew stuff, I wouldn't even seriously consider this option at all.
The classic options are to obtain a BBA, Lan Adapter, or Coder's Cable and use dcload-ip or dcload-serial. These options give you the ability to upload binaries right from your PC to the Dreamcast and to have a terminal to see output from printf() or similar functions. Unfortunately, finding one of these pieces of hardware is potentially a difficult and expensive proposition... If you're handy with a soldering iron and don't mind opening up your console, you could potentially rig up your own coder's cable substitute (either in the classic RS-232 variety or with a more modern USB-Serial converter board that operates at 3.3v signal levels). Another option if you don't mind soldering is potentially getting an Atomiswave Communication Cartridge and wiring up an adapter to plug it into your Dreamcast -- but this isn't really all that much cheaper these days than just buying an actual BBA if you look carefully for them.
Another option is to get a serial port SD Card adapter and to put your binaries on it and load them via something like DreamShell. This still gives you the ability to do things like log debugging output to a file or something on the card and read it back on a PC, which isn't quite as convenient as doing things with dcload, but still gives you most of the benefits of that option with a much lower price point (unless you're willing to solder a USB-Serial device, like I mentioned above).
If you have something like a GDEmu (or USB-GDROM or MODE device), you can of course build ISO images of your code and put them directly on the card/drive attached to the device and run them just like any other image. However, without something like one of the earlier options, you're not going to be able to easily see any printf() output unless you build extra functionality into your code to do it.
Failing all of that (or if you're really not looking to spend any money and happen to have a bunch of CD-Rs laying around) is to do what I did when I first started doing Dreamcast stuff -- burn a multisession CD-R with your binary and assets on it and use another CD with DemoMenu or something similar to load the binary off of it. Using a multisession CD lets you at least replace the data without having to use a new disc each time (I was often able to do upwards of 30 test binaries before having to replace the CD-R with a new one), but you're not going to be able to get any debugging output from printf() or similar without the extra work mentioned up above.
There's also the option if you happen to have an HKT-0120 DevKit laying around of using that... But I'm assuming you probably don't and wouldn't be willing to shell out the money for one. Considering how rare they are these days online and how they really don't offer that much over using dcload for homebrew stuff, I wouldn't even seriously consider this option at all.
-
bbmario
- DCEmu Freak
- Posts: 88
- Joined: Wed Feb 05, 2014 5:58 am
- Has thanked: 9 times
- Been thanked: 3 times
Re: Current best option for debugging on actual hardware?
Thank you for the detailed answer, BlueCrab. I really appreciate it. I have started hunting for a Lan Adapter. Being able to printf() everywhere is very important. 
-
|darc|
- DCEmu Webmaster
- Posts: 16393
- Joined: Wed Mar 14, 2001 6:00 pm
- Location: New Orleans, LA
- Has thanked: 124 times
- Been thanked: 92 times
- Contact:
Re: Current best option for debugging on actual hardware?
Just FYI you want to look for a Broadband Adapter, not LAN Adapter. LAN adapter (Fujitsu chip) is 10mbps and only compatible with the Japanese language LAN Passport disc and some homebrew. Broadband Adapter (Realtek chip) is 100mbps and compatible with multiple browser discs, several games, homebrew, etc. The Broadband adapter is way more common than the LAN Adapter anyway, just making sure you know not to actually get a LAN adapter.
It's thinking...
Re: Current best option for debugging on actual hardware?
Try a JTAG debugger like Segger J-Link or ST-Link for direct hardware debugging. Logic analyzers are great for timing issues.