I'll be back to making commits here sometime in the next couple days.
First I have some z80 stuff to work out but I hope to start knocking out CGB test roms after that.
Making renewed progress here now.
I fixed the virtual pad and included tilt controls.
Unlicensed games from Wisdom Tree are now supported.
The GBVideoPlayer tech demo is only one timing bug away from working, though it now correctly loads and plays the video, just a bit garbled. I know what change needs to happen to fix it, just not 100% sure of the proper implementation yet.
I made a few more timing fixes that fix some issues with a few of the more sensitive tech demos out there.
Oh! and CUTEDEMO relied on latching behavior of x-scroll which is now corrected.
Oh! also relied on sprite evaluation not happening in DMG when sprites are turned off. This is actually an easy to see hardware difference between it and CGB, where sprites are always evaluated.
GBVideoPlayer is now working as well, which relies on careful timing between STAT interrupts and y-scroll latching. So it's pretty cool to see it working. It will crash at the end though since the ROM is not padded to a standard size. I'll make a fix for that eventually.
At the same time I am being careful to make sure all the various test ROMs still work, so overall these are small but important accuracy improvements.
As a bonus, the notorious dycptest2 test ROM now looks correct:
So things are moving forward pretty well.
EDIT: CUTEDEMO still has what appears to be some BG color latching behaviour that needs to be implemented in the 'zilog inside' scene. I would need to see it running on real hardware to make sure though.
EDIT: CUTEDEMO still has what appears to be some BG color latching behaviour that needs to be implemented in the 'zilog inside' scene. I would need to see it running on real hardware to make sure though.
Does it need to be a monocrome GB or is GBC also fine?
EDIT: CUTEDEMO still has what appears to be some BG color latching behaviour that needs to be implemented in the 'zilog inside' scene. I would need to see it running on real hardware to make sure though.
Does it need to be a monocrome GB or is GBC also fine?
It has to be in GBC. That particular demo is GBC only.
EDIT: Also I implemented HuC1 support if anyone wants to test out those games. I don't know how they are supposed to use the infrared port. I can add it in as a control if necessary.
Joined: 3/31/2010
Posts: 1466
Location: Not playing Puyo Tetris
Alyosha wrote:
EDIT: Also I implemented HuC1 support if anyone wants to test out those games. I don't know how they are supposed to use the infrared port. I can add it in as a control if necessary.
HuC1 was used in Pocket Bomberman. I noticed that in the Jump game mode, the game will lock up at a particular point. Maby it's trying to use IR and the Emulator fails to have that emulated so the game crashes?
Though, it has been a while since I played Pocket Bomberman. Could be a useful test to see if the Jump Game crashes in Emulator using the new GBHawk?
It should be noted that I don't think the IR Port is useful at all in the game itself, except for maby trading scores? But during the game the IR port shouldn't need to be used.
When TAS does Quake 1, SDA will declare war.
The Prince doth arrive he doth please.
I just made a pretty big commit to GBHawk to improve accuracy fairly significantly. A bunch of tests from Wilbert Pol (which are variants of Gekkio's tests but also a lot of cool original stuff) now work for GB. CGB is a bit behind still, but I hope to catch up a bit as I sort things out and clean everything up.
There is a little work left to do for sprite evaluation, but it's now much more accurate. Also everything is much more fine tuned as the overall maturity of the core goes up.
If anyone finds any regressions please let me know.
GBHawk now passes all of Wilbert Pols sprite timing tests, hurray!
These tests combine x-scroll with sprites at various positions. They are pretty grueling. I'm pretty happy to have gotten them working. It means the most complicated part of the rendering pipeline is pretty solid.
Now I can move on to some of the subtleties of the GBC and weird stuff that happens with LY.
EDIT: Maybe this also fixes whatever is wrong with Mickey's Dangerous Chase.
You can now play HuC3 mapper games in GBHawk.
RTC is untested and IR functions don't work, but the mapper runs just fine.
Probably next will be MM001 or TAMA5.
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.
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.
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.
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.
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?
It is super laggy (22 FPS).
Master Karateka works. The game lets you fight 1 on 1 on a stage that resembles the first stage in solo play.
The loser gets kicked in the balls in good old Karateka fashion, lol...
Tennis lets you play 1 on 1. Maybe very interesting for TASing some tight matches.
Volley Fire lets you play 1 on 1. You can choose how much health each player has and what stage to play on (7 available stages).
----
In this very brief 20 minute testing, I ran into a fatal crash with the multi-disk bundler window (maybe a malformed .xml file?), and with Volley Fire I had the 2-player mode disengage randomly (maybe as a result of loading a state at a bad time). Player 1 was on the "choose health and stage" screen and Player 2 somehow reset itself and was on the title screen again.
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.)
I'm trying to make a test TAS with 2 player Tennis in GBHawk.
I noticed when loading a state, it does not immediately update the screen. Is there a way to turn that option on, or is it a bug, ...?
EDIT: I have encountered a desync while TASing (I spent like 10 mins)
http://tasvideos.org/userfiles/info/52509926919438589https://www.youtube.com/watch?v=FDmNfv_oBZ0
EDIT: Spent an hour or so, without desyncs. I will up it on my main channel.
So things are moving forward pretty well.
EDIT: CUTEDEMO still has what appears to be some BG color latching behaviour that needs to be implemented in the 'zilog inside' scene. I would need to see it running on real hardware to make sure though.
You can now play HuC3 mapper games in GBHawk.
RTC is untested and IR functions don't work, but the mapper runs just fine.
Probably next will be MM001 or TAMA5.
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.
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.
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?
Tennis lets you play 1 on 1. Maybe very interesting for TASing some tight matches.
Volley Fire lets you play 1 on 1. You can choose how much health each player has and what stage to play on (7 available stages).
----
In this very brief 20 minute testing, I ran into a fatal crash with the multi-disk bundler window (maybe a malformed .xml file?), and with Volley Fire I had the 2-player mode disengage randomly (maybe as a result of loading a state at a bad time). Player 1 was on the "choose health and stage" screen and Player 2 somehow reset itself and was on the title screen again.
