Anybody available to help with dc-load-ip testing?

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
User avatar
Quzar
Dream Coder
Dream Coder
Posts: 7486
Joined: Wed Jul 31, 2002 12:14 am
Location: Miami, FL
Has liked: 0
Been liked: 3 times
Contact:

Anybody available to help with dc-load-ip testing?

Post by Quzar » Thu Mar 21, 2019 6:02 pm

As a minor project, I've been going through dc-load-ip and trying to standardize the code for the Sega LAN Adapter (SLA) and BBA to match what is in KOS. 99% is just moving blocks of code around, renaming things, and adding register macros (but there were a number of differences that show some registers being set imprecisely that may have been causing issues). The goal of this is to allow these files to be easily maintainable for changes made to the KOS drivers (and to import any bug/stability/performance fixes that might have been made in KOS in the intervening years since the last update to dcload's drivers).

Though these changes should be almost entirely cosmetic, I'd certainly want to be able to test them and unfortunately I don't have an SLA to do so. Testing should just be a matter of burning and running it, uploading some stuff.

Thanks!
dc-load-ip-Q.zip
(23.09 KiB) Downloaded 31 times
These users liked the author Quzar for the post:
SiZiOUS
"When you post fewer lines of text than your signature, consider not posting at all." - A Wise Man
User avatar
|darc|
DCEmu Webmaster
DCEmu Webmaster
Posts: 16160
Joined: Wed Mar 14, 2001 6:00 pm
Location: New Orleans, LA
Has liked: 20 times
Been liked: 5 times
Contact:

Re: Anybody available to help with dc-load-ip testing?

Post by |darc| » Sat Mar 30, 2019 1:02 am

Quzar wrote:Testing should just be a matter of burning and running it, uploading some stuff.
Well, first trying to figure out if it's scrambled or not and making a cdi :P
Ran burritro demo, executed just fine, but got send_data error, tried it again, same problem both times.

Code: Select all

darcMBP:tool darc$ ./dc-tool -t 10.0.0.40 -x /Users/darc/Downloads/burritro2.elf 
Console enabled
Upload </Users/darc/Downloads/burritro2.elf>
File format is ELF, start address is 0x8c010000
Section .text, lma 0x8c010000, size 55744
Section .rodata, lma 0x8c01d9c0, size 1140032
Section .data, lma 0x8c133f00, size 3856
send_data: error in response to CMD_LOADBIN, retrying... DBIN
send_data: error in response to CMD_LOADBIN, retrying... DBIN
send_data: error in response to CMD_DONEBIN, retrying...
send_data: error in response to CMD_DONEBIN, retrying...
transferred 1199632 bytes at 648700.817748 bytes / sec
Executing at <0x8c010000>
Sending execute command (0x8c010000, console=1, cdfsredir=0)...executing
^C
darcMBP:tool darc$ ./dc-tool -t 10.0.0.40 -x /Users/darc/Downloads/burritro2.elf 
Console enabled
Upload </Users/darc/Downloads/burritro2.elf>
File format is ELF, start address is 0x8c010000
Section .text, lma 0x8c010000, size 55744
Section .rodata, lma 0x8c01d9c0, size 1140032
Section .data, lma 0x8c133f00, size 3856
send_data: error in response to CMD_LOADBIN, retrying... DBIN
send_data: error in response to CMD_LOADBIN, retrying... DBIN
send_data: error in response to CMD_DONEBIN, retrying...
send_data: error in response to CMD_DONEBIN, retrying...
transferred 1199632 bytes at 459087.146730 bytes / sec
Executing at <0x8c010000>
Sending execute command (0x8c010000, console=1, cdfsredir=0)...executing


Testing with the Broadband Adapter instead did not give the error:

Code: Select all

darcMBP:tool darc$ ./dc-tool -t 10.0.0.39 -x /Users/darc/Downloads/burritro2.elf 
Console enabled
Upload </Users/darc/Downloads/burritro2.elf>
File format is ELF, start address is 0x8c010000
Section .text, lma 0x8c010000, size 55744
Section .rodata, lma 0x8c01d9c0, size 1140032
Section .data, lma 0x8c133f00, size 3856
transferred 1199632 bytes at 1626130.344586 bytes / sec
Executing at <0x8c010000>
Sending execute command (0x8c010000, console=1, cdfsredir=0)...executing
It's thinking...
User avatar
Quzar
Dream Coder
Dream Coder
Posts: 7486
Joined: Wed Jul 31, 2002 12:14 am
Location: Miami, FL
Has liked: 0
Been liked: 3 times
Contact:

Re: Anybody available to help with dc-load-ip testing?

