Tuesday, May 25, 2010

Johnny Mnemonic released for Mega-CD

Good times!, lot's of prototypes getting released these days.

Some words from the dumper:

" I'm sure somebody will enjoy the cheesy story and cumbersome game play. It seems like a pretty complete game though it lacks a title screen and the game starts in what seems to be the middle of some plot with Johnny saying "YOU LET ME SLEEP?!!" to some chick. If you don't know how FMV games work, (like I did.) Then you will probably die a lot in this game. It forces you to use your brain to solve insane life or death situation puzzles. I've made it to I think stage 2 and it involves a subway that is really annoying to beat. The scene right before it involving the chick fighting the Japanese dude in hand to hand is pretty fun too.

Oh, and the game uses back up Ram, so if you burn it to a disk be aware of that if your Sega CD is low on memory. If the memory gets full, it could mess up saving of other games. (games like Sonic CD may not be able to load save files if Ram is full. As a result, loading a game will just give you a black screen. Just speaking from personal experience.)

Another note: I'm not sure if the video is fully emulated properly. It just seems to look worse than on actual hardware. Like it was semi corrupted some how. I'm not sure if this is emulation related or a result of it being dumped badly. The important thing is that it at least runs without any other problems on Fusion. Someone should burn it to a disk just to be sure everything works properly.

Have fun,
Download Johnny Mnemonic CD1
Download Johnny Mnemonic CD2

Wednesday, May 19, 2010

N64 Gameshark homebrew loader.

"This is a n64 homebrew loader I'm working on. It uses a modified version of HCS gsupload, along with an embedded MIPS binary in the windows executable that gets sent to the n64 when loading, whole lot of patching, still a lot of work to do. In the video you see it running the loader and communicating through a custom serial interface using raw gameshark 3.3v parallel port access, and me using that access to send keypresses. The video capture card I am using has delay, and I have my transfer timeout delay set really high, which is why it takes so long to load, and also why the video moves so slowly.

Devsters genesis/megadrive homebrew uploader tool.

"In a world where every girl wants to become a model, there is LAKABAJO. LAKABAJO is the name for a system that Devster devised to load executable 68k code onto a Sega Genesis console without using a flash cartridge, or any kind of cartridge with programmable memory.

In the past, rich developers had to pay thousands of dollars for official licensed development kits to develop Sega Genesis games. In the last decade, poor hobbyists had to pay $50 for an unnofficial flash cartridge from Hong Kong suppliers to run tiny chunks of code on the Genesis. Today, poor developers won't need to pay a dime (joking, at least $20) to get their code running on the real hardware.

Basically, this uploading system works by using a controller exploit in games, in combination with a Game Genie game enhancer. The Game Genie codes are automatically entered for you using the uploader program. The exploit running on the console loads a data from the controller port, into the Genesis work RAM. The exploit then starts execution from work RAM."


Tuesday, May 18, 2010

Shigeru Miyamoto on Swedish tv

Short interview from Swedish tv that I slapped some English subs on.

If anyone has that Janguru taitei 64 proto then dump it:P.

Sunday, May 16, 2010

First Queen web site/flash port.

Kure Software Koubou has made a full flash version of their X68/PC98 rpg game First Queen, check it out here: http://www.kure.sakura.ne.jp/FQ1AS_0/index.html

Friday, May 14, 2010

Hidden palace proto flood.

Hidden palace has released some more protos for Megadrive/Saturn , grab them Here and Here
Crypt Killer (Prototype - Jan 8, 1997)
Duke Nukem (Prototype - Sep 18, 1997)
Fighters Megamix (Prototype - Apr 08, 1997)
Fighting Vipers (Prototype - Sep 06, 1996)
Loaded (Prototype - Sep 3, 1996)
Primal Rage (Prototype - Feb 12, 1996)
Sega Rally Championship (Prototype - Oct 31, 1995)
Slam N' Jam 96 (Prototype - Feb 1, 1996)
Ultimate Mortal Kombat 3 (Prototype - Feb 07, 1996)
Virtua Racing (Prototype - Oct 30, 1995)
Winning Post (Prototype - Dec 27, 1995)

Source: http://www.hidden-palace.org/?updates/c/33

Tuesday, May 11, 2010

Capped some N64 demos.

Sadly I only have a crappy easycap that can only do PAL50 so the demos aren't capped at a perfect framerate but it will have to damn do!


Saturday, May 8, 2010

Doctor V64 faulty bios recovery.

