You are not logged in.
Lost Password?

All Posts (Guy Perfect)




#1
Re: PVB Emulator & Fundraiser
Posted on: 2/14 4:32
VUE(xpert)
Joined 2012/12/4
387 Posts
CoderLong Time User (6 Years)
Quote:

StinkerB06 wrote:
There's just one thing missing here in this update: a column table tab.

Any ideas for how that might be visualized?

Quote:

StinkerB06 wrote:
For instance, the Wario Land game's intro cutscene actually uses a fade effect on the sides via the column table.

While testing Wario Land in the emulator, the column table didn't appear to be updated during the intro cutscene, which seems wrong. The result is a very dark cutscene, which makes sense because the brightness is turned down for the column multiplier to take effect, but it never seems to be written.

I may have screwed something up, but it should be a simple matter of store instructions, so I can't quite pin down what's (not) going on.

Quote:

StinkerB06 wrote:
The Sacred Tech Scroll draft just got updated with details of the VB's hardware timer. http://perfectkiosk.net/stsvb1.html#timer

Jumping the gun a bit are we? Feel free to post the next software update so I can take a break. (-:


The Next Software Update

... is attached to this post. I adjusted the focus when running the emulated program, so the keyboard keys should correctly apply without intervention.

I also implemented the timer into the emulation core... I think. Everything looks like it checks out, and the timer itself is fairly simple, but I haven't had a chance to fully test it. I was hoping Galactic Pinball would start working magically once it was implemented, but something else is causing that game to hang on the title screen.

If anyone has a simple test ROM handy that just does timer functions, see if it works correctly in this build of the emulator. Otherwise I'll draft one up for next week to verify that everything is working as intended.

Attach file:


jar pvbemu_20190213.jar Size: 247.74 KB; Hits: 8
Top

Topic | Forum


#2
Re: Technical questions and looking for oddities
Posted on: 2/11 14:26
VUE(xpert)
Joined 2012/12/4
387 Posts
CoderLong Time User (6 Years)
Quote:

MESHUGGAH wrote:
Is it possible for a game to poll the controller multiple time within a single frame (x02000010, 0x02000014, 0x02000028)?


Yes, the game pad component operates independently from the video component, so input can be processed multiple times per display frame. I don't know if any commercial games do this, though; honestly haven't checked. If I had to place a wager, though, I would guess that all commercial games process input once per frame.

Quote:

MESHUGGAH wrote:
Does it have a "cart lock", a plastic piece preventing cart swapping while the console is powered on?


There's nothing preventing the cartridge from being removed while powered on, but I don't know whether or not the hardware will issue a reset interrupt when inserted. Even if it doesn't, the open bus behavior (zeroes gives you MOV r0, r0, ones gives you OUT.W lp, -1[lp]) will send the current program position rocketing out of the solar system, making it impossible to reliably time the insertion correctly.
Top

Topic | Forum


#3
Re: PVB Emulator & Fundraiser
Posted on: 2/6 21:35
VUE(xpert)
Joined 2012/12/4
387 Posts
CoderLong Time User (6 Years)
Apologies for the delay. Had something happen that amounts to little more than "a long story" at the end of the day, so I won't go into details. I feel terrible about the long absence, but I feel great about what I have to show you today...

Who wants to play some Virtual Boy games? That's a thing now!

The current build is attached to this post, compiled for Java 8.

Open in new window


The Overhaul

Since our last episode, the entire user interface has been redone from the ground up--including the CPU and VIP windows. There's not much to say for the most part, as it looks and feels the way it always did, but under the hood there's a lot less duplication of code going around, and component layouts in general have been simplified. Performance is up, stress is down.

Also, the hex editor will honor Scroll Lock when you have a byte selected. Just putting that out there.

All English-language text in the UI now comes from a localization text file that can be swapped out for any other set of localized strings when the time comes to translate to other languages, even at run-time--all controls will be updated to the new text when changing localizations. Right now the only one available is the provided US English, but the groundwork has been done whenever more languages are added.

The much-maligned VIP window overhaul was every bit as horrible as I feared it would be. I went through about a dozen different iterations of it until finally settling on the one that I... well, disliked the least. It's maybe not the most amazing approach possible, but it's functional--and best of all, it only ever accesses the data it needs right then and there. It won't decode anything from VIP memory unless it immediately needs it, and this counts for drawing the displays.

While the VIP window is implemented and functional, the backing code is in a bit of a state of limbo between two different implementations. It's not broken, and is nonetheless clean and organized, but I still wouldn't say it's in a "done" state. One of these days, but for now I'm gonna leave it and move on.

VIP

The Registers tab is the ol' classic "throw everything at the user" style of interface design. Normally I discourage too many controls on a form, but in this specific case, I feel it's appropriate:

Open in new window


In the emulation context, the VIP is now implemented to the extent I intended to implement it. The code that renders images into the frame buffers is as optimal as I could make it, though it really does showcase the need for a native-backed implementation in the future. Nonetheless, it's all lean and mean, and runs reasonably smoothly on my sorta-nifty computer.

Console

Hey, this is new! It comes in red/cyan and green/magenta flavors with use of Ctrl+3:

Open in new window


To run the program, press the F5 key. Or F8, or Pause. They all do the same thing. Press it again to pause the program.

Controls are quote-unquote "supported", and you'll have to click in the middle of the Console window after the program starts running before they'll register. The following keys map to controller buttons:

• F = A
• D = B
• S = Start
• A = Select
• Up = Left Up
• Left = Left Left
• Right = Left Right
• Down = Left Down
• I = Right Up
• J = Right Left
• K = Right Right
• L = Right Down

While running, the debugger interfaces will not be updated. Once the program is paused, the debugger will reflect the new state. At the moment, debugger controls remain active even during active emulation, so you probably shouldn't go changing settings in there manually. I mean, you could do it, but I can't promise nothing ugly will happen.

Granted, the thing runs a bit slowly in the Java implementation, but the important part is that it works. At long last, it plays games!

Unimplemented Things

The following system features remain unimplemented and may cause issues when attempting to run Virtual Boy software in the emulator:

• Audio
• Game Pad (the current controls support is a dirty hack)
• Timer
• Wait Controller
• Link port
• Bit string CPU instructions
• Floating-point CPU instructions

On the other hand, interrupts and exceptions are implemented, and the VIP module takes full advantage of that. Homebrew games that use VIP interrupts ought to work just fine (provided they don't use any other interrupts).

Attach file:



png  AllInOne.png (60.70 KB)
3060_5c5b44fddd634.png 786X593 px

png  VIPRegisters.png (38.50 KB)
3060_5c5b450569799.png 641X480 px

png  GreenMagenta.png (28.23 KB)
3060_5c5b450a210ae.png 400X254 px
jar pvbemu_20190206.jar Size: 223.10 KB; Hits: 13
Edited by Guy Perfect on 2019/2/6 21:47
Top

Topic | Forum


#4
Re: PVB Emulator & Fundraiser
Posted on: 2018/9/4 19:33
VUE(xpert)
Joined 2012/12/4
387 Posts
CoderLong Time User (6 Years)
Quote:

Fire-WSP wrote:
How is it looking on the VB Emulator front?
I got the feeling everthing has slowed down quite a bit. :(

It fortunately hasn't slowed a great deal, but the things I've been working on over the past six weeks or so don't "look" like anything on the front-end, and presenting it here wouldn't look like a step forward. Every post would be "it looks exactly the same, but it's better, I promise."
I've incorporated several features that were originally slated for "eventually", but as the UI was being pieced together, it became quite clear that "eventually" needs to become "ahead of time", so a lot of planning and preemptive implementation has taken place to ensure the rest of the pieces have a place to fall.

Quote:

Fire-WSP wrote:
Also I read your posts here very carefully and what I learned is that you do the usual Coder thing. You code a thing and smash it down again just to code it again in the hopes to make it better.
That is not a bad thing but that can get a bad thing if you repeat that to much. I know very well that coders are never satisfied with their own code.

On the contrary, I'm generally pleased with the code I produce, taking the time to simplify the algorithms and carefully document the source. The work I've already presented demonstrates that. Over the course of a project like this, certain requirements present themselves after implementation has already begun, necessitating revisions or else those requirements will have to be omitted.

I will say that I made an error by misjudging the task of constructing the UI I envisioned in my head, especially considering the unexpected limitations Java has imposed. I was strongly confident with my designs for the emulation core--code that has remained brilliant since I started work on it--and basically assumed the UI would follow suit. Although I do have the UI under control, it has certainly taken longer than I would have liked and I want to extend my gratitude for everyone being patient while I work with it.

Ernest Hemingway is said to have put it best: "The first draft of anything is shit." No one wants to read the first draft of a book, or the first rehearsal take of a song, or the first storyboard of a film. Revisions are a regular part of the creative process, so it should come as no surprise that they're happening with this project as well.

Quote:

Fire-WSP wrote:
The project is now like 4 month in and is is still about Debugger Windows.

A common misconception regarding software development is that if it looks done it is done, and conversely if it doesn't look done it isn't done. I ask that you refrain from making that assumption here. The debugger windows are critically important, not just for the development and reverse engineering side of things, but also because they greatly aid in testing and debugging the emulation core.

One of my earliest attempts at emulation years ago had CPU instructions all neatly implemented, but when it came time to test it and make sure everything was working correctly, I couldn't. There was no debugging output, so I was somewhat powerless to verify whether my code was as correct as I thought it was. With this project, I can see what the CPU sees: I know what instruction comes next, I know what's in each register and I know the contents of RAM. The same goes for the VIP and ultimately the other hardware components as well.

Without some sort of debugging interface, the emulator itself couldn't be debugged. Since the project calls for a debugging interface as it is, it makes sense to focus on that concurrently with development of the emulation core. Every piece of the machine is connected, and each piece supports the others.

Quote:

STEREO BOY wrote:
Do you think, you could set limits to your heart bleed for this project to push it further?

I don't know that I'd call it perfectionism. Certain things are, such as retooling something to eliminate senseless duplication, but other things aren't. Consider the following features:

• Supports multiple languages
• Performant and responsive
• Accessible
• Consistent with system/user settings
• Minimal duplication (-:

These are all somewhat abstract things, except maybe the language one which is easy to visualize. They're all requirements for the application, but when I started, they were all in that "eventually" category. For example, every time I hard-coded some English-language message, I thought to myself "I really shouldn't be doing it this way", and I knew that each one I did would make more work for myself down the road.

I wanted to focus on "results", and kept letting these things slip by. They ultimately caught up with me, and the excessive duplication of the VIP window was what sent me over the edge. If this was ever going to be anything more than a big steaming pile of first draft, something needed to be done. At first, that was going to be tidying up the VIP window. Then it became the other things.

All of that restructuring is done now. I'm putting the UI back together now, setting it up so the user experience is more or less the way it was before. It looks exactly the same, but it's better, I promise.

And hey, if you need some hype, I'm proud to announce that the hex editor now honors Scroll Lock! Yeah, if that doesn't get you fired up, nothing will.
Top

Topic | Forum


#5
Re: PVB Emulator & Fundraiser
Posted on: 2018/8/11 18:36
VUE(xpert)
Joined 2012/12/4
387 Posts
CoderLong Time User (6 Years)
Yay, an update! Boo, it's not the VIP window. (-:

After my previous message, wherein I described that the philosophy of "fix it later" is generally fruitless, I considered the other parts of the UI that I wasn't happy with. Then I donned my canvas gloves, overalls, safety glasses and respirator, then grabbed a hammer and went to town. The implication is essentially rebuilding all the UI stuff, but that's not so bad because the design is already done and I can copy/paste work from the previous round so I don't have to actually do it all over.

So here's what I've done so far!

The software now supports localization. Previously, display text such as "An error occurred while reading the file." was hard-coded into the source and only supported... you know... my localization. Now, all localized strings are loaded from text files bundled with the software. This means the application can now be translated into pretty much any language according to the user's preferences, and people who want to get involved will be able to provide those translations to the project.

Debugging displays will now only update when the state they're displaying changes. The old setup I used was just a simple "refresh" command that regenerated output any time anything changed in the emulation state. This applied to everything, from the disassembler to the hex editor to each of the individual VIP tabs. In the grand scheme of things this doesn't have a huge performance impact, but I never did like how it would draw all those pictures when you used the hex editor to change a value that wasn't even in video memory...

Global UI settings are now managed centrally. This sounds super-obvious, but at the time I was so bent on getting debugging features implemented that I let "do it correctly" take a back seat... Basically this means any configuration settings (back-end) are now all accessed in the same way from every part of the application. In particular, this applies to text elements. Things that depend on global fonts are now registered with the configuration object, and any time the font(s) change(s), all appropriate controls are updated as well. Additionally, all controls that depend on localized strings will be automatically updated whenever the locale is changed.

Right this minute I'm doing a bit of analysis on the disassembler to see if it should be done differently from what I had before. I'll probably wind up using the previous code, then move onto the other UI components. Finally I feel good about everything.
Top

Topic | Forum


#6
Re: PVB Emulator & Fundraiser
Posted on: 2018/8/6 19:37
VUE(xpert)
Joined 2012/12/4
387 Posts
CoderLong Time User (6 Years)
I'm as excited as you guys are! A lot has been going on, but since none of it is visible on the front-end and I'm not quite finished with what I ultimately decided to do, I can't really post about it yet... So thank you, everyone, for your patience. I realize it's probably felt like a blank wall in this thread lately, but it's totally worth the wait. <3

My OCD got the better of me with regards to the mechanics of the VIP window and I found myself unable to allow it to slip through in a "good enough" state that I wasn't exactly happy with. After all, that's how we get shoddy, bloated, over-par software: we make compromises early on under the assumption that it will be "improved later on", and then ultimately "later" never comes around. I don't want that to happen. Not to my project, and not to Virtual Boy. I want it done well, and I can do it well.

How this mess got started in the first place was an unfortunate assumption. When I first designed the VIP window, I started with the Character tab and figured I could set up a simple little mechanism to decode character memory into pixel patterns. Then I did the BG Maps tab and recognized that I needed to rely on the functionality of the Characters tab, also requiring additional palettes and mirroring capabilities. Then I worked on the Worlds tab and found the need to rely in turn on the functionality of the BG Maps tab, and so-forth. What started as a "simple quick thing" wound up becoming the cornerstone of the entire UI, and I wound up gluing more and more onto an abomination instead of building a lean machine from the outset. Right now, finally, I bit the bullet and decided to build that darn lean machine.

It caught me off-guard because in software design, it becomes second-nature to design code in such a way that it is what they call loosely coupled. What this generally means is that all code that pertains to a certain concept should be as self-contained as possible, with only minimal interfacing with other modules. This is almost universally the best way to set it up, since it means modules can be hot-swapped with others in the event of--for example--new development, but it isn't always possible. In the case of the VIP window, I went into it thinking each tab would be loosely coupled from the others, and designed them to be self-contained independently from one another. Once I began implementing them, however, I found that they were intrinsically linked because later tabs relied on the features of earlier tabs--resulting in a tightly-coupled situation. It was a mesh of contradicting design philosophies, and while the outward appearance was satisfying, the backing code left a lot to be desired.

The plan is once again to have the VIP window done "this week", but I realize I've said that before... But so help me if it doesn't come to pass, because it's sooo close to a reality that I can taste it. I'm extremely eager to sink my teeth into actual VIP implementation in the emulation core and finally see programs running on their own, and this is the final task between this moment and that one.
Top

Topic | Forum


#7
Re: PVB Emulator & Fundraiser
Posted on: 2018/7/13 20:52
VUE(xpert)
Joined 2012/12/4
387 Posts
CoderLong Time User (6 Years)
Still alive! Sorry about that. I said "expect something this week" and now it's two weeks later. My bad. (-:

While yes, progress has been made on the project, it was on the back-end and the VIP window isn't complete yet. I reworked most of the VIP I/O interface to correct for an oversight where I was treating all memory accesses as though only the emulated CPU could do it. Since the debugger is allowed to do "debug" accesses, it meant allowing for certain impossible things such as writing only the upper byte of an I/O register, etc. That's all sorted out now, and the Registers tab is looking amazing.

So what was I doing for two weeks? The short answer is Something Came Up™. It was a time-sensitive affair not related to Virtual Boy that I was hoping would be resolved in just a handful of days, but I don't want to sink any more time into it. Virtual Boy needs me! It's a bit frustrating because the other thing is nearly fulfilled and yet I have to leave it in the hands of the others involved. Oh well, that's how things are, and VB needs more love, so VB gets more love.

We now return to our regularly scheduled development. The support for this project is always well appreciated and I'm looking forward to charging back into it. <3
Top

Topic | Forum


#8
Re: PVB Emulator & Fundraiser
Posted on: 2018/6/25 21:04
VUE(xpert)
Joined 2012/12/4
387 Posts
CoderLong Time User (6 Years)
Splatoon 2: Octo Expansion came out of nowhere and took my attention for a week, but I'm back on the Registers tab and things are going swimmingly. Expect the VIP window to be mostly done this week, save for the Framebuffer tab that will be coming later.

Don't grow too attached to the current GUI (CPU window included), because it is subject to change eventually. With each new piece that goes into the interface, I come up with ideas and learn things about how different pieces interact. Eventually I'm going to gut the whole thing and rebuild it (bigger, faster, stronger, etc.), but not right now. There are two reasons for this: 1) I could spend all my time making things perfect and then never really moving the ball forward and 2) after more GUI elements go in, I may find myself in a position where I just have to rewrite it all again anyway.

So for now, it's business as usual, with the functional-yet-lackluster GUI that will be replaced one day. (-:
Top

Topic | Forum


#9
Re: PVB Emulator & Fundraiser
Posted on: 2018/6/10 18:29
VUE(xpert)
Joined 2012/12/4
387 Posts
CoderLong Time User (6 Years)
Quote:

StinkerB06 wrote:
Has anyone experienced the generic colors not working in all but the Characters tab? I'm having this issue. Not even Ctrl+3 is changing the color palette.

If the program initializes the palettes to black, they'll be drawn as black even when using the generic color scheme. All the generic palette does is use a pre-defined set of brightness levels instead of the current brightness settings in the VIP. As such, black is black no matter what. (-:

Quote:

speedyink wrote:
That's actually the F Zero homebrew. Interesting project, but halted unfortunately :(

It ain't dead, though. I'm curious to try offloading some of the image processing to the CPU and see if I can boost the performance without affecting the output. But that's for another day.

Quote:

StinkerB06 wrote:
When the emu starts, the anaglyph colors initialize to red and blue. Pressing Ctrl+3 makes it green and magenta. Do it again and red and cyan. Do it once more and it's back to green and magenta. There's no way to get the red/blue one back. Note that the colors blue and cyan are different.

That's correct. The red/blue set is just the default, and it's not changed until Ctrl+3 is used. The final application will allow the anaglyph colors to be fully configurable, but I highly discourage use of straight-up #ff0000/#0000ff for reasons discussed earlier.
Top

Topic | Forum


#10
Re: PVB Emulator & Fundraiser
Posted on: 2018/6/10 2:35
VUE(xpert)
Joined 2012/12/4
387 Posts
CoderLong Time User (6 Years)
This is a work post.

That pesky Worlds tab is finally done. After over 9000 revisions to the underlying code of the VIP window, all tabs are now simplified and playing nice with one another. And worlds are implemented.

By this point I've kinda forgotten exactly what I need to say about it... The Objects and Worlds tabs are now present, which do a simple anaglyph output for the time being. The default colors are red and blue, but you can toggle between the perception-calibrated colors sets with Ctrl+3.

The Framebuffer and Registers tabs remain, but I need to sit down and figure out what comes next. I've been fighting with Java's middle-of-the-road graphics support for so long that my train of thought derailed a couple weeks ago and never got back on track. O-:

The current build is attached to this post, and the Sacred Tech Scroll has been updated on the project page with the latest revisions.

Attach file:


jar pvbemu_20180609.jar Size: 191.18 KB; Hits: 45

png  WorldsTab.png (49.76 KB)
3060_5b1c7239e67e9.png 640X480 px
Top

Topic | Forum