RunnerPack wrote:
Actually, while that may be true on a standard V810 bus, are you sure its applicable to the VB? The address masking alone shows how much Nintendo messed with the V810 when they made the NVC. I don’t think there is a way to access individual byte addresses on the cart, since there is no A0 line (which is why the upper bytes read from cart RAM have to be masked off). I do believe the pinout on the Wiki is correct, though, according to information gathered by David Tucker and DogP while testing the actual hardware (and, obviously, the Flashboy+ works ;-)).
Since I checked the pinout and contributed to it while working on my dumper (which also works correctly), I, too, assume it to be correct.
Notice how I didn’t say the SRAM was byte-addressable — merely byte-accessible. You still have the byte aliasing.
However, I see no point in Nintendo screwing with the write strobes as they are used like the documented counterparts on the WRAM chips.
I didn’t find any substantial research into this. As a matter of fact, I found very little research into any of the hardware in the homebrew scene. Sure, code will work without knowing this specific piece of information.
However, I’d like to think that it operates just the same as 16-bit fixed mode, Table 5-2 in the official μPD70732 data sheet.
Until somebody comes up with better information using a test program and a logic analyzer/oscilloscope this is moot, however.
RunnerPack wrote:
Now it seems like you want to use the cart SRAM (i.e. save-game RAM) space for the SRAM, which would require modifying the ROM or retargeting the compiler. Am I close?
No. Merely have this register somewhere accessible and it will switch between enabling the ROM (for your bootstrap code) and SRAM in ROM space — or any space you want, really.
The register itself could be in either ROM, SRAM or EXPANSION space for that matter.
However, you could also simplify this circuit quite a bit by just being a register and executing the code from WRAM, so you don’t need a delay if that is what concerns you.
You’d read the appropriate code beforehand, write it to WRAM, then jump to it. You could then even build the register to selectably turn SRAM on/off at will, which might help with programming if you need to access data in your bootstrap ROM in-between.
This might even be better for programming anyway.
RunnerPack wrote:
As an aside, what do you normally use instead of Eagle
On other occasions, I have used the industry standard software package Altium. I thought doing this in Eagle might help me get started, but it was really painful :-/
RunnerPack wrote:
I just did a quick check, and your parts list comes to quite a bit more than the cost of many of the ATtiny chips (only checked Mouser, though).
I only checked Digikey, but made sure to look for prices at low quantities.
However, I caution you not to use a software solution for this. IIRC, the bus accesses are done at 20 MHz, so you will have to have quite efficient code and a really fast clock to do this in software.
Apart from that, there is also no need for a software solution for this problem.
cYa,
Tauwasser
Attachments:
RunnerPack wrote:
Would you care to apply your 1337 logic haxx0ring skillz to that problem?
Don’t patronize me.
cYa,
Tauwasser
RunnerPack wrote:
Tauwasser wrote:
Dude, a 4-bit register would suffice for this.Do you have an actual part number for this? It sounds like you’re talking about a quad D flip-flop.
I am talking about a quad DFF, specifially one with clock and write enable. Four bit counters have this option and are cheap.
I picked up the line “in shift register configuration” somewhere and it stuck. Yes, it means connecting the outputs to the next input. However, I did not explain in too much detail what I actually meant, my bad.
The purpose of not using a dedicated part is to be able to adjust the bus access cycle delay.
So you can either have byte and half-word access to only half-word access, or only word-access to our register.
RunnerPack wrote:
What does #LWR mean? I assume you mean the ROM/EXP write strobe, pin 5. What is the purpose of doing this?
It’s the write strobe for the least-significant 8 bits on the data bus. The meaning is the same as for the WRAM chips. You could also use #UWR if you so wished (only half-word/word access then). Look at this Wiki page where I updated the signal names and corrected the pinout.
It’s /WE0 and /WE1 respectively. I doubt the table is correct, because the write strobes don’t really depend on memory ranges but on bus configuration and width of write/read access. Which is why I stick to #LWR and #UWR.
RunnerPack wrote:
Where on the boot ROM does Q_A connect? #CE?
Yes. And with some logic in-between to accommodate safe power-up the other output will go to SRAM.
RunnerPack wrote:
IMO, switching between the ROM and the SRAM shouldn’t be based on a pre-determined number of read cycles. For maximum versatility, it should be totally under the control of the software running on the VB.
It is totally under control of the software. You write to anywhere in the ROM region, either byte-wide or half-word-wide (so we have one bus access cycle). Then you jump to the reset vector of whatever you just wrote into SRAM.
You will have to bridge the delay
– from writing to our register,
– reading the JMP instruction — one bus accesses in instruction format I,
– executing the JMP instruction
Instruction cache will have to be off for that, but I image it will have to be off either way or you risk data from your bootstrap being used in place of program instructions?
An ugly eagle drawing will suffice:
(This is the first time I used Eagle – and I hope it’s the last time…)
Gating logic could be for instance 74LVC1G57 + Transistor + Pullup Resistor. Take 74HC161 for the 4-bit synchronous counter with asynchronous clear and we’re looking at part costs of about 1.50 USD with no special programming equipment and no concern for high-voltages needed for PALs/GALs that would kill our other parts.
cYa,
Tauwasser
Attachments:
It could be done with discrete logic, but a more compact (and likely cheaper) method would use some kind of programmable logic chip.
Dude, a 4-bit register would suffice for this. Just
– configure it as a shift register,
– have asynchronous reset connected to the #RESET line,
– clock connected to #ROM_CE, and
– parallel load connected to #LWR.
Then either make the input A a static ‘1’ or D0 or something. The output Q_A goes to the boot ROM.
You should then use a little logic gate to invert this enable signal for the SRAM chip: tie the SRAM CE to deasserted state when #RESET is asserted to protect SRAM from spurious writes during powerup.
Overall though, I think slapping an FPGA on a cart with some modern memory is the way to go. If I had time to finish projects, I’d just build a real cart like I prototyped up a few years back
An FPGA would be an excellent expansion lol. However, I do think an FPGA/CPLD for this kind of project would be overkill 
cYa,
Tauwasser
Hi,
I’d say it’s definitely better now as forums seems to stay read.
However, marking all forums read on the main forum page shows all forums as grey, yet I have had the “Virtual Boy Development Board” and the “PVB Coding Competition 2013” boards show up with unread topics once I clicked on them.
I marked all forums read individually now and that seems to have worked for now 
Thanks,
Tauwasser
取得日 – data of purchase?
No idea on the second one, it’s just too blurry
cYa,
Tauwasser
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
DanB wrote:
ehm… you can play almost any videogame system in the dark, except for the original gameboy/color/advance(pre SP)
There were backlit gameboys Just in Japan, tho. But you can import one, if you really want one.
Game Boy Light is the mono-chrome backlit Game Boy Pocket derivative.
cYa,
Tauwasser
jzagal wrote:
It’s the real deal by the firm who does all hardware debuggers for BigN.
Really? I assume they’re the same ones that have done a bunch of games for Nintendo platforms as well? (ie Galactic Pinball for VB).
In other words…these guys:
http://en.wikipedia.org/wiki/Intelligent_Systems#Virtual_BoyI’m surprised there’s no mention of hardware debuggers on the Wikipedia page…someone should update that!
Oh, they also program the DevKits. They supply code and hardware. Here’s a quick google for their game boy color hardware debugger: http://devkits.handheldmuseum.com/IS-CGB-EMU/index.htm
They also programmed software emulators for SNES and stuff. Being the internal dev guys for Nintendo must rule 
cYa,
Tauwasser