Haven't used this one myself but I guess it can be of use to somebody out there.

"How to re-enable a V64 faulted in Bios upgrade to upgradable :

1. Use tpc download from PC or load from a CD let the bios file (can not use a name likes 'v64_verx.xxx', for example named it 'biosv174.v64') loaded into V64's DRAM.

2. Use tpc download from PC or load from a CD let the run file 'biosup.r64' loaded in V64's system ram and run it by press any key except the 'Stop' key. After that your Bios can be upgradable again.

Remark: Please upgrade to Bios V1.74 or later versions to prevent the faulty problem of unable to upgrade."

How to make a N64 game trainer.

Another nfo that might be handy for people who want to make new trainers for games that never got any trainers back in the day.

___\ /___
:_) (_:
| | .
| +{N64}+ | |
| | _. . thE LiGhtFoRCE - FAStER thAN LiGht .
| ____ | .___)| siNce 1987
: ______ \__/ :______ | |____ ____ _________ __ ________ _____ ______
. \ /_____./ __/__| | _| \.) __/ _ \_ / _/ __/_
. / / | _) | _ \_ | _/ \ / /. \_. _/ |
: \__________|____\ ___|____| |_____|____|________\_____|______|_______|
| : \/ -Mo!/aL|____|[C O N S O L E D I V I S I O N]
| |
| | How to make a N64 Trainer Documentation by:
|_ _| >>>>> Icarus <<<<<
: )___ ___( :
/_ _\

Ladies and gentleman,
Welcome to my "How to make a N64-Trainer" documentation.

The reason why i did this doc is very simple: i am quitting
all my activities in the "n64-scene" for many reasons, i think
you don't care for so i won't go into that any further.
Furthermore it would be nice to see more groups doing trainers.
So i hope this will help some dudes to start!

So however, let's come to the real documentation.

First i want to explain how my trainers are working..
I think you all know the hardware game-enhancers like
"Action Replay", "Gameshark", "Gamebuster" and so on...
with this hardware stuff you can enter codes like this e.g.:

8003567C 0067

If YES i will explain what the fuck this codes mean:
8003567C 0067 <-- Value to be written
~~~~~~~~ ****
Memorylocation in N64 RAM

If you enter such a code the Gameshark hardware or whatever
will do the following: It updates the MEMORYLOCATION with
the VALUE very often (don't know exactly how often i a second
but this doesn't matter now! :-) )

And exactly this is how my trainers work. So in a strictly
definition my trainers are no REAL trainers, like i did them
on e.g. the Amiga. On Amiga for example it was better to
find the ROUTINE in the GAMECODE which was responsible for
subtracting your Lives or Health etc.. and once you found
this routine, you had the possibility to kill it with a NOP
or something..

On N64 you can say its emulating a Gameshark.
Unfortunately I must do it like this way but the fact is that
i just dont have this much possiblities with hard and software
like on my good ol' Amiga;) NMI-shit and stuff..

But the result is the same so... its not a clean way but it
works also.

So basically what we have to emulate a Gameshark and this is
very easy!:

1. We need a routine which is called VERY OFTEN to replace
VALUES in N64-MEMORY while the user is playing the game.

Okay, if you still know what i am talking about, CONTINUE READING!
If you don't know what i am talking about, QUIT READING NOW:)

So first step:

We must try to find a routine in the GAMEROM which is called
very often.. here we can hook up our own UPDATE-CODE which will
do the rest (=the "trainer" itself).

Personally i use "OsViSwap" but you also can use
"WriteBackDCacheAll", or "__osRestoreInt"... i just tested my
trainers with the above mentioned three functions and it works

To find this routines get the tool "LFE" from www.dextorse.com
(LFE = [Libary-Function-Extractor] (c) Ravemax of Dextrose)

Then get the library "libultra.lib" from the PSY-Q-N64-Devkit..

Swap your gamerom now to Z64/CD64 format and make a backup of
the rom... now RESIZE the ROM to 8 Megabit and use LFE to find
out where the functions are in the ROM.

The commandline for this is:

LFE.EXE [ROM.Z64] libultra.lib

This will take a while now.. - then LFE gives u back a ".COD"

Here i included such a .COD file just for example:

[============BEGIN TEST.COD==============]
0x8005e980,osWritebackDCacheAll <--- THIS ONE MAYBE
0x80066170,__osRestoreInt <--- THIS ONE MAYBE, TOO
[=============END TEST.COD===============]

So now search for one of the above mentioned functions.
Hmm... in this game we dont have a OSViSwap.. so we could
use the "osWritebackDCacheAll"-Function for our example.

Now take the resized 8-Mbit-ROM again and disassemble it with
N64PSX by NAGRA! (get it from www.blackbag.org or

The commandline will look like this:

N64PSX.EXE -n64 [ROM.Z64] >ROM.ASM

This nice tool will use the .COD file created by LFE
and will mix it together with the disassembled code so you can
exactly see where the functions begin.. my example will bring
ROM.ASM as a result.

Now, open "ROM.ASM" in your favorite editor and search for
the function we want to use ("osWritebackDCacheAll").

[============BEGIN ROM.ASM==============]
8005e974: 00000000 .... nop
8005e978: 00000000 .... nop
8005e97c: 00000000 .... nop
8005e980: 3c088000 <... lui $t0,32768 ; osWritebackDCacheAll
8005e984: 240a2000 $. . li $t2,0x2000
8005e988: 010a4821 ..H! addu $t1,$t0,$t2
8005e98c: 2529fff0 %).. addiu $t1,$t1,0xfffffff0
8005e990: bd010000 .... cache 0x1,0x0000($t0)
8005e994: 0109082b ...+ sltu $at,$t0,$t1
8005e998: 1420fffd . .. bnez $at,0x8005e990
8005e99c: 25080010 %... addiu $t0,$t0,0x0010
8005e9a0: 03e00008 .... jr $ra <--THIS IS THE END OF THE FUNCTION!
8005e9a4: 00000000 .... nop
8005e9a8: 00000000 .... nop
[=============END ROM.ASM===============]

Now, we must search for the end of the function, this must
be a "jr $ra". Once you found it, keep the memory-address
where it is located. (In our example its: $8005e9a0)
At this address we will hook up our trainer-routine.
Let's move to the next chapter!


Okay, here we go with the main-routine which is responsible for
updating the values in N64 RAM!

This routine is very simple

Just Imagine you got a Gameshark-Code like this:

8003567F 0064

As i said above this means for the Gameshark nothing else than:

So here a neat code which will do this for us in ASSEMBLER and
this will be the code which will be hooked to the Function we
found before, to go sure our routine will be executed every
time the function osWriteBackDCacheAll is called.

sub sp,28 ;Get som Stackspace
sw s0,0(sp) ;Better save this regs
sw t0,4(sp) ;coz our routine below
sw t1,8(sp) ;will trash them!
sw t2,12(sp) ;t1 and t2 is for additional stuff

li t0,$8003567F ;Memory-Address
li s0,$64 ;Value
sb s0,(t0) ;Write it into Memory.

lw s0,0(sp) ;Okay.. lets restore the
lw t0,4(sp) ;regs..!
lw t1,8(sp)
lw t2,12(sp)
add sp,28 ;Free our Stackspace!
jr ra ;This will jump back
nop ;to osWriteBackDCacheAll!

That's IT!


Above we just coded our trainer-routine. But now we
must attach this routine to the "osWritebackDCacheAll"-Function
we found in the gamerom in order to get the trainer working.

This is a very simple routine, too so take a look at the
following ASM code:

org $BXXXXXXX ;Orged in ROM see explanation

la t0,patchstart ;patchstart
li t1,$A0000200 ;This is place our Trainerroutine
;will stay
la t2,patchend-patchstart+4 ;Lenght to copy
lw t3,(t0) ;this loop will copy our
sw t3,(t1) ;patchroutine to $A0000200
add t0,t0,4 ;so easy.
add t1,t1,4
bne t2,zero,loop
sub t2,t2,4

li t0,$A005E9A0 ; our osWritebackDCacheAll function!!

li t1,$3c088000 ; Patch the function
sw t1,(t0)
li t1,$35080200 ; Patch the function
sw t1,4(t0)
li t1,$01000008
sw t1,8(t0)

li ra,$b0000008 ;This is the universial backjump
lw ra,(ra) ;routine.. explanation follows.
add ra,ra,$10
jr ra ;Back to the game!!

;here is the patchroutine (see above) :)

Okay, what does this routine now?

First of all i have to say something about the "org". Before you assemble
this little loader you must search in the Gamerom for a nice unused
place. Take your favorite hex-editor and load up your gamerom again
and take a look.. - if you found freespace at e.g. $7FC000 in the
rom and want to place your loader there, you have to ORG it to $B07FC000.

Then our neat code will copy our "Trainerroutine" (patchstart) to a
safe memory-location. (its $A0000200)

After that it will patch the routine located at $A005E9A0. Yeees, you
are right.. this $A005E9A0 is our osWritebackDCacheAll, we found
some chapters ago! but be sure to replace the "8" with an "A".
(We found $8005E9A0 and we will patch $A005E9A0)!!!

Yeah, all done!, our trainerroutine is in a safe-memoryloaction where it
can operate from, the osWritebackDCacheAll points now to our
trainer-routine, so it will be called everytime the Function is called.

So we can jump back to Gamecode: I have made a nice routine, which will
do it universial, so no need to change something for every game.


So.. finally we made it! we have the Trainer. The only thing you have
to do now is to patch the ROM-Start at $1000, save the orig-code from
this location, jump to your loaderroutine ($B07FC000) and before you
jump back, execute the orig-code you saved from $1000. And OF COZ, doing
a nice trainermenu in Assembler (get Titaniks excellent sources from
www.dextrose.com or get my trainermenu-source at dextrose.com, too)
Thats it.. get movin'!!!!!!!!!!

I hope i helped you with this document a little bit. Maybe this method
will be nonsense, if new hardware appeares, where you can set Breakpoints
and other usefull stuff.. But in this current point of time i think its
a good way to do trainers.. - not the best way... but WORKS:)

