Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
^ that's needlessly rude.
@PikachuMan: A simple bug report without the whining will do. We do try to avoid regressions, surely someone will patch it up for the next release.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
It works!
@Masterjun thanks for testing . Yeah each green frame is an input latch. Each red (lag) frame is a video frame edge , so a dump script for playback would only dump green frames.
@DrD2k9 well you can work on Gimmick too. Or anything that polls input often like Punch Out.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
I didn't know this, but apparently there is a dev build for branches as well, you can download a compiled build with subneshawk here:
https://ci.appveyor.com/project/zeromus/bizhawk-udexo/builds/21423589/artifacts
Remember that to enable subneshawk, you need to both enable NESHawk in the core menu and also check the 'SubNESHawk' checkbox in the core menu.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
It's not in the dev build yet, it's still a PR.
You have to build it from source until it's merged.
DrD2k9 wrote:
Awesome!
I love that you figured this out in less than a month after telling me "Subframe input on the piano roll isn’t happening." here. Even if it is only for 1 or 2 cores.
This is essentially what I was suggesting/hoping for. WAY TO GO!
FWIW, I'm willing to help work on getting the SMB3 run re-done to see if it will work.
yeah funny how that works, I guess a change in perspective is all I needed from working on something completely unrelated. That's very often how it works for me.
Yeah SMB3 should probably be the first goal.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Alright I got everything straightened up for a pull request. Anyone who wants to try it out can check out the SubNESHawk branch.
Everything seems to be in working order. You can load up and use TAStudio (audio and video need a bit of work still for TAStudio) and I'm pretty sure savestates work correctly.
Right now I just have default 2 standard NES controllers plugged in, with no option to change them. As things mature I can add back in other options.
Resets aren't supported yet, only normal controller input. If there is a specific use case for it I can look into adding it in.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
brunovalads wrote:
This is really interesting!
Is there any NES TAS that uses subframe inputs? SUBNESHawk would be a different core to be chosen in the core dropdown list? TAStudio would have subframes like "1234, 1234.1, 1234.2, 1234.3 ... 1234.999, 1235"? Could the same be done in the bsnes core, like Lsnes does?
The SMB3 run from GDQ a couple years ago does. it constantly spams different controller readings until a stack overflow happens I believe. Hopefully this will allow that TAS to be remade and published.
You will choose with a checkbox in the core submenu (right below GB as SGB.) You'll need to have NESHawk selected also.
I'm not touching TAStudio, so you'll just have to re-interpret the frame number as input frames instead of video frames.
No this won't work for SNES. What I'm doing relies on the fact that I can run NESHawk at single PPU tick precision from a separate core layer. This is possible for GBHawk as well, so technically it would be possible to make something similar to MrWint's Pokemon Yellow ACE, but that's a long way off. A2600/7800 would also technically be possible to do this. SMS is possible in principle but the core would need to be re-written for single cycle execution.
So basically anything like SNES, GBA, or any ported core is not applicable here. You would need an entirely new emulator for it. This is basically just trickery with being able to run in-house cores with fine precision.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
As I was working through GBHawk Linked play support recently, I suddenly realized that what I was doing was really, really similar to what I needed to do to get subframe input working natively on NESHawk.
In fact, it was so similar that I decided to have a go at implementing it using what I learned from GBHawk.
As it turns out, it worked! I can run the NESHawk core at single cycle intervals until I hit a controller read, or until I hit a frame boundary.
The trick is that I had to modify FrameAdvance to return a bool value depending on whether or not a full frame had rendered. Obviously, all the other cores will just return true as usual, but SUBNESHawk will only return true at frame boundaries.
With this information, you can record video of only the actual frames. So even though a movie file might contain thousands of 'frames' (individual controller reads) when you record a video it will still be recorded at normal frame rate and produce a correct encode.
So, I can successfully bypass all of the problems with subframe input. I can make movies at the subframe level, I can use TAStudio since I have access to the complete core state at every cycle, and I can make encodes at the frame level as usual. Pretty neat!
I'll be making a PR in the coming days as I clean things up, but I don't foresee any major difficulties.
So if you find this interesting, please post suggestions so I can add them in as I go.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Cool thanks for testing! Yeah GBHawk is pretty resource intensive, so unless you have a newer computer it's too slow to be useful in linked play. I have a pretty new computer and I can at least get GBC double speed mode running under linked play at full speed, but not much faster.
I've never seen the multi-disk bundler window crash, if you can figure out how to reproduce that reliably please report it.
I'll go over states again and make sure I didn't miss anything, in the savestate.
EDIT: There was a savestate error after all. Fixed now. (this is why I need people other then me to test stuff I guess.)
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Making more progress on Linking. now GBC double speed mode linking is possible and seems to be fully functional.
I also fixed a weird bug in Lego Racers where the game expected writes to palette data to fail during rendering (which incidentally also fixed the zilog screen in the CUTEDEMO I mentioned a few posts ago.) Kind of weird they wrote it that way, but whatever.
@MUGG: can you try those games you mentioned and see if they are working for you in linked play?
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Challenger wrote:
You did something that was "impossible" until now! Great stuff.
Definitely wasn't impossible, I literally copied gambatte which already has this capability.
It does lay some foundation to extend beyond gambatte's capability though.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
One of the perks of working with BizHawk is that you can avoid the tedious and difficult tasks associated with making an emulator. It provides services for you to work with for audio and video and input, and all you have to do is implement the requirements correctly and everything just kind of works.
With this in mind, I decided to see what would happen if I just hoped for the best and blatantly copied the dualgambatte code and replaced 'gambatte' with 'GBHawk' to try and get linked play support. And in only a couple of hours, it basically worked!
The games aren't actually linked yet, they just run seperately for now. But basically everything else is up and running. I'm surprised how quick and painless the process actually was. Within the coming days I'm hoping to have the actual linking stuff going. I planned ahead for this so that part shouldn't be too hard.
In the future it might even be possible to have 4 player support, but I'm not sure it would run at full speed.
This opens the door for other things down the road like IR and maybe other addons.
EDIT:
Alright got it working!
Initial tests are looking good. Everything seems to be nominally working without grinding to a halt in performance. needs a lot more testing of different cases though. It seems to have trouble when linking is initiated at the same time on both consoles, not sure if similar happens on hardware or not.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Congrats Sapphard and great work ! Too bad you spent so much of your time in frustration only to have a solution randomly pop up, but eh that’s how it goes sometimes.
BizHawk is getting a lot of portability improvements lately, pretty cool.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
I'm working on re-syncing ferret warlord's select glitch run in GBHawk. Originally the idea was just to see if the glitch behaves the same, but it turns out that metroid behavior is very timing dependent. It syncs different between BizHawk 2.3 and the dev build. So if there is a way to test runs directly on a GB, this is a good candidate to check emulation accuracy.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
I was curious about the GB boot rom, so I went to the source by neviksti.
I opened the DMG ROM.txt file, but what I saw didn't resemble what the actual rom was supposed to look like, and it wasn't obvious to me how to extract the bits in the right order. So I went back to the original pics of the physical rom and stitched them together. But even then I couldn't figure out easily how the address decoding was supposed to work, and couldn't find any documentation on it.
Luckily I found this site:
DMG CPU decapped
This had a better zoom which allowed me to see some extra structure, particularly here:
So, you can see 16 lines going into the red box, which presumably is the address decoder for the actual mask rom (the yellowish blob in the top part of the image.)
In the blue area, you can see 8 big doodads which probably hold the data bits. The important part is how they are grouped from lines in the mask rom. Each bit is pulled from 1 of 2 blocks. This is the hint I needed to decode the original text file.
What you do is pull one bit from column 0 of block 1,3,5,7... to form a data byte.
Then you go down one row and repeat to get the next data byte.
Once you reach the bottom, then you go to column 1 of block 1,3,5,7....
Repeat until you are done with all 8 columns of those blocks.
then go and do the same for blocks 2,4,6,8....
Anyway it seems straight forward after you look at that picture, but I stared at the raw bits for a couple hours without realizing what the algorithm was supposed to be.
I didn't see this documented anywhere, so I guess it couldn't hurt to add a little detail to fill in neviksti's missing steps. It was an interesting exercise.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Fortranm wrote:
Alyosha wrote:
NES accuracy tests: Most of the emulators listed in the table there are irrelevant for TAS (or now even for general use.) I'm thinking of simple removing them and leaving only NESHawk, PuNES, FCEUX, and adding Mesen. Also there are some relatively new tests to add. Any thoughts on this?
I actually like the fact that the list includes ancient emulators so that it's easy to see how much progress has been made through out the years.
I think there's a better way / place for historical stuff, but at any rate you can still find the complete table here.
Realistically, Mesen has superseded basically every other emulator anyway. Once it gets TAS tools, the table itself will be more or less pointless.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Alright, I went over the obvious stuff and cleaned things up a bit. There will be more to come.
A lot of the core pages only have one or 2 lines of info, maybe everything can be combined into one 'Core Information' page?
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
I was looking at the BizHawk wiki page and noticed it was quite out of date. I was thinking of taking some time and giving it a bit of an update.
A lot of it is just adding new information or removing old and now incorrect information, but there are a few things I would like some feedback on:
NES accuracy tests: Most of the emulators listed in the table there are irrelevant for TAS (or now even for general use.) I'm thinking of simple removing them and leaving only NESHawk, PuNES, FCEUX, and adding Mesen. Also there are some relatively new tests to add. Any thoughts on this?
TODO page: It's a mess, mostly years old outdated stuff. What should be there now? Is it even needed?
Core road map: I guess it's not even really a road map, just a list of ideas. Are there any concrete plans for any of them?
Known Desyncs: last updated in 2014, is it still relevant?
If anyone has any additional thoughts feel free to chime in.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Fixed a few bugs with GBC emulation so Slugfest intro now runs correctly and several more of Wilbert Pol's GBC variant tests pass.
This also fixed a minor but very annoying bug in CUTEDEMO fish scene.
So overall things are really moving forward quite well for GBHawk.
Making more progress on Linking. now GBC double speed mode linking is possible and seems to be fully functional.
I also fixed a weird bug in Lego Racers where the game expected writes to palette data to fail during rendering (which incidentally also fixed the zilog screen in the CUTEDEMO I mentioned a few posts ago.) Kind of weird they wrote it that way, but whatever.
@MUGG: can you try those games you mentioned and see if they are working for you in linked play?
Alright got it working!
Initial tests are looking good. Everything seems to be nominally working without grinding to a halt in performance. needs a lot more testing of different cases though. It seems to have trouble when linking is initiated at the same time on both consoles, not sure if similar happens on hardware or not.
So, you can see 16 lines going into the red box, which presumably is the address decoder for the actual mask rom (the yellowish blob in the top part of the image.)
In the blue area, you can see 8 big doodads which probably hold the data bits. The important part is how they are grouped from lines in the mask rom. Each bit is pulled from 1 of 2 blocks. This is the hint I needed to decode the original text file.
What you do is pull one bit from column 0 of block 1,3,5,7... to form a data byte.
Then you go down one row and repeat to get the next data byte.
Once you reach the bottom, then you go to column 1 of block 1,3,5,7....
Repeat until you are done with all 8 columns of those blocks.
then go and do the same for blocks 2,4,6,8....
Anyway it seems straight forward after you look at that picture, but I stared at the raw bits for a couple hours without realizing what the algorithm was supposed to be.
I didn't see this documented anywhere, so I guess it couldn't hurt to add a little detail to fill in neviksti's missing steps. It was an interesting exercise.