Post by Quzar » Thu Apr 04, 2019 12:45 pm

Thanks darc. I think I'll go back to the drawing board for now and restrict myself to toying with the BBA side, since I can test that myself.
"When you post fewer lines of text than your signature, consider not posting at all." - A Wise Man
User avatar
|darc|
DCEmu Webmaster
DCEmu Webmaster
Posts: 16160
Joined: Wed Mar 14, 2001 6:00 pm
Location: New Orleans, LA
Has liked: 20 times
Been liked: 5 times
Contact:

Re: Anybody available to help with dc-load-ip testing?

Post by |darc| » Thu Apr 04, 2019 1:17 pm

No problem, if you do end up messing with the LAN adapter stuff I don't mind doing testing. I have a good collection of rare DC accessories but they're to play with, not to sit in a box on a shelf. And I have a GDEmu so I don't need to burn CDs.
It's thinking...
User avatar
SiZiOUS
DC Developer
DC Developer
Posts: 386
Joined: Fri Mar 05, 2004 2:22 pm
Location: France
Has liked: 13 times
Been liked: 10 times
Contact:

Re: Anybody available to help with dc-load-ip testing?

Post by SiZiOUS » Fri May 31, 2019 4:32 am

First of all I want to say thank you to Quzar for such update. dc-tool/dc-load are, for me, a crucial part of the KOS environment and sadly it seems that it don't have the attention its deserves, especially about the debugging capabilities (which are put in highlight on DreamSDK R2 for ex). Of course, no blame here! I know the whole Dreamcast members are hobbists, starting from me. :)

Unfortunately, I don't own a LAN Adapter but only 3 BBA, so I think I'll be useless for your request.

The only thing I would notice to you, is the fact I made some interesting changes to the dcload-ip/dcload-serial projects and posted them on GitHub. May you, if you would mind, take into account the following:
  • May you create an official mirror of dcload-serial/dcload-ip on GitHub, based on the projects on SourceForge, like you already did for kos and kos-ports?
  • May you take into account my repositories, which contains fixes for the MinGW environment (which not breakes other environments)?
  • Or if possible, may you take into account my bugs fixes, which includes a little issue on the -E parameter handling and more important, proper GDB session closing (more details here)?
