You are not logged in.
Lost Password?


Register To Post



 Bottom   Previous Topic   Next Topic

#21
Re: PVB Collaborative Emulator
Posted on: 2016/8/19 18:21
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (6 Years)
I spent the last week considering the best way to handle GUI stuff, and settled on a disappointing conclusion: it will be most appropriate to treat SDL as the target plaform, rather than try to make everything platform-independent.

When considering how to implement GUI things in a platform-independent way, the solution I kept coming back to was basically "write a generic API that wraps around SDL for one implementation and whatever else for other implementations." Since SDL is already doing that with native windows and I/O, it just adds another layer of abstraction where there doesn't really need to be one. If some port of the emulator application needs to implement its internal API regardless, it may as well implement a stand-in for the SDL functionality directly.

In other, more exciting news, I've decided to add armhf and arm64 to the list of supported architectures for Linux. This benefits the general mobile market, but has particular significance for single-board development. Raspberry Pi in particular has a community with a strong emphasis on video game emulation.
__________

EDIT:

Oh yeah, forgot to mention... As part of the initiative to treat SDL as the target platform, I've also opted to forego OpenGL directly and use the SDL 2D rendering API instead. This was an easy decision because there's about one finity ways to implement something, and even if my OpenGL code works one place, it may not be suitable in another. May as well code up the GUI renderer in such a way that it's best-suited for the platform at hand, and that would be through letting SDL decide how to best carry out its drawing instructions.

A 3DS version of this emulator will probably just wind up using the emulation core library and implementing its own GUI from scratch...
Edited by Guy Perfect on 2016/8/19 19:27
Top

#22
Re: PVB Collaborative Emulator
Posted on: 2016/8/29 2:38
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (6 Years)
It's not time to turn in our homework yet, but Gookanheimer and I have made some handsome progress.

Attach file:



png  AsPromised.png (4.98 KB)
3060_57c38408ce1d8.png 688X512 px
Top

#23
Re: PVB Collaborative Emulator
Posted on: 2016/8/31 13:44
VB Gamer
Joined 2012/12/21
Australia
26 Posts
Long Time User (6 Years)
I brought the handsome, Guy brought the progress.
Top

#24
Re: PVB Collaborative Emulator
Posted on: 2016/8/31 14:57
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (6 Years)
It's that time again, and attached to this post are the spoils. It's only built for 32-bit Windows at the moment, mainly because Debian has an older version of SDL and I'll need to build my own cross compilers for the ARM architectures, but hey, there's the source code!

To use it, find yourself a Virtual Boy ROM file and drag it onto app.exe.

Controls:
• F6 - Step Over (works on functions and branches alike)
• F7 - Single Step (aka Step Into)
• Up - Scroll up (experimental - somewhat buggy)
• Down - Scroll down (experimental - somewhat buggy)

Eventually the emulated program will hang because it's waiting on some hardware activity. Wario Land in particular checks for the VIP ready status, which of course never comes because that component isn't implemented yet. If that happens during a Step Over, then the actual emulator program will hang as well, but such are the joys of alpha development.
__________

So what was done in August?

Emulation Core

This thing is every bit as delicious as I hoped it would be. There's a single object type used to represent the entire emulation state of a virtual Virtual Boy, and a handful of API functions for working with it. You supply it with a ROM file and tell it to emulate, and off it goes.

Like mentioned before, various control points can be hooked into by the application to intercept things like bus accesses or pause before an instruction is executed. Clever use of these control points can enable things like disassembler and cheat engines to work without bogging down the library with excess code.

The disassembler in this build doesn't actually use these control points. It just runs the emulate command with a maximum cycle target of 1, meaning it will break after every instruction. Lazy, sure, but again, this is what we call "the alpha stage of development."

CPU Emulation

A joint effort between myself and handsome up there, the CPU emulator is very nearly implemented in its entirety. The missing features are bit string instructions (pending research), floating-point instructions (pending development) and exception handling (NP was set, what was I to do?).

Each instruction has its own function called by the library, and the library can be compiled in one of two ways depending on the compiler and speed of the target platform: use a big switch statement, or use function pointers. Never too many options, I guess.

Every instruction takes some number of CPU cycles to complete, and bus accesses may factor into that. Cycles are tracked and enumerated, and additional features will make use of that figure in order for everything to remain properly synchronized. When the time comes, all the other hardware components will be told to "do whatever you can in this many CPU cycles."

GUI Subsystem

You wouldn't know it from this program, but there's a full-featured GUI subsystem in there. It supports a hierarchy of elements--each of which can have nested child elements--and handles mouse and keyboard focus on all of them.