All infos, n64-sources etc can be obtained from www.paradogs.com, too.

To make trainers is an ART not a RACE! :D

Signed, Icarus of Paradox/Lightforce/Crystal/TRSi/Vision/LSD/Hellfire

AUGUST - 1999!

Greetings to all my friends in the scene.. stay cool.
To all the others... FUCK OFF!

How to fix your Doctor V64 Junior 512mbit.

"How to fix your V64Jr512 (by Socketz)

I have a V64Jr512, so I don’t know if my solution will work with any other model.

I had a lot of trouble with my V64Jr512 and after considerable effort, found out why and was able
to fix it.
I tried EVERYTHING! I disassembled it, changed the common components like the 74HC245s,
solder plated the cartridge edge connector, solder plated the memory edge connector, (very
carefully) soldered the memory to it’s socket, (again, very carefully) soldered the Altera chip to its
socket, added thermal dissipation to the Altera chip, then changed the memory SIMM socket and
the Altera PLCC socket, but NOTHING OF THIS WORKED!
I also tried changing the memory with some SIMMs, but discovered the V64Jr512 uses a custom
made memory SIMM. No, it’s not a standard DRAM SIMM, and it’s not a standard EDO memory

Then I noticed the following:
If I sent a game to the V64Jr and immediately verified it, it checked ok.
If, after sending a game to the V64Jr I left it on for some time (I tested mine for half an hour), then
verified it, the memory was still ok.
Finally, if I sent a game to the V64Jr, then plugged it into the N64 and turned it on, after a short
time (less than 5 minutes), the game crashed. After turning the N64 off and verifying the game, I
found out the memory had failed.

