You are not logged in.
Lost Password?

All Posts (blitter)




#1
Re: The Yetee VB Shirt
Posted on: 11/10 5:34
Nintendoid!
Joined 2007/12/14
160 Posts
CoderLong Time User (8 Years) App Coder
Quote:

Hedgetrimmer wrote:
Got one too, thanks for the tip, but dare I say it, with the other forum post being resurrected again, Stand Position, the stand is on backwards 😊


No sale for me then. ;)
Top

Topic | Forum


#2
Re: Sound Chip
Posted on: 10/23 23:10
Nintendoid!
Joined 2007/12/14
160 Posts
CoderLong Time User (8 Years) App Coder
My VB Sound Generator app was only written for OS X, and is pretty much geared only as a sandbox for the chip itself-- you can't use it to write music or anything like that. I do indeed have a music engine in progress, but I haven't seriously touched VB development in a long time so it just sits in a private Bitbucket repo for now. It's being written in pure assembly and requires that you architect your engine a certain way, but I already have tools written that ultimately convert MIDI files to my own .VBM format. One of these days I'll get back to it.
Top

Topic | Forum


#3
Re: GCCVB for Mac/Linux
Posted on: 9/18 3:20
Nintendoid!
Joined 2007/12/14
160 Posts
CoderLong Time User (8 Years) App Coder
Sure. http://www.planetvb.com/modules/newbb ... t_id=25933#forumpost25933

However do note that there are bugs. I recommend you check out what ElmerPCFX has been doing to improve GCC in this thread and apply some of his fixes before building the toolchain.
Top

Topic | Forum


#4
Re: PVB Collaborative Emulator
Posted on: 7/11 6:11
Nintendoid!
Joined 2007/12/14
160 Posts
CoderLong Time User (8 Years) App Coder
Quote:

Guy Perfect wrote:
I understand that you have an emotional investment in using C++ (or, as the case may be, in not using C), but I remind you to think carefully before accusing someone of making unsubstantiated claims. I don't want a constructive debate to devolve into name calling and hearsay.


Perhaps that was a little harsh and if so, I apologize. My point still stands though-- many of your claims so far about your preference for C are unsubstantiated.

Like I said, I don't care what language you use for your own personal projects-- if you love C and want to write in it, great! But starting a topic and making claims like "C is about as close as you can get to machine code without writing architecture-dependent programs, meaning it'll be about as fast and memory-efficient as they come" and "While the difference in performance is negligible, there's still a relevant impact when using C++ instead of C" is pretty disingenuous and a bit of a red flag to me. No offense intended to you, but this discussion doesn't fill me with a whole lot of confidence about this project from the get-go. If I have an "emotional investment" in anything around here, it's in seeing VB devs succeed-- while I'm sure you'll pull more than your fair share of the weight on this project alone, I predict it will take a much longer time without help or adoption, and I'm having a hard time envisioning a number of folks signing up.

Good luck with the project. :)
Top

Topic | Forum


#5
Re: PVB Collaborative Emulator
Posted on: 7/10 21:41
Nintendoid!
Joined 2007/12/14
160 Posts
CoderLong Time User (8 Years) App Coder
Quote:

Guy Perfect wrote:
1) Some of the features of C++ necessarily have more demanding runtime requirements to compensate. I mentioned the "new" keyword, which was confirmed to allocate a small block of memory every time an object is created.


Not any more memory than malloc() does for the same object. Literally. The GNU implementation of new is a sanity-checking wrapper around malloc(). Don't like it? Write your own. (Note that due to lack of function overloading, you can't easily replace malloc() in C.)

Quote:

But it was also brought up that trapping exceptions--one of the most powerful features C++ offers over C--has a host of overhead making it work. The runtime library required to use a C++ program has a larger memory footprint than the C runtime. While the difference in performance is negligible, there's still a relevant impact when using C++ instead of C.


pssst... you don't have to use them... ;)

Quote:

No amount of C++ trickery is going to make the emulation core work in a C environment, performance notwithstanding.


Absolutely false. (Seriously, this is the first Google result returned for "c wrapper for c++ library"-- did you do any research yourself or are you blindly going by what your "associate" says?)

Look, you personally can write your project in whatever language you want, and that's fine, but when you as a project leader open it up to the world and then place arbitrary restrictions on its development without supporting arguments that make technical sense, you're not getting off on the right foot. Code conventions are one thing, but shutting out a huge part of the language that's been in use for over 20 years because of some preconceived notions that it's less performant, top-heavy, memory-intensive, or what-have-you without confirming it for yourself first in practice, is at best silly and at worst irresponsible. Are these concerns really all that significant in the overall scope? Is it worth shooing away good C++ coders so you can recoup that .00001%? Worrying about speed or space issues is premature optimization that should be done only after profiling a project to see where the bottlenecks are-- otherwise it's time wasted over a mostly futile effort.
Top

Topic | Forum


#6
Re: PVB Collaborative Emulator
Posted on: 7/6 23:10
Nintendoid!
Joined 2007/12/14
160 Posts
CoderLong Time User (8 Years) App Coder
Quote:

