You are not logged in.
Lost Password?

All Posts (Guy Perfect)




#11
Re: PVB Emulator & Fundraiser
Posted on: 2019/3/27 23:10
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
A new build is attached to this post:

New Features
• Audio is now implemented, disabled by default, toggled with Ctrl+A
• Added disassembler comments for VSU registers

Code Changes
• Rebuilt the Console class with new threading, timing and audio code

Bug Fixes
• Items in the Link menu will now retain the check mark when selected
• Triggered breakpoints will no longer steal focus from other main windows
• Corrected the address that presents BKCOL disassembler comments
• Disassembler comment detection for I/O ports now correctly masks address bits

The key attraction this time around is audio support, and the Sacred Tech Scroll has been updated as usual. There's very little left for the document before the formal v1.0 release, and the emulator application just needs a few menu items implemented before it's quote-unquote "ready" for its own version 1.0.

If you give the audio a go, you'll probably notice pretty quick a bit of a glaring problem: it's a bit too much for Java to handle unless you've got a hulking monster of a computer. On my own box, most games stutter pretty badly, spending more time between frames than presenting them, which is why audio is disabled by default. This isn't a problem that's going to go away without a native implementation driving the workload. The JVM profiler does its best to optimize the emulation core, but there's just too much going on for it to keep up.

Audio does work correctly, though, and dare I say perfectly. Attached to this post is a .ogg file that is a log of audio output from the emulator during a short Wario Land session. If you open it up in an audio editor, you'll see the actual samples produced by the emulator, including the simulated analog filter that centers the output around zero. All of the samples are unedited, exactly as they came out of the emulator. The only thing I did to the clip was trim off some silence at the beginning.

Also attached to this post is an IPS patch (use it with something like Lunar IPS) that will modify Wario Land slightly in order to use the HALT instruction while waiting for VIP activity. The disassembler and breakpoints came in real handy for this! Performance is improved relative to the unmodified game, but it's still not quite fast enough on my box. That native implementation is going to be the key to getting performance back up to where it needs to be, but that's still a ways out yet.

Lastly, a copy of VSU Workshop is attached to this post for testing purposes.

All of the internals regarding the frame animator were completely redone in this build, meaning a completely different set of potential bugs now applies. If you could play around with the window commands and linked window communication to check for bugs, it would be appreciated.

Attach file:


jar pvbemu_20190327.jar Size: 345.74 KB; Hits: 135
ogg wario_log.ogg Size: 3,001.43 KB; Hits: 91
ips wario_halt.ips Size: 0.16 KB; Hits: 91
vb vsu_workshop.vb Size: 32.00 KB; Hits: 81
Top

Topic | Forum


#12
Dear Homebrewers: Halt!
Posted on: 2019/3/27 4:27
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
While developing a Virtual Boy emulator in Java, I finally hit critical mass where the simulation was a little more demanding than my environment could process in time. Sometimes this would happen when using breakpoints, but it came out in force after implementing audio, and that's no fun. I have an idea of what to do about it, so don't worry about me... You've got your own things to worry about!

tl;dr: if you're developing for Virtual Boy, use the HALT instruction.

When your program needs to wait for an interrupt to occur, it's common practice to check on a global variable until an interrupt handler comes along and changes that variable. This works, but is not recommended because the CPU is busy chugging away wasting time. Even worse, it's wasting power, which is kind of a deal on Virtual Boy with its six AA batteries. Worst of all, it's slowing down my emulator!

The better way to wait for interrupts is with a dedicated CPU instruction called HALT. This instruction suspends CPU activity entirely until some external component (such as the video processor) requests an interrupt, at which point the CPU comes back to life and handles the request. Power isn't consumed for spin waiting this way, and no processing takes place until the interrupt does its job.

If your development tools don't provide ready access to the HALT instruction in your programs, you can access it yourself with this simple yet janky C function:


void halt
() {
    static const 
long code 0x181F6800L;
    ((
void(*)())&code)();
}

Use the HALT instruction any place where you need to wait for an interrupt and don't have anything else to process while doing so. This will ensure better performance in emulation efforts going forward as well as make the world a better place in general...
Top

Topic | Forum


#13
Re: PVB Emulator & Fundraiser
Posted on: 2019/3/22 20:15
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
Turns out I'd forgotten to put the new "config" package into the .jar file, so the previous upload did not work. The one attached to this post should be fine.

Also, after typing out why I had to process linked simulations one cycle at a time, it occurred to me that I could check for communications while both simulations were in halt status even if the communication doesn't raise an interrupt. This build takes that into account and sees vastly improved performance over the broken one that you never got a chance to use anyway because of the aforementioned .jar mistake...

Attach file:


jar pvbemu_20190322b.jar Size: 325.71 KB; Hits: 89
Top

Topic | Forum