Again, I don't want to be rude, as I know my English isn't really great, so please forgive me if I miswritten something; I just want to contribute to promote the fact that Dreamcast development is easy (that's why DreamSDK exists) and keep the community going and fully united (that's why DreamSDK isn't a "fork" of the old development environments like DDE/CodeBlocks DDE and uses only the official repositories, except dc-tool for the reason exposed above)! :wink:
User avatar
|darc|
DCEmu Webmaster
DCEmu Webmaster
Posts: 16160
Joined: Wed Mar 14, 2001 6:00 pm
Location: New Orleans, LA
Has liked: 20 times
Been liked: 5 times
Contact:

Re: Anybody available to help with dc-load-ip testing?

Post by |darc| » Fri May 31, 2019 11:49 am

SiZiOUS wrote:
Fri May 31, 2019 4:32 am
Again, I don't want to be rude, as I know my English isn't really great, so please forgive me if I miswritten something
Don't be silly, you're not being rude and your English is fantastic :lol:
It's thinking...
User avatar
Quzar
Dream Coder
Dream Coder
Posts: 7486
Joined: Wed Jul 31, 2002 12:14 am
Location: Miami, FL
Has liked: 0
Been liked: 3 times
Contact:

Re: Anybody available to help with dc-load-ip testing?

Post by Quzar » Wed Jun 19, 2019 4:48 pm

SiZiOUS wrote:
Fri May 31, 2019 4:32 am
First of all I want to say thank you to Quzar for such update. dc-tool/dc-load are, for me, a crucial part of the KOS environment and sadly it seems that it don't have the attention its deserves, especially about the debugging capabilities (which are put in highlight on DreamSDK R2 for ex). Of course, no blame here! I know the whole Dreamcast members are hobbists, starting from me. :)

Unfortunately, I don't own a LAN Adapter but only 3 BBA, so I think I'll be useless for your request.

The only thing I would notice to you, is the fact I made some interesting changes to the dcload-ip/dcload-serial projects and posted them on GitHub. May you, if you would mind, take into account the following:
  • May you create an official mirror of dcload-serial/dcload-ip on GitHub, based on the projects on SourceForge, like you already did for kos and kos-ports?
  • May you take into account my repositories, which contains fixes for the MinGW environment (which not breakes other environments)?
  • Or if possible, may you take into account my bugs fixes, which includes a little issue on the -E parameter handling and more important, proper GDB session closing (more details here)?
Again, I don't want to be rude, as I know my English isn't really great, so please forgive me if I miswritten something; I just want to contribute to promote the fact that Dreamcast development is easy (that's why DreamSDK exists) and keep the community going and fully united (that's why DreamSDK isn't a "fork" of the old development environments like DDE/CodeBlocks DDE and uses only the official repositories, except dc-tool for the reason exposed above)! :wink:
I will absolutely take a look at your fixes and updates the next time I take a run at this. It's at the top of my Dreamcast project queue, but unfortunately buried under many others.
These users liked the author Quzar for the post (total 2):
|darc|SiZiOUS
"When you post fewer lines of text than your signature, consider not posting at all." - A Wise Man
User avatar
ThePerfectK
Insane DCEmu
Insane DCEmu
Posts: 108
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 10 times
Been liked: 13 times

Re: Anybody available to help with dc-load-ip testing?

Post by ThePerfectK » Sat Jul 27, 2019 11:47 pm

So question: I know virtually nothing when it comes to networking technologies, so please forgive me if this is a dumb question, and understand that I'm in no way feature begging or asking anyone to devote time to figuring this out, but is it conceptually possible to use a DreamPi with DCLoad-Ip and DCtool-Ip to debug and launch executables like a BBA? One of the most difficult parts of getting people into Dreamcast programming is getting them set up with a debugger, since you usually need to recommend either an expensive BBA or some soldering work to build a coder's cable (or USB port). If DreamPi was an available option, that would give people a very cheap (under $50) solution to debugging on the Dreamcast without any soldering necessary.

Again, sorry if that's a dumb question, but is there some fundamental reason why it wouldn't work? What would be necessary to do something like that? Would it just be a case of having the RasPi itself handle the interfacing or what?
Still Thinking!~~
kazade
Insane DCEmu
Insane DCEmu
Posts: 130
Joined: Tue May 02, 2017 3:11 pm
Has liked: 1 time
Been liked: 8 times

Re: Anybody available to help with dc-load-ip testing?

Post by kazade » Mon Jul 29, 2019 12:34 am

That actually might just work. Obviously the dc-load-ip boot disc would need adapting to connect to the internet before waiting, but then the Dreamcast would get it's own ip address on the local network...
nymus
DC Developer
DC Developer
Posts: 955
Joined: Tue Feb 11, 2003 4:12 pm
Location: In a Dream
Has liked: 0
Been liked: 1 time

Re: Anybody available to help with dc-load-ip testing?

Post by nymus » Mon Jul 29, 2019 3:23 am

I think bluecrab got something started in this area...

https://dcemulation.org/phpBB/viewtopic ... y#p1043419
behold the mind
inspired by Dreamcast
User avatar
ThePerfectK
Insane DCEmu
Insane DCEmu
Posts: 108
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 10 times
Been liked: 13 times

Re: Anybody available to help with dc-load-ip testing?

Post by ThePerfectK » Mon Jul 29, 2019 2:12 pm

nymus wrote:
Mon Jul 29, 2019 3:23 am
I think bluecrab got something started in this area...

https://dcemulation.org/phpBB/viewtopic ... y#p1043419
The last post in that topic is to the effect of:
In theory, sure. Anything written with KOS that has network support could easily be made to support the modem using this library.
My ignorance of all things networking is pretty staggering, am I to understand that BlueCrab's PPP library will connect the modem to the internet and route it through the appropriate socket, such that the networking functions of something like dcload-ip would go through the modem with minimal adaptation? Or do I have the concept all wrong?
Still Thinking!~~
User avatar
ThePerfectK
Insane DCEmu
Insane DCEmu
Posts: 108
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 10 times
Been liked: 13 times

Re: Anybody available to help with dc-load-ip testing?

Post by ThePerfectK » Mon Jul 29, 2019 2:25 pm

double post...
Still Thinking!~~
User avatar
|darc|
DCEmu Webmaster
DCEmu Webmaster
Posts: 16160
Joined: Wed Mar 14, 2001 6:00 pm
Location: New Orleans, LA
Has liked: 20 times
Been liked: 5 times
Contact:

Re: Anybody available to help with dc-load-ip testing?

Post by |darc| » Mon Jul 29, 2019 4:31 pm

ThePerfectK wrote:
Mon Jul 29, 2019 2:12 pm
My ignorance of all things networking is pretty staggering, am I to understand that BlueCrab's PPP library will connect the modem to the internet and route it through the appropriate socket, such that the networking functions of something like dcload-ip would go through the modem with minimal adaptation? Or do I have the concept all wrong?
The PPP library allows anyone writing KOS applications to use the modem to dial into a network. It would theoretically be possible to use this to create a new application, let's say dcload-ppp, which dialed into a local network via DreamPi, Netopia, PC-DC Bridge server, etc. and then waited for a dc-tool client to send code over.

But someone would have to write that application, and it would be annoying as all hell to use because of having to dial in every time you want to run your code.

I don't think this method would offer much advantage over the main 3 ways of testing on a real DC:

BBA/LAN adapter -- best way, if you have the money
USB/serial cable -- if you can DIY the setup
SD card adapter -- it's $15 and you'll have to move the SD card back and forth, but it works
It's thinking...
User avatar
ThePerfectK
Insane DCEmu
Insane DCEmu
Posts: 108
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 10 times
Been liked: 13 times

Re: Anybody available to help with dc-load-ip testing?

Post by ThePerfectK » Tue Jul 30, 2019 12:37 am

|darc| wrote:
Mon Jul 29, 2019 4:31 pm
I don't think this method would offer much advantage over the main 3 ways of testing on a real DC:

BBA/LAN adapter -- best way, if you have the money
USB/serial cable -- if you can DIY the setup
SD card adapter -- it's $15 and you'll have to move the SD card back and forth, but it works
With due respect, I disagree. I actually have a BBA setup with my toolchain and use DCload-IP, and I've also very recently put together a tutorial on both creating a coder's cable by sacrificing an HDMI cable and also installing a dedicated USB coder's port on the dreamcast using the test points on the motherboard, and I've experimented with various ways to use the SD card adapter for development (i.e. redirecting stderr and stdout to a file written to the card). They all have perks and cons, namely related to cost and skill required to obtain. The BBA is of course pretty idiot proof, but I spent over $200 on my BBA. Building a USB coder's port or a serial cable requires a steady hand with the soldering iron and taking your DC apart, but are otherwise pretty cheap. And using an SD card adapter makes it hard to do things like, for example, saving output during a crash if, say, there's a SEGBUS error or something (For whatever reason, my custom error handlers never seem to fire), and there's no way to use live GDB debugging.

There is also the option to use Redream in linux to set up a virtual serial connection using socat and gdb debug that way. I've gotten that working, but walking people through it is pretty involved. And there's always an desire for testing on the real, target hardware due to emulation inaccuracies.

My main interest is getting other people besides myself into Dreamcast development, and to get them developing larger, more complicated programs than mere monolithic demoes. I've written a tutorial on developing an entire framework for the Dreamcast, creating and maintaining low level memory structures (like memory pools, and implementing rudimentary inheritance and polymorphism in C to avoid the overhead of C++, and using memory alignments to best use the Dreamcast's data cache). Developing something like that is pretty difficult without being able to access GDB (or at least was for me -- while on the subject, is there any way to view the contents of cache lines programmatically?).

From my perspective, DreamPi is pretty much the only cheap "idiot proof" solution out there that could, theoretically, offer GDB debugging. That'd allow people with not a lot of money to jump into DC development, without even needing to crack open their Dreamcast. It'd offer a mod-less solution to DC development outside of the comparatively rare and expensive BBA. In my experience teaching people (I run a class at a local makerspace on non-dreamcast related stuff), the more you ask of a potential student, the less likely they are to see a project to completion. Once you start asking people to shell out a lot of money, or open their dreamcast, many walk away. I've lurked DCemulation since 2001 and one of the best things about DC homebrew has been how easy it is to jump in and get code running compared to other consoles, and how over the years everything has generally become easier. It'd be great for the homebrew scene if the barrier to gaining access to a real terminal output and a gdb debugger was low enough to not require any hardware modification and a solution that costs less than an average $60 video game purchase (thus in impulse buy range for many).

Again, just to clarify, I'm not complaining that this doesn't exist, nor suggesting anybody put aside their valuable time to actually make this happen. I'm just curious as to how one could potentially create such a tool, or if I could take a stab at it. I looked into Siz's code for his latest version of DCload-ip, and it looks like there are two adapter headers that use function pointers to create a loose interface that creates interoperability between the Lan adapter and BBA. adapter_detect() itself calls a method called bb.detect() or la.detect() (depending on BBA or lan adapter) which is a function pointer to specific internal functions that initialize and connect an adapter. From there, there appears to be functions that map to specific serial routing - TX request, RX request, etc. Seems to me the steps to building some sort of dcload-ppp would be:

-dial in and connect to a network using bluecrab's ppp library
-map serial function pointers to appropriate ppp library commands
-integrate into the first half of dcload's main function, which is split into two parts (connecting, then idling).

My main limitation is that I'm a general dummy when it comes to all things networking, I don't even know the basics of what sending data from one computer to another in any sort of protocol is like. Ah well...

EDIT: incidentally, I have both a DreamPi and *3* netopia routers and a TLS phoneline simulator, haha. I've actually thought about this for a long time, several years at this point. I just wish I had the networking knowledge to actually make it happen.

EDIT AGAIN: Re: dialing in every time you want to run code: Is that how DCload-IP works? The way I do my testing is that I keep DCLoad-IP running on my dreamcast through multiple builds. If I terminate my program (through, say, a quit key on my DC keyboard), my dreamcast screen will turn black and idle until I send new code through DCtool-ip. The moment I send code again, it's instantly uploaded to the Dreamcast, no reboot necessary. Is DCload re-establishing a connection every time I terminate my program? Or is the connection maintained the entire time, until I physically turn off my Dreamcast (or send a command to end the connection through, say, dcload)? If so, then you wouldn't necessarily need to dial in *everytime* you sent code, just every time you launched DCload from the dreamcast itself. Seeing as DCLoad uses a constant connection to talk back to the gdb server I use for realtime debugging, I would think the network connection stays constant until I power off the DC.
Still Thinking!~~
nymus
DC Developer
DC Developer
Posts: 955
Joined: Tue Feb 11, 2003 4:12 pm
Location: In a Dream
Has liked: 0
Been liked: 1 time

Re: Anybody available to help with dc-load-ip testing?

Post by nymus » Tue Jul 30, 2019 12:08 pm

It's great that you are excited to get this working. Personally, I don't think re-dialing would be a big issue since the videos show it taking less than 5 seconds...

I'd love to read your guides on Dreamcast gdb-over-bba though, just to get the hang of cross-platform debugging. I suppose I've never written anything big enough to stray outside of the the printf method, even when the tools were available.
behold the mind
inspired by Dreamcast
mrneo240
DCEmu Freak
DCEmu Freak
Posts: 61
Joined: Wed Mar 14, 2018 12:22 am
Has liked: 4 times
Been liked: 8 times

Re: Anybody available to help with dc-load-ip testing?

Post by mrneo240 » Tue Jul 30, 2019 5:12 pm

I'll second gdb over ip
User avatar
ThePerfectK
Insane DCEmu
Insane DCEmu
Posts: 108
Joined: Thu Apr 27, 2006 10:15 am
Has liked: 10 times
Been liked: 13 times

Re: Anybody available to help with dc-load-ip testing?

Post by ThePerfectK » Tue Jul 30, 2019 10:08 pm

nymus wrote:
Tue Jul 30, 2019 12:08 pm
It's great that you are excited to get this working. Personally, I don't think re-dialing would be a big issue since the videos show it taking less than 5 seconds...

I'd love to read your guides on Dreamcast gdb-over-bba though, just to get the hang of cross-platform debugging. I suppose I've never written anything big enough to stray outside of the the printf method, even when the tools were available.
I've been putting together a very large guide that walks people through every step of what I described above, including the creation of the framework itself, and I'm trying my hardest (literally working full time day and night on it) to get it out this september 9th.

If you really need help GDB debugging today, the process isn't so difficult so long as you are using the same version of dcload-ip and dctool-ip. I actually struggled for a couple of years to get gdb debugging going due to what I assume was somehow a version mismatch on my end, until Siz released his latest versions of dctool-ip and dcload-ip within the last yearish. Building both tools from source form his latest versions solved the version mismarch problem I was running into and everything went smooth from there.

The version mismatch error I was receiving manifested in two ways. First, the actual dcload-ip idle screen was green, not blue as many people reported, which should have actually tipped me off that it was an old version. Second, even though I could transmit and load elf files from the dreamcast through through the mismatched versions of dcload-ip and dctool-ip, gdb itself would crash. You could tell this was happening, because anytime I used the gdb_init() function call in my program, the program would hang. By moving the call around a series of printfs, I could tell it was that specific function that would make my program hang. What is supposed to happen is that, when you call that function, it should print out "waiting for gdb connection..." or something similar. With a version mismatch, that statement never printed out and I was never able to advance, the entire command prompt would just hang.

After matching the versions by building the tools myself from Siz's latest source, connecting gdb to the dreamcast was a snap. Once your program says "waiting for gdb..." in the terminal, open up another terminal window and launch sh-elf-gdb. If I recall correctly, I built sh-elf-gdb from scrach and finding instructions on how to do it was sort of tricky. But, I've tested moving the binary I built around to different machines over the years and it works fine, so I'll provide a link to download a pre-built version of it. If my build of sh-elf-gdb somehow doesn't work on your PC, you'll have to google around to find how to build it from source yourself. IIRC it was mainly a matter of setting some compiler flags.

Once you launch sh-elf-gdb, you connect to your Dreamcast by using the command:

Code: Select all

target remote :2159
That tells GDB that you want to debug a remote application on the network, which is communicating through localhost:2159. You don't actually need to write the localhost bit, hence the ":2159" in the command. That'll connect GDB to your dreamcast. However, since this is a remote application, GDB won't have any of the debug symbols loaded, so you need to do that manually. To do that, use the command

Code: Select all

file <path_to_ef>
to load the debug symbols from your program. The "path to elf" is the local path on your PC that you submitted to your dreamcast via dcload/dctool. Make sure your source is built with the -g command flag to preserve debug symbols. Another quibble I ran into is that the cross compiler KOS uses expects the -g command to be the very first argument. So if your argument list for kos-cc is like "-W -O2 blah" you need to make sure that the -g command comes at the very front of all other commands. Similarly, when you launch dctool-ip, make sure the -g command is the very first argument sent. I dunno if this weirdness regarding the placement of the -g command in my arguments list is a quirk of my particular setup, but just a tip.

Once you load the debug symbols by loading the elf into gdb, you can use it like any other session of gdb. I have noticed, however, if you don't properly exit your dreamcast title (i.e. if you turn off your dreamcast while it's running the program, instead of implementing a quit key into your program) that the port gdb uses, :2159, remains connected for a long while unless you manually kill it, and dctool-ip similarly stays running. to kill it, use the command

