(2013-08-14 videos removed, they are old.)
I'm awful at this.
There's still a long road ahead, but at least some things are playable. More videos to come once more is implemented.
Based on the interest expressed, mapper 0005 (Ocean) has been added to the interim. This includes games like Robocop 3 and Terminator 2. Sprites aren't coded yet so it's not really playable, but it loads and executes fine. When sprites are added, it should be ready to play.
Robocop 3 required some firmware. What file do I need?
FW is required for all games. The ones I am testing with are from the VICE 2.4 emulator (which can be found online) however any firmware for the C64 should work. The four that are required are: basic, kernal, chargen, and dos1541. They should be placed in C64\Firmwares.
Robocop 3 won't work just yet anyway- that cartridge mapper isn't implemented (it's unique). I don't envy the NES team- there are only 28 known mapper configurations for C64.
Heisanevilgenius wrote:
Yesssssssssssssss
You've got some baller Moon Patrol skills, son. I did notice with that game the explosion sounds seemed rather quiet. I don't remember it being like that on C64 hardware or other emulators. Maybe it's related to the sound issues you're having?
Thanks :) The sound has been completely rewritten since these videos, and sounds a lot more like the real thing.
A funky chip. I like it :)
Patashu: Your Famitracker stuff is impressive, that's good for 1 hour :x My OHCs in tracker don't compare.
Here's a little something from my newest release.
Link to video
Accuracy tests: (more to be added later)
Sound
(2013-08-14 link removed.)
Status: Really needs work. You can load the PRG files directly into the interim build to test them (they are direct conversions from the SID files)
Envelope test: Commando
Filter test: Progressiva
Waveform abuse test: Opium 2
Waveform sync test: R1D1
Graphics
coming soon..
Here's what I've been busy doing the last couple weeks...
NOTE: The sound will be a little rough on some of these videos! Please watch your volume.
(2013-08-14 videos removed, they are old.)
EDIT by feos 2019-06-22Introductory Guide to Commodore C64 TASing in BizHawk
Sound core emulation tends to be the most needed. The APU in NESHawk for instance is its weakest link. Atari sat for quite some time with no sound core. We have a few cores in the work that I'm worried about ever having sound.
I can't say I am terribly familiar with all the sound cores needed, but I'll definitely look it over and do some testing. It'll take a bit to get off the ground with anything other than C64 SID since that is really the only sound chip I know from top to bottom. But there's a ton of documentation for the NES APU, so it shouldn't really be that hard if the docs are good.
I have coded projects in C#. In my sig there's actually a link to an emulation project I have created myself. I am familiar with 6502-based ASM and have contributed to both the demoscene and the VICE Commodore 64 emulator.
It may not be relevant but I have also have contributions lined up for MAME. (specifically, 4-bit DPCM accuracy in the 054539 chip)
My expertise is in sound processing, but emulation is fascinating and I would like to contribute to this rapidly growing project.
I'm really curious, what is it about the emulation that actually makes it slow? I know it's due to accuracy, but what specifically takes so much processing time?
I think it's fantastic you were able to abuse this bug. The whole idea of skipping directly to the end is exciting. But my vote means "would I watch this again?" No, probably not.
Edit: nevermind this post. I need to finish my findings and confirm :]
By the way, you can open doors in the move box on the lower-left. Would this save any time in the very first screen where you escape the car?
In fact, you can open doors and travel when you have no action selected (0012=00). This does not work on openable objects- it simply examines them in this case.
Do you have any documentation on the interpreter? I want to develop something that picks apart the scripts for all 3 of the NES Macventure ports so that we can more easily find exploits. So far, I've been able to get object name text and I've also isolated the 6-bit text decoder.
Unrelated but interesting: object 59(hex) wins the game when you Examine it. It first says you can't open it, it's locked! Then the screen fades out :P
Whaaaaa. That is an impressive way to break the game! But I do agree, the run's real value is in the shock value, and after watching it once loses it. Still definitely worth publishing if only to have people see it once and get the same surprise!