#14
Re: PVB Emulator & Fundraiser
Posted on: 2019/3/22 19:06
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
Although the outward functionality appears to be relatively the same, reworking the application UI to accommodate linked pairs of emulation windows was a lot of intricate work. But it's done now!

Attached to this post is a new build: (See following post)

New Features
• The main application window has been redesigned
• The communication port is now implemented

Code Changes
• Unmapped reads in the 0x02000000-0x02FFFFFF range will now be zeroes
• The localization driver was updated to support substitutions
• A new class MainWindow was created for representing the application interface
• Multiple windows can now be instantiated and linked
• Global input commands are now implemented and are configurable
• The Config class and its new helper classes are in a new "config" package

Bug Fixes
• Writes to DPSTTS were forwarding to DPCTRL, which I don't think is correct
• Simultaneous Left/Right and Up/Down are disabled by default, correcting a crash in Wario Land
__________

To use the new communication feature:

• Create an additional emulator window with File → New Window
• Associate communication peers through Emulation → Link
• Use the emulator windows as you normally would

When only one emulator window exists, the Link sub-menu will not be available. When multiple windows exist, the Link sub-window will display a list of all current windows, allowing the user to select one to associate as a communication peer. If the window is already linked, a Disconnect option is also available in the Link sub-menu.

Communication Workshop has been attached to this post to help with testing.

I did a lot of experimentation with boosting performance when linking simulations, but the unfortunate fact of the matter is that the only way to keep linked instances synchronized is to process them one cycle at a time. I thought maybe checking if both simulations were in halt status I could boost performance by skipping to the next interrupt, but communications don't always raise interrupts, and there's no way to predict ahead of time when the software is going to trigger a communication event...

... So long story short, linking in the current Java implementation is slow. Hopefully the eventual native implementation can handle linking at full speed.

Each emulation window animates frames in its own thread as a consequence of how timers work. However, linked frames will only use the animation thread from whichever window initiated simulation processing. I'm pretty sure I got all the logic correct, but since thread locks are rather intermingled under a variety of circumstances, it's possible there might be some combination of circumstances that could cause the application to deadlock.

The following describes the general contract of the linking behavior:

• Unlinked windows operate in their own threads
• When paused windows are linked, the one that invokes the Run command controls both
• When running windows are linked, the one that invokes the Link command controls both
• When a running and paused window are linked, the paused window is activated and the one that invokes the Link command controls both
• When running linked windows are disconnected, the "slave" window resumes control of itself
• Closing a linked window invokes the Disconnect command
• The following commands will only apply to the linked window that invokes them: Reset, Frame Advance, Step Over, and any user-defined breakpoints

Keep an eye out for any reproducible problems that might occur with thread management, and please report any problems in a reply. I did my best to make sure it works correctly, but this is a bit of an atypical method of threading windows and I don't want to say with absolute certainty that it can't break.
__________

Besides the link feature, the main window was redesigned and all of the old features remain implemented. However, the only new feature that was implemented is the Game/Debug Mode setup, with additional menu options to be implemented later. One thing to keep in mind with regards to window modes:

• In Game Mode, emulation will always begin when a ROM is loaded
• In Debug Mode, emulation will always be paused when a ROM is loaded

This should be most useful to the most users and might wind up in the Settings window depending on what I decide on the matter.

Ctrl+3 still cycles anaglyph colors, but it is a temporary command that will be removed once the Video Settings interface is implemented, which will allow the user to configure whatever colors they wish.

The debugger interfaces still do not contain any safeguards while the simulation is running, and should not be used unless the simulation is paused. This is also temporary, as I didn't want to delay this build any longer than necessary.

Step, Step Over and Frame Advance can now be used while the simulation is running. All three will cause emulation to pause after they complete.

Attach file:


vb communication_workshop.vb Size: 16.00 KB; Hits: 64

png  Linked2.png (24.19 KB)
3060_5c9522ae356dd.png 773X555 px
Edited by Guy Perfect on 2019/3/22 20:15
Top

Topic | Forum


#15
Re: PVB Emulator & Fundraiser
Posted on: 2019/3/14 1:18
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
No build this week, but there's plenty news about updates. Part of what's taking so long is a management shuffle at work resulting in an unusually heavy workload, and part of it is... well, let's find out!

For starters, the link implementation is all set up and works just fine. I was able to test it with a truly terrifying hack-n-slash second Console window:

Open in new window

The "Communication Workshop" program in the screenshot can be found attached to yonder post, but since I can probably count on one hand the number of people who can make effective use of it, there's not much incentive for anyone to go grab it. But it does indeed work correctly, which is the important part.

As may be apparent, the main application window needs to be adjusted in order to properly present two linked simulations to the user. I decided to take the opportunity to redesign the main window entirely, fixing various usability problems along the way and introducing my vision of the final application UI.
__________

Many Hats

