Jul -- General Game/ROM Hacking: Food For Thought... (NES Emulation) Black and Red 3DChat

GuyPerfect
Catgirl
Level: 68

Posts: 728/1096
EXP: 2665649
For next: 63151

Since: 07-23-07

Since last post: 1.7 years
Last activity: 219 days

Posted on 05-20-12 09:13:10 PM

Link | Quote

*Huff, puff*

Okay, I gotta give this David Tucker fellow props for figuring everything out for Virtual Boy, but dang son, if this is the level of communication you use when you sit down for hours to write a technical document, I can't imagine what kinds of unintelligible grunts you make during a typical conversation.

(I kid David Tucker, but seriously, this document was only mostly clear, fairly ambiguous in places, and downright incorrect in a few spots that I only caught as a technicality)

With that out of the way, I've documented the vast majority of the video subsystem, using a language called English that humans use to express information to one another oh I couldn't leave it be could I. There's still a few things left to document, like palettes, the VBlank interrupt and a complete memory map, but my brain is tired.

Originally posted by Rena
You would have to do bounds checking on every access, though.

That's two host cycles per emulated load/store instruction I'm willing to sacrifice for the cause.

GuyPerfect
Catgirl
Level: 68

Posts: 729/1096
EXP: 2665649
For next: 63151

Since: 07-23-07

Since last post: 1.7 years
Last activity: 219 days

Posted on 05-21-12 06:23:28 PM

Link | Quote

Okay, I gave the video documentation a twice-over, and now I'm satisfied with the current state of the document. I'm at the point now where details are becoming sparse, so I figure Mr. Tucker just said "screw it, if they want to know more they can look at the source code of my emulator."

Moving forward, I intend to discern as much significance as I can by examining what the actual game programs are doing, using the Reality Boy source only as a reference if I get stumped.

So until further notice (when I get time to implement some emulation stuff), the document will remain in its current state: http://perfectkiosk.net/guyperfect/stsvb.html
__________

Soooo... Bet you weren't expecting this, but the Virtual Boy is actually more sophisticated than the Game Boy Advance: it has both a faster processor and a more feature-rich video subsystem. Unless the two systems were developed concurrently, then they intentionally took a step backwards. If you're shocked and in disbelief, check the document and see what you think.

In regards to my emulator's video module...

Windows and sprites within windows with a lower index have higher priority and are drawn in front of those with a higher index. Effectively, this is like starting at the highest index and drawing all pixels moving down towards index 0. Reality Boy does this, but it seems pretty inefficient to me. We know during rendering if a pixel is already drawn and the foremost pixel at that location on the screen, so why spend the time drawing all potential values for that pixel on top of each other starting at the back?

Instead, I think I'll keep an array of flags handy--one for each pixel--that indicates if the given pixel already contains its final color value. This way, as each tile is drawn to the frame buffer, it can check "Do I need to process this pixel? No? Okay, next pixel." For unobscured pixels, this adds some overhead that wouldn't be there otherwise. But the act of loading the flag and branching if non-zero arguably takes fewer host cycles than fetching the pixel color value for the current pixel in the current tile, fetching the color for that value from the corresponding palette, multiplying that color value with the global brightness value for that color, then storing the resulting value in the frame buffer. For multiple overlapping layers, I think it will win out for performance.

Also, I've got a sweet pair of anaglyph 3D glasses coming in the mail.

Rena
I had one (1) message in Discord deleted and proceeded to make a huge, huge mess about how it was a violation of free speech and how moderators are supposed to be spam janitors and nobody should have the right to tell me not to talk about school shootings
Level: 135

Posts: 4776/5390
EXP: 29075300
For next: 259705

Since: 07-22-07

Pronouns: he/him/whatever
From: RSP Segment 6

Since last post: 342 days
Last activity: 342 days

Posted on 05-22-12 07:10:59 AM (last edited by Rena at 05-22-12 07:36:11 AM)