WHY? What’s the difference???
I used a tester to measure the voltage while battery powered and then while powered by the N64
and found a very slight difference… nah, can’t be that stupid…

IT IS!!!!

******** The V64Jr512 uses 3.3 Volt memory ********
The designers at Bung just took the 5V coming out from the 7805 voltage regulator, put 2 diodes
in series to drop the voltage to something less than 4V and fed the memory with this!
Why? Well, that’s easy, it was cheaper than adding a 3.3V voltage regulator. How much? Oh,
about $1.50 cheaper! You can’t believe it? Me either!

Let me tell you something: 3.3V memory requires 3.3 Volts, NOT 3.9V nor 3.2V.
This is a design flaw!

Well, let’s fix it… "

Read the rest of this in the original pdf file written by Socketz here: FixYourV64Jr512.pdf

Friday, May 7, 2010

Inside the Doctor V64.


Info and Picture by _MiSFiT_

6 major IC's on Doctor board.

2 of which are covered with black epoxy

1 - U11 = W9950D - Winbond - MPEG RELATED most likely

1 - U8 = W9925PF - Winbond - MPEG RELATED most likely

1 - U1 = V64CO silk screened on doctor board - epoxyed chip

1 - U2 = V64 silk screened on doctor board - epoxyed chip

1 - U9 = 424260 silk screened on doctor board - RAM of some sort
I HOPE SRAM - if its RAM for the MPEG then WHERE the hell
is the SRAM?? Or maybe its for both.. It LOOKS like the address
lines go to the MPEG chip..

