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.
DCEmu Freak
DCEmu Freak
Posts: 73
Joined: Wed Mar 14, 2018 12:22 am
Has liked: 9 times
Been liked: 10 times

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

Post by mrneo240 » Sat Nov 23, 2019 1:48 pm

Moopthehedgehog wrote:
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 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?
Could you post what you have now? I'm very interested and might be able to help or offer ideas.

I too like writing tiny stuff for DC :lol:
User avatar
DCEmu Freak
DCEmu Freak
Posts: 84
Joined: Wed Jan 05, 2011 4:25 pm
Has liked: 4 times
Been liked: 32 times

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

Post by Moopthehedgehog » Sat Nov 23, 2019 3:34 pm

Uh, well I think I broke something with DHCP renewal, Fixed it. There was a router thing and I forgot a certain variable... I'll know for sure in about 45 minutes. and I'm trying to optimize the memory footprint... and right at this second it doesn't boot because nowhere are the memory limits for this program documented. I'd prefer to post something that boots, if that's alright. I'll make a new thread for it. Be warned, with the way I've been working on this I might make some radical changes as soon as 30 minutes after I post what I've got. :)

Edit: posted the source in this new topic: ... 9#p1057109

Last bumped by Moopthehedgehog on Sat Nov 23, 2019 3:34 pm.
I'm sure Aleron Ives feels weird with his postcount back to <10668
Post Reply