Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Al82 wrote:
Not having much luck with the MSX core - I just get a black screen when trying to load a cartridge. Bios files are present in firmware and no error message (only thing mising is bios_test).
Try with only the bios file I linked above in your firmware folder. (remove the MSXJ one so it won't load it.)
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Did you download the most recent dev build? Do you have MSXHawk.dll in your dll folder?
Those are the freeware BIos files from C bios 0.29a that I use for testing.
(The most recent dev build works fine for me.)
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I have added MSXHawk to the dev build. Currently it will load with Jp bios to NTSC mode. It also uses the JP keyboard layout.
It doesn't support basic yet, only loading cartridge ROMs.
Please test and let me know of any deficiencies.
NOTE: most games don't require the keyboard, so I have default controller settings to joysticks only, change it in sync settings if you want / need to use the keyboard.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
It looks like you only exported one player into the fm2. Also i forgot I even had a WIP of this. I hope you are motivated enough to continue, it would be nice to see this done, even if it is in FCEUX.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
^I'll leave A5200 for any potential future devs to work on as an easy case. MSX (and O2) will be the last two 8 bit systems I work on personally. There's a lot of low hanging fruit right now, I hope it peaks someone's interest.
I've added keyboard support to MSX and made some optimizations that give about a 10% performance boost. I'd say it's almost ready for general testing. I probably won't be adding floppy disc support at this time, so I'm starting to think about MSX 2.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
^ fixed in master.
@SchlAuChi: I have a line glow algorithm built in, but it's hard to tell since it's currently so pixelated it just looks blurry instead. I'm not interested in overlays since that's basically postprocessing, but maybe I can look into higher resolution.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
TASVideoAgent wrote:
I chosed the Bizhawk emulator over FCEUX, contrary to the previous run, as it can play the rom unmodified (and its movie file suffix is short for this very game :D).
:O, somehow this is something I would have never thought to put together myself, it's always funny to me how people perceive different things.
Anyway yes vote, nice improvement.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Alright thanks for the help, I'll go with that then.
I'm leaving some notes here as I try to make performance improvements.
One of the most important things I realized is that performance is directly related to video buffer size. This was unexpected. At first I was trying to compare to gambatte which was getting 800 fps. But then I removed all calls to MSXhawk and just ran the core doing nothing and it only got 700 fps. I struggled to figure out what was going on until I decided to change the screen size as a last resort. I changed it to only be 100 x 100 and got over 1100 fps. This also means I was wrong with my previous guess that the ppu was slowing things down.
I'm not sure what to make of this. I seem to recall this not being the case before. I ran up QuickNES to double check, and sure enough it only goes at ~600 fps, where as in my memory I'm pretty sure it used to go double that.
But anyway, using 700 fps as a starting point, adding in fetching the video buffer and sound buffer from the core and processing controller input and other once per frame tasks like that costs negligible performance as expected.
Processing video is actually quite fast, costing only about 25 fps.
Processing audio costs 50fps.
So roughly speaking with the cpu turned off the core does 625 fps. Not too great considering this is roughly equal to quicknes running correctly. With the CPU running in it's current state I'm at 450.
Knowing this gives me at least a more realistic target. I can't get to gambatte speeds but if I can get to around 600 fps I'll be in good shape.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
^thanks, that saves e a bit of time. Is there a standard one for PAL, or is it the same?
I'm making decent progress overall. Savestates seem to be working and I can load basic games. Still have to do keyboard and a few other details.
This one seems to be going at about 450 fps compared to the 550 I had with GG. The cpu is the same at same speed, and the sound isn't much different, so the ppu must be much slower here. This will be a good chance to see what kind of things work on the ppu side to speed things up.
With some effort I'm pretty sure I can end up around 600 fps through obvious optimizations. I still want / need to be around 800 though, so I've got a very long way to go.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I'm able to get in game now on MSX1 with joystick control.
There are some audio bugs left to work out and I haven't thoroughly tested savestates yet, but at least for MSX1 this is almost in a TASable state.
I could use some help getting a list together of good hashes (SHA1) for BIOS files though, if anyone more familiar with the system knows what the standards are.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
If I remember right the enemy that comes out of the crystal on the screen before the boss is on a very long global timer, nothing you can do about it. Other then that there are a lot of little tricks to battletoads movements, feos is the expert.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I've converted over to an actual MSX machine now and am getting the bugs worked out. It shouldn't take too much longer to have a reasonably complete MSX1 machine ready for use. I'm not sure how far I'll go into the MSX line up, maybe just the 2.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Fortranm wrote:
Do you plan to turn this into new cores for SMS and GG as well?
Nope, I don't really see that as being of high utility.
After the first big round of optimization in the CPU I'm at about 550 fps. Started from about 495 so not bad, but a long way to go. This came at a fairly substantial cost of clarity in being able to follow the code step by step, as I basically pre-compiled the instruction vectors at the start. This cleans up the execution loop but also adds some complications in some execution paths. Regardless though this is necessary for any more modern core so it was good practice.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I'm making steady progress on the new core. Input, sound, and savestates now work. If this were a production core it would basically be done.
Now it's time to optimize. I've already played around with a few things, and was happy to see that things I thought might improve performance actually did. This is very welcome considering how much I banged my head against the wall with C# trying to optimize things.
Once I'm comfortable with the level of optimization and can verify that nothing gets broken along the way, I can start the process of turning this into an MSX core. That part shouldn't be too hard hopefully. Having all of this infrastructure and the z80 in place is already at least 80% of the work.
For follow on work I'm leaning heavily toward an MC68000 based system. I think this will offer the most utility in the long run just having the cpu available. But I'm still not 100% sure yet.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
I'm making progress on a new C++ core. I made a game gear version as a proof of concept since it has mostly the same parts as MSX. It was more of struggle to convert things to work in C++ then I thought. Actually most of the problem was due to needing to use a C interface in the DLL. Things would be so much easier if there was a standard C++ interface, but oh well. This was a very worth while exercise because I was able to sort out most of the bugs just by comparison with the existing C# core.
As you can see in the screenshot, this core runs around 490 fps on my laptop. This is actually not very good, since this core in C# runs at 310 fps. This is no where near the performance I need, it should be up around 800 like gambatte. So I obviously have a long way to go in terms of optimization. The whole point of going to C++ though is that there are many possibilities to achieve those optimizations, so I'll be starting down that road once all other aspects of the core are done.
On the up side, starting from scratch has let me organize the core in very straightforward way that should hopefully be largely reusable as I build more systems. Also some of the more complicated things like memory domains and trace logger are done. The two major thins I have left to add are sound and savestates, but neither of those should be too tough.
After that I'll probably rework the CPU core to take advantage of C++ features. The Z80A is really slow, partly because I needed to capture all the signals for spectrum and CPC, but also just because it's poorly optimized. That was partly by design since I wanted maximum clarity in order to easily fix bugs in development, but by now it's quite well verified and I can sacrifice some clarity on the C++ side to go fast.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
Wow! Starting off 2020 strong with a awesome find, nice work The8bitbeast!
Although I would like to see this performed on console to ensure it's not a mupen artifact.
Editor, Experienced Forum User, Published Author, Expert player
(3602)
Joined: 11/30/2014
Posts: 2749
Location: US
feos wrote:
“arc” wrote:
They also suggested using some games that aren't so ancient. The zoomers watching were born around the year 2000 and didn't grow up with games from the 1980s/90s.
Do they also realize that GDQ runs also play “ancient” games? Because this isn’t a TASBot only thing. Do they even understand the point of GDQ?
I don't think they are really comparable. I think people expect novel things from TASBot that demonstrates advancement, it's why TASBot gets prime time spots and not early morning spots.
I'm able to get in game now on MSX1 with joystick control.
There are some audio bugs left to work out and I haven't thoroughly tested savestates yet, but at least for MSX1 this is almost in a TASable state.
I could use some help getting a list together of good hashes (SHA1) for BIOS files though, if anyone more familiar with the system knows what the standards are.
I've converted over to an actual MSX machine now and am getting the bugs worked out. It shouldn't take too much longer to have a reasonably complete MSX1 machine ready for use. I'm not sure how far I'll go into the MSX line up, maybe just the 2.
I'm making steady progress on the new core. Input, sound, and savestates now work. If this were a production core it would basically be done.
Now it's time to optimize. I've already played around with a few things, and was happy to see that things I thought might improve performance actually did. This is very welcome considering how much I banged my head against the wall with C# trying to optimize things.
Once I'm comfortable with the level of optimization and can verify that nothing gets broken along the way, I can start the process of turning this into an MSX core. That part shouldn't be too hard hopefully. Having all of this infrastructure and the z80 in place is already at least 80% of the work.
For follow on work I'm leaning heavily toward an MC68000 based system. I think this will offer the most utility in the long run just having the cpu available. But I'm still not 100% sure yet.
I'm making progress on a new C++ core. I made a game gear version as a proof of concept since it has mostly the same parts as MSX. It was more of struggle to convert things to work in C++ then I thought. Actually most of the problem was due to needing to use a C interface in the DLL. Things would be so much easier if there was a standard C++ interface, but oh well. This was a very worth while exercise because I was able to sort out most of the bugs just by comparison with the existing C# core.
As you can see in the screenshot, this core runs around 490 fps on my laptop. This is actually not very good, since this core in C# runs at 310 fps. This is no where near the performance I need, it should be up around 800 like gambatte. So I obviously have a long way to go in terms of optimization. The whole point of going to C++ though is that there are many possibilities to achieve those optimizations, so I'll be starting down that road once all other aspects of the core are done.
On the up side, starting from scratch has let me organize the core in very straightforward way that should hopefully be largely reusable as I build more systems. Also some of the more complicated things like memory domains and trace logger are done. The two major thins I have left to add are sound and savestates, but neither of those should be too tough.
After that I'll probably rework the CPU core to take advantage of C++ features. The Z80A is really slow, partly because I needed to capture all the signals for spectrum and CPC, but also just because it's poorly optimized. That was partly by design since I wanted maximum clarity in order to easily fix bugs in development, but by now it's quite well verified and I can sacrifice some clarity on the C++ side to go fast.