Code: Select all

sudo netstat -ap | grep :2159
in a terminal to list the pid of the program connected to that port. It'll usually bd dctool itself. Note the pid of the program, and use the command

Code: Select all

sudo kill <pid>
to end the use of that port. If you don't do this, when you next try to launch your program, as soon as "waiting for gdb..." appears, it'll report a gdb buffer overflow error and crash.

This isn't a problem, however, if you properly exit your program. That is done by letting your main function return. I do this by calling out to a looping function which is gated by a global static variable, and changing that variable breaks the loop, which returns to main, which itself returns. If you do that, once your program ends, dcload-ip will blank the screen and idle until you send another elf across dctool-ip. Similarly, if your program actually crashes and you still have gdb connected, you can send the quit command (q) from gdb and it'll ask if you want to terminate your debugging session. Doing so will cause your dreamcast to soft reboot and go back to dcload-ip, freeing the port. Exiting your program in either of these ways saves you the hassle of having the use netstat and kill the port.

Similar to the above, redream in linux offers a non-documented --serial command line option. If you use this, it'll emulate a serial link from redream. In this example, rather than using dcload-ip and dctool-ip, you use dcload-ser and dctool-ser to foster the connection. The gist of it all is that the --serial command needs to be pointed at a serial device in linux, usually /dev/tty0 or something. Instead, we use a program called socat to create a virtual serial link between two aribtrary files in linux and route redream to that.

