NRage Input Plugin V2.00 BETA (an overhaul)

[rabiddeity]

Transfer pack and mempack works now. Setting of buttons is still lost after change.

RomID and description are always empty, are they useful or error on my side?

NRage-Debug.txt, using 7z for less size (4MB unpacked)

Yep, one thing at a time, I was just trying to fix the transfer/mempak crash bug first.

RomID and description are debug fields, supposed to be sent to the plugin by controller spec 1.1, which THEY STILL HAVEN'T FIXED IN PJ64 1.6 (so complain to them for not releasing a patch for a simple issue). But in spec 1.0 mode they don't do anything, so just ignore them.

Button settings I'm going to start working on now that the crash issue is fixed.

guille007, you're right though, that code is quite hacked together. I haven't messed around with it much because I don't want to break the Poke Yellow support that I just fixed. But yeah, once I get the Win98 bugs taken care of that's next on the list. (Crashes and major usability issues take precedence over perfect MBC5 emulation support, I'm sure you understand why.) Give me a couple days and I'll get a proper response to you once I take another good look at the code.

 

[squall_leonhart]

MBC3 already works fine though.

Pokemon crystal loads fine in pokemon stadium as do all the other games.. except for green...

the problem with Pokemon Tower is the core,

when you go to start pokemon tower, the emulator enters an infinite loop state

 

[rabiddeity]

it would have to be.

bool WriteCartMBC5(LPGBCART Cart, WORD dwAddress, BYTE *Data) {
    .........
	else if ((dwAddress >= 0x2000) && (dwAddress <= 0x2FFF)) { // ROM bank select, low bits
		Cart->iCurrentRomBankNo &= [COLOR="Red"]0xFF00;     [/COLOR]
		Cart->iCurrentRomBankNo |= Data[0];
		DebugWriteA("Set ROM Bank: %02X\n", Cart->iCurrentRomBankNo);
	}
	else if ((dwAddress >= 0x3000) && (dwAddress <= 0x3FFF)) { // ROM bank select, high bit
		Cart->iCurrentRomBankNo &= [COLOR="Red"] 0x00FF; [/COLOR]
		Cart->iCurrentRomBankNo |= (Data[0] [COLOR="Red"] & [/COLOR] 0x01) << 8;
		DebugWriteA("Set ROM Bank: %02X\n", Cart->iCurrentRomBankNo);
	}
...........

You're right. The only reason it worked before was because nothing read from ROM above bank 16. Fixed in my copy of the code, so it will appear in the next DEBUG versions and in further RELEASE versions.

another well-known problem that found is this.

bool WriteCartMBC3(LPGBCART Cart, WORD dwAddress, BYTE *Data) {
.................
	else if ((dwAddress >= 0x2000) && (dwAddress <= 0x3FFF)) { // ROM bank select
		Cart->iCurrentRomBankNo = Data[0] & [COLOR="Red"]0x3F;[/COLOR] // HACK: should be "& 0x7F" according to spec, removed this hack for now --rabid
		[COLOR="Red"]if (Cart->iCurrentRomBankNo == 0) {
			Cart->iCurrentRomBankNo = 1;
		}[/COLOR]
		DebugWriteA("Set Rom Bank: %02X\n", Cart->iCurrentRomBankNo);
	}
.................

yes, it must be 0x7F to load the Pokemon Crystal (mbc3) in PokemonStadium2 (max load)

Also correct. Just to clear things up, the "if" is there because MBC3 is unable to access bank 0 through the upper registers; it has to use the 0x0000 to 0x3FFF range directly. Bank 1 is mapped by default to 0x4000 through 0x7FFF, and if you try to select bank 0 it automatically switches to bank 1.

As for the MBC1 issues, I tried fooling around and doing some optimization in the read/write code. So if you compare it to the MBC3 code, for example, you'll see it uses bit shifting and cases instead of a series of "if ((dwAddress >= 0x4000) && (dwAddress <= 0x7FFF))" statements. I think it makes more sense, as the bank controller is using the upper bits to determine what gets read from... it uses far fewer comparisons but may be a bit harder to read for some people. I don't think that's the problem, but we can try reverting if you want to see if that fixes it. Please take a look and see if you think the logic is OK.

Another possible cause might be the RAM enable switch on the MBC1, which still isn't properly emulated. You'll notice a check for RAM reads in ReadCartMBC1 which is commented out. My documentation isn't clear on which carts it's present in. When I tried to add it to all carts, it caused a mess of problems in MBC3 and MBC5 carts, so I think either it's just an MBC1 setting or the transfer pak takes care of the RAM enable when it goes through its initialization routines. If it's not taken care of by transfer pak initialization, then it could be used as a sort of pak check.

Finally, and I think this is the most likely reason, according to this updated doc that I just discovered, selecting bank 0x20, 0x40, or 0x60 will switch to bank 0x21, 0x41, and 0x61. http://www.work.de/nocash/pandocs.txt I'm not sure if that doc is correct. But if it is, then that might cause issues... and it also provides more details on technical quirks of the MBC1 that I'm going to try changing in the current debug code.

Anyway, I've updated the DEBUG version with your changes so you can download and test. I'll upload source as soon as I've fixed Kruci's save problem.

 

[guille007]

FIRST sorry about English .

Another possible cause might be the RAM enable switch on the MBC1, which still isn't properly emulated. You'll notice a check for RAM reads in ReadCartMBC1 which is commented out. My documentation isn't clear on which carts it's present in. When I tried to add it to all carts, it caused a mess of problems in MBC3 and MBC5 carts, so I think either it's just an MBC1 setting or the transfer pak takes care of the RAM enable when it goes through its initialization routines. If it's not taken care of by transfer pak initialization, then it could be used as a sort of pak check.

I believe that all the MBC have a form of “SET RAM ENABLED”, to prevent the lost of data in the PowerUp. Anyway the Pokemon Stadiun tries to SET RAM ENABLED = false, before writing in the ram. ¿?¿?¿ WHY!! :-S ?¿??¿? (in pocket Monster Green (J) (MBC1) and in Silver (U) (MBC3))

I found This:=

bool WriteCartMBC[1,2,3,5](LPGBCART Cart, WORD dwAddress, BYTE *Data){
.......
		Cart->bRamEnableState = (Data[0] == [COLOR="Red"]0xA0[/COLOR]);
		DebugWriteA("Set RAM enable: %d\n", Cart->bRamEnableState);
.......

it would have to be 0x0A, acording to specifications, and pokemon estadiun try to SET ENABLED with 0x0A (so 0x0A its ok) in some place of Nrage-Debug.txt , but not in the place that would have. Anyway this does not fix anything, if check for bRamEnableState before Write to ram then dont work. Now i am trying to find out that it happens.

Great found! :=

 bool WriteCartMBC1(LPGBCART Cart, WORD dwAddress, BYTE *Data){
...............................
	case 2:	//	else if ((dwAddress >= 0x4000) && (dwAddress <= 0x5FFF)) // RAM bank select
		if (Cart->bMBC1Mode432)	{
			Cart->iCurrentRomBankNo = Cart->iCurrentRomBankNo % 32 + ((Data[0] & 0x03) << 5); // set bits 5 and 6 of ROM bank
			DebugWriteA("Set ROM Bank through 4/32 mode: %02X\n", Cart->iCurrentRomBankNo);
		}
		else if (Cart->bHasRam) {
			Cart->iCurrentRamBankNo = Data[0] & 0x07;
			DebugWriteA("Set RAM Bank: %02X\n", Cart->iCurrentRamBankNo);
		}
		break;
...............................

it would have to be

 bool WriteCartMBC1(LPGBCART Cart, WORD dwAddress, BYTE *Data){
...............................
	case 2:	//	else if ((dwAddress >= 0x4000) && (dwAddress <= 0x5FFF)) // RAM bank select
		if ( [COLOR="Red"]![/COLOR] Cart->bMBC1Mode432)	{
			Cart->iCurrentRomBankNo = Cart->iCurrentRomBankNo % 32 + ((Data[0] & 0x03) << 5); // set bits 5 and 6 of ROM bank
			DebugWriteA("Set ROM Bank through [COLOR="Red"]16/8[/COLOR] mode: %02X\n", Cart->iCurrentRomBankNo);
		}
		else if (Cart->bHasRam) {
			Cart->iCurrentRamBankNo = Data[0] & [COLOR="Red"]0x03[/COLOR];  [COLOR="Blue"]//max of 4 ram banks[/COLOR]
			DebugWriteA("Set RAM Bank: %02X\n", Cart->iCurrentRamBankNo);
		}
		break;
...............................

This will FIX Pocket Monster Green (J) RAM LOAD , BUT not ROM :-S (in Stadiun 2 (J))

Finally, and I think this is the most likely reason, according to this updated doc that I just discovered, selecting bank 0x20, 0x40, or 0x60 will switch to bank 0x21, 0x41, and 0x61. http://www.work.de/nocash/pandocs.txt I'm not sure if that doc is correct. But if it is, then that might cause issues... and it also provides more details on technical quirks of the MBC1 that I'm going to try changing in the current debug code.

mmm,, I hope that that is not truth :-S , it's a freak feature, anyway the Pocket Monster Green (j) (MBC1) dies by another thing trying to set ROM BANK in some anormal way (this in PocketMonsterStadiun) :-S , ANYWEY It seens that ROM loads perfectly in Stadiun GS (J) (....I DONT KNOW WHY....)

 

[guille007]

FIRST sorry about English . Again

mmm,, I hope that that is not truth :-S , it's a freak feature..

Sorry, Iam mistake this feature it's posible and its already implemeted , (I dont know if a GOOD mistake or exelent implementation)
explication:
0x20 = 0100000 b = 01 00000
0x40 = 1000000 b = 10 00000
0x60 = 1100000 b = 11 00000

to set this ROM BANKS you need use 16/8 mode so FIRST put the lower bits (00000) (5 bits)

	case 1:	//	else if ((dwAddress >= 0x2000) && (dwAddress <= 0x3FFF)) // ROM bank select
		Cart->iCurrentRomBankNo = Data[0] & 0x1F;
		[COLOR="Red"]if (Cart->iCurrentRomBankNo == 0) {
			Cart->iCurrentRomBankNo = 1;
		}[/COLOR]
		DebugWriteA("Set ROM Bank: %02X\n", Cart->iCurrentRomBankNo);
		break;

but you put "00000" then the "IF" switch then to "00001" and then
0x20 , 0x40 , 0x60 are switch to 0x21 , 0x41 , 0x61

anyway I think its a especial case,

	case 1:	//	else if ((dwAddress >= 0x2000) && (dwAddress <= 0x3FFF)) // ROM bank select
		[COLOR="Blue"]Cart->iCurrentRomBankNo &= 0x60;  //kill 5 first bits, keep 2 higers bits[/COLOR]
		Cart->iCurrentRomBankNo [COLOR="Blue"]|=[/COLOR] Data[0] & 0x1F;
		[COLOR="Red"]if (Cart->iCurrentRomBankNo == 0) {
			Cart->iCurrentRomBankNo = 1;
		}[/COLOR]
		DebugWriteA("Set ROM Bank: %02X\n", Cart->iCurrentRomBankNo);
		break;

I think this will the correct implemetation, the especial case alredy exist, but can by evaded by FIRST set the Higers bits. Perhaps the manual talked about this. anyway it is necessary to really see a manual , a good one. .
suggestions??? :-S

 

[rabiddeity]

Anyway this does not fix anything, if check for bRamEnableState before Write to ram then dont work.

Yeah, that's the reason I originally disabled the checks for Ram Enable. But you're right that the check should be 0x0A and not 0xA0. I don't know what I was thinking! Wow, it's broken on the other paktypes too. Fixed.

I think I figured out one other thing. The way I was thinking of it before was a single RAM select register (2 bits) and a single ROM select register (7 bits). But really it's even simpler-- the ROM select register is only 5 bits, and the 2 "magic bits" are used for either RAM select OR the top bits of ROM select. So say there are two access modes, large RAM and large ROM access modes. If we are in large RAM mode, then the ROM bank select uses 0 for the first two (high) bits. If we are in large ROM mode, then instead of the 2 RAM select bits being used for selecting RAM, they are the two high bits of the ROM select.

So when we switch between the two modes, we must be careful not to discard those two bits. Here's an example. Say we are in RAM select mode, and we select RAM bank 0x01, and we select ROM bank 0x0F. Now we switch select modes. RAM bank is now 0x00 and ROM bank is now 0x2F (because it uses two bits that were previously used for RAM bank number.) The reverse is also true; if we ROM bank select a high bank in "big ROM" mode, and then switch to RAM select mode, bank 0 will not be selected. Does that make sense?

It also explains why trying to select ROM bank 0x20 selects 0x21 instead; the circuitry is "dumb" and only looks at the 5 least significant bits! Thankfully, no GB cart is going to try to access those "forbidden" banks anyway, so it shouldn't be too big a deal. I'll emulate it anyway.

Looking at this code now it needs a few other changes. I'm going to change the name of bMBC1Mode432 variable to bMBC1RAMbanking. I think it makes more sense-- the boolean set to true uses the two "magic bits" for banked RAM, and the boolean set to false uses the two "magic bits" for the most significant bits of ROM bank. Also several variables are switched from type "int" to type "unsigned int" so that I can do bit shifting properly. I've posted up a set of temporary source code, and debug binary is updated. Here's the link:

http://www.randomwisdom.com/files/NRage_DInput8_V2_2.00b_betasource.zip

By the way, thanks for helping out. It's good to have another coder looking at this stuff!

 

[R0YB0T]

Rumble issue

Hi I am using a PS2 pad with an EMS USB2 adapter. The rumble seems to work sometimes. When it does work it does not rumble much at all though. I have the rumble strength set to 100% and Constant Force enabled.

I have tried Ramp also and it doesnt make too much difference, it does seem a bit weaker than Constant. Which I think is intended.

Would there be a way to have it send more rumble requests per instance? I don't know if that came out right, but basically when the game wants the pad to rumble, could it send a few per every 1 time it wants to, or a longer duration per time?

I am using Zelda OOT to test. when I charge up the spin magic attack, i can feel it rumble VERY slightly. And not always.

Thanks.

 

[rabiddeity]

First, make sure your game is running at full speed with no hitches. That's not a sure fix, but if that part isn't right then rumble isn't going to work well at all.

The N64 makes the controller rumble different amounts by turning the rumble motor on and off very rapidly. NRage emulates this by sending DirectInput effect start and stop messages. How your USB adapter's driver handles this determines how well the rumble works. Unfortunately, I can't drive your PS2 rumble motors directly, so it's up to your adapter maker to fix this.

I'd say it's an issue with your USB adapter's driver. See if there's a newer version of the software out there (a google search reveals the latest version is 3.0, at the vendor's site, link removed because emutalk isn't behaving today ). If that doesn't work, maybe there's another driver you can use.

 

[squall_leonhart]

Rabiddiety, where is the forcefeedback info stored in the registry?

nvm found it

 

[R0YB0T]

First, make sure your game is running at full speed with no hitches. That's not a sure fix, but if that part isn't right then rumble isn't going to work well at all.

The N64 makes the controller rumble different amounts by turning the rumble motor on and off very rapidly. NRage emulates this by sending DirectInput effect start and stop messages. How your USB adapter's driver handles this determines how well the rumble works. Unfortunately, I can't drive your PS2 rumble motors directly, so it's up to your adapter maker to fix this.

I'd say it's an issue with your USB adapter's driver. See if there's a newer version of the software out there (a google search reveals the latest version is 3.0, at the vendor's site, link removed because emutalk isn't behaving today ). If that doesn't work, maybe there's another driver you can use.

Thank you for the work you have done and the reply!

I have the latest updates for my USB EMS 2 adapter. I have noticed that sometimes the rumble works great, and some times it works as I described it (too weak), and sometimes not at all.
I am currently testing it on OOT.

 

[rabiddeity]

Sounds to me like the adapter isn't processing the DirectInput effects fast enough. I'm not sure what I can do to fix it. Does the problem show up in 1.83?

 

[rabiddeity]

Hey guille, is the MBC code up to speed? Does everything seem to be working OK?

 

[squall_leonhart]

checked the roms and they are working.

 

[lion10]

I have discovered an other essential issue. It seems, that version V2.00(a) is absolutely incompatible with legacy Windows OS like 9x or ME. Each of my N64 emulators crashs after load and / or after press the plug-in config button. (Note, I have the newest versions of drivers, DX, emulators etc.) On Win NT based machines, I haven’t noticed such problems.

If this incompatibility is known and volitional, this must be mentioned in the readme.txt, under (system-) requirements.

 

[squall_leonhart]

Win9x Bugs are still being tested and fixed.

can you provide the crash info that is shown in the event viewer

 

[lion10]

Win9x Bugs are still being tested and fixed.

can you provide the crash info that is shown in the event viewer

There is nothing like an "event viewer" under legacy Win OS. I can provide some screenshots. After this error message pj64 and mupen freezes totally, 1964 can be closed normally after pressing “ok”.

 

[guille007]

Hey guille, is the MBC code up to speed? Does everything seem to be working OK?

all Ram are WORKING , exept for Ram enable.
Rom working exept Pocket Monster Green in Pocket Monster Stadiun 2 (J).
I can rewrite MBC code to speed up if you wish.
posible speed up :
make a switch (dwAddress >> 13) in all MBC function
put "bool (ptrfnReadCart *) (LPGBCART Cart, WORD dwAddress, BYTE *Data) in struct _GBCART and initialize this value in LoadRom(...) (not realy nesesary , but more faster)
put "bool (ptrfnWriteCart *) (LPGBCART Cart, WORD dwAddress, BYTE *Data) in struct _GBCART and initialize this value in LoadRom(...) (not realy nesesary ,but more faster)
put more logic in DebugWrite(...) (only if posible).

The rom and ram banks need to be circulate. try to read (or write) invalid bank return data from another bank. ( bank_to_read = bank % iNumRomBanks (beacause the "MBC chip" dont knock the iNumRomBanks) NO N64 ROM CHECK THIS! (code more easy)
The Default value reading in a invalid Addres could by 0x00 or 0xFF depending of circuit (pull-up or pull-down circuit) (OPTIONAL , usualy pull-up) NO N64 ROM CHECK THIS!

I have the same problem whit Rumble, sometime GREAT , sometime NOT so great.
I skip the problem by doin this:
1 ) Set Force-Fedback device = None
2 ) SAVE , and close the emulator
3 ) open emulator , and run the N64 Rom
4 ) Set Force-Fedback device = My_Pad.
5 ) ENJOY.

I have no idea of set Ram enable! , I think is beter to fix ramEnable and Pok. Green before rewrite the code.
Nrage dont work in win98, seen to be a Function in the importation table.

 

[squall_leonhart]

pokemon green will not work, none of the stadium versions were made to work with green, you need the Red J 1.1 or Blue j 1.0 roms or Red U 1.0 and Blue U 1.0 roms to use it

 

[guille007]

pokemon green will not work, none of the stadium versions were made to work with green, you need the Red J 1.1 or Blue j 1.0 roms or Red U 1.0 and Blue U 1.0 roms to use it

HAPPY NEW YEAR!!!

I know that PMGreen is not soported in Usa and Europe version but i dont know if it work in Japan version.
It's strange because you can load pokemons from P.M.Green (j) in P.M.S.2 (j) and P.M.S. GS (J). Why PMS2(j) and PMS.GS(j) allow you to run the ROM in Pokemon Tower if Green is not soported?
—http://www.nintendo.co.jp/n01/n64/software/nus_p_npsj/sonota/sonota.html
the last 2 pictures seems to be pocket Monster Green in Poket Monster Stadium 2 (j) , may be Iam wrong . I didnt find info about soport or not soport of Pocket M.Green in PMS2 (j). can you check it?
Anyway Pokemon Tower does'nt work in the emulator so take it easy

 

[Majihal]

Guille007 the green version works at least on PMS 1 and, I think, on PMS 2 too. I haven't tried on PMS GS but I think it's the same ^^
If you want I'll try this later

(and happy new year to everyone )

EDIT : It works only on japanese versions of PMS 1 & 2 of course ^^