Could you post what you have now? I'm very interested and might be able to help or offer ideas.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 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?
I too like writing tiny stuff for DC
