What's new

Rewriting N-Rage DirectInput8 Transfer Pak

Status
Not open for further replies.

Dark Savant0

New member
Ummm, I came across this topic in my search of the web for more info on the transfer pak. My transfer pack is not working for some reason. I am using the pc, not an adaptoid or anything, a rom and the save. Whenever I enter the Doduo Tower in Pokemon Stadium 1, It goes blue screen(the emu) for a couple seconds and freezes. With the latest build, it has a black screen all the way. But on the others, it doesnt, just blue. The freezing happens only in the latest and the official 1.82. Doomulation's doesnt freeze, but does not emulate. I have tried with both a red and blue rom.

EDIT : I forgot to ask for advice, and say that the roms are loaded from all the controller sockets but controller 1, if that helps. Thanks in advance.
 
Last edited:
OP
MadManMarkAu

MadManMarkAu

Transfer Pak Expert
Yeah, that's a problem I'm working on... I'm not 100% sure whether it is a problem with the emulator or a problem with the plugin. I need to do a Transfer Pak capture. Heh, I'm not even sure if a Transfer Pak connected with an Adaptoid works on a PC emulator. Anyone cate to tell me if it does or not?

If anyone's GB tower works with an adaptoid and Transfer Pak, then tell me. I need to see just what my Transfer Pak emulation code is doing wrong, and seeing there's no documentation for a Transfer Pak, I'm kind of in a tight situation.