I have a script which does everything for me, that I'll paste snippets from to explain how to do this. Major thanks to inolen, the author of redream, for the advice on using socat to create terminal output in the first place:

Code: Select all

socat pty,raw,echo=0,link=/home/gabe/tty0 pty,raw,echo=0,link=/home/gabe/tty1> /dev/null 2>&1 &
This command creates a simulated serial link between the arbitrarily created files /home/gabe/tty0 and /home/gabe/tty1. The stuff on the right, if you're unfamiliar, is some stuff to manage output of the script.

Code: Select all

/home/gabe/redream/redream --serial=/home/gabe/tty0 /home/gabe/Projects/DreamcastFramework/dcload2.cdi> /dev/null 2>&1 &
I launch redream with the secret --serial function and point it to my ~/tty0 file and also send my dcload executable.

Code: Select all

sleep 15

xfce4-terminal -e "/home/gabe/dc-load-ip/dcload-ip-master/host-src/tool/dc-tool-ser -g -t $HOME/tty1 -x /home/gabe/Projects/DreamcastFramework/DreamcastFramework/program.elf"
I sleep a bit in my script to give redream time to boot and wait in the dcload idle screen, then I open a new terminal window and launch dc-tool-ser from it. The command argument list includes the -g flag I mentioned earlier (again, first in the argument list) then a -t command to target ~/tty1 as the connection point, then I use the -x flag to automatically send my program elf.