I ended up doing the exact opposite of what I said I would do: I wrote a wrapper around SDL for cross-platform support and I'm doing the rendering with OpenGL directly. These decisions were made because SDL's setup isn't really analogous to how the emulator application works, and because OpenGL gives us some useful tools that SDL's rendering API doesn't.

Simple font support was implemented, and will be expanded in a future build. All fonts will be bitmaps in this program, and Unicode will be supported. Right now, only block 0x0000-0x00FF is supported, but the plan is for strings internal to the application to have full support for UTF-8 up to 0xFFFF, save for some fancy things like combining diacritics and oddball control characters (right-to-left, etc).
__________

So what will be done in September?

I don't know about you, but I've always felt like having "only the CPU" was kind of a small step in terms of writing an emulator, but every time I sit down to think about it, I realize just what a percentage of the overall project it really is. The remaining system components are way less complex and will not take as long to implement, so I think this project is going to come together a lot faster than I expect.

That being said, I have some goals for September:
• Implement CPU exception processing.
• Implement the VIP. The whole VIP.
• Implement the game pad interface.
• Create basic GUI controls (buttons, scroll bars, etc.)

If time permits (aka "stretch goals"):
• Finish UTF-8 font support
• Create fileopen dialog
• Create disassembler window
• Create memory hex editor window

Something we here at Planet Virtual Boy can do in the mean time is toss around some designs for the user interface. What would you like to see? How would you organize things? What tools do you want to have at your disposal? Now's the time to talk about it, because we're nearing the time when we can make it happen.

Alright kids, see you on September 30!

Attach file:


zip pvbe_20160901.zip Size: 582.02 KB; Hits: 118
Edited by Guy Perfect on 2016/8/31 15:57
Edited by Guy Perfect on 2016/8/31 16:04
Top

#25
Re: PVB Collaborative Emulator
Posted on: 2016/9/3 21:48
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (6 Years)
EDIT:

The following post was partly based on an assumption that turns out to be false. The fact of the matter is that C# and .NET simply cannot incorporate stock C code like I thought it could. Toss in the cross-platform considerations and .NET is kind of not really an option.

We're pretty much down to just C or Java at this point.

__________

I have a dilemma. I'd appreciate any and all insights before I drastically change the project requirements.

What I'm considering doing is keeping the C89-compliant emulation core library branch of the project, but trashing all the GUI work and using either Java or .NET for the application.

Not that I've encountered difficulties, mind you. I'm actually having a lot of great success with the GUI side of things and am quite proud of the API I came up with. It's just that the strengths of application-centric development platforms and the relative weaknesses of C for application development are really making themselves apparent.

I'm a big fan of Java when it comes to application development, but I find myself leaning towards C# thanks to its ability to straight-up use C code verbatim. Cross-platform concerns come to mind, but the Mono project seems to be picking up speed lately, so it would at least run on all our target platforms.

I don't much like the idea of requiring our developers to install Visual Studio, but at the same time, it's not ostensibly different from requiring them to install the JDK, and I also don't like the idea of porting the emulation core library to Java and maintaining two versions of the same thing in tandem.

Tell me your take on this situation, mysterious reader. Which path should lead to the future?
• Continue implementing GUI stuff in C code, missing out on a lot of modern features, relying on SDL for cross-platform support
• Use C#, allowing the C library to be used, relying on Mono for cross-platform support
• Use Java, allowing the application to run on many platforms, but require maintaining a ported copy of the C library
Edited by Guy Perfect on 2016/9/3 22:33
Top

#26
Re: PVB Collaborative Emulator
Posted on: 2016/9/3 23:28
PVB Elite
Joined 2003/7/26
USA
1465 Posts
PVBCC EntryCoderContributorSpecial AchievementTop10 PosterHOTY09 EntryLong Time User (15 Years) App Coder20+ Game RatingsPVBCC 2013 Entry
1) Great work!

2) Is there a makefile or other build script/instructions available? I'm using MinGW, and I'd like to be able to make the odd contribution now and then.

3) To answer your question, I would prefer that you stick to plain C, or maybe C++ (but whatever you do, please don't add a V. Studio dependency on Windows).

4) If you must add a non-C language for the GUI, you could do much worse than my personal favorite scripting language: Ruby.
* It's easy to learn.
* It runs on all the target platforms (and is easy to install on any of them).
* It's built to allow easy wrapping of C code inside a "C extension" (and there are even tools like SWIG which perform most of the work for you).
* If you don't need a "rubyish" OOP interface, you can simply call functions inside DLLs from Ruby code.
* There's a great, well-maintained, cross-platform, graphics/input/sound library for it called Gosu (which is a clean, well-designed API wrapper around SDL2 and OpenGL. BTW, it's written in C++ and the Ruby version is made using SWIG). It already does fonts (using TTF, but individual characters or the whole font can use custom bitmap images) and text input. You can even incorporate custom OpenGL code into its pipeline.
* There are many other useful libraries available in the form of "gems" (at http://www.rubygems.org/) installable with a nice package manager that comes with Ruby (e.g. getting Gosu is as easy as "gem install gosu").

5) The word "acknowledgment" is misspelled in the copyright notice.
Top

