gator
Deep Blooper
Posts: 24
|
Post by gator on May 24, 2022 23:34:16 GMT
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 24, 2022 23:35:41 GMT
We still need to test with a real release, properly tagged though
|
|
|
Post by elmer on May 24, 2022 23:44:22 GMT
Hahaha, you're right, and I'm just being old-and-unaware! I had no idea that github's "1 tags" was modern-speak for "click here to download files".
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 24, 2022 23:59:33 GMT
Cool From Github point of view, it's a published release, that we're updating every time the master branch successfully completes a build (tip of the branch) It's constantly changing, so use it at your own risk. Once we tag the repo with a real version, it will be added to the list of releases, and we can craft a nice explanation message, release notes, etc, and we (well you) decide when to push the published version. I think if we start using the issue tracker, we can also get some nice release notes auto-generated, and all kinds of cool stuff that goes with it. If we ever have an organization setup, the file things.todo should be deleted and be replaced with actual tracking issues
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 28, 2022 15:04:04 GMT
elmer, I was looking at the test script (test/mk) and saw the call to tgemu was commented out. And when I uncommented it, the test execution got stuck when calling it. It started, but never completed its job. Is this a known issue?
|
|
|
Post by elmer on May 28, 2022 20:16:24 GMT
elmer , I was looking at the test script (test/mk) and saw the call to tgemu was commented out. And when I uncommented it, the test execution got stuck when calling it. It started, but never completed its job. Is this a known issue? Err, nope. The tests pass, even the ones where failing is the CORRECT result ... I don't know how that could be if tgemu isn't run <EDIT> OK, a "blame" says that turboxray disabled the tests 2 years ago. Time to find out why. Well, re-enabling the test hangs, as you say, so that's probably why it was disabled. I guess that needs to go down on the list of things to fix.
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 28, 2022 21:29:45 GMT
I guess I'm not looking at the right place then. This commit, made a long time ago, commented out the call to tgemu. github.com/jbrandwood/huc/commit/357c6140ccbd76fa4062cb61bff6a1ba9f537b8bThe latest version of the file in your repo also has the call to tgemu commented out (https://github.com/jbrandwood/huc/blob/master/test/mk) Is there another place where tgemu is called ?
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 28, 2022 21:31:31 GMT
Ah, just saw your edit Any objections if we use the issues tab of your repo to track that kind of stuff ?
|
|
|
Post by turboxray on May 28, 2022 21:48:12 GMT
elmer , I was looking at the test script (test/mk) and saw the call to tgemu was commented out. And when I uncommented it, the test execution got stuck when calling it. It started, but never completed its job. Is this a known issue? Err, nope. The tests pass, even the ones where failing is the CORRECT result ... I don't know how that could be if tgemu isn't run <EDIT> OK, a "blame" says that turboxray disabled the tests 2 years ago. Time to find out why. Well, re-enabling the test hangs, as you say, so that's probably why it was disabled. I guess that needs to go down on the list of things to fix. You're getting forgetful hahahah. We recently talked about this tgemu issue (and why I wanted to write my own pce emu or modify mednafen).
|
|
|
Post by elmer on May 29, 2022 0:51:31 GMT
You're getting forgetful hahahah. We recently talked about this tgemu issue (and why I wanted to write my own pce emu or modify mednafen). Yep, as I said, I am getting old! But actually, I thought that you were just talking about running the tests on Windows, and I've never been able to successfully do that, only on Linux ... which is now apparently broken, too.
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 29, 2022 4:30:05 GMT
Good news I wasn't going completely crazy Is it possible to get the tgemu part running again on Linux, so we can have something to test short-term ? Is the generation of pce, sgx and iso deterministic across all platforms? If so, testing on linux-only may be good enough, while adding a check that Win64 and Macos are generating the same output as Linux. Crazy thought, is there a way to deploy remotely a pce / iso to an actual pcengine, using an overdrive / terraonion or something else ? (basically turning it into a modern testkit)
|
|
|
Post by gredler on May 29, 2022 19:40:15 GMT
Good news I wasn't going completely crazy Is it possible to get the tgemu part running again on Linux, so we can have something to test short-term ? Is the generation of pce, sgx and iso deterministic across all platforms? If so, testing on linux-only may be good enough, while adding a check that Win64 and Macos are generating the same output as Linux. Crazy thought, is there a way to deploy remotely a pce / iso to an actual pcengine, using an overdrive / terraonion or something else ? (basically turning it into a modern testkit) Yeah the turbo ever drive 2 was briefly sold with a USB port, and the current turbo ever drive 2 has a pad where the USB can be soldered onto ( dshadoff did it to his). These USB enabled cards can be hooked up to windows and you can use the usb2ted2.exe to push pce ROMs to the pce while it's sitting at the rom selection menu. You need to reboot the everdrive back to rom selection every time you need to push a new rom but the physical reset button works for this. I use this all the time and love it. I am not aware of a way to run a CD ISO in a similar fashon though
|
|
|
Post by elmer on May 29, 2022 20:35:53 GMT
I am not aware of a way to run a CD ISO in a similar fashon though You can now upload a HuC SCD overlay through the TED2's USB for testing ... I mentioned that in the "HuC Development Futures" thread, but you're right, there is no virtual-cd-drive-through-usb yet. My asm libraries support development for the TED2, and also for the upload of a new TED2 Homebrew test-ROM while you're still in the current test-ROM without having to reset the TED2 ... as long as your test-ROM hasn't crashed, and you call the appropriate wait-for-vblank routine. That'll be available to KickC developers, but HuC just isn't compatible with TED2 development without some *major* re-working.
|
|
|
Post by elmer on May 30, 2022 18:21:22 GMT
Is it possible to get the tgemu part running again on Linux, so we can have something to test short-term ? We're going to have to debug tgemu to find out what broke. That may take some time. Is the generation of pce, sgx and iso deterministic across all platforms? If so, testing on linux-only may be good enough, while adding a check that Win64 and Macos are generating the same output as Linux. It should be the same everywhere, they're all targeting the same PC Engine hardware! Crazy thought, is there a way to deploy remotely a pce / iso to an actual pcengine, using an overdrive / terraonion or something else ? (basically turning it into a modern testkit) It is theoretically possible, with the right hardware ... but such a huge PITA that it wouldn't be worth the effort. An emulator is a much-easier solution. If we can't fix tgemu, we'll look for another alternative. BTW, gator ... I've now had the CI build fail on multiple check-ins in the last "publish" phase. Re-running that phase then fixes the problem. Sounds like github is sometimes a bit slow, and that the "publish" phase needs a retry or two added to it! Is that something that you can look at?
|
|
gator
Deep Blooper
Posts: 24
|
Post by gator on May 30, 2022 19:28:07 GMT
Yep, gonna have a look at that. I've been too trusty of github own infra
|
|