Code: Select all

sleep 8

socat pty,link=/home/gabe/tty0,raw tcp:localhost:2159 &
I sleep again a bit to give dc-tool and dc-load some time to send the elf and launch it, then I use socat to set up a virtual link between the file ~/tty0 and the tcp localhost port 2159.

To make sure you get conceptually what's happening here, we have redream, which is using a file called tty0 as a link to it's emulated serial port. That file tty0 is using a program socat to simulate a serial connection with another file called tty1. dctool-ser is pointing to tty1 like it's a mount point for a real serial connection on your PC and transmitting data through it. We then use socat again to create a second virtual link between tty0 and our localhost tcp port :2159, which is the port gdb uses to communicate.

Once that's done, we can connect sh-elf-gdb to our tty0 file and we're good to go:

Code: Select all

sh-elf-gdb -ex "target remote /home/gabe/tty0" "/home/gabe/Projects/DreamcastFramework/DreamcastFramework/program.elf"
this is a combined command to launch sh-elf-gdb to automatically remote connect to tty0, and also to automatically load my elf file for debug symbols.

All said and done:
Image

Regarding actually trying to make a dcload/dctool-ppp, I admittedly don't know enough about networking to make a real stab at it yet, but I've been reading up the last few days. I think I understand now how to transmit data through bluecrab's ppp library, I just don't quite understand how to make it idle and wait to receive transmitted data. I'll keep asking around with the usual suspects for help, though.

