It’s not an issue of being undocumented, it’s an issue of being undefined. When the destination string starts less than 64 bits after the source string, the output won’t be the same from one execution to the next.

Maybe you could simulate it by tossing a random number generator in there, but no matter how you slice it, you can’t match what the CPU is doing.

I must issue an apology to Mednafen. With regards to bit strings, even though its results differed from those on the Virtual Boy hardware, it didn’t implement them wrong.

I also withdraw my praise for RealityBoy. With regards to bit strings, even though its results matched those on the Virtual Boy hardware, it didn’t implement them right.

If anyone’s right or wrong, though, it’s me. I was wrong. Let me explain…

In my quest to know everything, I’ve just spent some time conducting extensive testing of the elusive bit string instruction. There’s a pretty solid behavior going on here, and it’s misleading, as this thread can testify.

Here’s the secret:

As it turns out, if the destination bit string begins after the source string, but by less than 64 bits, the result is undefined. As in, while it’s mostly consistent, some bytes will change between executions on the hardware.

And the truth of the overlapping behavior? When the destination string starts 64 or more bits after the source string, there will be feedback where a modified result is read back in as input.

The discrepancy deals with the way the CPU processes bit strings one word at a time rather than one bit at a time. Throw in further complications with the pipeline parallelism and the two-stage store buffer and it’s not surprising that problems arise when accessing data so close to itself. To play it safe, an emulator should–just as Mednafen does–process bit strings one bit at a time, feeding modified output back as input if the destination overlaps the source.

Overlapping bit strings where the destination is located *before* the source doesn’t cause any anomalies on the hardware, even with a distance as small as 1 bit. Bit strings that coincide don’t cause any problems either.

Er, right. Upper 31 bits. Only bit 0 can be written.

This thread reminds me of something, but I just can’t seem to put my finger on it.

retronintendonerd wrote:
Even if the light inside was also replaced to the same color as the lenses?

It’s not a simple matter of changing the bulb. The reason Virtual Boy is red in the first place is because that was the cheapest color to manufacture. Take a look at this:

That’s a photograph of the LED array that produces the images for one of the eyes (meaning there are two of these in the system). It’s a single column of 224 red LEDs, and they’re in total only about a centimeter long at most.

Changing the color of that isn’t something you can do with a soldering iron and big dreams. (-:

Passing red light through a purple filter will result in red light coming out the other side. You could alter the wavelength of the light with some unidentified metamaterial, but you’d have to sacrifice something in return, such as the strength of the light passing through the other side.

Attachments:

1. 

   vb_led_zpscaa71122.jpg
   

2. 

   metamaterials.png
   

The tech scroll has some more information regarding registers, notation and the calling convention:

http://www.planetvb.com/content/downloads/documents/stsvb.html#cpucallingconvention

Red-and-black has been long established as the Super Villain Color Scheme.

Never say never. Memory would pose a greater threat to SNES emulation on Virtual Boy than CPU power. Remember, just because whatever emulator might not be super-fast might just mean it isn’t written as efficiently as it could be. With the advent of JIT recompilation, we can emulate some pretty majestic stuff on systems that are only marginally more powerful.

I dunno, Earthbound doesn’t exactly push the system to its limits. You could probably emulate it on Virtual Boy.

3DBoyColor wrote:
Also, that VB programming guide. How accurate is it? Can I pull tech specs from it?

It’s approximately this reliable:

Use this one instead. It’s far from perfect, and I do have some pending updates to publish, but it’s more than reliable enough to utilize the hardware features of the system:

http://www.planetvb.com/content/downloads/documents/stsvb.html

I’d just say it can display three simultaneous shades of red with configurable brightness, personally. The fact that there are 128 practical levels is somewhat technical.

It’d be in groups of 4 columns of pixels, so not very useful.

3 shades of red at a time, plus black, out of 128 possible.

It’s effectively 7 bits of brightness. Games typically set register C to 0, and register B to twice the value of register A, which gave four equally-spaced levels of brightness for frame pixels.

As games often implemented software brightness controls and “fade to black” effects during transitions, individual titles most likely made use of the full range of brightness the system had to offer.

3DBoyColor wrote:
If 4 shades out of 32 is wrong, then how come it’s in the specs page here on PVB?

The specs page was inspired by this little piece of cheese, which says:

David Tucker wrote:
Four shades of red, at one time, from a pallet of 32 shades

The same document then goes on to correctly document the function of the brightness registers. |-:

Virtual Boy has three brightness registers, meaning under normal circumstances, it’s black and three shades of red. The registers can be assigned arbitrary integer values, which correspond to brightness. There is a couple quirks, however:

* Though the registers are 8 bits, testing shows that values above 127 don’t appear to increase the brightness, yet risk emission overtime.
* While registers A and B use their assigned values directly, the final brightness value for register C is A + B + C.

In practice, one could consider this a “palette of 128 shades” of red, although that lingo doesn’t reflect the semantics of what’s going on. The brightness value is used as an actual measurement of time for the LED to emit light, where longer emissions have greater apparent brightness.

The scanning hardware also has a “column table” that stores records regarding the amount of time to emit for each set of 4 columns as well as a brightness multiplier. Again, technically, the multiplier is in fact the number of times to emit light during each column’s pixel period, but the apparent effect is multiplying brightness.

Case in point, the intro cinematic for Wario Land uses non-uniform values for brightness in the column table, which gives it that “fading out on the sides” effect:

If every group of columns had a different repetition parameter, one could technically get 128 different shades of red in addition to black in the same frame.

Furthermore, the brightness registers can be modified during frame rendering, though since VIP operations depend on the work that needs to be done, it’s impractical to try and time it that way. Still, though, it’s possible. I don’t know what limitations are actually in place, but as far as I know each group of 8 rows can have different brightness values assigned.

Attachments:

1. 

   wariofade_zpsf65d5e74.png
   

3DBoyColor wrote:
4 onscreen reds + black, out of a 32 red palette).