#27
Re: PVB Collaborative Emulator
Posted on: 2016/9/4 0:40
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (6 Years)
Quote:

RunnerPack wrote:
2) Is there a makefile or other build script/instructions available? I'm using MinGW, and I'd like to be able to make the odd contribution now and then.

There's a makefile that I set up to compile for different platforms depending on the target name passed to the make command, but I ran into some complications when it came time to set up the build environment in a VM.

Turns out you have to build your own cross-compilers that run on the platform of your choice to do the compiling--OS distributions don't pre-build compilers for other architectures for you. Keeping these up to date means periodically rebuilding them from source.

Another problem is that there's no elegant way to do Mac development without developing on a Mac, and I don't have a Mac. It's possible to copy over all the headers and libs, which I'm not opposed to doing, but it can't be updated very easily.

Quote:

RunnerPack wrote:
3) To answer your question, I would prefer that you stick to plain C, or maybe C++ (but whatever you do, please don't add a V. Studio dependency on Windows).

I've been going back and forth on this one all afternoon. I don't want to add another development language into the mix, but doing so comes with a lot of benefits. Those issues regarding cross-compilers and Mac OS don't apply to Java, and it packs a fully-featured GUI system to boot.

Still trying to weigh the pros and cons in my head, but I can't shake the thought that if I try to do the GUI myself, I'm going to overlook something important or fail to implement something that needs to be in there.

I'm not a fan of Microsoft in general, and I'm pleased that they don't offer anything over Java with regards to this project. (-:

Quote:

RunnerPack wrote:
5) The word "acknowledgment" is misspelled in the copyright notice.

