[e5frog]

I was thinking about if it was possible to move a whole game to another position in memory. Taking a disassembly and place that after another game and then assemble all the code again…

I have done it with some Fairchild games and it worked out very well. There’s a good disassembler for Fairchild that also replaces all the real addresses with labels instead, so you’re free to move it to any place on the memory map.

If there are absolute addressing in the Virtual Boy game it will of course not work unless these are altered.

Then you could make a menu and have it jump to the right location. This would perhaps make it possible to place all the American released games on one 128 Mbit cartridge.

It looks like it’s possible to cram four 32 Mbit eproms in one cart, when looking at the FlashBoy circuitboard.

You would have to place the smaller games inside the empty space of the large ones to make it fit, but I know nothing about how this work. I have noticed there must be some header last in the cartridge rom, how will this be affected?

Alternatively you could cram all versions of the commercial games into two carts and top them off with the nicest and most practical homebrews. The homebrews would of course be a lot easier to move anywhere on the memory-map, right?

It would be nice if someone with a FlashBoy and programming tools as well as skills could make a test. Disassemble Mario’s Tennis and Panic Bomber, place one after the other in memory, add a tiny “menu” – it doesn’t even require any graphics, just wait for button A or B, pressing A jumps to where Mario’s Tennis starts and pressing B makes a jump to where Panic Bomber starts.

Assemble all of it and try it out…

Perhaps it could even be tested with Reality Boy. I guess the final rom-image of 1MB plus menu code has to be padded to a 2MB rom and header changed appropriately to work with FlashBoy…

Mario’s has a gap from $7DC90 to $75D5F, if there was only a jump added somewhere in the beginning to that address and the menu code was “hidden” in that free space and the final rom was shortened with as many bytes as that initial jump would take you could perhaps even make it work without padding – if run in Reality Boy, or add a 1MB game as well or two more 512kB games – so you could have four games on your FlashBoy at ones – or even more if you crammed in some of those small homebrews.

Possible? Feasible?

If the roms can be freely moved around in memory it seems both possible and feasible to me. It would simplify the hardware side of making a true Multi-Cart. Just put all of it on a large eprom or bank of eproms.

The other way to go would otherwise be a large memory of some kind, most likely not an eprom as there are none large enough at reasonable cost that would hold all games. So let’s say a SD micro card – it’s small, cheap cards will easily hold all available data for the Virtual Boy and there are already finished routines to read and write to them with both PIC-processors and Atmel AVRs.

Then some kind of memory that the selected program would be copied to, perhaps the same type of eprom that the FlashBoy has or if there is large enough ram…

A menu program would be loaded into the active memory when cartridge is inserted – unless it was permanently stored in some other small memory. In the menu you would choose program – in an automated list created by the micro processor after reading the file names of the contents of the SD micro card.

Biggest problem with the second approach is speed, it will take a little time to transfer the data from the card to the eprom/ram.

Any thoughts on this, any constructive critisism?

• This topic was modified 14 years, 11 months ago by e5frog.

[e5frog]

Found some disassembly tools, tried it on Mario’s Tennis…

vbasm seems to work

V810 Dissasembler v1.04 crashes:

Exiting due to signal SIGSEGV
General Protection Fault at eip=00006022
eax=00000000 ebx=00000000 ecx=ffffffff edx=00000073 esi=00001a10 edi=3a644924
ebp=00049c20 esp=00048850 program=D:\DOWNLO~1\–_VIR~1\DEV\DIS.EXE
cs: sel=01a7 base=029e0000 limit=0006ffff
ds: sel=01af base=029e0000 limit=0006ffff
es: sel=01af base=029e0000 limit=0006ffff
fs: sel=017f base=0000ff50 limit=0000ffff
gs: sel=01bf base=00000000 limit=7ffeffff
ss: sel=01af base=029e0000 limit=0006ffff

Call frame traceback EIPs:
0x00006022
0x00002f99
0x00002251
0x0000280a

Can I assemble the output of vbasm with vbasm – you would think that would work, right – noooo… There’s an uncommented adress first on every row that the assembler doesn’t like – rather than being placed commented after the opcodes…

EDIT: Removed the addresses, got errors on the first three “trap” commands, didn’t check all it stopped the assembly after too many errors.
I thought it was because of the address so I had to add 0x07000000 bytes in the front of the file to make it disassemble to 0x07000000… not too neat. 😉
Same problem though, won’t assemble the trap commands and perhaps other tings as well. It’s only a syntax error so perhaps it can be rewritten easily, I’m not phased into V810 assembler however so I don’t get it.
These disassembled rows produce a syntax error:

trap 000aea0 movea 28, $0, $10
trap 000f188 jal 03ff21b6
trap 0016a6c trap 0016a6e mul $27, $23

When using the 0x07000000 offset there’s ofcourse 0x07000000 more in the six digit address.

Aaa… there’s actually two rows of code on the same row… Three on the last one – disassembly error there then. 😉

• This reply was modified 14 years, 11 months ago by e5frog.

My mistake, the error appeared when I used a search and replace command to remove the addresses first on every row…

In short… no, you can’t move them around easily, especially because the tools aren’t particularly usable. You’d be lucky to be able to disassemble and reassemble the same file, mostly because the disassemblies aren’t completely correct.

It’s trying to disassemble both instructions and data, and some instructions are 16 bit and others are 32 bit, so unless you know the actual execution path and data/code segments (from running in an emulator or something), you’re not going to properly disassemble all instructions.

I’ll add more info when I get back home from work tonight.

DogP

[e5frog]

I guess things get a bit tricky if data and instructions are mixed, and the disassembler interprets everything as instructions…

I managed to remove the addresses correctly, but the disassembly doesn’t output the same binary when assembled again (surprise).

It’s 4764 bytes smaller and the binary files looks a lot like each other but there are scattered differences.

Is it really impossible to make a general disassembler whose code will assemble into the same binary file for the Virtual Boy?

The disassembler in Reality Boy is supposed to output used code when playing (apparently disabled in the current release build), but I guess it’s quite difficult to use all code when actually playing… so there will always be gaps. Some of them could be filled by checking where the graphics are, but there would probably still be gaps.

Too bad, I guess the SD micro card option is the most realistic then – if you want everything (or just several) on one cartridge.

It would be possible of course to crunch the games, place them on eproms and unpack them onto a 16Mbit ram or eprom, but it wouldn’t take all games anyway so it would be necessary to make several carts.

Are there any crunching routines available? If zipping Mario’s Tennis with the lowest setting it shrinks to 209kB instead of 512kB…

• This reply was modified 14 years, 11 months ago by e5frog.

Disassembly->Assembly is not impossible, but the current tools don’t do it. I started a “good” disassembler a while ago, but I haven’t gotten a chance to finish it (or even make it work properly). The disassembler really needs some smarts to figure out the disassembly, but since instructions are only 16 or 32 bits, there’s only two possible paths. So using some common sense, it should be able to make a good guess, and my disassembler used information from the emulator on whether a section had data or code, and what was the start of an instruction. I wasn’t trying to make a disassembler that could then reassemble though… I was just trying to make one that gave a correct disassembly, so I could further analyze the code.

And yeah… homebrews are much easier, especially since they can just be compiled to whatever location they want. I inserted my own app into empty space in a commercial ROM by telling the compiler that my code was in that space, put it in the ROM, then changed the reset vector to point to my app. Then my app called the address that the reset vector called to start the game.

Large flash media is definitely the best option if you want multiple games on one cart, though the VB is 5V and most devices aren’t, so you’d need to do the level translation. Then you’d still need 16mbit of Flash or RAM to extract the ROM on to.

DogP

SD and such would be more convenient, but it is much easier than that to make a multi cart.

Three options I see…

1. Use dip switches that are hardwired to the upper few address lines of your large rom/flash chip (or to the CEs of a few smaller ones). Advantage is it is real easy, disadvantage is you have to allow for each game to be the max size any game ever was, and have to hack your cart up.

2. Use a uc that is connected to the EXT lines. Then, put in your own program somewhere on the main ROM that runs your code. Once you select the game you want to play, the micro will control the upper address lines just like the dip switch did. It will be told what to do based on the info it gets over the EXT lines. Advantages are you don’t have to hack your cart up, it looks more professional, and you can have different sized games all on one cart. Disadvantages are harder to implement.

3. Put an FPGA inside that would convert real addresses to virtual addresses. Would work by getting instructions on the mapping in a similar way as the uc. By using an FPGA, you could make a cart that would let you load games at any spot you want on the rom.

I put them in order of my initial guess of complexity.

