Hi,

So I’m just wondering if there are actually any schematics at all for the Virtual Boy and its cartridges out there?

I can fing semi-decent information on the cart connectors, although the info is a little shaky.

        _____
     GND | 1  2| GND
     #WE | 3  4| #ES
   #RST? | 5  6| #RAM_CS1
 RAM_CS2 | 7  8| VCC
 #INTCRO | 9 10| A22
     A18 |11 12| A21
     A17 |13 14| A20
      A7 |15 16| A19
      A6 |17 18| A8
      A5 |19 20| A9
      A4 |21 22| A10
      A4 |23 24| A11
      A2 |25 26| A12
      A1 |27 28| A13
      A0 |29 30| A14
 #ROM_CE |31 32| A15
     GND |33 34| A16
     #OE |35 36| VCC
      D0 |37 38| D15
      D8 |39 40| D7
      D1 |41 42| D14
      D9 |43 44| D6
      D2 |45 46| D13
     D10 |47 48| D5
      D3 |49 50| D12
     D11 |51 52| D4
     VCC |53 54| VCC
 RSND_IN |55 56| LSND_IN
RSND_OUT |57 58| LSND_OUT
     GND |59 60| GND
          ¯¯¯¯¯

This is what I found on most web pages and for instance in David Tucker’s guide.

[list]
[*]Pin 5 is apparently not guaranteed to be reset (I assumed low-active).
[*]Is there no external clock or data/address line stable signal?
[*]Are all VCC/GND pins connected to the same source on the Virtual Boy side, or if there are maybe two or more power rails for VCC?
[*]Are all VCC/GND pins guaranteed to not be some digital value that somebody who tested the pinout mistook for VCC/GND?
[*]Do the data bus/address bus/interrupt lines use internal pull-ups or will they float?
[*]Why are both chip selects for RAM provided? Usually I would have assumed that one of the two chip selects would be controlled by the battery backup IC (MM1134, MM1026) – as is the case for Game Boy — and not both be available from the CPU.
[*]This leads to the question what a typical SRAM access/expansion area access would actually look like. Are both CS pins asserted at exactly the same time? Are the CS pins actually asserted for expansion area accesses at all?
[/list]

————————————

Also, is there anything known about the encoding of the PCB names? The DMG (Game Boy Classic) PCBs follow a strict set of rules.

So far, I have only seen VUE-AA-01 and VUE-AA3A-01 mentioned.
Interpreting them like the DMG codes:
VUE is obviously the VB, the -01 are revisions, where the first digit is hardware revision (0-based) [add/remove components) and second digit is mask revision (1-based) [move components, re-route tracks].
The DMG uses 3-to-4-letter codes, where the first is the mapper (and battery), second is ROM size, third is RAM size and last is ROM package (oddly enough…).

This doesn’t seem to apply here in that matter though. The DMG codes are also letters-only, not alphanumeric.

So I summarize what I suspect:

VUE-XXXX-NN
 |  |||| ||
 |  |||| |#- Mask Revision
 |  |||| #-- Schematic Revision
 |  |||#---- RAM size
 |  ||#----- Battery/something else/???
 |  |#------ ROM size
 |  #------- Mapper
 #---------- Virtual Boy-related PCB

code   | Mapper | ROM size          | ???  | RAM size
(none) |   -    |     -             | none | none
  A    |  none  | 16 Mbit (1M x 16) | ?    | 64kBit (8k x 8)

————————————

So is this information (first part of my post) documented somewhere in its entirety? I looked through multiple guides, the developer handbook etc. But most official guides mention anything hardware-related at all. And most other sources seem to be blatant copies of David Tucker’s guide.

cYa,

Tauwasser

EDIT: I had to replace \ backslash with #, because apparently \ backslash is filtered even in code tags.

*bump* Seriously, nobody :(?
Maybe I should have separated my questions into separate threads?

cYa,

Tauwasser

Chillax, dude; we can’t all check PVB every day 😛

1. Pin 5 is the (active low) write strobe for the expansion and (I believe) ROM areas.
2. No clock lines, but the chip select/output enable lines should serve as “address stable” signals, no?
3. AFAIK, there is only one VCC rail connected everywhere.
4. I think pin 7 is actually just a VCC line, but I’m not 100% sure.
5. I think DogP said that the address/data lines (at least) will float high when not driven.
6. See #4
7. I don’t have any timing diagrams, but some of these are obviously going to be based on the settings in the NVC’s on-board wait-state generator.

I have no idea about that cart PCB marking stuff. Does anyone have photos of the cart PCBs? The only ones I have are of a development flash cart, and it doesn’t use the above code system.

Now I’m interested in why you want this info! 😉

Hi,

thanks for responding 🙂 “Chillaxing” a bit more now 😉

1. Haven’t read that info anywhere until now. Shouldn’t the regular \WR signal be enough for those purposes?

So \ROM_CE + \WR = Write to ROM
And \ES + \WR = Write to Expansion

I mean, I get that they might have split those two up – however, there doesn’t seem to be an immediate need to do so.

2. Depending on the access timing, yes, I suppose you’re right.

Check this out. Basically, imagine that the Game Boy only has a \RAM_CS, which changes when the address changes. So the combinatorial logic inside the mapper (Memory Bank Controller; MBC) will switch depending on the address bits, thus consuming power. However, when pin2 is low, all lines are always stable – so no switching and no unnecessary power consumption/sram chip selection etc.

Basically, on GB something like this might be happening: (X and >< are bus changing data, different timing for illustrative purposes)

CLK  |¯¯¯|__|¯¯¯|__
\CS  ¯¯|____|¯|____
ADR  ==><======X===
DATA ==><======X===

If the virtual boy only selects after lines are stable, then that’s a good thing :)