The next build introduces a new application paradigm: presentation is split into two modes depending on the user's preferences. In Game Mode, the top-level window is only the menu bar and video display, and in Debug Mode, the MDI that has been used up until now will be used. Debug mode is toggled on and off in the File menu.

Open in new window

In Game Mode, the File menu has these options. Most should be pretty self-explanatory, though New Window will produce another top-level main window with all the same features. This is what will enable link play, as we'll see in a bit.

Open in new window

In Debug Mode, the File menu becomes slightly different as it adds options for ROM file management as well as individual control over SRAM (in Game Mode, SRAM is automatic using the ROM filename). Modifications made to ROMs in the hex editor or, eventually, the assembler can be saved as new files for ease of development. ROMs and SRAM can also be resized.

Open in new window

The new Emulation menu brings options that were previously known only to the monks of the mountain who study such things. All of the old keyboard commands will continue to function, but now every command available becomes more accessible thanks to being visible on-screen. Step and Step Over are hidden in Game Mode, since they're not useful there.

The Link sub-menu brings up a list of additional windows, allowing the user to select one to associate as a communication peer. This is where the New Window option from the File menu comes in handy.

Open in new window

All of the settings will actually be accessible from a single window, but the Settings menu has some common options to help the user get to where they need to go without excessive navigation of the menus. Input, Video and Audio all bring up a new Settings window, but they each automatically select the appropriate tab/page. The Settings item simply shows the Settings window in its most recent state.

Additional settings--such as localization/language, disassembler configuration and the eventual native implementation selector--will also be in the Settings window, but simply not have shortcuts in the Settings drop-down menu itself.

Open in new window

The Debug menu should be familiar, as it's the same as the Window menu up until this point. The entire menu is hidden in Game mode.
__________

While most of the menu items are right-this-second unimplemented, I was still able to get a decent chunk done over the week despite the activity at work...

Anyone familiar with the source code layout will find that App has been broken free of its connotation with the main application interface, and a new class MainWindow was introduced. App functions mainly as a window manager, but also houses the global configuration accessible through the Settings menu.

The code that drives localization of on-screen control messages has also been updated to add some more flexibility that wasn't there before. The new features will benefit messages that require substitutions, such as the main window title and the Breakpoints window error message. With the new improvements, 100% of the strings are now fully localized and can be swapped out with a new localization file at runtime. An associate of mine has agreed to do a Japanese translation when the time comes, so it won't just be US English through the end of time.

What I'm currently working on involves input from the user. All of the keyboard bindings are about to be user-configurable, which includes things like "F5 to run/pause" and "D is the B Button". It's being set up to eventually support controller/joystick input as well, although that will require native modules to pull off.

Attach file:



png  Linked.png (13.23 KB)
3060_5c8996e9ef8a3.png 786X593 px

png  File1.png (6.14 KB)
3060_5c8997ab60d3f.png 255X217 px

png  File2.png (6.27 KB)
3060_5c89986bddcca.png 255X238 px

png  Emulation.png (5.24 KB)
3060_5c8998e15d818.png 196X239 px

png  Settings.png (4.45 KB)
3060_5c89998ec5ee0.png 222X186 px

png  Debug.png (5.64 KB)
3060_5c899b0962d4a.png 277X257 px
Top

Topic | Forum


#16
Re: Virtual Boy speaker quality
Posted on: 2019/3/10 19:53
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
The audio output from the VSU is a DC signal that gets converted to analog and attenuated with the volume wheel. All of that processing takes place on a small board mounted next to one of the displays, so tapping into the digital line shouldn't be too problematic.

Having said that, the audio quality is the same on the analog side of things because the only processing is an RC circuit that applies an inaudible ~7.234 Hz high-pass filter, followed by the attenuation from the volume wheel. The audio signal in Virtual Boy isn't irreversibly transformed on output like it is on NES and some other systems.
Top

Topic | Forum


#17
Re: PVB Emulator & Fundraiser
Posted on: 2019/3/6 20:09
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
This beast keeps getting closer and closer to completion. Another update, another attached build:

New Features
• Bit string instructions are now implemented
• The wait controller is now implemented
• Illegal instructions now display in the disassembler as ---
• Added disassembler comments for remaining hardware component registers

Code Changes
• Researched and implemented correct timing for DPBSY and SBOUT
• Breakpoints interface moved into Debugger package where it belongs
• Deleting a breakpoint will now select the next available breakpoint in the list
• Tweaked timing code to always refresh between frames
• Tweaked read and write CPU cycle counts
• The Console window now displays images with a one-frame delay, as the hardware does, in order to facilitate slower software rendering

