#5538 closed defect (outdated)
DC SVN: Not Loading/Working
| Reported by: | SF/scorches-forge | Owned by: | zeldin |
|---|---|---|---|
| Priority: | normal | Component: | Port: Dreamcast |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
Howdy.
After downloading, and burning the latest Dreamcast nightly build, I found that it doesn't work. Not the plugins, main menu, etc., but the binary itself. It quits with a system reset after booting up the Dreamcast.
The version was labeled "dc-trunk-r54664" in the compressed download folder.
Ticket imported from: #3123788. Ticket imported from: bugs/5538.
Change History (26)
comment:1 by , 14 years ago
| Owner: | set to |
|---|
comment:2 by , 14 years ago
comment:3 by , 14 years ago
Might be related to the change in the CDDA interface; I rewrote the code but for some reason which I haven't had time to investigate yet it didn't run OK, so I haven't committed it yet...
comment:4 by , 14 years ago
@OP: Could you please try a build with version r54714 or higher once one is available, and report if you get the same problem with that one? (It will probably take a couple more hours until the buildbot publishes a new archive...)
comment:5 by , 14 years ago
Sorry. I didn't check my e-mail in a while.
Well, I just burned the 'dc-trunk-r54858' SVN build, and it's not working either.
Instead of beginning to load, and resetting. This one just loads straight to the DC's menu, and apparently isn't detected as having an executable .
Peace.
comment:6 by , 14 years ago
Hi
Thanks for checking this.
However, now I have to ask you: Have you ever been able to create a working ScummVM disc from the nightly builds? Because if the disc doesn't even boot, then it can't be a bug in the software itself, but must be a mistake in either burning the disc, or in the preparation of the plainfiles done by the buildbot (although the only thing I can think of that could be wrong in the plainfiles to cause this would be a faulty IP.BIN).
comment:7 by , 14 years ago
Thinking back, the last time I tried the SVN builds was in the 0.13.x versions. They loaded the the ScummVM menu, but didn't detect a particular game - The 7th Guest.
I built the images with Bootdreams in 'audio/data' mode. Actually... I wouldn't even know how to create an bootable DC image manually.
I burned them like I do with almost every other DC image I've burned. ie - NesterDC, DreamSNES ;-), OBOR, etc...
comment:8 by , 14 years ago
Ok, thanks.
In the meantime I checked out the contents of the most recent package produced by buildbot (r54877), and in fact it didn't contain an IP.BIN at all. Weird. And the build logs had already been removed... I guess the buildbot setup needs a bit of a lookover.
comment:9 by , 14 years ago
Sorry to butt in but I remember having a similar problem. I was using emulator and I can't seem to reproduce it now but I think I messed up the whole scrambled/unscrambled thing when I made CD image.
I could probably help out with this, using both emulator and real Dreamcast, but it'd be easier to test if I could just upload the ELF to DC via serial and see if it works. Not sure if the menu/selector need any additional files to run? I don't care it if actually works, as long as it shows something rather then reset/hang.
comment:10 by , 14 years ago
Well, to be able to detect and launch a game, you would need at least one engine plugin. But to get an empty selection screen (with "Please insert game CD") the ELF itself should be sufficient.
comment:11 by , 14 years ago
Yeah, I tried serial uploading today, the results are:
scummvm-1.2.0-dreamcast-plainfiles -> descrambled binary, works dc-1.2.0-r54860 -> elf, works dc-trunk-r54877 -> elf, hangs dc-trunk-r54898 -> elf, hangs
Hangs means my TV shows no output (as in, DC does not send any video signal) and it stays like that until I cycle DC power. I should add that I'm getting weird invalid opcodes in emulator but that could be a regression on my side. 1.2.0 branch (stable and latest) shows colorful screen asking for game CD, haven't tried to play anything because I'm fresh out of CD-Rs - but I suppose we can say it's working.
comment:12 by , 14 years ago
dknute,
Did you have serial logging enabled when running the ELF?
One difference between the trunk build and the branch one is that the trunk build is configured for serial port debuggning. If there is no serial cable attached, or there is nothing listening to it (i.e. the Dreamcast does not get a Clear To Send), the program _will_ hang due to RS232 flow control. I tried the ELF from the r54916 build myself, and with a serial cable connected and Putty running on the computer, it starts just fine. Without the cable, it hangs with a black screen.
comment:13 by , 14 years ago
@OP: One more question: Did you include all engines when mastering the disc? It turns out that in the 1.2.1 release, the engine plugins have just exceeded the available memory space in size, and in the trunk build there are even more engines available. I believe that it you were to include them all, ScummVM would either lock up or perform a system reset before the selection menu appears, which is consistent with your report. You might want to try opening the drive lid either during the "SEGA" screen (in which case no plugins will be loaded), or some time during the plugin loading (in which case you'd get some of the plugins). If that works, too many plugins on the disc would be the most likely explanation.
comment:15 by , 14 years ago
| Priority: | normal → blocker |
|---|
comment:16 by , 14 years ago
| Priority: | blocker → normal |
|---|
comment:17 by , 14 years ago
Sev, I think you'll have to wait a long time for the release if you make reducing the memory footprint of all engines by about 50% release-criticial. That's what it's going to take to allow a disc with _all_ engines built by the buildbot on it to boot up. For the releases I make two discs with half the engines on each, but this bug is about the buildbot packages, not the releases (which in itself makes it weird to have as release-critical...)
Changing priority back again.
comment:18 by , 13 years ago
marcus_c: Looking at the master.cfg, I don't think it would be too hard to split the dc target on the buildbot into dc_1 (A to M) and dc_2 (N to Z) and thus have these packaged as separate daily builds.
The first build would be "./configure --enable-all-engines" + "--disable-all-engines --enable-agi "... etc. until "--enable-mohawk" and the second "./configure --enable-all-engines" + "--disable-agi" ... etc. until "--disable-mohawk" i.e. the first build would end up with engines A to Q (except for any newly added which aren't in the list.. until someone updates the file), the second would get engines N to Z (plus any newly added ones... which might start with A to Q, but at least they default into a build).
Since other memory constrained targets might need this kind of split, it might also be prudent to place those two strings into a constant at the top of the file so that all split targets can be updated easily..
The overhead would be fairly minimal as most of the build time is compiling of the engine code IMHO.
marcus_c: Does this sound correct/desirable?
sev: Would you be happy for me to do this?
comment:19 by , 13 years ago
It doesn't make much sense to run two different configures. The plugins are dynamic, so it's no problem to build all of them and then create two archives with half the files in each. I don't know if it's actually any point in doing so though. The person downloading the archive can mix and match to create a CD with the plugins of his own needs, and having to pick from two archives (if he wants a CD with AGI and SCI, for example) sounds like it would only be a nuisance...
comment:20 by , 13 years ago
marcus_c: Ah OK. So a user can test the buildbot daily builds with DC.
Since: * this bug is against such an old version, * I assume that you are not seeing issues on a quick test and * the reporter is not responding to this bug, I would suggest that it is closed or at least set pending to close with an invalid resolution.
Though since this seems to be bad communication about the needs of DC daily builds to run i.e. Serial Cable connected for debugging, split engines over multiple CDs to prevent overload; I'd suggest that you update http://wiki.scummvm.org/index.php/Dreamcast with a basic pitfalls / HOWTO to stop any new DC testers getting discouraged.
comment:21 by , 13 years ago
Hmmm, the same user is still having some problems, but with only Toon? on a much newer build: https://sourceforge.net/tracker/index.php?func=detail&aid=3310202&group_id=37116&atid=418820
comment:22 by , 13 years ago
The daily builds can be tested, one only has to be a bit restrictive with how many PLGs one puts on the same CD. The same goes for the plainfiles archive in the actual releases.
The Toon issue seems to be completely unrelated, because the reporter says that the game selection menu appears in that case. It's probably some engine bug, but I don't have the game so I can't test.
comment:23 by , 13 years ago
OK... so am I correct about the resolution of this bug and need for a bit of documentation workup for getting more debug info from DC users then? i.e. "Since: * this bug is against such an old version, * I assume that you are not seeing issues on a quick test and * the reporter is not responding to this bug, I would suggest that it is closed or at least set pending to close with an invalid resolution.
Though since this seems to be bad communication about the needs of DC daily builds to run i.e. Serial Cable connected for debugging, split engines over multiple CDs to prevent overload; I'd suggest that you update http://wiki.scummvm.org/index.php/Dreamcast with a basic pitfalls / HOWTO to stop any new DC testers getting discouraged."
comment:24 by , 12 years ago
Have added notes to Dreamcast port wiki page as http://wiki.scummvm.org/index.php/Dreamcast#Running_Debug_Builds
If the user is still total load failure problems with the latest v1.4.1 / v1.5.0git, then they can file a new bug for this as this is now very out of date. Closing with this resolution.
comment:25 by , 12 years ago
| Resolution: | → outdated |
|---|---|
| Status: | new → closed |
comment:26 by , 6 years ago
| Component: | → Port: Dreamcast |
|---|
Are you talking about the daily builds created by our buildbot? I am not sure whether those are ready for consumption... Marcus?