Waaaaaaaaaah! *Sobs*

The Virtual Boy can display black and 4 shades of red onscreen out of 32 possible shades.

This is inaccurate enough to make me cry, and I know exactly the source where the author got this mistaken information. It needs to die in a fire.

Mkay then. It’s been two weeks, and nobody went for the ROM module. Not that I expected anyone would, but I figured I’d toss in something easy just in case someone wanted to step up to the plate. (-:

On that note… The cartridge!

Three Times the Charm

Of the eight sections of the memory bus, three of them are allocated to the cartridge:

* 7 = Cartridge ROM
* 6 = Cartridge RAM
* 4 = Cartridge Expansion

7 – Cartridge ROM

ROM is, by definition, Read-Only Memory. The intent is that data that should not be changed, such as program data, be unable to be changed in order to prevent corruption. It also typically means cheaper circuits, since writeable memory is more complex than memory that can only be read.

Per this thread, I don’t want to try and support All The Things™ in some feeble attempt to foresee the future. I’ve decided the best way to keep this project going is to just implement something that makes sense, and if at some point we develop new hardware for Virtual Boy, we can update the emulator accordingly.

Writing to a ROM address won’t do anything. On older systems such as NES, where 32KB of ROM addresses are allocated, additional ROM banks could be selected by configuring mapper circuits in the cartridge itself. This was done by writing into ROM addresses, but did not in and of itself alter the data at those addresses.

6 – Cartridge RAM

RAM stands for Random Access Memory, which doesn’t make a lot of sense. It has to do with those really old tape storage devices where in order to read from whatever byte, you had to seek forwards and backwards, making it a slower operation and efficient code would read sequentially when possible. “Random access” refers to the ability to read any arbitrary byte without any overhead.

Anymore, the term “RAM” is used to refer to memory that can be written to and used as scratch memory for a program. On NES, where 2KB of system memory is available, it was useful to have cartridge memory because that had 8KB of addresses allocated to it, and many games did use cartridge RAM as scratch memory.

Typically, cartridges with RAM (both NES and Virtual Boy, and a great many other devices) had some means of preservation–usually a battery. This made it so that the memory stored in the cartridge was still there after powering off the system. And that was instrumental to the art of the save game.

4 – Cartridge Expansion

Wait, if ROM is 7 and RAM is 6, wouldn’t expansion be 5 instead of 4? One would think so, but system RAM got the 5 slot on the bus. This makes me think that the cartridge expansion section was added in as an afterthought once the initial memory map was drafted.

What’s it for? Anything you want. Maybe a game needs more than 16MB for program data, and uses the expansion area as another ROM bank. Maybe the cartridge contains some audio hardware (the audio signal passes through the cartridge before going to the speakers) and the expansion area accesses the control registers. Maybe… maybe… well, you get the idea.

As no known hardware exists at this time that uses the cartridge expansion area on Virtual Boy, we don’t need to supply a driver for it. It can remain with those dummy memory access handlers. (I’ll have to double-check to make sure values read from this region are indeed 0x00)

Mirroring and You

For an address range to be mirrored means that it can be accessed by more than one physical address. In the case of the VB’s memory bus, which is only 27 bits wide, the value of the upper 5 bits is meaningless. 0x00000000 accesses the same memory as 0x08000000, 0x50000000 and 0xF8000000.

Addresses within cartridge ROM and cartridge RAM are likewise mirrored: memory circuits must be some exponent of 2 bytes in size. That is to say, they must have some exact number of accessible bits. The reason for this is that any bits above the readable portion are, like the system bus, meaningless and produce mirrors of the lower addresses.

The reason for that is part of the V810 specification: The address of the first instruction to be executed by the CPU after a system reset is 0xFFFFFFF0. Thanks to address mirroring, provided the ROM is some exponent of 2 bytes in size, the address 0xFFFFFFF0 will always be the sixteenth-to-last byte in the ROM.

Consider Wario Land, which is 2MB in size, which in turn is 21 bits out of the 24 available:

* System address 0xFFFFFFF0 loses its top 5 bits to produce a mirror of 0x07FFFFF0, which is in the cartridge ROM area.
* The remaining bits, 0xFFFFF0, lose the top 3 bits to produce a mirror of 0x1FFFF0, which is the sixteenth-to-last byte of Wario Land.
* Therefore, system address 0xFFFFFFF0 maps to ROM address 0x1FFFF0 after all mirroring takes place.

While it’s not strictly a requirement, RAM also typically mirrors. I don’t know about commercial games, but the FlashBoy Plus at least has 8KB of memory (13 bits), and testing has shown that it does mask off bits above that and produce mirrors.

Local File Data

A file needs to be loaded for cartridge ROM, and a file will need to be loaded and saved for cartridge RAM.

Ta dah! The shortest section you’ll see in any of these posts. (-:

The Code

Changes to the code include the following:

* Cartridge RAM and cartridge ROM APIs implemented in ramrom.c
* System WRAM also implemented in core.c

Tauwasser wrote:
If you’re keen on distributing everything on one file, then create your preferred file format(s) and zip them together with the ROM. Problem solved.

This is the idea I like the best. MAME does it this way, and as MAME can testify, a given game can have a lot of little ROMs depending on the system hardware. That should be more than sufficient in all cases, and a manifest can be supplied when/if necessary.

Tauwasser wrote:
However, what you’re proposing is essentially butchering the ROMs respectively adding an iNES-type of header.

That’s exactly correct and exactly the intention. Doing it that way pairs the ROM with its respective metadata, and avoids the issue of attempting to keep a comprehensive database of Virtual Boy software somewhere. The meta data simply must be included with the ROM data in order to be useful.

Even what Higan does with its games database doesn’t solve the problem I see when someone distributes or receives a Virtual Boy program, but the emulator doesn’t necessarily know what kind of hardware it was intended to work with. That’s why I strongly feel that the metadata needs to be in the same file with the ROM.

I do a lot of experimenting, we’ve got a fair amount of homebrew, and someday we might even do some manufacturing. It’s simply not practical to try to keep a running bank of everything all the time.

Tauwasser wrote:
Representations change, knowledge changes, requirements change etc.

My proposal fully supports arbitrary representations and affords the additions of new features at a later date without breaking compatibility. I understand the dangers of making assumptions.

Tauwasser wrote:
But please, don’t invent some custom ROM header format that will get spread for no good reason and become out-dated once the first real-world mapper application is developed and being emulated.

That’s why I made this thread; to keep that from happening. (-:

Though again, my proposal isn’t something that can become outdated because there’s no rigid format that makes any assumptions about the software contained within the ROM file.