Bug Fixes
• Interrupt handling now correctly sets interrupt masking level
• Corrected a read bit in SCR that prevented Mario Clash from reading input
• Writing into frame buffer memory will now be visible in the Console window
• Corrected disassembler treating illegal opcodes as bit strings
• Clicking in the list of breakpoints now commits any breakpoint edits
• Disassembler comments for interrupts should now appear even without a breakpoint
• Logical Not (! operator) in Condition and Goto now works properly when used on boolean and integer values

An edit to the number of CPU cycles taken by bus accesses seems to have improved performance across the board. Apparently Java wasn't the problem so much as the simulated CPU was too slow, and now most games run full-speed on my workstation. Waterworld, which was previously so choppy as to be unplayable, now runs smoothly, and the mysterious flickering in Mario's Tennis has stopped as well.

Red Alarm does not boot in this build. It seems to be especially sensitive to system timings, and when I do get it to run, some frames exhibit errors like blank contents or failure to clear the previous frame. It will take some research, as it does depend on WRAM and VRAM bus access latency, so until further notice the emulator will not have 100% compatibility with commercial games.

The sacred tech scroll now documents the display timings, the hardware component memory map, further details on bit string instructions and even the communication port. I wasn't able to have link support ready to go in time for this update, so I guess you know what to expect next time. (-:

Attach file:


jar pvbemu_20190306.jar Size: 298.48 KB; Hits: 80
Top

Topic | Forum


#18
Re: Link Behavior
Posted on: 2019/3/5 23:41
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
Did some more experiments today, which came with an update to Communication Workshop, attached to this post. The Sacred Tech Scroll has been updated with my findings.

Quote:

1) When initiating a communication with the internal clock selection, it will immediately process without a peer and load 0xFF into CDRR.

This appears to be true when another system is linked and powered on, but with it powered off or disconnected, CDRR gets garbage bits. This is unfortunate, as it makes it more difficult to automatically negotiate which unit gets to host the clock signal.

Quote:

5) Does the C-Int-Inh or CC-Int-Inh bit corresponding with the source of the interrupt need to be set in order to acknowledge the interrupt? The literature says CC-Int-Inh works for both, but I haven't tested it.

There are two distinct sources for communication interrupts: one configured via CCR and the other through CCSR. If either register's condition triggers an interrupt, that register's Int-Inh bit must be set to acknowledge it.

This can be tested with the new Communication Workshop. If you store 0x01 into CDTR, it will unconditionally attempt to acknowledge any interrupt with a write to C-Int-Inh. Similarly, 0x02 makes it try CC-Int-Inh. If any other value is in CDTR, interrupts will be acknowledged automatically.

The text next to the IRQ field in the output describes what happened. It will say either "CCR" or "CCSR" if a single register was needed, "Both" if both registers qualified, or "Twice" if the first attempt specified by CDTR failed and the interrupt handler was called a second time.

Quote:

7) I haven't yet tested the behaviors of CC-Rd or CC-Smp with only one unit or without a pending communication on a remote unit. It's getting late and I'm tired. I'll do it tomorrow!

If there is no connected unit or the connected unit is powered off, CCSR automatically behaves as though a phantom second unit has the same configuration in that register.

Quote:

8) Will changing C-Clk-Sel while C-Stat is set abort the current communication? I'd hate to think that the link component could soft-lock itself on both units by waiting for an external master unit that will never come...

A communication initiated with C-Start cannot be canceled, but changing C-Clk-Sel from External to Internal will cause the normal internal behavior to carry out, even if you don't write to C-Start.

Attach file:


vb communication_workshop.vb Size: 16.00 KB; Hits: 76
Top

Topic | Forum


#19
Re: MultiBoy 32
Posted on: 2019/3/5 21:26
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
This is some fantastic work. If you're desperate for customers hit me up, but I'd be happy to wait for upgrades to the design once it takes hold.
Top

Topic | Forum


#20
Re: PVB Emulator & Fundraiser
Posted on: 2019/3/5 19:02
VUE(xpert)
Joined 2012/12/4
418 Posts
CoderLong Time User (7 Years)
You're not wrong: the UI needs some work. Emulator operations are controlled with keyboard commands:

Emulation Commands
F5 - Run/Pause
F6 - Frame advance
F10 - Step Over
F11 - Step

When running, only the Pause command will be carried out.

Application Commands
Ctrl+3 - Cycles between color modes
Ctrl+B - In disassembler toggles the bytes column
Ctrl+G - In disassembler or hex editor prompts an address
Ctrl+P - In disassembler or hex editor seeks to PC

Controller Input
F - A button
D - B button
S - Start button
A - Select button
E - L button
R - R button
Up Arrow - Left D-pad up
Left Arrow - Left D-pad left
Down Arrow - Left D-pad down
Right Arrow - Left D-pad right
I - Right D-pad up
J - Right D-pad left
K - Right D-pad down
L - Right D-pad right
Edited by Guy Perfect on 2019/3/5 19:19
Top

Topic | Forum