We're using cookies to ensure you get the best experience on our website. More info
Understood
@guyperfectRegistered December 4, 2012Active 3 years, 10 months ago
375 Replies made

FL Studio is designed for fancier audio productions and comes with a professional price tag. If you just want to play around with chiptunes, there are much freer options out there such as FamiTracker you might consider instead.

I used FL Studio with a plugin designed to generate NES sounds. I made sure none of my “channels” were generating more than one sound at a time for that authentic flavor.

I kinda fell off the face of the planet this month, but I’ve been working on the emulator off-and-on and have a lot to show for it. Well, not to show, exactly, since a lot of it was back-end work, but I know in my heart that good things have happened. (-:

A lot of this was slow-going because my goals for the application dealt with things I didn’t have any real prior experience in. The level of configurability (is that a word?) I have my heart set on requires a lot of planning ahead, and I took the time to do that so I wouldn’t paint myself into a corner. Among other things, the infrastructure supports the following features:

• There is no human language hard-coded into the application–all localized strings are loaded from text files. This facilitates easy translating, allowing the application to instantly switch languages.
• Application-wide commands that can be invoked via keyboard or game controller are dynamic and can be configured by the user and written to/read from file. Multiple inputs can be associated with one command.
• Individual text controls can be configured for font, color and whatever other settings are appropriate. Finally, you can do your hacking in Comic Sans if you want!

One feature I want to accommodate is scaling of other UI elements such as menus and buttons. Sometimes your display is just too small to make out what you’re working with, and an accessible application should provide a solution.

When I got all that out of the way, I got back into the disassembler and just a few minutes ago got it pretty much complete. The only thing I can think to add at this point is maybe a small toolbar that allows the user to navigate to a particular address or directly to the address in the CPU’s PC register. A full set of inputs is supported in the disassembler:

• Up and Down scroll by one instruction.
• Page Up and Page Down scroll by one “page” of instructions–the number of fully-visible instructions in the window.
• Left and Right tweak the topmost instruction’s address by 16 bits if available, in case the disassembly is misaligned. This shouldn’t be an issue in most cases, but it’s good to have the option.
• Scrolling the mouse wheel up and down scrolls by one instruction per click.
• Scrolling the mouse wheel while the CTRL key is held down will instead change the font size.

The vertical scrollbar is a custom class I had to build due to the fact that JScrollBar doesn’t accommodate a full 32-bit range very well. While working on that, I took the liberty to introduce some new functionality to make the scrollbar more usable. The following behaviors are implemented:

• Clicking on the scroll buttons scrolls by one instruction.
• Clicking on the track scrolls by one page of instructions.
• Dragging the knob seeks to the corresponding location in memory. Since there’s some 4.3 billion addresses, scrolling in this manner isn’t very useful, at least not until we have millions-of-pixels-tall monitors.

Conspicuously missing are inputs for things like Toggle Breakpoint and Step Over. These are actually application-level commands that can be invoked from places other than the disassembler, such as the Debug menu or the yet-to-exist debugging toolbar. That’ll actually be the next thing I tackle.

There’s a lot going on, and I continue to learn new skills from this project each day that goes by. It’s a real privilege to be involved with this (even if by myself), and I owe a lot of that to the PVB community’s eternal passion for the system.

Attachments:

Yup, that’s the infamous deteriorating display problem. It’s not always horizontal lines across the display, as you’ve seen. The display signal is digital, so complete or partial disconnection can cause a wide array of graphical effects.

I’m an opponent of cooking the displays in an attempt to correct the problem. The silicone adhesive originally used to affix the ribbon to the PCB cannot be reactivated with heat because it’s chemically cured. Any attempts at physically manipulating it will at best result in only a temporary fix that will revert over time, or at worst damage the display circuit.

The correct solution is to have the displays serviced to enforce a stronger connection. The ol’ “strip off the ribbon coating with lye and solder the leads directly to the PCB” method is the best we’ve come up with, but I’m convinced there’s gotta be a better way…

If you build from parts, you’ll save a ton of money over buying a complete system from a vendor, plus you won’t be bogged down with all the bloatware they try to make you use. The only real drawback to building is that if you want to run Windows or OS X, you’re gonna have to put down some healthy dough to purchase a copy.

The system I built a couple years back is still out-performing my needs, and I do gaming and video editing myself. The whole thing cost me about $750, which is kinda remarkable for the specs I got. I apparently have different ideas for what constitutes a “powerful” machine than RetroDan, since my price point is less than half of his. (-:

If you’re going to invest in a machine, I’d recommend going for nothing less than an Intel Core i7 for the CPU. I got an i5 myself, which works for my needs, but a lot of fancy peripherals out there (video encoders/streamers especially) really benefit from the features of the i7 that aren’t available on the i5. AMD aren’t the beast they used to be–they seem to have gotten stuck in the “faster = better” rut and never pulled themselves out of it.

How are SSDs performing these days? A few years back I’d advise against using them for video editing because of the above-average write behaviors, but maybe these days the technology is better than it used to be and you won’t wear out an SSD so quickly that way.

It’s such a big relief seeing this finally be in a traditional window. Working up the GUI stuff in Java feels way better than what I’d done in C for the previous iteration of the project, and I feel like the sky is the limit. I’ll be coasting high on this one for a bit. (-:

Attachments:

Thanks for looking into it, HorvatM! I always value your input because you do some of the strangest things…

It’s true that I disagree with many compiler warnings. (-:

Having said that, a goal of the project is for the emulation core library to compile in strict C89 on as many compilers as appropriate without any errors or warnings. In gcc, this meant the following options:

-std=c89 -pedantic -Wall -Wextra

And that does compile with no messages. It did entail doing some things that I disagree with, such as putting unnecessary parentheses around things like bitwise operations and assignments used as conditions, but I figure it was all for the greater good.

I don’t have Clang/Haiku handy, so I don’t know the nature of the warnings it’s giving. If you could compile just the libvue portion and give me some samples, I’d appreciate it.

I say just the libvue portion because the SDL program and disassembler in this build are temporary and will not be present in the application. Four months of deliberation have settled me on Java as the application platform, and I’m maintaining an unmodified port of libvue in Java to that end.

I’m hoping that by the end of the month I can have this disassembler in an actual GUI. (-:

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.

I’m happy to report that ferris and I will indeed be joining forces. The PVB emulator project will be on a public Github repository and gain the benefits of both our capabilities. I’ll have a formal announcement in the coming days.

ferris wrote:
@Guy Perfect: Are you on anything else, perhaps slack? I can probably find you on skype, but I’m not usually on there. Is IRC perhaps another option? 🙂

It’s Discord or Skype for me. Anyone not on one of those has to avoid them on purpose. (-:

I’m not adverse to installing something, but it sounds like you’re already on Skype, so let’s go with that for now. You can use it through a web browser right here if you’re like me and don’t want to install the application.

Otherwise, it’s good, old-fashioned PVB message board, but I’d really like to have some real-time conversation on the topic when you have some time.

I finished up a coding demonstration for a prospective employer on Friday, and just sat down saying to myself, “it’s about time to get back to work on Virtual Boy stuff.” So I came here and saw this. Neato. (-:

We should talk. I’ve got a lot of refactoring to do what with the inclusion of a Java code base in the project, so it wouldn’t hurt to compare notes. You can find me on Skype at guy.perfect or on Discord at GuyPerfect#8467

I use a cotton swab, personally. No cleaning solution–just use it plain.

3DBoyColor wrote:
Were you hoping to arrange something like with Hyper Fighting? Or more just a mutual collaboration?

More general-purpose collaborative is what I had in mind. If I could team up with someone who did a lot with hardware innovations, I can only imagine what we might be able to accomplish together.

3DBoyColor wrote:
Also, I know this can seem low priority, but was there any kind of project you had in mind? I know having a clear goal can make a big difference in making the best of time and money.

My exact plans include both anything and everything. In the short term I want to get back to work on the emulator project, and I have my audio project and another project on the list. But that’s just me. Working with someone else capable of getting stuff done, who knows what we might do.

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.

ElmerPCFX wrote:
What’s his “devkitv810”, I haven’t seen mention of that before?

Sorry, didn’t mean to hijack the thread…

dasi put together a devkit for V810 that outputs Virtual Boy and PC-FX programs. I’ve been working with him to get certain things implemented, but as I don’t really have much of a clue as to how GCC distributions work, it’s becoming rather out of date and could stand to see a newer build.

In conjunction with my minimalist Virtual Boy API, we were able to streamline several processes that accommodate more capable VB homebrew. Among other things, you can easily use any function as an interrupt handler if desired, incorporate binary files directly into your programs without byte array headers, and access individual data units on the memory bus without any pointer casting or index manipulation (including audio samples). Some simple functions and macros are present to perform common tasks such as polling the game pad, initializing the column table, configuring the instruction cache and interrupts, and halting the CPU.

A proper release will include a PC-FX API in the same vein and fix all of the outstanding issues (such as the current incompatibility with the C runtime). I’d love to get a committee together to weigh the pros and cons of combining the two devkit projects (GCCVB and devkitv810), but that would be stepping on dasi’s toes.

Since I do all of my Virtual Boy development with devkitv810, no one else will be able to compile my programs without modification unless devkitv810 is also public. I don’t want to release it over dasi’s head, but if he doesn’t come back around by the time I have some code to publish, I’m going to have to think hard about pushing the current, incomplete devkit out there before it’s officially ready to be released.

If anyone knows how to get ahold of dasi, please get in touch with me. I caught him online briefly in January, but he likes to be scarce of late.

Before too long, if dasi doesn’t rematerialize, I’m going to push the incomplete devkitv810 public so we’ll have something a little more accommodating for VB homebrew. devkitv810 is compiled for Win32, but works just fine through Wine on Linux/Mac.

virtualnoob wrote:
Im supprised that there is no Virtual Boy port of “touhou music video – Bad apple”.

Homebrew on Virtual Boy is harder to find than WMDs in Iraq. It should come as no surprise whatsoever. (-:

syncophono wrote:
A way this could be done that is not memory intensive is to only update the CHARS that need updating. Many of the areas of the screen in bad apple are all black or all white, so they will not need to be changed on a per-frame basis.

This is a fundamental technique for video compression, and is often coupled with motion compensation to further reduce the number of changes between frames. Compression in its simplest form is elimination of redundancy, so if the result of a part of one frame is the same as the result of the previous frame, that part can simply be skipped over.

In practice, since source frames are rarely identical even in part, a “lossy” form of compression is used that generalizes whether a difference between two frames is “close enough” to skip over. Consecutive frames are typically rebuilt starting with a keyframe, which is a regular image, followed by some number of frames that only describe changes to the frame that can before it. Eventually, another keyframe will be needed to give the process a good foothold again.

syncophono wrote:
So we need to write a code-generating script that takes in a video, converts the frame to virtual boy’s 384×224 2bit format, checks each 8×8 segment to see if it is different from the previous, and if it is different, generate a line of code that writes that char to the world.

And this describes both sides of the task of implementing of a video codec. Are you sure you don’t work in the data compression industry? (-:

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.

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. (-:

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.

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

  • This reply was modified 8 years, 10 months ago by Guy Perfect.

I just got four of my displays (yes, I’m an addict) back from HP Lovethrash last week, and they work great. Four of the six I sent him had the ribbons completely detached and he was able to put them back on. They work like a charm and I’ve got two units up and running now, meaning I’m primed and ready to do some development with that link cable DogP sent me…

Man, this is gonna be a great year for PVB. I’m actually doing stuff again! (-: