Freeplaytech Forum

Full Version: NeoGPC v1.1.0 - (11/9/2013)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8
Glad seeing support for NGP/NGPC emulation. Will full bios emulation equal reading my horoscope on the emu? Only time will tell. LOL

Keep up the good work.

(11-06-2012, 03:01 PM)Cthulhu32 Wrote: [ -> ]I went ahead and released an updated Test 2 of the NeoGPC emulator. I found the scratchy audio issue, added back in the flash reading/writing and added Flavor's code changes for reading from the Flash when the chip is in flash read-mode. I still need to investigate exactly what Koyote.bin is before I add that in, but I believe its a memory dump immediately after a boot. That means the bios has executed all of its routines and the rom has just loaded, giving us a fresh RAM post-bios. If someone could confirm this that would be mucho appreciated.

I'm gunning for a December release of the first alpha. This will essentially do everything RACE/NeoPop does, but in a nice external way so it should be easy to port. The sound code is still a bit tricky, but I managed to pull all Win32/SDL dependencies out of the core and cpus. I'll keep on trucking, and I can always use some moral support Smile

You've got my moral support. I really like how this is coming along.

I think you're right about Koyote.bin. I haven't looked at it for quite a while, but my recollection is that it's a mem dump with all the values necessary already set up. For anyone that didn't know, Koyote was another NGPC emulator made by a guy named David Raingeard.
I can't seem to get a new attachment in the first post, so I'm putting the latest test in here. I fixed the graphics being blurry, the DAC sound buffer, updated the menu quite a bit, and its getting much closer to the first release.

I'm also being heavily distracted by reverse engineering the entire NGPC bios. Its a daunting task (there's A LOT of code to go through and a lot of undocumented calls) but I'm learning a ton. I'll post updates on that possibly in a different thread, but I don't want to dive too deep until I can compare software vs. hardware results.

Hopefully after Turkey day I'll get some time to finalize the first edition of the emu and start working on the graphical debugger. I've gotten the okay from my wife on ordering the FlashMasta on Nov. 30th, so expect an order then flavor Smile
Nice to see more progress in such a short time! Unfortunately, despite the improvements, the emulator simply kills my processor, taking as much as 45% ~ 75% of CPU time. Today I closed pretty much everything I had running in the background, and simply started the program. Here's the Process Lasso graph [click to enlarge]:

[Image: neogpcprocess.th.png]

You can easily spot when the emulator was started and when it was closed down. The processor use goes all the way up, to the point when Process Lasso lowers process priority of the emulator. The graph shows a decrease in responsiveness, but when the emulator is running, the overall system responsiveness is much lower than those 40% or 50% drop spikes, so I'm not really sure how Process Lasso determines responsiveness in general.

Everything goes back to normal pretty much the second I shut the program down. I'm probably going to test this on a laptop, which is newer and faster, even though it came with Windows Vista. This slowdown problem makes it pretty much impossible for me to test anything, so here's to hoping things will get faster in the near future!
Keep in mind that RACE! was mainly developed to run on a single-application handheld platform. When it is running, it assumes that nothing else is important.

There are some places in the emulation that wait for things to happen. In particular, I can think of a main emulation loop that tries to emulate clock speed by waiting until the right time to execute the next set of operations. What I don't recall is how this loop is implemented. I think there were different versions of this. On a multitasking OS, you would not want to do something like this pseudocode...

while(it's not time for the next operation)
{
check what time it is
}

Essentially that would just keep checking the current time until the proper time is reached. This sort of thing should probably be changed to something more like.

if(it's not time for the next operation)
{
waitTime = calculate how long until the next operation
sleep(waitTime)
}

I don't know what state the code is/was in. Even if the main wait is already written like the second version, there may be other places that aren't releasing the CPU when they're not doing anything useful.

I'm not really telling you this as a coder, Cthulhu32. I'm more mentioning this generally to anyone reading.

Oh, and yeah, I have some bundles ready. I think I have 2 that are pretty much ready to ship. After that, I have about 6 more that just need a bit more soldering and testing.
(11-22-2012, 12:28 AM)Flavor Wrote: [ -> ]Keep in mind that RACE! was mainly developed to run on a single-application handheld platform. When it is running, it assumes that nothing else is important.

There are some places in the emulation that wait for things to happen. In particular, I can think of a main emulation loop that tries to emulate clock speed by waiting until the right time to execute the next set of operations. What I don't recall is how this loop is implemented. I think there were different versions of this. On a multitasking OS, you would not want to do something like this pseudocode...

while(it's not time for the next operation)
{
check what time it is
}

Essentially that would just keep checking the current time until the proper time is reached. This sort of thing should probably be changed to something more like.

if(it's not time for the next operation)
{
waitTime = calculate how long until the next operation
sleep(waitTime)
}

I don't know what state the code is/was in. Even if the main wait is already written like the second version, there may be other places that aren't releasing the CPU when they're not doing anything useful.

I'm not really telling you this as a coder, Cthulhu32. I'm more mentioning this generally to anyone reading.

Oh, and yeah, I have some bundles ready. I think I have 2 that are pretty much ready to ship. After that, I have about 6 more that just need a bit more soldering and testing.

Yeah I need to find a cleaner way of sleeping in Win32. Right now I'm not sleeping at all which is why its killing your CPU most likely, but I do have a QueryPerformanceCounter() in there to determine when it needs to run the next Z80/TLCS step.

I will work on this for the next test version and see if I can get the performance up, that is a pretty big CPU hit for this emu.
Flavor, you should see my order come through as I just bought a Flashmasta. Excited to get some real hardware, this should really progress my BIOS dumping as there is a lot of undocumented BIOS calling stuff going on. A first version of NeoGPC is coming soon, then I'll start working on the debugger and BIOS emulation Smile
Yeah, I got it, thanks! I plan to get this sent out around Tue/Wed next week. I have some units built, but these last batch have had some questionable components. I've needed to do extra testing and sometimes had to replace/resolder. It's all part of the process, but I just want to let you know. This also reminds me that I need to send an email to another guy that recently ordered.

Thanks!!!
No problem at all, its better to double check everything and do it right than have to deal with troubleshooting later on. Take your time and thanks again!
While trying to test the patch , I've seen that RACE (and NeoGPC too) have graphical issue with Melon's chan growth diary.

I don't know if other black & white game behaves the same but at least, Master of Shogi is ok.
Pages: 1 2 3 4 5 6 7 8