Posts for Alyosha


Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
smellyfeetyouhave wrote:
I have absolutely zero experience in emulator development so even if I did make it work, it probably wouldn't be pretty. I may take a look though assuming I can find some good references. I have a metric ton of C64 games in T64 format rather than TAP.
Don't worry about it being pretty, or having no experience in emulation. Just getting things working is the biggest and most important step. It's especially helpful for systems like C64 where we are really lacking the knowledge base needed to move the core forward.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
This sounds very similar to what happened to Silva Saga for the NES. New SRAM was initialized to 0x00 but the game expected 0xFF. It read 0x00 as an existing (and corrupted) file. You might want to try making an SRAM file initialized to the opposite of whatever it currently is. I’ll try myself tomorrow or Friday if it’s not resolved already.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Yes. Dip switches are part of the sync settings and are not controls like ‘insert coin’. You can find them in one of NESHawk’s menus (I’m not at my computer right now though to check which one .)
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
With some help from gifvex, I got the recent Pokemon Blue run to sync in GBCHawk. That's pretty good indication that I'm on the right track in terms of accuracy. Also I started working on MBC7 for Kirby tilt 'n tumble TASing, but it's not done yet.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Interesting, I guess with ever increasing technical prowess in researching games this was bound to come up eventually. My opinion would be that as long as the SRAM state needed can be constructively achieved without relying on anything uninitialized, then it’s fine. In this sense it’s similar to a NG+ run, where you still have a setup time but that time isn’t counted toward the run. In SMW you can obviously just get ACE and write whatever you want to SRAM, but generally i would say a set up file is required.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
smellyfeetyouhave wrote:
On another note, does C64Hawk support the T64 format? It's not part of the filter when loading roms, but the core recognizes T64 files as valid files. I can't get it to run any games so I'm guessing it doesn't work? When loading a T64 file, the C64 RAM is populated, but RUN doesn't launch the game. Edit: Looking at the code it looks like the framework is there for T64 files but it doesn't actually know how to handle them. Any plans to support T64 in the future?
I have no plans to do it myself. Probably it would only get done if SaxxonPike returns. Feel free to give it a go if you are interested.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
smellyfeetyouhave wrote:
Sameboy runs the SGB at the SGB1 clock speed, whereas BSNES runs the SGB at the original clock speed. Is BSNES emulating the SGB2?
I don't think it is. SGB in BizHawk needs some work in general.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
That was fast. Nice work! Good to see another open end wrapped up. Edit: I noticed you used the difficulty switches to manipulate the geeese, but this isn’t allowed RTA, do you know what the best time is without switching ?
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I added compatibility for the Bootleg game Rockman 8. This is easily one of the most ridiculous bootlegs I've seen, probably not even worth adding, but I got a laugh out of it at least. I'm not going to spend much time on bootlegs but this one was really easy.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I've made some more commits to GBC, and finally fixed the long open bug with Sachen Beast Fighter. It turns out the GBC Warriors of Might and Magic was doing the same thing as Beast Fighter, so it was pretty easy to work out what the intended behaviour was.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Fortranm wrote:
Thanks for the hard work! Are you gonna implement a hacky support for the GBA mode, or are you gonna wait for the actual bios dump?
GBA mode is supported in the same way as it is in Gambatte, by replacing a few bytes in the GC Bios with ones that seem to correctly reproduce hardware timings. It's probably correct aynway, although technically it's not known for certain.
Post subject: GBCHawk alpha
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Over the past few days I've been expanding GBHawk to have GBC support. It's now in a fairly presentable state so I thought I'd make an announcement in case people want to try it out. It's still a bit buggy but I'm hoping to iron things out over the next couple days. All of the grunt work of sorting things out between GB and GBC is done though, and all of the basic GBC functions are in there (except IR port.) Originally I was going to hold off on doing this until some new test ROMs became available to properly fix PinBall Fantasies, but I don't see them yet and I wanted to get started on GBC while I have a little time to focus. GB is still the primary accuracy component of the core, but I'll be working on GBC accuracy as the core becomes more mature. In terms of performance for me it currently runs about 130 fps, while the GB side runs around 210. I think 130 isn't too bad considering double speed mode, HDMA, and colorizing things makes the core do considerably more work. Maybe some optimizations here and there can improve things a little more, but Gambatte is still 10x faster anyway. _____________________
Kurabupengin wrote:
http://hhug.me/gbx/1.0 Someone is is making a new file format for Game Boy games. I don't know if it's a good idea if GBHawk could support it.
I won't be supporting that. The existing GB ROM header seems perfectly sufficient.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Neat, I'll give it a yes. If you are interested MrWint, you might want to try to get 32.67 in Barnstorming. It's another legendary Todd Rogers time but this one is probably possible, although no one else has reproduced it yet. Should be kind of straight forward from a bot perspective though.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
phoenix1291 wrote:
This is the reason why I wonder, since M.A.M.E is "soon" being integrated, this emulator and this one have not been tested for integration since the "waterbox" exists for BizHawk. And WinUAE seems perfectly suited for such integration, but nothing seems to be planned. We need a CPC emulator as I mentioned earlier, and a Game & Watch emulator, and that would be almost perfect!
Things are added to BizHawk based on the interest of people adding them. Personally I've never even heard of the CPC before, so I have zero interest in working on it. Realistically it would take someone like Asnivor who is really interested in the system to come in and build the core for it to become a reality. (At this point many common chips, such as the z80 and AY-3-8910, already exist in BizHawk in various forms. And probably a lot of architectural elements from the Spectrum could be borrowed for the CPC, but even still it would take a good 15-20 hours of effort to make work.) natt is the only person who can do the waterbox stuff, so it's really up to him what happens with it. Also there just isn't much demand for old computer emulation. Apple II and C64 have a combined 10 TASes. Having said that, if you happen to know any enthusiasts who are interested in working on emulation, now is a good time to jump in. There is low hanging fruit like MSX where there is basically 100% commonality with parts from other cores. It would mostly just involve learning BizHawk's system to make that one work. From there other systems are not that far off.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Mugen Senshi Valis, for PCE, has been a game unplayable in BizHawk since the release of the PCE core. I just now fixed this game, but I thought I'd write a little bit about what went wrong and why it took so long to fix. As it turns out, this game was running some timed code. It's using a VBlank loop to do a few operations, and using the remainder of frame time to load data from the CD. The VBlank loop counts down, and after a certain number of VBlanks, the last VBlank interrupt turns off VBlanks. The game is expecting the other loading code to not be finished at this point, because at the end of the loading code, it turns VBlanks back on again! BizHawk was loading in data too fast. So the loading code was finished too early, and turned on VBlanks even though they were still on. Once the VBlank loop ended, it turned off VBlanks, but now had no way to turn them back on again! Oops! To fix the problem, I just increased the loading time from CD reads, which seemed likely to be the correct solution. This all probably seems pretty obvious just reading that last paragraph, but getting to that point took many hours of debugging, I'm glad it's finally done! Now an even greater challenge awaits, why is there audio issues when loading gate of Thunder in the 4 in 1 CD? I've spent even more time on that one and still have no idea. EDIT: nevermind, 4-in-1 is fixed in the same way. Oldest issue on the tracker solved!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Something that I think is worth pointing out here is that even though GBC BIOS is used, it is modified internally in Gambatte like so:
	unsigned readBios(const unsigned P) {
		if (gbIsCgb_) {
			if (agbMode && P >= 0xF3 && P < 0x100) {
				return (agbOverride[P - 0xF3] + cgbBios[P]) & 0xFF;
			}
			return cgbBios[P];
		}
		return dmgBios[P];
	}