However, some “modern” MBCs also use this as a clock line for a 4.1943 MHz/4 clock. I think that turned out to be a very beneficial happenstance for the Game Boy.

3. Ok, that’s what I assumed anyway.

4. Hmm, it’d be terrific to know that for sure. Before connecting to some component that has a low-active CS or somesuch.

5. That is unfortunate :-/

7. Yeah, I wondered about the CPU operation anyway. It is apparently a V810 operating in 16-bit fixed mode?
A quick glance in the various data sheets seems to indicate the timing is fixed.
However, I don’t really know where the individual chip select signals come from, so it’s kind of hit-and-miss looking at the timing diagrams.
The Game Boy for instance uses the highest address bit as a chip select for ROM – however, the V810 \BE0 and \BE1 are both pulled low for during byte and 16-bit word operations, so I guess they didn’t just connect \BE0 to \RAM_CS and \BE1 to \ROM_CS. Or maybe their CPU is so custom that the regular datasheet doesn’t apply at all in that regard.
Couldn’t find a pinout of the Virtual Boy CPU either to confirm this suspicion.

—-

As for cart markings. I looked for pictures of actual cartridges in vain. Only some crude block diagrams on the goliath industries website.
My own cartridges are currently at another place, so I cannot just open them up and take some pics. I plan to do so in the future, though. I’d also make detailed schematics while I’m at it ;)

I’m just interested in the code system, because the codes usually encode all important info for mapping the connector to ROM/RAM/etc. Also, it’d be good to document this :)

As for the hardware info. Well, I owned a FlashBoy for a long time, but haven’t been able to get started (yeah, what’s a student earning a degree supposed to do…). Also, lately I have become really interested in hardware engineering, so I thought it’d be a good exercise to document the VB carts, build a dumper, that sort of thing.
For the Game Boy, relatively much info is known. I reverse engineered the cartridge naming scheme for that, collected PCBs, made schematics, dumped games, etc. :)
So I just wondered what the Virtual Boy is like in comparison to that.

cYa,

Tauwasser

Hi!

First of all, sorry for bringing an ancient thread back, but was tackling with making a simple EPROM + SRAM cartridge, and I am not very sure on the pinout nor the schematics… and I do not own one with save functionality that I can trace.

I have fallen in this URL (http://www.goliathindustries.com/vb/VBDiagrams.html), but given the pinout provided by Tauwasser in the first post, the connections on the Edge connector are not obvious to me… I do not get what are the connections outlines at the three last lines behind the Edge connector title in the 3D Tetris cartridge schematics, thus, I do not understand where to connect things.

Anybody knows the correct pinout, or rather correct interpretation, of…

3 – 26, 27 (U2)
6 – 26, 20 (U2)
7 – 25 (U2)

I may be sleeping too little, but I do not get those pin correspondences. What are the first column, second column, and third (if present)? For the first and second lines, to me it seems as if it were a shortcuit with that 26 in common, and so a shortcircuit between all those pins (3, 26, 27, 6 and 20, wherever they beong too), which does obviously not make any sense.

Any help is much appreciated,
3L_S4N70

I think that URL contains erroneous information (it’s quite old). For one thing, it doesn’t indicate how the /OE pins need to be wired; if you don’t have those hooked up, you’re not going to get anything on the cartridge bus. Going by what https://www.projectvb.com/vb/tech/cartpinout.html says, I think what you’re looking for is the following:

Pin 3 on the edge connector is the /WE pin for the “RAM” area on the cart.
Pin 6 on the edge connector is the /CS pin likewise.
Pin 7 on the edge connector is the /RESET pin from the V810 CPU.

Pin 3 on the edge connector should be wired to 27 (/WE) on U2. Pin 27 on U2 is active low, so when pin 3 on the edge connector goes low, /WE goes low (active) on the RAM chip,

Pin 6 on the edge connector should be wired to pin 20 (/CS1) on U2. Pin 20 on U2 is active low, so when pin 6 on the edge connector goes low, /CS1 goes low (active) on the RAM chip.

Pin 7 on the edge connector should be wired to pin 26 (CS2) on U2.

The V810’s /RESET pin is active low, so according to the datasheet for the HY6264A SRAM chip, the above pin assignments mean that CS2 should be active as long as the VB is running, i.e. the SRAM chip is enabled during normal operation. Pins 3 and 6 enable writing to SRAM when both are low. The aforementioned datasheet suggests that /CS1 should go low before /WE, but I don’t know how the VB actually behaves in that respect.

Thanks a lot blitter for the great explanation, now things make much more sense, haha.

I have to tackle with a Virtual Boy that supposedly resets itself when pressing down on the right DPAD (have not been able to reproduce this on a 5 minute play of Mario Tennis), but if everything goes ok with it, I will start developing a simple flaschart with SRAM.

Have a great day!