Link | Quote

Post #4776 · 05-22-12 02:10:59 AM

Sounds like a depth buffer. Are you maybe reinventing OpenGL?

btw:

  0x00078000-0x00079FFF - Linear Mirror of Pattern Table 0

  0x0007A000-0x0007BFFF - Linear Mirror of Pattern Table 1

  0x0008C000-0x0007DFFF - Linear Mirror of Pattern Table 2

  0x0008E000-0x0007FFFF - Linear Mirror of Pattern Table 3

"an exponent to raise 2 to the power of" sounds a bit strange. Just "an exponent of 2" might be clearer?

  bg_arr_x = affine_x + (window_x + affine_parallax) * x_increment

  bg_arr_y = affine_y + (window_x + affine_parallax) * y_increment

Quite interesting machine... similar CPU to the N64, though slower, and 4 times as much memory... more sophisticated graphics than the GBA...

Does it not have the branch delay, though? On N64, the instruction after a branch executes before the branch itself (due to pipeline delays or some such), so you'll see code like:

LUI $a0, 0x8011

JAL somewhere

ADDIU $a0, $a0, 0x1234

(and if that instruction is also a branch, who knows what happens... it's undefined behaviour.) Even more fun, there are conditional branches for which the delay instruction executes only if the branch is taken, so you can find things like:

BEQL somewhere

ADDIU $a0, $zero, 1 ;skipped if the branch condition was false!

somewhere: ...

____________________

Programs

stuff goes here

Log out Shut down

Post #4776...[blag][Twitter][Freenet]

GuyPerfect
Catgirl
Level: 68

Posts: 730/1096
EXP: 2665649
For next: 63151

Since: 07-23-07

Since last post: 1.7 years
Last activity: 219 days

Posted on 05-22-12 02:56:07 PM (last edited by GuyPerfect at 05-22-12 03:51:38 PM)

Link | Quote

Originally posted by Rena
Sounds like a depth buffer. Are you maybe reinventing OpenGL?

This priority business is nothing new. It's been in the books since NES. But yeah, it can be conceptualized as a 1-bit depth buffer.

Originally posted by Rena
"an exponent to raise 2 to the power of" sounds a bit strange. Just "an exponent of 2" might be clearer?

I think when I was writing it I was thinking "exponent of 2" meant the same thing as "power of 2," but thinking on it some more, I'm not sure they're identical. I'll look into it.

Also, thank you for providing the first-ever feedback on my document.

Originally posted by Rena
Does it not have the branch delay, though? On N64, the instruction after a branch executes before the branch itself (due to pipeline delays or some such), so you'll see code like [snip]

All instructions finish executing before the next instruction is fetched, including branches, with the possible exception of the bit string instructions, which can be aborted/paused by interrupts.

Originally posted by Rena
Quite interesting machine... similar CPU to the N64, though slower, and 4 times as much memory... more sophisticated graphics than the GBA...

Crazy, innit? I was quite surprised to learn this myself, since all of the games released for Virtual Boy are only so-so in the tech department. A couple were great fun (I'm looking at you, Wario Land), but nothing really made me say "Wow, the Virtual Boy's pretty neat!"

Also, for what it's worth, the system has 64 KB of on-board memory and the most SRAM used in any commercial cartridge was 8 KB.

EDIT:
Just saw what you meant with the pattern table mirrors. The 7s you marked are actually correct; it's the 8s that were wrong. I've updated the document to fix this.

GuyPerfect
Catgirl
Level: 68

Posts: 732/1096
EXP: 2665649
For next: 63151

Since: 07-23-07

Since last post: 1.7 years
Last activity: 219 days

Posted on 05-22-12 05:11:20 PM (last edited by GuyPerfect at 05-22-12 05:32:03 PM)

Link | Quote

Okay, change of pace. I think I've come up with an elegant way to handle debugging features without bogging down the execution time. And it's flexible! Like, really flexible!

Every emulation module, like Core and CPU and Video, will use function pointers for each task they can perform. For Core, as an example, the Read, Write and Execute functions will execute from pointers. For CPU, each of the individual instruction handlers would execute from pointers (which they were doing anyway, but this has implications now).

When an external feature--any external feature--wishes to commandeer various tasks, they call an AddHijack function that corresponds with the given module. Or maybe if they want to hijack tasks they can call a Commandeer function... Either way, the function accepts an identifier for what is being taken control of, a new function pointer to use in its place, and a context parameter so the hajacker knows exactly what a given hijacking is being used by. When a hijacker is finished, it can RemoveHijack itself, and if no hijacks are active, the module will reinstate its default handler.

The fancy business of breakpoints and conditions would be the responsibility of the corresponding hijack module. The only thing the Hijack interface provides is a pass-through mechanism for external features.

So let's say I want to implement those Step Over and Step Out features I mentioned. They need to override the behavior of CPU_JAL and CPU_JMP. When JAL occurs, it increments a counter. When JMP r31 occurs (a situation that needs to be detected by the hijacker when JMP is used), it decrements the counter. When the counter reaches zero (for Step Over) or negative (for Step Out), a break occurs.

All of this together will allow not just built-in expansion features, but user-created features as well, which could plug in maybe by DLL on Windows, or... <mumbles>possibly even a Lua interpreter at some point</mumbles>

Emulator user interfaces would make use of the break functionality as well, like when you hit the Esc key in ZSNES. That particular feature does not require any hijacking, however, as it is simply a function of Core that is called and immediately pauses emulation. There will also be a Run function that's used to start emulation as well as resume after breaks. External features that don't actually need to trigger a break, well, they just won't trigger breaks. Simple as that.

So with the core and its subsequent modules decoupled from the user interface, this thing will be able to be compiled on nigh-on anything. 3DS, anyone?
__________

Some personal brainstorming:

Core

Private, hijackable

• Read_BS, Read_BU, Read_HS, Read_HU, Read_WS, Read_WU
• Write_BS, Write_BU, Write_HS, Write_HU, Write_WS, Write_WU
• Execute
(All reads are hijacked by Read and writes by Write)

Public

• Run
• Break
• Reset
• AddHijack
• RemoveHijack
• GetHijacks
• ClearHijacks

Exposable members

(The entire memory map, read/write except for unmapped addresses)

CPU

Private, hijackable

• (One handler for every instruction)
• Exception
• Duplexed Exception
• Fatal Exception

Public

• AddHijack
• RemoveHijack
• GetHijacks
• ClearHijacks

Exposable members

• (General-purpose registers)
• (System registers)
• PC

GuyPerfect
Catgirl
Level: 68

Posts: 733/1096
EXP: 2665649
For next: 63151

Since: 07-23-07

Since last post: 1.7 years
Last activity: 219 days

Posted on 05-22-12 06:20:12 PM

Link | Quote

Mockup time!

Bear in mind that the red is just for humorous effect. The real colors will actually be bearable.

• Please give feedback! What do you like, what do you not like? What would you rather see?

• Would you, as a programmer/hacker, feel comfortable using a debugger set up like this?

• I'm still undecided as to how to incorporate the breakpoint feature, so any input is appreciated. At the moment, I'm just thinking it will have a window of its own.

Darkdata
Ruins!? ♥
Level: 103

Posts: 2646/2892
EXP: 11445954
For next: 25452

Since: 07-04-07

Since last post: 202 days
Last activity: 10 days

Posted on 05-23-12 02:14:28 AM

Link | Quote

Made a small change to the thread title.

____________________

GuyPerfect
Catgirl
Level: 68

Posts: 734/1096
EXP: 2665649
For next: 63151

Since: 07-23-07

Since last post: 1.7 years
Last activity: 219 days

Posted on 05-23-12 03:07:23 PM

Link | Quote

Having slept on it, I think I'm ready...

I'd like the emulation core to be standalone, and its source code will be made public (though not "public domain," but people can still use it for whatever purposes). It will contain all the essential bits and widgets to emulate the system, and nothing more. No intrinsic support for cheat codes. No intrinsic support for debugging features. No intrinsic support for user interfaces. It's just the emulation core, and requires a driver application to make use of it.

The core will be a sort of self-instantiating interface setup ultimately being drawn from just a single API function: Create. The Create function will accept a pointer to a parameter structure containing initialization parameters like the ROM image and desired audio frequency, and return a pointer to an interface object. The interface object will contain all the properties and function pointers pertinent to the operation of the emulation core. When the driver is all done with the interface object, it can call the object's Release method to take care of deallocating everything.

It is the responsibility of the driver application to provide timing, input and output for the core, since the core will not handle those things on its own. The Core will have a few external methods, such as Render Frame, Render Audio and Execute, but it's totally ignorant in regards to what system it's running on and the application needs to take it from there. The Execute method runs one instruction at a time, reporting to the driver if any events occurred in the form of a bit-packed return value. If a fatal exception or VBlank occurs, for instance, the driver can respond accordingly.

The driver application I'll be making to go along with the core will feature such things as joystick input, the debugging features and a cheat engine. Oh, and a user interface. It will be "official" in that it is maintained alongside the core, but for now I don't think I'll be making its source code available.

Originally posted by Darkdata
Made a small change to the thread title.

Thanks! It was once NES, but is NES no longer.

GuyPerfect
Catgirl
Level: 68

Posts: 735/1096
EXP: 2665649
For next: 63151

Since: 07-23-07

Since last post: 1.7 years
Last activity: 219 days

Posted on 05-23-12 05:57:38 PM

Link | Quote

You know, I always thought LG to be an exceptionally competent company. Oh well, my mistake. At least it was only five bucks.

Someguy

Shyguy
Level: 23

Posts: 70/92
EXP: 64810
For next: 2913

Since: 07-26-07

Pronouns: he/him
From: California now!

Since last post: 4.4 years
Last activity: 8 hours

Posted on 05-23-12 09:30:00 PM

Link | Quote

I have yet to get a pair of 3D Glasses that worked exactly how I hoped. I wonder if a Virtual Boy emulator could adjust the exact colors of left/right eyes to work on such glasses, rather than only using black and white/red/red&blue?

Sorry if I don't have much feedback beyond that, I'm not too good at these kind of things since a lot of this is just going over my head. I'll just be cheering you on from the sidelines, perhaps.

I do wonder if the reason parts of the Virtual Boy are apparently more powerful than the GBA due to things such as screen size. I assume it has to render the full screen twice, one for each eye Nintendo 3DS style, possibly store a decent amount of alternate copies of tiles for left and right eyes, while keeping up the ability to pull of things like sprite resizing for things going into the distance and mode 7 style effects on both eye screens at a reasonable speed, as well as multiple layers.

GuyPerfect
Catgirl
Level: 68

Posts: 737/1096
EXP: 2665649
For next: 63151

Since: 07-23-07

Since last post: 1.7 years
Last activity: 219 days

Posted on 05-23-12 10:16:57 PM

Link | Quote

Originally posted by Someguy
I have yet to get a pair of 3D Glasses that worked exactly how I hoped.

To be fair, these were explicitly anachrome glasses, not anaglyph like the website falsely advertised. Anachrome deliberately lets some of the wrong light through so that pure colors won't be totally excluded from one eye, which I can confirm can be difficult to line up properly. For full-color images like Universal Pictures films on Sony Blu-Ray, I'm sure it works great.

Still, I wanted red and cyan filters, not partial red and cyan filters. I'll have to finish the job with acrylic paints or something.

Originally posted by Someguy
I wonder if a Virtual Boy emulator could adjust the exact colors of left/right eyes to work on such glasses, rather than only using black and white/red/red&blue?

If we've got all three primary light channels passing through both filters, there's nothing that can be done. It's 3D glasses fail.

Originally posted by Someguy
I do wonder if the reason parts of the Virtual Boy are apparently more powerful than the GBA due to things such as screen size. I assume it has to render the full screen twice, one for each eye Nintendo 3DS style, possibly store a decent amount of alternate copies of tiles for left and right eyes, while keeping up the ability to pull of things like sprite resizing for things going into the distance and mode 7 style effects on both eye screens at a reasonable speed, as well as multiple layers.

The system writes frames into buffers before displaying them on the screens. It's double buffered (for both eyes), so while one is being drawn, the other can be written to. As far as strictly 2D graphics is concerned (the parallax depth thing notwithstanding), Virtual Boy is the fanciest I've ever seen.

Originally posted by Someguy
Sorry if I don't have much feedback beyond that, I'm not too good at these kind of things since a lot of this is just going over my head. I'll just be cheering you on from the sidelines, perhaps.

Are you interested in learning? The community has a wealth of knowledge; I'm sure we'd be willing to help you out.

Posts: 4781/5390
EXP: 29075300
For next: 259705

Since: 07-22-07

Pronouns: he/him/whatever
From: RSP Segment 6

Since last post: 342 days
Last activity: 342 days

Posted on 05-24-12 12:49:48 AM

Link | Quote

Post #4781 · 05-23-12 07:49:48 PM

Originally posted by GuyPurrrfect
It will be "official" in that it is maintained alongside the core, but for now I don't think I'll be making its source code available.

Why not?

bsnes uses a similar design, doesn't it? A library that does all the actual work, and a user interface to it.

____________________

Programs

stuff goes here

Log out Shut down

Post #4781...[blag][Twitter][Freenet]

stag019

Red Koopa
Level: 26

Posts: 38/129
EXP: 91339
For next: 10936

Since: 09-11-11

Since last post: 5.6 years
Last activity: 2.1 years

Posted on 05-25-12 08:11:36 PM

Link | Quote

I'm sorry I can't provide anything useful, but this (and the Mario Tennis screenshot from the Wikipedia article) inspired me to make some simple converters for Red/Cyan 3D and left/right images. Here is the splitter, and here is the merger. These are optimized for Virtual Boy or Virtual Boy-esque images (4 shades of red [one being black isn't enforced in the scripts]). Greyscale is an option to greyscale the image before turning it red, which for example makes a Super Gameboy image behave rather well.

About forcing the 2bpp:
In the split script, forcing the 2bpp actually just makes the stereo image have 16 colors. In the merge script, it does enforce the left and right images having 4 colors, but they don't share the same palette.

Originally posted by VB Sacred Tech Scroll
(Editor's note: ...Also, these can supposedly be changed while the screen is being drawn to give the illusion of more colors, but that'd be tough as crazycakes to pull off accurately.)

The same thing could be done with CGA to switch palettes while in graphics mode.

Originally posted by Wikipedia
Through precision timing, it is possible to switch to another palette while the screen being scanned (drawn), allowing the use of any one of the six palettes per scanline. The best example of this in use is the game California Games when run on a stock 4.77 MHz 8088. (Running it on a faster computer does not produce the effect, as the method the programmers used to switch palettes at predetermined locations is extremely sensitive to machine speed.) The same can be done with the background color, to create the river and road in Frogger. Another documented example of the technique is in Atarisoft's port of Jungle Hunt to the PC.

So I don't see it being too farfetched...

GuyPerfect
Catgirl
Level: 68

Posts: 746/1096
EXP: 2665649
For next: 63151

Since: 07-23-07

Since last post: 1.7 years
Last activity: 219 days

Posted on 05-26-12 12:31:07 AM (last edited by GuyPurrrfect at 05-26-12 01:05:31 AM)

Link | Quote

I started implementing some arithmetic instructions, which led me back into the overflow flag. A little thinking and a little research, and I discovered the following things (as they pertain to two's complement representations):

Adding different signs cannot produce overflow.
Subtracting same signs cannot produce overflow.
Otherwise, if the operation matches the sign of the first operand (i.e. subtracting from a negative number) and the result has the opposite sign, an overflow occurred.

An example addition:

// Flags in the status register somewhere

unsigned char Z, N, CY, OV;



// Perform an addition of two 8-bit operands

unsigned char add_8bit(unsigned char op1, unsigned char op2) {

    unsigned char result,

        s1 = (op1 & 0x80) ? 1 : 0,

        s2 = (op2 & 0x80) ? 1 : 0;



    // Perform calculation

    result = op1 + op2;



    // Update flags

    Z  = (result)                  ? 0 : 1;

    N  = (result & 0x80)           ? 1 : 0;

    CY = (result < op1)            ? 1 : 0;

    OV = ((s1 == s2) && (s1 != N)) ? 1 : 0;



    // I'd comment this next one, but it kinda already is

    return result;

}

The results of the corresponding subtraction can be mimicked by simply passing -op2 to this function.

Originally posted by Renyan
Why not?

Eh, I have a few reasons to keep it to myself and not many to let the world have it. Feel free to change my mind, though: I admit I haven't put a great deal of consideration into it.

Originally posted by stag019
The same thing could be done with CGA to switch palettes while in graphics mode. [...] So I don't see it being too farfetched...

The main obstacle is the timing, like the article you linked/quoted points out. Not all of Virtual Boy's instructions have rigid execution times, so to try and time it that way is an exercise in futility. There's also the matter of adjusting the brightness at every 3 pixels maximum (to allow more than 3 non-black shades of red arbitrarily), which I'm not certain is possible on the hardware. There is a timer interrupt that I don't know much about, so it may or may not be doable to an extent through that.

I really need to get my hands on a system and wire up a custom cartridge to see what can be done.

EDIT:
Correcting an error with the overflow calculation. The logic I outlined in English is correct, but the implementation was bad.

stag019

Red Koopa
Level: 26

Posts: 39/129
EXP: 91339
For next: 10936

Since: 09-11-11

Since last post: 5.6 years
Last activity: 2.1 years

Posted on 05-26-12 03:03:34 AM

Link | Quote

Originally posted by GuyPurrrfect
I really need to get my hands on a system and wire up a custom cartridge to see what can be done.

That would be awesome. Good luck though.

The first Google result for a "Virtual Boy flash cart" costs $100 bucks (if you're buying one and not making your own), and you're likely to spend more on the system.

I also forgot to mention I've taken a bunch of these images and ran them through StereoPhoto maker to make .mpo's for my Nintendo 3DS. Some of them look great, while others make my eyes hurt immensely. I'm pretty sure that's one part of the reason the Virtual Boy failed (while the Nintendo 3DS, while a little straining after playing for a while, doesn't literally hurt with just one still image).

GuyPerfect
Catgirl
Level: 68

Posts: 748/1096
EXP: 2665649
For next: 63151

Since: 07-23-07

Since last post: 1.7 years
Last activity: 219 days

Posted on 05-27-12 04:33:10 AM

Link | Quote

Originally posted by stag019
The first Google result for a "Virtual Boy flash cart" costs $100 bucks (if you're buying one and not making your own), and you're likely to spend more on the system.

Pff, ain't spending that much on a flash card. I'd already decided to make my own. Mr. Tucker may have stopped half way through the software documentation, but boy howdy did he get his hardware diagrams in place.

Originally posted by stag019
I'm pretty sure that's one part of the reason the Virtual Boy failed (while the Nintendo 3DS, while a little straining after playing for a while, doesn't literally hurt with just one still image).

I believe the main reason Virtual Boy gave people headaches was because of how the screens were synchronized with each other. To reduce costs, rather than have a 2D matrix of LEDs for each screen, they only use single columns of LEDs which blink at such intervals as to reflect off of vibrating mirrors to create the illusion of a 2D display. There's one of these for each eye, which presents opportunities for depth perception.

However, to maintain balance, the screen vibrations are 180 degrees out of sync with each other. This means that while one screen is drawing, the other is retracing. This in turn means that while one eye is perceiving light, the other is not. Take this into context: you're looking at two images flashing into your eyes 50 times each second, attempting to focus on objects therein at varying depths, and all the while only one of your eyes is actually seeing anything at any given time.

Sails
2800

as a video game‎‎‎‏‏‎ grows old its content and‏‏‎ internal logic‏‏‎ deteriorateÿ
Level: 102

Posts: 2678/2803
EXP: 10922256
For next: 167711

Since: 07-04-07

Pronouns: He/Him
From: MA

Since last post: 120 days
Last activity: 28 days

Posted on 05-27-12 10:13:50 PM

Link | Quote

I got my Virtual Boy with stand and three games (Controller and power adapter too) for $20 two years ago...

(Off craigslist)

____________________

GuyPerfect
Catgirl
Level: 68

Posts: 757/1096
EXP: 2665649
For next: 63151

Since: 07-23-07

Since last post: 1.7 years
Last activity: 219 days

Posted on 05-29-12 06:53:24 PM

Link | Quote

Mr. Tucker, if you're ever reading this someday...

I thank you for your efforts in reverse-engineering Virtual Boy, and for your authorship of the RealityBoy emulator. It really makes these old games enjoyable in an age when Nintendo would rather forget about them. Due to your work, a short-lived era of gaming history is preserved and you will forever have your place as the man who cared when no one else did. I cannot understate the scope and significance of your achievements.

However... (You knew there was going to be one of these)

You didn't finish the job. You got the games up and running, and then you quit. There are many questions left unanswered, and many considerations left unaccommodated. There is more to making an emulator than merely getting games to run, but your documents and programming don't reflect that. Don't get me wrong: I am not angry or even disappointed, considering just how much you have done. I simply find myself unable to proceed with my own work based on yours; work which has been presented as nearly complete despite falling rather short of the goal...

I intend to complete the work that you started so that the mysteries of Virtual Boy may be laid bare once and for all.
__________

From the RealityBoy source: //could be done a lot better, later maby!

The emulator processes frames based on CPU cycles, then renders images and waits on the host machine accordingly. However, there's no way that's how the system actually operates: frames are double-buffered, meaning the display cannot be constructed from the source data while it's being drawn to the screen. All that would accomplish is a sort of automatic screenshot mechanism. What RealityBoy implements is a system with no frame buffering at all, which defeats the purpose of buffering and makes me wonder if the system can actually draw images using all of its available capabilities at once within the allotted time.

I do not have an answer to this question. All commercial games operate just fine as though the system did not use buffering, but I find myself uncertain of how it actually operates. I need to craft my own code and test it on the real system before I can implement that behavior in an emulator.

As such, I find myself in much the same position I was with NES. )-:<

But that's fine. I won't be turning my attention to another system: I'm going to master this thing. And the first step is to get one to stuff my eyes into, then make it dance to my little spells. The secrets it holds will be wrested from its grasp; of this I am certain.

Sooo...

It'll still be a few weeks yet before I get paid for my current job (freelancing), and I can't currently afford to put much towards resources in getting this system emulated properly. If there's interest in it, and if people have some spare change, then we can work something out... Halp?

Register - Login
Views: 99792331	Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies	05-03-22 04:47:06 AM

Query execution time:	0.079312 seconds
Script execution time:	0.048267 seconds
Total render time:	0.127579 seconds