For those who want to know, I originaly created the Transfer Pak emulation by looking at an actual Transfer Pak capture. However, I don't have the capture anymore. Heh, I don't think GB tower even worked for the guy who did it, either :(
 
OP
MadManMarkAu

MadManMarkAu

Transfer Pak Expert
ok, I believe it may be the actual Pokemon Stadium cartridge that does the GB emulation... I found this post:
The Stadium cartridges are heavier than normal.

It's probably a "system-on-a-chip" original or Colour Game Boy on a single chip within the cartridge...

I downloaded the PJ64 source code, and I'm going to see if there's any unusual or lots of transactions between the emulator and cart. I'm not 100% sure how an N64 cart works, tho, and I can't find much info on it.
 

Doomulation

?????????????????????????
I think I've encountered a little crash with n-rage. It's plugin dependant, though. Haven't debugged it yet. I don't really think it's hardware dependant these bugs... but here are the specs if you really need them:

Video: Rice (for Paper Mario), Glide64 or Jabo.
Sound: Jabo's.
Input: N-Rage (duh) (my unofficial version, debug compile).

CPU: Amd Athlon 3000+ Bathon core @ FSB 166 MHz.
Memory: Two sticks, both DDR, although diffrent memory speeds which I can't say exactly because I honestly don't remember.
 

noctrun

noctrunal internet surfing guy
MadManMarkAu said:
ok, I believe it may be the actual Pokemon Stadium cartridge that does the GB emulation...
that post was a mere guess and not a proven fact. go here to check out the inside of the cartridge itself and compare it to some other scans you can find on that site, this proves nothing, I'm guessing here too.
 

okstorms

New member
Those Pokeman scans definitely don't look like they have any additional chips on the PCB. That site is very interesting, thanks for the link!
 

Clements

Active member
Moderator
The Pokemon Stadium cartridge may have a software emulator on it that plays the game. Then again, the transfer pak itself may be responsible for this, either through hardware or software. Just random thoughts.
 
OP
MadManMarkAu

MadManMarkAu

Transfer Pak Expert
Interesting... I've also noticed that the authors of PJ64 didn't do a good job on the CPU emulation. I've noticed many commands that are in the MIPS handbook missing. And, I've also noticed that after the GB Cart is loaded, the CPU executes some instructions, then the emulator freezes the CPU. I've yet to find out why it's doing this. It's freezing on the same memory location every time. But the funny thing is, it's a valid instruction. I'm going to trace through the recompiler just before it hits that location, and see exactly what's happening.

Thanks to everyone for their input.
 

Hacktarux

Emulator Developer
Moderator
If you post which opcodes are causing problem and what's the memory location you're talking about, maybe i or someone else can tell what's this supposed to do or why it's been ignored in pj64...
 
OP
MadManMarkAu

MadManMarkAu

Transfer Pak Expert
It's ok. The only opcode that was actualy causing a problem was the SYNC opcode. Some demo I had needed it and PJ64 didn't like it. So I added it in, and the demo worked. But, I have a strong feeling that there are a few others missing too. It's probably just me, but I believe that when you write any form of emulation, it should emulate all concievable aspects.

Anyway, there's also, apparently, seems to be some piece of hardware PJ64 fails to emulate.I have no idea what that hardware is, but games access it during startup and at some other spots (like in GB tower when the cart is fabout to be loaded).

But, I've found why PJ64 seems to crash on GB tower. I broke into execution a few times, and found that it's always in the Audio plugin. When using the No Audio plugin, the RSP is the one who gets all the execution.

I think it's possible that Stadium puts the RSP into a never-ending processing loop, and seeing the CPU core emulation waits for th RCP to finish execution (I think)... This may be the cause of the crash.

Assuming the RSP is placed into infinite-loops, the only possible use I can think of is to constantly map a screen bitmap onto the screen, or some other task like that, tho I'm sot sure what any benefit could be. I'm fairly certain that, if it is an infinite loop, it has something to do with audio. I'll check all this out tomorow.

But, then agin, I could be completely wrong. I don't know much about the RSP at all. I'll have to learn about that too.

I'm off to bed now.
 

Hacktarux

Emulator Developer
Moderator
If your code is using standard n64 lib, there can't be any infinite loop, that's why, all current n64 emus are waiting until the rsp task is finished to continue main processor emulation. If it's really an infinite loop, it would mean it's used in a very unusual way and it would be possible to fix it by using threads. It's adding some difficulties to the rsp emulation especially if you want to have timing nearly perfect and i think it would be slower... But it can added as a special mode for this game. Anyway, it needs to be checked first to be sure it's really an infinite loop.
 

noctrun

noctrunal internet surfing guy
Clements said:
The Pokemon Stadium cartridge may have a software emulator on it that plays the game. Then again, the transfer pak itself may be responsible for this, either through hardware or software. Just random thoughts.
annother random thought: I start too wonder if there is any emulation involved since the pokemon company certainly has the source code of the gameboy games, a port of the game with access to some specific data form gameboy cart by the transfer pack could definitely do the job
 
OP
MadManMarkAu

MadManMarkAu

Transfer Pak Expert
Morning everyone.

Noctrun, good point. Only, the GB cart is totaly (or at least very close to totaly) loaded when GB tower is run. One way to test your theory is if someone with a real N64 + transfer pak replaced the cart with another non-pokemon cart. See if it will run Mario Tennis or some other non-pokemon game.

Also, with the theory that the Transfer Pak does the emulation (I with that were true.. make my job lots easier), if that were true, then the N64 wouldn't need to load all the data from the cart into memory.

Anyway, I'm just about to check the RSP plugin now.

******************
EDIT: Ok, this may be a teeny little bit of a problem... the RSP really is going into an infinite loop... Or, at least it's never leaving the RunInterpreterCPU(DWORD Cycles) function... I'm going to try and force it to exit when infinite looping, just to see if it moves the N64 along any further. Then if that works, I'll try to adress the problem of the infinite looping...

EDIT2: I've found that the RSP is not deliberately put into an infinite loop. I checked the RSP instructions, and found this:

r0 = 0 at this point...

0x638:
MFC0 t0,SP status (t0 now = 0x440)
ANDI t0,t0,0x0400
BNE t0,r0,0x638

There must be something missing from the RSP emulation. I assume, seeing it's reading the floating point status, that it's waiting for a floating point operation to complete or something... I don't know. I can't find any documentation on the RSP anywhere.
 
Last edited:

BountyJedi

New member
well it does seem to load it atlest when running there you can in pkmn 2 make it load less in the beginning and load a bit here and there to save loading time in beginning.
 

Hacktarux

Emulator Developer
Moderator
OK, i know what's wrong. 0x400 bit in SP Status is normally used to tell the cpu a RSP task is finished. Only the RSP set it usually. I think that in this game, the cpu is supposed to clear this bit when it has finished to use the data produced by the previous RSP task. But in current emulator implementation RSP and CPU are not running in parallel so it falls in an infinite loop. I think that it shouldn't reach this case if there was correct timing of the RSP and RDP interupts.
 
OP
MadManMarkAu

MadManMarkAu

Transfer Pak Expert
Aaah, I see. That would make sense. I just now need to multithread the two. Boy, this is going to be fun :( I'm not used to using threads and critical section objects... Give me a day or two to look up multithreading in C on the net, then I'll tackle this problem.

I'm just wondering, in the real N64, the RSP doesn't run all the time, does it? I tried multitasking the R4300 CPU and the RSP by modifying the RSP code where the execution is run to only run for a set number of cycles passed to the function, then calling this function telling it to run 1 cycle, calling it every 6 R4300 cycles (R4300's execute on the rising and falling edges of the clock pulse). It didn't really like it :( I know it was a dodgy way of doing it, but I wanted to see what a multitasked RSP would do. Probably shouldn't have started until the first RunRSP() call...

I know this probably removes something from the whole HLE thing, but if it gets GB tower working, the authors of PJ64 may add it in as a workaround for GB tower, like, have it selectable in the options...

EDIT: Ok, this is doing my head in... The RSP doesn't seem to like leaving it's processing loop to return processing to the R4300 CPU... I think I might need to write my own emulator or something. Well, for now I'm going to concentrate on the N-Rage plugin, and get it released. Once I've done that, I'll get GB tower working, because we've determined GB tower not working is not the fault of the plugin. Once I'm done with the plugin, I'll work on the emulator.
 
Last edited:
OP
MadManMarkAu

MadManMarkAu

Transfer Pak Expert
Ok, I'm ready to make another release of the plugin. I haven't been able to fix the crash bug. I believe it's something inside Project64 V1.5 that's doing it, because it doesn't crash under 1.4... If anyone has any problems with it crashing under 1.5, please tell me. But, due to the unavailability of the 1.5 source (which is a bummer), I can't find out exactly what is going wrong. It doesn't crash under other emulators, so I've com to assume it's a problem with 1.5.

I'm going to wait a few days, maybe a week, and unless someone finds a bug, I'll get N-Rage to update his site, and inform some Emu sites about the new plugin.

Anyway, check here for the source and DLL. This is going to be an official release, with the possibility of change if someone finds a bug I missed.

Enjoy :)

EDIT: NOTE TO ALL EMULATION PAGE WEBMASTERS - While this plugin is an official release, please don't upload it to your sites yet. I want to wait a few days and see if any bugs appear. I'll re-edit this post and say when it's OK to upload to your sites.

EDIT: NOTE TO ALL EMULATION PAGE WEBMASTERS #2 - There doesn't seemt o be any bugs or issues in this new plugin, so I'm now allowing Emu sites to host this plugin on their site. Here's the information you'll need:

Change summary for version 1.83:
- Rewrote GB Cart emulation (Now supports ROM-only, MBC1, MBC2, MBC3 and MBC5 carts)
- Added support for GB Cart RTC based on VisualBoy Advance save format.
- Added option for slower rapid-fire in macros. Fixes problems with some games like Paper Mario.
- Added optional and adjustable rapid fire to standard input keys.

If you host this plugin, please put my E-Mail address ([email protected]) with N-Rage's E-Mail, because as far as N-Rage is concerned, this emulator is doscontinued, and I don't think he'd like getting E-Mails asking for tech support.
 
Last edited:
Status
Not open for further replies.

Top