You may have put them in order of complexity, but I’d say the reverse order is the most realistic in implementation. A 2MByte flash chip is difficult to find, good luck finding one that can hold ALL ROMs (32MByte or so?). Then, unless you want to waste 2MBytes for all ROMs, you’d also need a switch for the 1MB and 2MB address lines to either connect it to the CPU controlled address, or to select upper/lower, then the rest of the upper lines need just high or low. That’d be really ugly (and nobody would want to flip all of them anyway) 😛 .

With an FPGA, you could have a large serial flash (or SD), and then large RAM or Flash which the ROM gets copied to, and then executed from through the FPGA. I could easily write the code for that, though the hardware would be slightly complex due to (probably) needing level shifting, voltage regulators, FPGA, RAM, Flash (FPGA configuration and ROM holder), (micro) SD, etc… all inside a VB cart.

DogP

All that work is probably better spent on a more compatible emulator, and all that money is better spent on an HMD with which to view said emulator. 😀

Heh, yeah… that’s why I haven’t attempted any of them 😉 . I have given it a lot of thought, but there’s really just no easy way. An FPGA VB cart would be really cool though, as it could double as a co-processor and memory manager.

DogP

In my Fairchild Multi-Cart I use plain logic chips and when a write to a certain adress (perhaps a write to 0x07E****** could be decoded for V.B.) occurs the latch is loaded with what is on the data line – and the latch outputs are permanently connected to the address pins of the relatively large eprom which would then swap to the selected memory slot.

There are also logic chips to decode the signal lines for when a reset is made – to reset the latch upon reset.

So, no strange stuff, no programmable circuits (PIC, PLD, CPLD, FPGA) or microcomputer.

A manually switched version would perhaps be the first step in such a setup. But I wonder how the size of the memory on a game is sensed? With FlashBoy it’s permanently set to 16Mbit – what sets it is it the actual connection of the address pins?

I think the problem using that method is to find cheap enough memory to fit all or enough games. There’s no reason for anyone to buy a cart with 4-5 games on for $100 when you can buy a FlashBoy for less and change games as often as you like.

So given the situation – I’m leaning towards a SD micro card solution.

There are enough 5V 1MB x 16 bit ram or eproms out there (haven’t checked the price though) to last for everyone that want a cart. The problem is rather if there are enough buyers to make it worth the effort and to get parts cheap enough. If you wanted to make new cartridge shells for example…

The microSD card is 2,7-3,6 V as far as I can see. If a microprocessor that can handle both 3 and 5V is used that might be a solution to the voltage problem. A small regulator is needed for the microSD-card unless it can be driven from an output of the µP.

If there are no such devices available a 5V µP should be used as there are less lines to level shift when interfacing the microSD card. Perhaps a simple voltage divider can be used for some lines?

I think I’ve drifted away from the subject, the answer to the question is probably not with the tools available today.

I guess I should make a new post…

I am using a 32Mb (aka 4MByte) flash chip that I thought was pretty cheap…

http://www.mouser.com/Search/ProductDetail.aspx?R=AT49BV320D-70TUvirtualkey55650000virtualkey556-AT49BV320D70TU

It runs at 2.7V, but it was made to work with 5V systems as well. I have not been able to verify that it works, but according to the spec system it should. You still need a voltage regulator, but it can handle 5V inputs and should output 5V as well (you put whatever voltage you want the outputs to be on one of the pins)

You can get larger ones in the same pin config, which is the reason I went with this one. Don’t have time to look up the other chips, but I don’t think the bigger ones are too much more expensive.

So SD would be cheaper for a lot of memory, but I mean, flash seems cheap enough to me.

You’re using a 32Mbit chip (linked) but you don’t know if it works? So you’re not using it on a 5V system then?

I read somewhere in the datasheet that the maximum voltage (even on N/C pins) was 4.1V.

Maybe a 512Mbit chip then, it would fit all 26 games in 16Mbit slots, and room to spare for a few homebrews.

http://se.mouser.com/ProductDetail/Spansion/S29GL512P11TFI020/?qs=sGAEpiMZZMuJXIph4YZFJYc5FqmmyEI%2f%2f2JaTqOrfEY%3d

The datasheet wouldn’t open so I couldn’t check details.

Just slap a big enough dip-switch and probably level shifters and a voltage converter.

… and you’d have to get a eprom programmer that could program it of course.

Then you’d have a single cart with all commercially released games.

I should say, I have a physical pcb in hand with everything soldered in place, but I have no programmer yet. So I am using the above chip, but I don’t know for sure it will actually work.

