For VSP Mayhem In Monsterland is also a good test case. See also https://csdb.dk/release/?id=126927 for AGSP
I trust you know about the VICE test repository?
I'll check that one out!
And yes, I am familiar with the VICE test repository. A lot more of those tests behave as expected with the merge that I put in today.
The big ones from the merge:
- fixed SID voice 3 going silent with the HP filter enabled
- way better VIC emulation, including VSP
- soft and hard reset (soft reset behavior may need some further research)
- debugger functionality is back in, and both CPUs (the mainboard and the 1541) can be interacted with
- disks can be written to
Some caveats about disk writing:
- G64 images are always read-only because they're generally copy protected disks that are write-protected anyway (perhaps we will want to offer that as an option later)
- D64 images are always writeable (these changes will not be persisted to the input file itself)
- soft/hard reset will not reset the state of inserted magnetic media (but a core reboot will)
- we still do not have a way to save images back out to disk for further study, might be a good idea to treat these changes as we do saveram in the future (but as a delta for this kind of media)
Some interesting info about T64 files, which are apparently unrelated to tapes whatsoever and are a relic of really old emulators:
https://www.lemon64.com/forum/viewtopic.php?t=71839
Now that I know they aren't related to tapes (and even have "1541 file types" on them!) I could probably just stick the contained files into a disk image the same way we do with PRGs and be done with them.
Lots of new work has been done on this core this month. It's probably not good form to do this all in the form of a PR, but..
https://github.com/TASVideos/BizHawk/pull/1607
Mario is looking good. Lots of demos and intros are too. I've got some savestate work to do (trivial) and some disk work as well (not nearly as trivial - there are still some fastloaders that don't like the VIA implementation) but overall, we're in way better shape than we were.
Got some improvements in this week; still working on VSP. VIC pipeline is probably going to need some major updates in order to facilitate the VSP feature.
Even more demoscene stuff works great as a result of these changes. And I’ve got some limited scope tests to be sure that things are working as intended moving forward.
We’re getting closer to acceptable emulation across the board.
I've got a message out to the C64 SMB creator to see if he thinks it may be related to the VSP scrolling. I haven't received a reply yet.
I'm guessing it has something to do with how BizHawk processes that scrolling technique.
I've also tested on VICE with no problems and CCS64 as well also with no problems.
EDIT: I received a reply from ZeroPaige (the SMB dev), who suggested I test Mayhem in Monsterland in BizHawk as it also uses VSP scrolling. After testing, I can confirm that it also exhibits this same twitchy background bug. So anyone wanting to update/improve the C64 core now knows where to look to improve this issue.
Thanks for the tip. The VIC has some things to fix with respect to interrupt and BA/AEC timing. I'm going to be working on this using the examples you provided.
Uridium (this one's plus, but the original would be great):
https://www.youtube.com/watch?v=X4Wvtm7_bd8
That's a really old video from a WIP version, but given how well it worked back then, I think it's definitely reasonable to do now.
I wrote a script that would show on-screen where all the lootable items were in a room:
https://www.youtube.com/watch?v=hhUHl4tpNx8
I'll see if I can dig that up and share it here; the memory locations might be valuable at the very least.
I imagine the optimal route would account for the following:
- placement of puzzle pieces in easy to look locations
- robot behavior
- number of operations required for puzzle assembly (related: cursor movement time requirement)
- placement of the final door
Probably too many variables to do it perfectly in reasonable time, but you could probably prioritize the high impact ones.
Thanks for the answer Alyosha
I also noticed that having the keys for player 1 and player 2 on the same buttons (I did it for simplicity, in case a game requires playing with the second player, for example) could cause some problems in some game (freeze, pause, etc).
Moon Patrol (Moon Patrol (1983)(Atari).crt SHA1: B5F5F296D4E50BF514096508A8ECF5ADF4DFFCEB) directions and jump work well, but the P1 and P2 buttons do nothing.
Would anyone have any advice on "the best" configuration in "sync settings"?
VIC-type: "Pal", "Ntsc", "NtscOld", "Drean"?
SID: "OldR2", "OldR3", "OldR4AR", "NewR5"?
Tape Drive: "None", Commodore1530"?
Disk Drive Type: "None", "Commodore1541", "Commodore1541II"?
I personaly use Ntsc or Pal, OldR2, Commodore1530, Commodore1541II. but it's not the "best configuration" I think.
Having both tape and disk devices connected simultaneously shouldn't cause any issues. Of course you will want a tape drive enabled when running tape games and so on.
NTSC vs NTSCOld: Between these two, avoid using the 'old' setting. There are some very, very old demos and software that will display visual weirdness with the new timing, but it's all pretty much written in 1982- the standard NTSC setting is the vast majority of NTSC systems and most interrupt tricks rely on there being 65x263 clocks per frame as opposed to 64x262 (old). In addition, the regular NTSC setting is also very slightly faster.
Drean: A C64 system was manufactured for Argentina and actually has the fastest clock available, and also has 65x312 clocks per frame - essentially some kind of hybrid between NTSC and PAL timing to the video chip. This will mess with PAL/NTSC autodetection routines (most of them don't account for this kind of system) but it may be possible for some games to actually perform better on this kind of system. It's pretty rare to obtain one of these for real though.
SID type doesn't matter, ideally there would be different filter settings for them all, but really the only difference it will make to the system is Old vs New (6581 vs 8580) because the way the envelopes work is very slightly different and, since envelopes can be read by the system, have the potential to affect any games that rely on reading that register. I suspect this is *really rare* but I recall stumbling across one game that used one of the SID oscillators to generate a wave form which was used to derive vertical sprite positions.
Commodore 1541(II): These just change the kind of disk drive ROM to expect. Almost every fast loader works with the original 1541 ROM, but the 1541-II ROM fixes some bugs (and might as a result conflict with certain fast loaders). Try both with your game, but if you want something free of hassle, the safe bet is the plain 1541.
It also occurred to me we lack a soft and hard reset. That's priority one. Followed by getting better disk and tape support. We still have quite a few games that aren't loading yet.
This reminded me Saxxon, that interrupts need a second look as well. I ran into trouble with the game MoonDust, which was doing some non-standard stuff with interrupts. The fix was simple but it took me a very long time to realize what the problem was. See this commit: https://github.com/TASVideos/BizHawk/commit/f99f9847b43d7ec51899ef65b91443e14e56b1a7
I didn't check for consistency in the other interrupt sources, so it's possible some issues are related to that.
Also porting reSID would be good so my hackish FFT stuff can be removed.
According to this: http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt
...your change is correct. The VIC interrupt latch should not be changed by a potential interrupt condition unless the interrupt itself is enabled. I'll go over the other interrupt sources and make sure that's the case.
I did some playing around with the C64 core tonight, specifically the disk code. A good number of fastloaders and copy protections work. Some do not.
- Unformatted track checks seem to work fine. Shamus is one such game.
- Fat tracks (one form of Electronic Arts protection) work fine. Adventure Construction Set is one such game.
- Vorpal is hit or miss. The games that work consistently work, the games that do not, do not.
For those of you unfamiliar with the system...
Disk games easy start guide:
- At the READY prompt, type LOAD"*",8,1. The " is mapped to shift-2 and the * is mapped to ] to stay relative to the physical layout of a C64.
- If READY shows up again with a blinking cursor, the game is not an auto-loader, so you have to type RUN and press enter. It will commence loading.
Tape games easy start guide:
- At the READY prompt, type LOAD and press Enter. We force Play to be pressed, so it should immediately begin to load the program on the tape.
Things to remember:
- The C64 has two joystick ports. Some games require port 1. Some games require port 2. If your input doesn't seem to be working, switch ports.
- Games that are published on magnetic media have very slow access times. Be patient with them.
- Cartridges require no intervention; they will load immediately.
It also occurred to me we lack a soft and hard reset. That's priority one. Followed by getting better disk and tape support. We still have quite a few games that aren't loading yet.
I'd be happy if I could get to 180 fps (without making the code unreadable.)
I tried not resetting the other 2 array values but it didn't seem to speed anything up.
I'm not familiar with what 'unsafe' code means. I'm not a programmer in real life so to me that sounds ... unsafe.
Good idea about the decay function though I'll definitely look into that.
Sure I'll report back tomorrow with frameDelay and emulationSpeed values. I'll edit the results into this post.
thanks for the help!
C# doesn't have macros or that's how I'd be doing performance optimizations. As it stands, the C64 core is hardly optimized at all (mostly because it's still got some ways to go before it's decently compatible.)
C# does favor type and memory safety above performance, but it does offer "unsafe" access via pointers at least. I'm quite tempted to use them myself after the C64 core matures. I would refuse to do any sort of addressing with unsafe pointers that I couldn't calculate with bit masks, though: these tend to be the least crash prone if the array is large enough to hold all the possible addresses.
The code above uses multidimensional array access. That's expensive because of all the additional checks it must do to retain safety. int[][] is said to work better than int[,]. It also allows memory management to split up the inner arrays better in memory as opposed to allocation one massive chunk. Downside is each inner array needs to be initialized individually. Not a huge deal if only ever done once. Alternatively, if you wanted to throw readability right out the window, you could flatten it to one giant array and consider the sprite number as part of the address.
Those are my two cents.
Anything's possible in an emulated environment ;)
I haven't looked at it in some time, but I'm guessing we would probably just use the existing bundling mechanism. A lot of C64 owners (in the US at least) almost permanently had an Epyx Fast Load in their systems.
Then there's the prospect of custom Kernals such as Jiffydos...
This stuff *could* probably be implemented, but where do we draw the line for TAS? I also feel like the existing disk bundling mechanism we have right now might not entirely be appropriate for this sort of setup.
Something to investigate when I get back.
Some software on the Commodore 64 is locked to a particular video standard (they will attempt to survey the video hardware to determine this) but quite a lot of software, especially early software, will actually run on both. Many of these titles will run faster and have their sounds and music pitched higher on NTSC.
Everything depends on the video circuitry you choose. Here are the important ones:
MOS 6567 R8 - NTSC, prefer later revisions as they're a little faster and are far more common (some timing sensitive games will not run correctly on R56A.)
MOS 6569 - PAL (these are all identical as far as games are concerned)
Edit: The compatibility of the media itself has nothing to do with the video standard, all disk drives have a fixed 16mhz internal timing system, the C64 KERNAL handles tapes in a standard-agnostic way, and the only thing that's verified on cartridges is the string "CBM80", to verify a cartridge is in fact connected.
I tried to implement writes, but the results weren't that great. The write logic seems to be different than the read logic. Something for the to-do list for sure.
No, that isn't supported in BizHawk at this time. Feel free to write up a feature request. I thought about adding this support for C64 (those nib converters are hard to find and suck). It will be more complicated to support .nib for both, I'm not sure what the user experience would be there.
NIB files are a little more tricky to work with. When they're extracted from a C64 disk, for example, they often have more than one single rotation of the disk per track. In order to get a G64 file out of it, they will estimate where in the NIB file each track repeats. It's especially tricky with disks that use a custom format- you just sorta get a bitstream and have to guess.
We would probably have to employ something like Nibtools.
cpu_exec_space/test_cpu_exec_space_apu now passes with a few simple fixes. That makes 10 new tests passed, up to 90%!
I did not include DMA timing fixes, as I still don't know the problem is, so that 90% can be taken with a grain of salt, but still this is progress.
Pretty much every remaining test involves the APU. This is good, since it means the rest of the core is really solid, but that is also the least developed part, so will take some effort to get in order.
Oh good catch! After looking at that I noticed that the dummy read for various instructions also is not affected by the RDY pin as it should be, and I think that is part of what is keeping from passing some more of these test, so fortuitous timing.
Glad to hear! I'm thinking that should take care of all the dummy reads. A quick skim revealed nothing else.
If you're looking over it more, just remember the rule of thumb: if the 6502 isn't writing, it's reading. This applies at all times, regardless if the read is useful. If the code doesn't perform exactly one of these in any given cycle, it's a bug.
I noticed that the DMA work you've been doing relies on the RDY pin. I've put off working much on the 6502 CPU core until after I could get some automated testing going. However, the IncPc micro-op in the MOS6502X core was missing the dummy read (which would be stalled by RDY.) I've committed that fix today to master.
AHX/SHX/SHY illegal opcodes affected by the high byte of the effective address also behave differently based on the RDY pin. More info here: http://csdb.dk/forums/index.php?roomid=11&topicid=94460
If you read that, keep in mind that in the C64 context, RDY is controlled by the video chip and is made inactive when it needs the bus fully.
Now that we have disk support, I'm able to run the "1541 Test Framework". This is essentially a list of programs that will be loaded into the disk drive and run. Since the drive uses a 6502 processor (and not a 6510 like the main computer) tests against it should benefit other cores that use the 6502.
I don't have time this weekend to do much more testing. But it did reveal a couple things in decimal mode (ADC, SBC) that need to get fixed. It also failed on some of the "invalid" opcodes, but I'm not surprised- these often return different results depending on what machine the CPU is installed in.
I worked on Prophet64 and Action Replay (4.2+) support this week. I don't have a ROM to test the first with, and the second is being difficult. But the AR fastloader is reportedly the fastest cartridge-based loader you can use, according to this: http://www.lemon64.com/forum/viewtopic.php?t=41482&sid=697e0d8b25d115ffbfdc20ad9bffdd85
Better Action Replay 4.2+ support will come soon. There are still some incompatibilities with Krill's loader also. I'll be addressing all of these problems soon.
Would anyone have any advice on "the best" configuration in "sync settings"? VIC-type: "Pal", "Ntsc", "NtscOld", "Drean"? SID: "OldR2", "OldR3", "OldR4AR", "NewR5"? Tape Drive: "None", Commodore1530"? Disk Drive Type: "None", "Commodore1541", "Commodore1541II"? I personaly use Ntsc or Pal, OldR2, Commodore1530, Commodore1541II. but it's not the "best configuration" I think.