1 - U3 = 29EE010 silk screened on doctor board - EEPROM where bios are

U1 from the board layout looks like it would be the processor that the bios
is written for.

All the address lines from the eeprom (U3) seem to lead to U1 - But U1 has
black EPOXY all over it. If anyone can determine what processor the bios code
is written for please let someone know on #doctor64 on effnet.

People have been telling me its most likely a 6502 processor, I have included
with this file a version of the BIOS for those that are interested in looking
at it. (And dont have a doctor yet and want to start hacking - Believe me
there are people that DO NOT have the doctor yet that are writing UTILS)

I have also included a close up of the RAM board for those interested.


Original archive file can be found here docic.zip

Going in depth on N64's country check system.

Heres another text file from the old N64 scene days that I thought was very informative:).

Fixing-Doc - Part 1.1

by Hotblack/Dextrose 1999

Uh oh...first doc and immediately wrong :(
I kicked the wrong part about back-copying original code from rom
But since I heard that no one can follow my explanations - who cares anyway :)

The Country-Check

Since I got some questions lately about what PALadin exactly does, I decided to write
this doc (so I don't have to write it again and again ;) )

First thing you should know, is what country-check actually means.

While booting, the bootcode writes the kind of videosystem into a
special address in the N64-Ram:


This address is called osTvType and it's value is defined as follows:

#define OS_TV_PAL 0
#define OS_TV_NTSC 1
#define OS_TV_MPAL 2

That means, if your running a PAL-system, there's 0 (zero) written to $80000300

The country-check just checks this value. If a ntsc-game doesn't finds 1 (OS_TV_NTSC),
it won't start (sometimes displaying a msg about wrong video-system)

Usually a crack means killing all checks, but since there are several methods to read
a value in asm, it takes some time to find them all (they could be encrypted/packed)

A much simpler way to kick the check is writing the expected value to osTvMode
Since this value is written only once in the bootup-procedure, it can be changed
right after that when the execution of the real rom-code starts.

As you should already know (otherwise this whole info wouldn't help you much) the
entry-point in RAM is stored in the header at $b0000008.
The code beginning at $b0001000 (that's in the rom) is copied and execution continues
there, after the boot-procedure is finished.

[The address itself is $1000. If we talk about an address in RAM we need to add $80000000
and if it's the ROM-address we have to add $b0000000]

Now, what does PALadin do?

Let's look into an example. This rom has it's entrypoint at $80161600 and here's the
original code:

$80161600 lui $t0, 8007
$80161604 addiu $t0, $t0, 8360
$80161608 addiu $t1, $zero, 2530

We don't care, what that code does. It's unimportant and we only need it to get the rom
working again after we patched it.

PALadin inserts some code at the very end of the rom (hoping, there's no vital information
stored ;) ) and replaces the code above with the following:

$80161600 lui $at, b0ff
$80161604 ori $at, $at, ffd8
$80161608 jr $at

You see that there are three lines changed

The first 2 instructions move $b0ffffd8 into the register $at
The next instructions jumps to the address stored in $at

$b0ffffd8 is the place, where PALadin has inserted his fixing-code (in this example!)

No let's move on to the code at the end of the rom:

$b0ffffd8 lui $t0, a000 ; $t1 = a0000000
$b0ffffdc ori $t1, $zero, 1 ; $t1 = 1 (1=NTSC, 0=PAL)
$b0ffffe0 sw $t1, 0300($t0) ; *a0000300 = $t1

Those 3 lines do the fix. To write to a ram-address we have to use $a0000300 instead of
$80000300, because writing to $8xxxxxxx is always cached and it's not sure, that the cache
is updated to ram when the first check of the address occurs

This example is a PAL-Fix, that means we want the rom to "think" it's running on
a NTSC-system. That's why we write OS_TV_NTSC to osTvType.

$b0ffffe4 lui $t0, 8007
$b0ffffe8 addiu $t0, $t0, 8360
$b0ffffec addiu $t1, $zero, 2530

Hmm..looks familiar...those are the 3 lines which have been overwritten at the entry of the
rom. It's obvious that those lines have to be executed to get the rom working.
So PALadin just copied them here.

$b0fffff0 lui $at, 8016
$b0fffff4 ori $at, $at, 160c
$b0fffff8 jr $at
$b0fffffc nop

This is the jump back to the entry-point right after PALadins first 3 instructions
(no, we don't want them to be executed again)

This whole thing has one drawback: If the first 4 instructions of the roentry look like:

$80161600 xxx
$80161604 lui $t1, 8360
$80161608 jr $t1
$8016160c addi $t1, $t1, fff8

PALadins fix won't work. You surely can find out yourself why not ;)

There's another possibillity, which should always work.
First the entry should be overwritten with 4 instr, the last one a simple NOP
That makes sure, that the jump always sux aeh succeeds

>>>Instead of copying the 4 instr to the end we could just copy them back from the rom to ram
>>>and continue executing at the (now depatched and original) entry of the rom

Of course we can't copy them back from rom, because they're not there ;)
But we could copy them from where we stored it before (if we did)
The advantage would be, that those instructions would be executed exactly where they
would executed in the original rom - that would always work

Hmm...I think that's all
I know it was to confusing :P

Any suggestions, corrections or flames to Hotblack@dextrose.com
(well flames please to Actraiser@dextrose.com ;) )

Hotblack :)

PS: Now you see why such a country-check-removing-only PAL-Fix doesn't help PAL-Only-Users.
Even if the game would have an autodetection of the videomode and WOULD init PAL on PAL-systems,
this fix forces them to NTSC. To make it playable on Non-Multi-TVs we need to patch the
videotables (and sometimes the frequency of the sound) - but that's another story :)

Original text file can be found here dx-fdc11.zip

The worlds first twit on a MSX.

Meaningless but awesome!


How to build your own Doctor V64 power supply.

I'm going to start spamming my blog with old nfos,zip files from the N64 scene that aren't that easy to find in a fast google search , so hopefully these sort of posts will be helpful to new/old owners of mainly Doctor V64.




Ok Dudes, bung is very good in delivering defective Power-Supplies with their
Doctors, also at sometimes a Power-Supplie overheats and works no more.

Here is a simple way how to built your own powersupply:

Items you need :

1. A broken V64-PowerSupply (actually only the cable which gets plugged into
your Doctor64)

2. A normal PC-PowerSupply (same you use in your Desktops or BigTowers)
3. Some Solder Iron

All you have to do is to connect the cable from your DoctorV64-PowerSupply
to one of the free connectors of your PC-PowerSupply (for example one
of those you normally use for your powering a HarddiskDrive)

Here is the PIN-Layout:

Doctor V64 Cable:
blue = +5v
white = ground
red = +12v
brown = ground

red = +5v
yellow = +12v
black = ground
black = ground

All you have to do now is to solder/connect the stuff together

DV64 Blue <-> PC Red
DV64 White <-> PC Black
DV64 Red <-> PC Yellow
DV64 Brown <-> PC Black

Now that should work then.

-have fun

Conception and Realization: |-}MadDoc{-|
Tested: Nightraver
Translated to English: ACTRAiSER"

Original text file can be found here: psupply.zip

Thursday, May 6, 2010

NES RetroVision.

"Another secret project finally finished! Not going to set up a web page for this one yet because I only have 4 completed and ready to ship. If you want one, start a transaction! They are going to start at $130 including shipping.

This is basically the Super GameBoy, without the Super part. The guts of an original GB are transplanted into a NES cart. My incredibly amazing custom board then translates the GB graphics into NES format, and the NES controller to GB format. The original link port is accessible, so you can connect another GB or RetroVision or plug in the printer.

The colors and border can be changed using the 2nd controller. Audio either comes from the headphone jack or through the NES if you have done the resistor mod inside your console.

Inside the cart is PACKED. The GB cart does stick up above the surface, so a front loader will need the metal bar removed like with the Game Action Replay.

- It's the same as Super GameBoy: pretty much! No I don't expect this to be a big seller, but hopefully some of the new tech I used will be in future unknown projects.

- It's expensive: yup! Expensive parts, expensive development, lots of PITA assembly. See above if you are cheap

- It's not available: I only have a few of these built right now. After vacation I can get more done but each one takes a long time to create."

Source: http://nintendoage.com/forum/messageview.cfm?catid=6&threadid=32896

Monday, May 3, 2010

Bound High! redumped for Virtual Boy.

"It's finally done! With the help of our new member Kitaro, it was finally possible to build a good ROM of Bound High!

After all, it was neither a bug in the ISX converter, nor one in the game's source, but a faulty code optimization routine of the VUCC compiler, which could be circumvented with a very small change to the source. Such a little thing, so much hassle!

I'd like to say thank you to everybody who was involved in this and helped to work towards this release, you guys rock!

And now, enjoy this fine release!"

Release post