Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
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
(3560)
Joined: 11/30/2014
Posts: 2744
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
(3560)
Joined: 11/30/2014
Posts: 2744
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
(3560)
Joined: 11/30/2014
Posts: 2744
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
(3560)
Joined: 11/30/2014
Posts: 2744
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
(3560)
Joined: 11/30/2014
Posts: 2744
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
(3560)
Joined: 11/30/2014
Posts: 2744
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
(3560)
Joined: 11/30/2014
Posts: 2744
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
(3560)
Joined: 11/30/2014
Posts: 2744
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
(3560)
Joined: 11/30/2014
Posts: 2744
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
(3560)
Joined: 11/30/2014
Posts: 2744
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
(3560)
Joined: 11/30/2014
Posts: 2744
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
(3560)
Joined: 11/30/2014
Posts: 2744
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.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Lobsterzelda wrote:
Just to double-check: could a movie made on BizHawk 2.3.2 obsolete this movie if it’s faster than this movie, or does it need to be done on BizHawk 2.3.3?
If you are using gambatte it doesn't really matter which version you use, it hasn't changed since 2.3.2.
Really though we should start disallowing older BizHawk builds, most of them are very obsolete.
I see you have a complete level 1 now with a 2 second save, so I'll cancel this one, there shouldn't be any hangups that cost 2 seconds. Feel free to use it as a baseline or just avoid redoing the tedious autoscrollers.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Mario Maker was awesome!
That is the kind of innovative stuff that really fascinates me about TASBot, great work to all involved there.
For the other part of the block I agree with Arc's comments mostly, but am not really sure what to do about it. It's a tough spot to be in.
We have LibTAS now, but Celeste is done already so what comes next? I could make a SubGBHawk for GBC ACE, but that probably would still be seen as old news.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Oops, yeah you are right it should say 'don't change from 8.'
Yeah I should really remove that as a sync setting since it's probably always 8 (actually it's likely just CPU reset vector processing.) It's more of a leftover from comparisons with gambatte earlier on in development.
I'll probably remove it as a sync setting for 2.4. EDIT: Done.
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.