DC-Tool/DC-Load Version 3.0 Wishlist

[gyrovorbis]

Okay, guys, it should probably be clear to everyone at this point that we are overdue for a big update to DC-Tool and DC-Load to address some deficiencies and add some new features. There has been so much talk of new features and so many new requests, that I've decided to start this issue as a way to capture it all.

There is a lot of discussion about whether this next release should be a total overhaul/rewrite or something incremental... That's not really the point of discussion here. We're just gathering a wish-list, and I'm just going to call it "DC-Tool 3.0" regardless of whether it's something new or not. :)

Bugs to Fix:

• ISO Redirection
• EXTREMELY slow printf()/stdout performance
• Fairly slow FILE performance
• chroot inconsistencies across platforms (goes to root directory on Linux, which requires sudo)

Right now, here's the feature wish-list:

• Command-line argument support
• Return value support
• Environment variables accessible from host
• stdin, scanf(), etc implemented by taking input from host
• exec() family from C stdlib
• command-line argument for KOS to automatically sync the DC's RTC to the host's
• command-line argument for KOS dbglog verbosity level
• mkdir (and arguably rmdir if we're brave) support for /pc/ VFS
• CMD for remotely executing addr2line -> autogenerate decoded stack traces

Please feel free to respond with your own ideas!

[Tchan0]

Naomi / System SP support :) Can easily be done for dcload/tool -serial - just requires a hardcoding to VGA, like I do in my JinGasa custom Bios (https://github.com/Tchan0/JinGasa):

Before compiling, hardcode dcload-ser to VGA:
in target-src/dcload/video.s - _check_cable: change the 3 first commands:
MOV #0,R0 !by T - for Naomi & System SP - Tmp test, since KOS also does not know how to check the cable
RTS ! note: I commented out the 3 next commands, so that the size of the bin remains the same
NOP
! set PORT8 and PORT9 to input
! mov.l porta,r0
! mov.l pctra_clr,r2
! mov.l @r0,r1

[iamsh4]

• +1 to mkdir. I am writing test software to run on the DC which creates test result folders automatically back on the host with dumps/logs/etc. mkdir support would be great. I don't need rmdir, but it could be nice (perhaps enabling rmdir requires an extra flag or something like -enable-dangerous-rmdir).
• Not sure how printf and file io are implemented right now, but improved speed on those are always nice! In my use case, each PVR test writes up to 2 or 3 complete VRAM dumps to files. Over ethernet each one seems to take about 4 or 5 seconds for me. If that can be made faster that would be helpful. The number of tests I want to run will only increase!

[andressbarajas]

Loving the wishlist so far. I have a few comments. Do we update the KOS repo version of dcload-ip to match Sizious's in one fell swoop since its the one just about everyone uses anyway? The understanding of moops changes can be in the next phase which will be paying the technical debt by cleaning/organizing/documenting the code. I think a good plan that would make it possible to have a DC-Tool/DC-Load 3.0 release within the next year is:

1. Update dcload-ip repo to match Sizious.
2. Pay technical debt by cleaning up the code. Adding documentation. Bug fixes.
3. Do a "release" so that people can test that everything works the same.
4. Then we can tackling items on the wish list on a codebase that is well documented/organized.

Otherwise what I see happening is this would take a couple of years if we follow the same process we have been.

[Tchan0]

Merge the codebase of dc-load/tool ip & serial into 1 repo ? 1 repo could generate 2 executables...

[Kazade]

I have a big one! Stop assuming that UDP packets arrive in order, once, or at all. UDP packets aren't even guaranteed to leave your PC in the correct order and currently if a packet drops your DC load session is ruined.

This is one of the reasons I use serial over BBA. There are a few options.. we could abandon UDP, or we could implement a simple ack system (where all unacked data is sent with each message in each direction).

Also, it would be nice if code was shared between dc-load and Kos's implementation (which is enabled when INIT_NET is set)

[freakdave]

Low prio but I'd welcome a button combo (or DPAD controls) to cycle between different preset BG colors (dark mode).

[gyrovorbis]

@pcercuei I believe wanted the IP link status to show on the VMU, so he can run headless? Seems legit... lol.

[pcercuei]

Could even display the IP address.

One "good to have" feature IMHO would be service discovery (mDNS / DNS-SD), so that you wouldn't even have to specify the Dreamcast's IP address to dc-tool, it would auto-detect it.

[Tchan0]

For completeness, posting some stances of @ljsebald during some brainstorming talks we had in august 2023:

"I don't really want to have dcload-ip and dcload-serial in the same repo since it doesn't seem to make sense to me to do so." https://discord.com/channels/488332893324836864/1071178365307981845/1125641349425791126

"And then we have to add vmufs support to dcload That's a big NOPE." https://discord.com/channels/488332893324836864/614912396460556298/1116417826232741979

[QuzarDC]

My biggest thing would be for a new tool to be built around the DC-side being able to receive and jump into an update from the PC side automatically. You burned a disc for v3.1 and now v3.3 is out with new commands? When you connect, the PC side has the option to determine this then send an updated binary if you have it built.

This does usually work in the current versions, but it doesn't seem written with that in mind, and it's in no way baked into the PC side. This kind of paradigm could also allow for an even smaller minimal version (which could be useful for building into a BIOS for instance) that only has the basic loading functionality (which could then chain into a 'full' version).

A second, relatively more manageable change on my wish-list is support for a watchdog timeout (not necessarily using the WDT). Something where the DC side could trigger a reset/exit to loader when the system is otherwise unresponsive. I know that's a pretty common case for me when messing around with things is to have to power cycle manually to recover from those. Of course it wouldn't be able to work 100%, but even reducing some would be great.

Regarding merging/moving the repos, updating the existing, or such: if we want to implement even a fraction of this stuff I'd imagine it will just have to be a new codebase. Effort could be taken to try for backwards compatibility, but the reason for not moving/merging repos is to not subvert the original author's ownership, and a big factor for being so careful with updating is because we don't want to make people's burned discs useless.

[andressbarajas]

New codebase (like from scratch?) so does that mean the new applications should be called something else besides dc-tool and dc-load so there is no confusion?

[LobotomyDC]

I would like to see a feature for the Serial (but also IP) DC-Tool, that allows you select an asset folder to transfer to a directory on your GDEmu/TerraOnion/G1ATA/ODE of choice, and then stream in the executable for the program, using those uploaded assets.

It isn't going to be the fastest file transfer in the universe, but hopefully, you only have to do the bulk of it once. I have found myself in situations where I could have certainly used something like that.

Once your asset folder is on the SD card, you could also use DC-Load to make single-file changes in it, by sending a new version of the asset over, and then you can test your program again. Could speed up prototyping by quite a bit, especially for people who don't yet own a BBA, but can easily afford a Coder's Cable.

Since DC-Load stays in RAM, theoretically, that would open up the G1 bus, enabling this to work, right?

Also totally going to throw my support in for Real-Time Clock sync. That's an extremely good idea, especially for people with dead CMOS batteries in their consoles, who are trying to prototype a game with networking.