Put another mark on the Wikipedia Fails column. I just copy/pasted the language from their zlib License article, and upon reviewing the spelling from the zlib website, I find the word is indeed spelled correctly there. Someone on Wikipedia changed it when they copied it over. (-:

I'll fix it in all source files going forward. Thanks for pointing it out.
Top

#28
Re: PVB Collaborative Emulator
Posted on: 2016/10/28 3:10
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (6 Years)
Contrary to personal opinion, I haven't died!

I have, on the other hand, had something happen near the end of September: I had a surprise relocation sneak up on me (yeah, I'm moving again). And seeing as how I was unemployed at the time, I had to make a mad dash to raise a four-figure sum by the end of October. I finished up making money yesterday, and I'll be packing my things and heading out on Saturday.

The following is the most backwards sentence posted to the web this year: Fortunately, where I'm going, I'll have limited internet access.

Why is that a good thing? It means that computer time will be free of internetty distractions. I still have access to the internet for the sake of updates and the like, but I won't have it on my workstation, at least not in the short term. That means more working on Virtual Boy, and less postponing working on Virtual Boy.

Not intended as an excuse, but as an explanation. Good thing no one was following this thread, or else I might have disappointed someone. (-:
__________

VIP Shenanigans

I placed a curse on myself by saying "the rest will be really simple". Of course it isn't simple. It's never simple. The not-simple part is that while the VIP won't outright explode if you feed it unexpected input, it will act in a peculiar (albeit well-defined) manner. Pinning down all the sneaky little edge cases and documenting the results has taken WAY longer than I thought it would, and in the long run won't make a darned difference anyway. But I'm dedicated to the cause: this emulator will be accurate, take it or leave it.

What kinds of things am I talking about? Consider the following:

• What happens when you specify negative window dimensions?
• What are the maximum effective window dimensions?
• What happens when the background parallax setting approaches multiples of 4,096?
• What happens when a background is configured with more than 8 segments?
• What happens when affine-mode parallax approahces multiples of 1,024?
• How is per-row position information recorded during affine rendering?
• What is the exact frame-rendering procedure? There's evidence that it's not simply a matter of drawing each window one at a time in back-to-front order.

At the time I was thrust into an immediate need for full-time work, I had finished documenting the VIP memory and was in the process of documenting the VIP registers. My plan was to post the VIP section of the new draft of the tech document as a consolation prize before I started work, but I didn't even get that far. I'm also not 100% sure I got all the anomalous details completely correct, and it's been a month since I was last working with it...

Before I say that I've mastered the VIP, I'm going to want to write a sort of "acid test" program, at least for the unintended behaviors.
_________

Platform Considerations

I've thought long and hard about whether or not to make the primary emulator application in Java with an accompanying C library, and have decided that is indeed the route I wish to take. Both routes have their pros and cons, but in the end I believe the... well, the cons of C-only route outweigh the cons of the Java route.

The primary benefit of sticking strictly with C is that it means there's only one code branch for the entire project, and changes made to it are immediately reflected in the release builds. This saves the work of maintaning two different versions of the library in parallel, and completely sidesteps the possibility of a dreaded desynchronization. It's an attractive approach, and the one I wanted to do, but it has its drawbacks too...

On the other hand, the primary benefit of working with Java is that we get a cross-platform GUI out of the box. They take care of all the platform-specific stuff like window management, networking, input devices and Unicode, all of which would need to be implemented manually in a C-only project. A fair amount of a C implementation would fall into the category of "don't screw it up".

When it's all said and done, there's one detail in particular that makes Java look quite reasonable: dependencies. At its heart, C is a very portable programming language, but an application written in C will nonetheless have platform dependencies. SDL mitigates this to an admirable extent, but its scope doesn't cover some of the emulator's needs like directory lists or networking--some of the application will still need to be maintained for each target platform. Java, on the other hand, supports even more platforms than SDL and has industry experts making sure everything works correctly and efficiently. Java gives the emulator a bigger user base and a smaller margin for compatibility issues. When put in this context, using Java simply makes sense.

Of course, the C library will still exist alongside the Java project. It'll be the code people can use to add Virtual Boy to their system no matter what hardware or operating system it's running on.

Inclusion of a Java branch of the project comes with a mild caveat: the existing C library isn't structured the way a Java package needs to be. And honestly, that was an error on my part: my original goal was to make code in C with the express intention of it being portable to other languages if need be, and then I didn't stick by that when I implemented it. So now I get to take a step back and reorganize everything to make the C version and Java version match more closely when set side-by-side.

When I do this, I'll take care and try to design the C library in an even more portable manner so that it can be moved to additional languages with fewer issues.
__________

At this time, I can't give an informed estimate on a timeline for these two things will take place. Next week, after I get settled into my swag new rent-exempt abode, I should be better equipped to budget my time and assess what needs to be done going forward.
Top

#29
Re: PVB Collaborative Emulator
Posted on: 2017/1/26 22:47
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (6 Years)
Guys! Guys! I'm done with my August homework!

Between this post and my previous one, another relocation happened, and frankly, I'd be happy to remain in just one geographic region for any appreciable amount of time. But this one's already off to a good start, because I've done a ton of work on the emulator.

... Only thing is, the work I've done was restarting from scratch and getting to the point in the new project where I was in the old one. Why bother? I was never fully satisfied with how the old one was set up, but it was a good setup and worked well, so I went with it. After seeing yupferris and his work on Rustual Boy, I was inspired to dive back into the project in earnest, with the goal that every little thing I did would be done the best way I could possibly come up with.

And that's exactly what I did. Attached to this post is a new CPU emulator/disassembler like the old one, except it's substantially better--some of the best code I've ever written. I'm proud to present it to you guys as a taste of things to come.

Like before, it accepts a ROM file as its command argument and is compiled for 32-bit Windows. You can easily launch it by dragging a ROM file onto the EXE.

Only two controls this time:
• F6 - Step Over
• F7 - Single Step

Single Step executes a single instruction. Step Over will attempt to advance PC to whatever the next instruction's address happens to be, executing as many instructions as necessary to get there, even entering and leaving function calls (hence the name). Due to this, overzealous use of Step Over can make the emulator hang such as when the emulated program waits for an interrupt that's never going to happen.

The disassembler looks the same as last time save for the font, but the code backing it is cram-packed with features. Configurations include operand ordering, specifics of numeric formatting (base, delimiter, etc.), displacement notation (relative, absolute), Bcond and SETF displays, etc. I put in all that effort towards the end of "do it right now and I don't have to redo it later on"

The github repository isn't ready for prime time yet, but rest assured, it's up there. The attached ZIP file does include all the source code necessary to build this program, though.

This all came together extraordinarily quickly. I'm super-excited to see what February holds.

Attach file:



png  AndHereWeAreAgain.png (7.41 KB)
3060_588a6e6b4f0c4.png 640X480 px
zip pvbe_20170126.zip Size: 477.60 KB; Hits: 102
Top

#30
Re: PVB Collaborative Emulator
Posted on: 2017/1/27 4:31
PVB Elite
Joined 2013/6/17
Canada
1168 Posts
Top10 Poster10+ Game RatingsLong Time User (6 Years)
Good to hear you're making progress! I admire your tenacity for the project, to rebuild from scratch in order to make it the best you possibly can (and succeed!) is no small feat.
Top

 Top   Previous Topic   Next Topic


Register To Post