This changes the last few segments of BIOS execution from this:
00F2:  18 02     JR   00F6h          A:12 B:00 C:00 D:ff E:56 F:c0 H:00 L:0d LY:99 SP:fffe  Cy:12985836
00F6:  CD D0 05  CALL #05D0h         A:12 B:00 C:00 D:ff E:56 F:c0 H:00 L:0d LY:99 SP:fffe  Cy:12985848
.
.
.
00F9:  AF        XOR  A              A:43 B:14 C:00 D:00 E:08 F:c0 H:00 L:7c LY:93 SP:fffe  Cy:13053504
00FA:  E0 70     LDH  (#FF70h),A     A:00 B:14 C:00 D:00 E:08 F:80 H:00 L:7c LY:93 SP:fffe  Cy:13053508
00FC:  3E 11     LD   A,#11h         A:00 B:14 C:00 D:00 E:08 F:80 H:00 L:7c LY:93 SP:fffe  Cy:13053520
00FE:  E0 50     LDH  (#FF50h),A     A:11 B:14 C:00 D:00 E:08 F:80 H:00 L:7c LY:93 SP:fffe  Cy:13053528
0100:  00        NOP 
to this:
00F2:  18 01     JR   00F5h          A:12 B:00 C:00 D:ff E:56 F:c0 H:00 L:0d LY:99 SP:fffe  Cy:12985836
00F5:  CD D0 05  CALL #05D0h         A:12 B:00 C:00 D:ff E:56 F:c0 H:00 L:0d LY:99 SP:fffe  Cy:12985848
.
.
.
00F8:  AF        XOR  A              A:43 B:14 C:00 D:00 E:08 F:c0 H:00 L:7c LY:93 SP:fffe  Cy:13053504
00F9:  E0 70     LDH  (#FF70h),A     A:00 B:14 C:00 D:00 E:08 F:80 H:00 L:7c LY:93 SP:fffe  Cy:13053508
00FB:  04        INC  B              A:00 B:14 C:00 D:00 E:08 F:80 H:00 L:7c LY:93 SP:fffe  Cy:13053520
00FC:  3E 11     LD   A,#11h         A:00 B:15 C:00 D:00 E:08 F:00 H:00 L:7c LY:93 SP:fffe  Cy:13053524
00FE:  E0 50     LDH  (#FF50h),A     A:11 B:15 C:00 D:00 E:08 F:00 H:00 L:7c LY:93 SP:fffe  Cy:13053532
0100:  00        NOP  
The GBA identifier being the increment of B to one. @gifvex: how did this realization come about? I'm not aware of the GBA version of GBC BIOS being dumped. Did this solution just match up to observed behaviour and was simple enough to be correct? (I failed to arrive at this solution when looking over the code myself a couple months back so nice work to whoever came up with that!)
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Hurray new core! I consider this a pretty big advancement for BizHawk, it's not very often that a totally new system becomes available for TASing written from the ground up. The Spectrum also uses the z80 much more extensively, and has much more rigorous hardware testing programs available then SMS or colecovision. So along with the new system core it can be used to push the z80 core to be a truly cycle accurate core in pretty much all respects. (but that's a little way off still.) Great work putting this together Asnivor!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
For me 18 minutes of Mario can only be so entertaining. Maybe for aficionados like HappyLee there is some ideal of a ‘perfect’ run, but personally I’m not that interested and I find the technical aspects of optimization more fun anyway. I think in this case two projects with the same goal were happening unbeknownst to each other (until near the end) and MrWint just happened to win, it happens sometimes. Anyway I’ll give it a yes vote, mostly for the submission text.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Yes vote . The pace of this was easier for me to follow then super Metroid so I entertained throughout. Nice run. Edit: oh yeah, an audio channel bug was pointed out to me in 2.2.1 that is fixed in 2.2.2, I don’t know if it effects this game but it might be worth encoding it in 2.2.2 just in case.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Fascinating. I really like stuff like this, working right on the edge of what the hardware can do where accuracy is absolutely required to get it right. And when it comes to edge case ACE runs, my feeling is that it needs to work on hardware or it doesn't count, so having a temp encode of a console verification is a nice touch. Yes vote!
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
petaQ wrote:
C64 4 in 1 game cart doesn't work currently, unpaused Bizhawk auto-starts the first game, failing that you can use Joystick port 2 on frame 4 to select the second. Fiendish Freddy's Big Top o' Fun + International Soccer + Flimbo's Quest + Klax (Europe) (C 64 Games System).crt SHA1: 0b35ea869239ed1edbc4b31e6d5da185bf88ea19
Fixed.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Not planned, but I guess I'll do it eventually. I'll need to think of the best use interface for it though.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Since the coleco turbo controller was fresh in my mind , I decided to implement the A2600 Driving controller since the concept is identical (and way easier since the angular resolution is much lower.) Now you can play Indy500 (and whatever other games use this controller, if there are any.)
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
With a bit more refinement to the ColecoVision core the homebrew game Burn Rubber can now be played using the driving controllers. With this ColecoHawk has really caught up to speed with some of the other in-house cores, and although it doesn't run in single cycle execution yet, it's much more mature then it was when 2.2.1 was released.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
J wrote:
Something that came up on IRC today, the TAStudio state sizes for C64 games seem unusually large for a machine which has 64kB RAM. I tested a few roms, they seem to use either 0.26MB, 1.04MB or 4.26MB: From the cartridge ROMs I tested, one didn't seem to work, it just booted into normal C64 startup. Tested on fresh Vice, worked fine: "Leaderboard Golf (1986)(Access Software).crt"
I have no idea about the various state sizes, 4MB seems way too much though. Leaderboard Golf was incorrectly identified by BizHawk's ROM Loader as having a 128 byte header. It then unhelpfully truncated the actual header before sending it to the core, where it couldn't be processed. Fixing that made the game boot but it crashed before reaching the title screen, haven't tracked down why yet. Fiendish Freddy's Big Top o' Fun + International Soccer + Flimbo's Quest + Klax (Europe) (C 64 Games System) is doing some stuff with the CIA ports that is not being handled correctly, but I don't know how to fix it yet. EDIT: Leaderboard is gettng icorrect NMI's from CIA2. Have to track down what the reason is. EDIT2: For some reason Leaderboard was using the serial port and the core was sending intrrupts related to it incorrectly. For now I just disabled them completely since the current implementation was wrong and I don't think any games use them that I know of (but as always there probably is one out there somewhere.) Anyway leaderboard works now.