Anyways, didn't mean to hijack this thread or accidentally turn it into a port request thread or something, I just wanted to document how I got gdb to work on this board for others since figuring out the exact process of the above took a ton of trial and error and also poking around through 10+ year old posts, haha. Hopefully the explaination above helps some people out.
These users liked the author ThePerfectK for the post (total 4):
mrneo240BB HoodProtofallSiZiOUS
Still Thinking!~~
User avatar
Moopthehedgehog
DCEmu Freak
DCEmu Freak
Posts: 53
Joined: Wed Jan 05, 2011 4:25 pm
Has liked: 0
Been liked: 14 times

Re: Anybody available to help with dc-load-ip testing?

Post by Moopthehedgehog » Sun Nov 17, 2019 12:24 pm

I'm not sure if this is the right place to be posting this, but it's pretty related to the original topic. I'm actually trying to add DHCP to DCLOAD-IP right now, and I've hit a bit of a snag. I was originally trying to use KOS to init the system and do DHCP before handing off to DCLOAD-IP to do its thing. Unfortunately, I discovered that the KOS init and networking functionality takes up like 200-300kB, so it won't fit in the 24kB or so left in the RAM area specified by dcload.x (there's about 0xb400 left), which is doubly unfortunate since that would've had a dedicated thread to handle DHCP renewal and other nice things (like IPv6).

However, IPv4 DHCP is actually not a very complicated process. In fact, DHCP renewal wouldn't be strictly necessary, since I doubt anyone's going to be running a machine for more than 24h straight, which is the average DHCP lease time. Really it would just need the basic discover and request procedures, which are detailed here: https://ns1.com/resources/dhcp-protocol