Guy Perfect wrote:
One of my desires is to help lift the veil on the internet that enshrouds emulation in an air of mysticism. An emulator isn't some arcane box of hocus-pocus: it's a rigidly-defined set of rules that get from point A to point B. I want people from all over the industry to be able to look at Planet Virtual Boy and, in doing so, learn a lot about how emulation works and maybe take the system a little more seriously in the process. (-:


Frank Cifaldi is way ahead of you on that... ;)
Top

Topic | Forum


#7
Re: PVB Collaborative Emulator
Posted on: 7/4 21:12
Nintendoid!
Joined 2007/12/14
160 Posts
CoderLong Time User (8 Years) App Coder
Quote:

ElmerPCFX wrote:
Quote:

Guy Perfect wrote:

Developers welcome, but even if I do the programming myself, I'm totally fine with that. Either way, the project will be open-source and a version-controlled source repository will be open to the public... well, it might be restricted to PVB members, but that's public enough.


If you want to do it yourself, and have a personal passion to write an emulator, then good for you!

But if you just want a "better" emulator than what's available, have you considered not throwing away the years of work that other people have done, and to actually save yourself a lot of time and build upon one of the existing emulators and improve it?

Any major project is a huge commitment in time. Lots of people start things, and then the projects die because all the details mount up and things get frustrating and no longer "fun".

In the last couple of years I've used Mednafen to hack a large PC-FX CD game, and two PC Engine CD games.

Unless I'm hallucinating, it's already got 70% of what you want, and the rest isn't hard to add, because a lot of it is already supported on Mednafen's other emulations.

For instance VRAM viewing/breakpoints don't seem to work on Mednafen's VirtualBoy emulator, but they do work on Mednafen's PC-FX and PC Engine emulators. So the framework is already there, it just needs someone to add the missing bits for the VirtualBoy.

Might that not be an easier (i.e. more likely to happen) route than just starting from nothing?

Mednafen's debugger certainly has room for improvement ... which is why I spent the time to improve it for my own use, and intend to keep on doing so to add more new features.

But that's because my goal is to use an emulator to do other things, and not to write an emulator.

You just have to be very, very careful to decide where it is that your programming passion (and capability) lies.


This. All of this.

Creating a new emulator from scratch seems like we're throwing the baby out with the bathwater. Mednafen works well, has an amazing project lead, has the benefit of being maintained and patched over the years of its existence by countless contributors, and from my evaluation has no technical reasons why it couldn't be extended to do the things mentioned in the OP.

The VB community is *tiny*-- I don't think I can stress this enough-- and we're lucky to have folks like ElmerPCFX stop by from the PC-FX community to help us out. We should *encourage* folks not in the VB community to contribute to our tools, especially if it's mutually beneficial. A Virtual Boy-exclusive emulator such as this one only serves to isolate us from possible contributions. Improvements to Mednafen's debugging facilities, though maybe not always VB-specific, are improvements we get for free. Likewise, do you think the PC-FX community would be interested in helping to develop a Virtual Boy-exclusive emulator? Why would they? (Consider why Red Dragon and Reality Boy are no longer maintained. Hmmm...)

Quote:

Guy Perfect wrote:

I have made one executive decision, though: the main trunk of the project will be written in the C programming language. Not C++, but vanilla C, for the sake of simplicity. C is about as close as you can get to machine code without writing architecture-dependent programs, meaning it'll be about as fast and memory-efficient as they come.


I'm going to assume you know what you're talking about and that you have other reasons for choosing C, and would love to know those reasons, but for the benefit of others, choosing C over C++ for performance reasons is a mistake. C has no advantage over C++ performance-wise, and vice versa. C++ is a superset of C, meaning that you can use some or none of the extra features provided by the language, with no penalty in the latter case.

That aside, C++ affords the programmer many features now taken for granted that simply aren't present in vanilla C-- operator overloading, access specifiers, better const correctness-- these are things that make the programmer's life easier and/or help them not make silly mistakes (We're all human, after all). Aside from compatibility with legacy code or compilers, I cannot understand why a strictly C-based project is necessary in 2016, but if you continue to insist, then please use at least C99.
Top

Topic | Forum


#8
Re: Perfect "Stereoscopic Panorama" Book (Japanese)
Posted on: 5/12 18:42
Nintendoid!
Joined 2007/12/14
160 Posts
CoderLong Time User (8 Years) App Coder
Hah! Reminds me of Google Cardboard.
Top

Topic | Forum


#9
Re: Post pics of your VB Collection
Posted on: 4/30 6:56
Nintendoid!
Joined 2007/12/14
160 Posts
CoderLong Time User (8 Years) App Coder
An UncleTusk Dragon Hopper box, cool! Too bad the ESRB icon on it is placed in violation of guidelines. :P
Top

Topic | Forum


#10
Re: A newer GCC compiler.
Posted on: 4/21 6:03
Nintendoid!
Joined 2007/12/14
160 Posts
CoderLong Time User (8 Years) App Coder
Quote:

ElmerPCFX wrote:
Then you'd just have to fix the linker script to make sure that those sections really are put within the top 32KB of the cartridge.


Top 32KB? Is that because the displacement is signed? What if gp was set to the middle of WRAM? Then all variable accesses (minus constants of course) could be in the ZDA section. :)
Top

Topic | Forum