Anyway, I use a voltage regulator to power the chip at the appropriate voltage (I think I am using a 3V regulator).

Then I also tie the 5V from the VB to VCCQ, the output power supply. This allows my data output to reach logic level 1 for the VB.

And if you look at page 9, it says address and control lines can take up to 5.5V, and data lines can take VCCQ + 0.6V and output VCCQ – 0.1V.

http://www.atmel.com/dyn/resources/prod_documents/doc3581.pdf

So it should work with the 5V system just fine.

[e5frog]

Yes, you’re right, it looks like it would work just fine.

Are you going to have a switch on the highest address pin to swap between two slots of 16Mbit?

I wonder if we could fit seven 64Mbit chips of this type and an array of dip-switches. It would take all 26 games and have two slots left. One of them could be used for homebrews if these are recompiled and stacked with a menu in the lowest part of the memory.

How many homebrews are there (and which ones) that would be nice to have on a cart?

• This reply was modified 14 years, 11 months ago by e5frog.

Homebrew is at http://www.vr32.de/modules/games/?ht

And no, no switch on my design. Just a huge flash cart.

You could probably fit 7 of that package, but you would need a 4 layer pcb, and well I just don’t see the point. It would cost more than it would be worth. If something like that was going to be attempted, it seems like it would make more sense to try to use an FPGA and fewer flash chips. Or make a cart that actually has game save capabilities.

Strange, I wrote an answer here and it was saved and was actually in the thread when I reloaded the page. Last night I opened up the thread again and it was gone… back on this computer it was there again since I hadn’t shut down the page – but gone again when I reloaded…

Does this usually happen here?

This is what I wrote anyway:

There ought to be some interest in a multicart with all games, ging for 7 64Mbit chips would be one way to do it, one 512 Mbit chip would be easier though.

I almost feel like trying the 7 x 64 Mbit solution just to see if it can be pulled off on two layers. 😉

About the homebrews, not all of them would be really necessary to have on a non-changeable cart, like the Mario´s flying demo – perhaps not fun for very long.

Anyway. I think the initial question has been answered and to gather any interest and views in any other matters of the result of this discussion it’s perhaps best to leave this thread now and make new posts regarding other matters.

I think there’s been some problems w/ the site in the last day, so that’s probably the reason for the post funniness.

But if you’re thinking of trying a 7 chip cart, IMO, the best way would be to physically stack the chips and hand-wire the pin(s) that are different (since basically all pins are connected together except the /CS). It’d look ugly (and that way would be ugly), but so would the routing on a board with 7 chips all connected to the same lines. I guess you could also mount some chips upsidedown on the bottom of the board and use vias to connect the two sides.

DogP

Our host updated to PHP5 that night and that messed up some database tables, so I had to close the site until those were fixed. Nothing should have been lost, but that was probably the issue for the strangeness. Well, I hope it was and not some problems with PHP5. Let me know if this happens again!

About homebrews: also don’t forget that most of the very old ones, like Virtual Pong, don’t run on hardware at all, so you could let those out.

I guess you could also mount some chips upsidedown on the bottom of the board

The chips usually come in a reverse pinout version for this use.

I almost feel like trying the 7 x 64 Mbit solution just to see if it can be pulled off on two layers.

Go for it :thumpup:

It’s difficult to find chips at reasonable price that works right away, having to use logic level shifters as well is not very appealing. I haven’t looked into it – anyone knows if there are any small ones?
If going for a dip-switch version I guess it’s only needed for the address bus and possibly for a few of the enable pins and such for each chip.

I noticed when going through supported chips on my Willem Programmer that it does support one 64Mbit chip, however it’s only 8 bits which means I have to use an even number of chips.
This chip does also 5V I/O so that’s nice…

Cramming eight if these onto into one shell however…
There’s no apparent way to fit any chips on the back as it’s flat to the shell. Sandwich them would be possible… but I don’t know 24 pins on 12 mm – that’s two pins per mm – to bend down and attach to one just like it… Hard enough just to solder to the pcb (chip being 20x12mm)…

I could make two cartridges that holds all games, perhaps if I put all the sram-games on one cart and use a larger sram and switch that as well (with the same switches) it’s possible to keep the original functionality and there will also be room for some homebrews in there on both carts.

I have ordered a chip and adapter to see if it works, the eprom program says it was supposed to be a TSOP40-A3 (whatever -A3 is) but the ones I found was TSOP48 – so it’ll be interesting to see if it works.