I think it should be possible to implement just that part of DHCP, which would get an IP address without the need for arp (by the way, the 0.0.0.0/8 or 0.x.x.x region is reserved for DHCP, as all hosts I've ever seen use 0.0.0.0 for the handshake--the "arp" stuff really should be using the 169.254.x.x range; see here: https://en.wikipedia.org/wiki/IPv4#Spec ... _addresses). I have made modifications to dcload-ip's dcload.c to account for DHCP following IETF IPv4 standards, which I'm attaching here. Don't mind the "kosbridge" stuff, that's leftover from my trying to get the two systems to work together before realizing it would never fit. :)

My only issue now is that I need to learn how DCLOAD-IPs networking functions work, which might take some time (and it looks like I'll need to go buy some more CD-Rs...). So if there's someone who can do it faster than I can that would be really great!

Among other things, this would allow a single CD to be able to configure multiple Dreamcasts on the same network for things like development and possibly even Virtual-On LAN play.

EDIT: Uploaded a cleaner version of dcload.c, where the functions that don't compile are the ones that need to be made.

EDIT 2: So I managed to make something that *should* work, but now I'm 3712 bytes over the allotted RAM area. If I try to shrink bin_info.map from 16384 to 12288 to make space for bss (it's really tight, like I'm using 0xb280 out of 0xb400 available RAM according to the dcload.x linkerscript), I can compile, but I guess I must now be running over something because I can't boot to actually test what I did... Maybe I'm just running over the stack, hmm...
Attachments
dcload.c
Modified for DHCP but missing net backend support
(7.51 KiB) Downloaded 3 times
I'm sure Aleron Ives feels weird with his postcount back to <10668
:D
User avatar
Moopthehedgehog
DCEmu Freak
DCEmu Freak
Posts: 53
Joined: Wed Jan 05, 2011 4:25 pm
Has liked: 0
Been liked: 14 times

Re: Anybody available to help with dc-load-ip testing?

Post by Moopthehedgehog » Wed Nov 20, 2019 1:20 pm

Just an update, I've managed to create an entire DHCP handshake (and renewal!), and it required some rather extensive changes to the DCLOAD codebase. Functionality-wise very little will have changed to users.

It's not quite done yet (it's close!) but I'm having a problem where I can't send packets from either of my machines. I don't know if there are any known quirks with the BBA regarding transmission of packets--as far as I can tell it looks like it should be transmitting and it's just not. If anyone's come across something similar, any information at all would be really helpful.

Interestingly I did also find a couple bugs in the RTL8139 driver, but neither of them appears to have been the culprit... :(

EDIT: Wow. Well, I was capturing packets the wrong way. They were just all deformed. DC's sending packets. More debugging, but this is a good sign. :)
These users liked the author Moopthehedgehog for the post:
|darc|
I'm sure Aleron Ives feels weird with his postcount back to <10668
:D
User avatar
Moopthehedgehog
DCEmu Freak
DCEmu Freak
Posts: 53
Joined: Wed Jan 05, 2011 4:25 pm
Has liked: 0
Been liked: 14 times

Re: Anybody available to help with dc-load-ip testing?

Post by Moopthehedgehog » Fri Nov 22, 2019 12:17 am

Ok, so I did it. It's working. Need to buy more CD-Rs to finish beating up some bugs that are mainly due to memory size constraints.

DCLOAD-IP will have DHCP soon, as well as some other neat things I put in. I went a little crazy and implemented the ENTIRE IPv4 DHCP PROCESS into it. Yes, that includes DHCP renewal. Yes, it works and, equally awesomely, it all fits. It was not easy! Oh, and I went through and fixed all the warnings, so compiling it with -Wall is fine now.

There may be enough room to finish the LAN adapter driver, too, if it's not finished--I really have no idea, since I don't have one. I did suppress three "set but not used" warnings in lan_adapter.c with an "UNUSED" macro, as much as I dislike doing that...

This whole thing required a pretty extensive review and reworking of DCLOAD's internal functionality to make it all come together, and I needed to tap into some "undocumented" Dreamcast functionality. Did you know the DC has not one, but TWO 48-bit performance counters that can measure elapsed time, in addition to all kinds of other things? A mystery I've come across is that they appear to run at 2.4GHz, which doesn't make any sense to me since the PLL of an ST40RA--it's an SH4 like the DC's--tops out at just over 600MHz, so maybe someone else can figure out or explain what exactly is going on there. I'm using performance counter 1 (I call them 1 and 2, not 0 and 1) to measure DHCP lease time for renewal, and it appears to be working flawlessly as an easy-activate, minimal-code-required timer for that purpose.

At the moment, I have also implemented functionality to enable, stop, disable, restart, and clear these performance counters using network packets from DC-TOOL (with the ID "PMCR")... but I don't know how to actually send arbitrary packets to activate commands. Unfortunately I might have to get rid of this functionality because it takes up a very precious 1kB alone. An alternative would be if I can shrink the bin_info.map from 16384 bytes to 8192 or 4096, though that would mean changing the page size (it looks like that's what that is for?) to 2048B or 4096B from 1024B. If no one cares about being able to control these counters remotely I won't try to fit this, as I could sure use that space for the stack... One other option is moving exception.bin up 1kB, since it sits in a 3kB area and is only 2kB itself. It would be running right up against the 0x8c010000 boundary if I did that (don't know if that's OK or not). If anyone has thoughts about anything I've mentioned in this paragraph, please don't keep it to yourself! I really don't know what the best solution is here.

Edit: So I just discovered that removing a single 64-bit divide I was doing for the counter frees up 1.2 KILOBYTES of space. Wow. I also found that making a number of functions that should be static explicitly static causes GCC to free up another 500 bytes. There's one last thing I want to do that might free up another kilobyte and then there'll be quite a bit more free space than DCLOAD had to start with, which was about 668 bytes. Plenty of room for the remote perfcounter stuff! Also: "-Os" is really an awesome flag in the right circumstances. It alone saves 5-8kB of space over "-O2" here.

In any case, as I mentioned, I'm still doing some bug testing on it (I've got about 75 coasters here now...), and I'll make a new thread once it's ready to be released. Hopefully that'll be within the next couple days unless I run into a hidden super bug.

One question for @BlueCrab or @SiZiOUS: I'm currently calling this "DCLOAD-IP 1.0.5 - with DHCP."
Is it worth instead making it 1.0.6 or 1.1.0 or 2.0.0?
These users liked the author Moopthehedgehog for the post:
ThePerfectK
I'm sure Aleron Ives feels weird with his postcount back to <10668
:D
Post Reply