Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/59126674124379554
Here is a resync of the movie in the dev build.
Overall it synced pretty faithfully. There are some desyncs which seem to be due to elevator timing, but they were easy to overcome.
Overall I would say this movie is about 30 gameplay frames longer then the 2.3.1 version. I'm pretty sure this is just emulation differences, as I was not able to overcome different elevator timing even though I tried lots of different ways.
Also the time of 17:42 is correct, the original time of 17:34 is not correct due to frame timing errors.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I fixed the bad scrolling in the ending on GBHawk. I can help resync to current dev build if it desired, not sure if there will be any desyncs or not since a lot has chagned recently (there will definitely be frame definition desyncs but those are trivial.)
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Lag Count is the same as frame count for SubNESHawk, so you can get frame count just by turning lag counter on. Just be aware it's only accurate if you are at the end of the movie / last emulated frame.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
GJTASer2018 wrote:
Alyosha wrote:
I wanted a I8048 cpu core so this seemed worth it.
Is there an advantage of using this type of core vs. the waterboxed O2EM?
The I8048 is the sound processor in the original Donkey Kong arcade system, so my thought when I first came up with the idea was to use Odyssey 2 as a proof for the CPU and a stepping stone to that. However with the impressively rapid development of MAMEHawk, this goal now seems unnecessary. So no there isn't really an advantage, I just felt like doing it. Presumably the O2 is simple enough that having the fine grain details of an in-house core won't really matter.
Fortranm wrote:
I have a WIP version of the MC6800 which is used in all the Adam's peripherals, so it's closer then it was, but I don't yet have a proof for it. The only system that used the chip was the APF MP1000, and I lack the motivation to work on such a boring system. Also, the expansion pack for the colecovision that makes most of the Adam games (or ports of them) workable makes it a low priority for me.
Still, if someone made an APF MP1000 core to proof out the MC6800, I'd be willing to help put everything together to get a proper Adam core going, but otherwise no.
KAGE-008 wrote:
How possible is to implement a Dreamcast core? Using flycast source as base: https://github.com/flyinghead/flycast
Flyinghead is okay with forking it as long as you guys use the same name for the core.
Not very possible I'd guess, that would be a huge undertaking, it would probably take a new, dedicated person to do it.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I've started work on an in-house Odyssey 2 core. I know we have an unfinished O2EM waterbox core, but I wanted a I8048 cpu core so this seemed worth it. It will be slow going but if anyone has any suggestions feel free to ask.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I mostly fixed this.
Saving won't change the displayed value to hex anymore. Loading still will, but at least you can change it back now since the 'display as' button now works correctly.
Some things with signed values are still wrong, so I don't recommend using them.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/58687251796716780
I managed to recreate the game end glitch in Wario Land in the most recent GBHawk build. It's not exactly the same as the original, but I found another suitable setup with only small modifications. the levels are played the exact same, only the ending input changes.
This one would be cool to see console verified.
The Gambatte version does not work, it seems the STOP instruction is emulated differently in current builds. I'm not entirely sure what's going wrong.
EDIT: Game de Hakken!! Tamagotchi - Osutchi to Mesutchi (Japan) now works in GBHawk (except for RTC.) this is a Japan only Tamagotchi game that has it's own unique cartridge hardware. The game is playable in non-RTC mode at least now. I might go back to fix up the RTC someday but it's not a priority, I just wanted the mapper implemented.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Alright I added an RTC offset correction factor. It doesn't directly translate into the Gambatte equivalent setting, but I doubt there will be too many 2+ hour runs where it will be all that noticeable. From what I can tell the error is only around 1/32768 of a second.
EDIT:
http://tasvideos.org/userfiles/info/58555860013787500
Finally, this long exercise is at an end and I have a complete re-sync of the pokemon crystal run in GBHawk.
This has been an excruciating but also very rewarding task, as I learned a great deal about the GBC in the process and fixed many bugs both small and large.
With both the crystal run and yellow run working, the Gen 2 catch em all should be doable with realistic accuracy (although linking is not tested for accuracy itself.)
Now we should finally be able to start pushing forward with other games. I already pass many more sprite timing tests then Gambatte does, and with these two runs as bench marks it strongly constrains what in the code can be changed in the future.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Yeah we should definitely be able to start cracking some of the simpler games. for single speed mode at least (and GB games) there really shouldn't be much standing in the way of console verification anymore. I guess we'll find out.
After that double speed mode basically isn't even touched yet, so that should be interesting.
Anyway I'm over half way through the run now (past the radio tower.) Truth be told there are some inconsistencies with the RTC but it isn't effecting sync yet, and I can always adjust that as needed so it's not a big deal.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I ran into a desync around frame 60000, surprising it made it so far without running into it. Turns out it was a window timing bug. This process has revealed a lot of small errors here and there that I'm glad I'm getting the opportunity to fix. Now I'm up to frame 116000 (just past the third gym.) I don't think there will be any more desyncs unless something comes up with the RTC, but anyway I'll make sure to make it to the end.
Pokemon Yellow and Crystal both rely on careful mode 3 (HBL) timing but in different ways. Yellow relies on reading STAT mode 3 status, while Crystal relies on mode 3 interrupts. So, getting both the Crystal run and yellow run working at the same time strongly constrains what else can be right and wrong with PPU timing (at least for this part of it) so this is all really valuable for accuracy.
Cool stuff!
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
After the most recent changes I am now able to sync the crystal run up through the first gym leader. This has been a laborious process but it really helped me to understand the timings that need to be correct in order for this run to work.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Nope not STAT blocking I have that pretty well working I think.
It's figuring out when in the course of IRQ handling an interrupt from the same source can re-assert the IRQ flag. Originally I had supposed it was after the IRQ vector is chosen, but it seems this is wrong and it cannot happen until processing is complete and the next instruction starts. At least this is what is necessary for the pokemon crystal run, which is console verified, to work.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I'm making renewed progress on syncing up pokemon crystal. I'm able to get in game with the correct RNG and RTC now. I'm still investigating the emulation of the IRQ blocking that's going on on the cpu side. It looks like it blocks IRQs from re-raising the IRQ flag while the interrupt is still being processed. It works correctly for crystal. I'm going to take some time and make sure it doesn't effect the other runs before I commit it though.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Looks like Kwirk isn't quite done yet. I realized I made a mistake in 2-7 pushing a block unnecessarily, then I noticed that I could also saves 4 steps with a pretty obvious oversight.
I don't think there are any other improvements before 2-7, but I'm going over everything again.
EDIT: 3-4 improved by one move and one unnecessary push. 3-7 improved by 2 unnecessary moves. 3-9 improved 4 unnecessary moves (my goodness I made a lot of oversights.)
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Initial testing shows GB gmes running at about 25 fps on my laptop in 4x mode, pretty slow. I think I can probably improve this a little bit but it will be hard getting up to 60 fps, probably impossible for GBC games.
EDIT: actually I had my laptop in low power mode, in regular mode I get just about 60 fps. With a few optimizations I should be able to get full 60 fps when all the linking is done.
Also, here is card pop on pokemon trading card game:
This one seemed to give Shonumi some trouble so I used it as a test case to see how robust my implementation is. I didn't run into any trouble, but the games are changing speed a lot during the IR comm process, which is pretty strange. I didn't look into why they do this or too heavily into the IR algorithm since it seems to work just fine. One thing I did notice is that you can't have both players press 'A' near the same time or it fails.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I'm having fun working on Gameboy stuff lately, so I decided to go ahead and work on 4 player support. It will be a stripped down version focusing on the 4 player cable (DMG 007) for now, hopefully I'll be able to get the speed up to full speed. Nothing functional yet, but if anyone has any ideas of how 4 player support might be used in a TAS setting let me know so I can consider them.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
WRAM is pokable, so you can easily override the initial 'randomization' even in 2.x
Just do this after memory domains are setup:
for (int i = 0; i <_memoryDomainList> 0)
{
if ((i & 1) > 0)
{
_memoryDomainList[0].PokeByte(i, 0);
}
else
{
_memoryDomainList[0].PokeByte(i, 0xFF);
}
}
else
{
if ((i & 1) > 0)
{
_memoryDomainList[0].PokeByte(i, 0xFF);
}
else
{
_memoryDomainList[0].PokeByte(i, 0);
}
}
}
I think this correctly recreates the second pattern above (I just tested it and it works as expected.) Seems like a good alternative to the incorrect randomization routine.
Is this something we want to do for SNES? Will the run even sync with this 'fix?'
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
That's a cool graph, SNES people really have done their research. Thanks for posting that.
So looks like 0x55 is valid (or close enough.) And also 0x00 - 0xFF, that's surprising, pretty cool.
I wonder if I can force BizHawk to use that alternating 0x00 - 0xFF pattern, that should be enough for this submission, I think I'll try. (Building bsnes is hopeless for me, but maybe I can do something post initialization.)
to me. Both are likely equally improbable. Since 00 and FF both work, I think this is good enough.
That aside, this game looks cool and that ending was really impressive, I vote yes.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Fortranm wrote:
The pallets are not displayed correctly for Felix the Cat on GBC mode.
oops, fixed now.
EDIT: http://tasvideos.org/userfiles/info/58572449838190423
here is a GBHawk resync of the previous pokemon blue glitched run by gifvex. This run now uses a different ppu core in GBHawk so it's good it still works. This core will be used for GB compatibility mode games like this going forward.
EDIT2:
I got IR comm working now too, in 3x version as well.
http://tasvideos.org/userfiles/info/58555860013787500
Finally, this long exercise is at an end and I have a complete re-sync of the pokemon crystal run in GBHawk.
This has been an excruciating but also very rewarding task, as I learned a great deal about the GBC in the process and fixed many bugs both small and large.
With both the crystal run and yellow run working, the Gen 2 catch em all should be doable with realistic accuracy (although linking is not tested for accuracy itself.)
Now we should finally be able to start pushing forward with other games. I already pass many more sprite timing tests then Gambatte does, and with these two runs as bench marks it strongly constrains what in the code can be changed in the future.
This one seemed to give Shonumi some trouble so I used it as a test case to see how robust my implementation is. I didn't run into any trouble, but the games are changing speed a lot during the IR comm process, which is pretty strange. I didn't look into why they do this or too heavily into the IR algorithm since it seems to work just fine. One thing I did notice is that you can't have both players press 'A' near the same time or it fails.
I got IR comm working now too, in 3x version as well.