Anybody available to help with dc-load-ip testing?
- Quzar
- Dream Coder
- Posts: 7499
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Wed Jul 31, 2002 12:14 am
- Location: Miami, FL
- Has thanked: 4 times
- Been thanked: 10 times
- Contact:
Anybody available to help with dc-load-ip testing?
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!
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!
"When you post fewer lines of text than your signature, consider not posting at all." - A Wise Man
-
- DCEmu Webmaster
- Posts: 16378
- Joined: Wed Mar 14, 2001 6:00 pm
- Location: New Orleans, LA
- Has thanked: 109 times
- Been thanked: 91 times
- Contact:
Re: Anybody available to help with dc-load-ip testing?
Well, first trying to figure out if it's scrambled or not and making a cdiQuzar wrote:Testing should just be a matter of burning and running it, uploading some stuff.
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...
- Quzar
- Dream Coder
- Posts: 7499
- Joined: Wed Jul 31, 2002 12:14 am
- Location: Miami, FL
- Has thanked: 4 times
- Been thanked: 10 times
- Contact:
Re: Anybody available to help with dc-load-ip testing?
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
-
- DCEmu Webmaster
- Posts: 16378
- Joined: Wed Mar 14, 2001 6:00 pm
- Location: New Orleans, LA
- Has thanked: 109 times
- Been thanked: 91 times
- Contact:
Re: Anybody available to help with dc-load-ip testing?
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...
- SiZiOUS
- DC Developer
- Posts: 404
- Joined: Fri Mar 05, 2004 2:22 pm
- Location: France
- Has thanked: 27 times
- Been thanked: 19 times
- Contact:
Re: Anybody available to help with dc-load-ip testing?
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:
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)?
-
- DCEmu Webmaster
- Posts: 16378
- Joined: Wed Mar 14, 2001 6:00 pm
- Location: New Orleans, LA
- Has thanked: 109 times
- Been thanked: 91 times
- Contact:
Re: Anybody available to help with dc-load-ip testing?
Don't be silly, you're not being rude and your English is fantastic
It's thinking...
- Quzar
- Dream Coder
- Posts: 7499
- Joined: Wed Jul 31, 2002 12:14 am
- Location: Miami, FL
- Has thanked: 4 times
- Been thanked: 10 times
- Contact:
Re: Anybody available to help with dc-load-ip testing?
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.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: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)!
- 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)?
"When you post fewer lines of text than your signature, consider not posting at all." - A Wise Man
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
Re: Anybody available to help with dc-load-ip testing?
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?
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!~~
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: Anybody available to help with dc-load-ip testing?
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...
-
- DC Developer
- Posts: 968
- Joined: Tue Feb 11, 2003 4:12 pm
- Location: In a Dream
- Has thanked: 5 times
- Been thanked: 6 times
Re: Anybody available to help with dc-load-ip testing?
I think bluecrab got something started in this area...
https://dcemulation.org/phpBB/viewtopic ... y#p1043419
https://dcemulation.org/phpBB/viewtopic ... y#p1043419
behold the mind
inspired by Dreamcast
inspired by Dreamcast
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
Re: Anybody available to help with dc-load-ip testing?
The last post in that topic is to the effect of: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
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?In theory, sure. Anything written with KOS that has network support could easily be made to support the modem using this library.
Still Thinking!~~
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
-
- DCEmu Webmaster
- Posts: 16378
- Joined: Wed Mar 14, 2001 6:00 pm
- Location: New Orleans, LA
- Has thanked: 109 times
- Been thanked: 91 times
- Contact:
Re: Anybody available to help with dc-load-ip testing?
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.ThePerfectK wrote: ↑Mon Jul 29, 2019 2:12 pmMy 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?
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...
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
Re: Anybody available to help with dc-load-ip testing?
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.|darc| wrote: ↑Mon Jul 29, 2019 4:31 pmI 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
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!~~
-
- DC Developer
- Posts: 968
- Joined: Tue Feb 11, 2003 4:12 pm
- Location: In a Dream
- Has thanked: 5 times
- Been thanked: 6 times
Re: Anybody available to help with dc-load-ip testing?
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'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
inspired by Dreamcast
- ThePerfectK
- Insane DCEmu
- Posts: 147
- Joined: Thu Apr 27, 2006 10:15 am
- Has thanked: 27 times
- Been thanked: 35 times
Re: Anybody available to help with dc-load-ip testing?
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.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.
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
Code: Select all
file <path_to_ef>
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
Code: Select all
sudo kill <pid>
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 &
Code: Select all
/home/gabe/redream/redream --serial=/home/gabe/tty0 /home/gabe/Projects/DreamcastFramework/dcload2.cdi> /dev/null 2>&1 &
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"
Code: Select all
sleep 8
socat pty,link=/home/gabe/tty0,raw tcp:localhost: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"
All said and done:
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 thanked the author ThePerfectK for the post (total 4):
- mrneo240 • BB Hood • Protofall • SiZiOUS
Still Thinking!~~
- Moopthehedgehog
- DCEmu Freak
- Posts: 85
- Joined: Wed Jan 05, 2011 4:25 pm
- Has thanked: 4 times
- Been thanked: 39 times
Re: Anybody available to help with dc-load-ip testing?
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...
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 104 times
I'm sure Aleron Ives feels weird with his postcount back to <10668
- Moopthehedgehog
- DCEmu Freak
- Posts: 85
- Joined: Wed Jan 05, 2011 4:25 pm
- Has thanked: 4 times
- Been thanked: 39 times
Re: Anybody available to help with dc-load-ip testing?
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.
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 thanked the author Moopthehedgehog for the post:
- |darc|
I'm sure Aleron Ives feels weird with his postcount back to <10668
- Moopthehedgehog
- DCEmu Freak
- Posts: 85
- Joined: Wed Jan 05, 2011 4:25 pm
- Has thanked: 4 times
- Been thanked: 39 times
Re: Anybody available to help with dc-load-ip testing?
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?
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 thanked the author Moopthehedgehog for the post (total 2):
- ThePerfectK • BB Hood
I'm sure Aleron Ives feels weird with his postcount back to <10668