N64 Myth programmer bug reports & recommendations

[Conle]

Okay it seems that we're going to need such a thread.
Please use this thread to either report bugs or to suggest features so that we can have a todo list of what it has to be done.


I will start this , with a recommendation and proof.



One of the main things that adds a serious factor to the slow burns is the MFC text!


Edit : Seems its not the case , please see here the modified neo2client ->
http://www.neoflash.com/forum/index.php/topic,5921.msg43171.html#msg43171

I have made a very quick demo(with source) just to prove this!
You can toggle text rendering at runtime , and you also get the total
emulated burn time.



In the above example im creating a dummy 32Mbit rom to the C drive with 1byte written per cycle and updating the mfc label if the checkbox is ticked.

Run Neo_proof.exe and see the results.Modify the variables too and see that
text rendering should be always optional.Or disabled and just render the text with the rom that should be burned , before entering the idle loop.

I hope that in the next version of n64 programmer the text will be removed or it will be optional!

This is the code for those that only want to have a quick look ->

Code: [Select]

void CNEO_ProofDlg::OnButton1()
{
running = true;

CString buf = "";

unsigned int jmp = 0;
unsigned int i = 0;
unsigned int len = 0;

m_ChunkSize.GetWindowText(buf.GetBufferSetLength(MAX_PATH),MAX_PATH);
jmp = (unsigned int)atoi((LPCTSTR)buf);

m_RomSize.GetWindowText(buf.GetBufferSetLength(MAX_PATH),MAX_PATH);
len = (unsigned int)atoi((LPCTSTR)buf);

m_Output.GetWindowText(buf.GetBufferSetLength(MAX_PATH),MAX_PATH);

m_Progressbar.SetPos(0);

FILE* f = fopen((LPCTSTR)buf,"wb");


const CString base = "Burning some '$ROM                                  '   ";


CString dummy = "";

while( i++ < jmp )
dummy += "1";

i = 0;

startTicks = clock();

char s[128];

while( i < len )
{
syncThread();

if(!running)
{
fclose(f);
break;
}

if(fwrite((LPCTSTR)dummy,1,jmp,f) != jmp)
{
MessageBox("Write error","Error",MB_OK);

fclose(f);
break;
}

if(updateText)
{
sprintf(s, "%.2f", (( i + 1) * 100.0f / len) );

buf = base;
buf += s;
buf += "%";

runtimeInfoText->SetWindowText((LPCTSTR)buf);
}

m_Progressbar.SetPos( ( i + 1) * 100 / len);
i += jmp;
}

double dt = ((double)clock() - startTicks) / CLOCKS_PER_SEC;

sprintf(s, "%.4g", dt );

buf = "Task took = ";
buf += s;
buf += "ms";

MessageBox((LPCTSTR)buf,"Stats",MB_OK);


fclose(f);
}


[Link83]

I am still having problems backing up and restoring save files using the Neo2 Ultra Menu - it does not seem to work at all for me  

I posted much of the following info in the "Testers(and not only!) dump thread" but that thread seems to have died, so I will post it here as well:-


Backing up saves using the 'Backup Save' option in the Neo2 Ultra Menu does not seem to work  

All the save files seem to dump as the correct size and file type (EEP, SRA, FLA) but none of the save files actually work on any emulators, even when using the exact same rom and giving the save file the exact same name as expected by the emulator.

When compared with a hex editor all the save files I have backed up from the N64 Myth cart(Neo2 cart) have exactly the same data, even though the saves are from entirely different games. When compared with a hex editor to their corresponding game emulator save files they seem to be completely different, leading me to believe that incorrect data is being dumped from the SRAM by the Neo2 Ultra Menu.

After burning different games when I try to restore the save file for the first game back to the N64 Myth Cart using the 'DownLoad Save' option the save file will not work at all, the game will just create a new save file.

What is interesting is that if you restore any save file, and then back it up again you will get the exact same save data you restored dumped back, even after playing and saving a number of different games.

Basically I think the Neo2 Ultra Menu is backing up and restoring saves files to an entirely different part (memory address) of the Neo2 SRAM than where the games are actually being saved to.


The Neo2 SRAM does not appear to be completely wiped clean after a new rom is burnt to the flash. I noticed that after playing Zelda OoT, then Jet Force Gemini, and then back to Zelda OoT I could still find one of my three save slots from Zelda completely intact.

I think it would be wise if the Neo2 Ultra Menu completely cleared the Neo2 SRAM for each new game burnt to flash, this would prevent problems with corrupted data where one games save partially overwrites another etc. (Not all games are programmed to write over every bit of old save data)


When I have selected the 'CARD' save type in the Neo2 Menu to save to the original boot cartridge I cannot backup this CARD save file with the Neo2 Ultra Menu, I get an error message that says 'save backup failed' (Or similar) Does that mean the Neo2 Ultra Menu cannot access the original cartridge save?

Or does it mean it will only possible to backup the CARD save type by using the N64 Myth Cart boot menu that is under development? (To copy the original boot cartridge save to the Neo2 cart)


I also have a few small suggestions/tweaks for improving the Neo2 Ultra Menu's 'N64' tab:-

- When I manually change the size of the display columns to show more of the game name text etc the change does not appear to be saved when I close and re-open the Neo2 Ultra Menu.

- Change the 'Clr ROM' button to say 'Clear ROM' (less ambiguous for new users)

- Change the name of the 'DownLoad Save' button to say 'Restore Save'

- On the 'Format' tab the 'Menu Type Select' list currently says:-
GBA/NDS
MD Myth
SNES
N64
SFC/NES

But I think it would be better if the list said:-
GBA/NDS
MD Myth
FC/NES Myth
SFC/SNES Myth
N64 Myth


I hope Dr.neo will not mind me making these suggestions  

[ChillyWilly]

Save ram issues tend to get a lower priority than running games... for some odd reason.
 

They get worked out, so don't worry. Just keep posting any problems so we don't forget.

[abignale]

Recommendation: Please release the source code of the NEO2 Ultra Menu so we can improve it while ChillyWilly works on the boot menu.

If you make it open source it can only get better. It will also make it easier to debug subtle problems with the MYTH cart.

[Conle]

I think that we should better all focus on the menu and once ChillyWilly is done with the basic functional version , then we can turn the SD version into a killer machine.If all contribute , that is.


We don't need the  programmer in order to handle saves(for example) but we definetily we're going to need the plugin's patching funtionality , but don't worry about it , because i can make a host for it.


Remember that still its not "known" how to write data to the ZIP flash of the neo2 sd cart , and patches "cannot" be done on the fly.

That's the only downside.

[ChillyWilly]

Actually, we will probably wind up writing the flash in the menu just like the Windows menu. So we probably will do patches on the fly. Patches will be kept in memory, and as a part of the rom is read from the SD, it will be modified by the patch before being written to the flash.

[Conle]

Actually, we will probably wind up writing the flash in the menu just like the Windows menu. So we probably will do patches on the fly. Patches will be kept in memory, and as a part of the rom is read from the SD, it will be modified by the patch before being written to the flash.

Well apart from Cheats & APS/IPS (if the addresses /data pairs are sorted from lo -> hi) and header patching on the fly while transfering each bock, nothing else can work.

For example . for the CRC(full) you have first to loop through all the rom to calculate the crcs , then you have to write the crcs to the header.Same applies with the CIC crc calculation.

Unless the flash isn't address locked.

[Conle]

So i modified the executable(neo2client.exe) and disabled completely the static text - >



It seems that mfc text only adds a very small factor , so im afraid that nothing can be done.
 

I have attached the modified neo2client just in case.
Extract&copy the file to C:\neo2 ultra menu\ and run neo2client2.exe .

[LPShred]

Conle,

Sorry if this insults you intelligence, but did you remove the calculations for the static text?  Just because the text isn't being displayed doesn't mean it isn't doing the calculations.  The app may still be doing a calc after each write which is never sent to screen.  Thus it would still take as long as before.  This would explain why the only a small performance gain was made.

Just a thought.  If I'm right I should get a cart to test.

-LPS

[Conle]

Conle,

Sorry if this insults you intelligence, but did you remove the calculations for the static text?  Just because the text isn't being displayed doesn't mean it isn't doing the calculations.  The app may still be doing a calc after each write which is never sent to screen.  Thus it would still take as long as before.  This would explain why the only a small performance gain was made.

Just a thought.  If I'm right I should get a cart to test.

-LPS

I don't have the source of N64 Myth programmer , so i just modified the resources in the executable & changed some mfc flags for the given control.

Regarding calculations in an idle loop , its no issue for a modern cpu.Its just simple math.
The text rendering from the other hand is very slow , because of how mfc text rendering works.Its not like in a modern graphics engine were you can use texture mapped font which is 1x quadrilateral uploaded to the GPU.

Unfortunately its the way the whole thing works.Writes , validates , does some delays so really mfc text is not the issue im afraid.

For example , download and try madmonkey's MD MYTH test programmer and notice how much faster it writes the data.That's because there are no delays or data validation.

[LPShred]

I don't have the source of N64 Myth programmer , so i just modified the resources in the executable & changed some mfc flags for the given control.

Regarding calculations in an idle loop , its no issue for a modern cpu.Its just simple math.
The text rendering from the other hand is very slow , because of how mfc text rendering works.Its not like in a modern graphics engine were you can use texture mapped font which is 1x quadrilateral uploaded to the GPU.

Unfortunately its the way the whole thing works.Writes , validates , does some delays so really mfc text is not the issue im afraid.

For example , download and try madmonkey's MD MYTH test programmer and notice how much faster it writes the data.That's because there are no delays or data validation.

Hmm.  I never realized that drawing the text would consume more resources than preforming the actual calculations.  But apparently that's not the problem. 

It looks like we will have to wait to see the source before we can speed up the process.

[Link83]

Ok, I have just been testing the new Neo2 Ultra Menu V2.98, and I still can not backup and restore saves. However after some experimentation I have found out something interesting....

I believe there are actually two SRAM chips being used, one in the Neo2 cartridge and one in the N64 Myth cartridge (I had been wondering why their was a battery inside the N64 Myth Cart!) Apologies if this was already well known, but I had not read about this anywhere else before.

The Neo2 Ultra Menu is currently only backing up the SRAM from one of these chips (I think its backing up the Neo2 cartridge SRAM) Which is why we cannot currently backup and restore N64 saves as they are being saved to the other SRAM chip. We need a new menu option so that we can backup and restore the SRAM on both cartridges separately.

I discovered this whilst examining the SRAM dumps and Save backups using a Hex Editor (Hex Workshop) First I byte flipped the 2Mbit/256KByte SRAM dump which showed that there was already a game save file called "ANCMMOSUUE6M 4" which when byte flipped was actually "NAMCOMUSEUM64", which is an N64 game I have never even played! I am guessing my tester cartridges had previously been used by Dr.neo in the N64 Myth testing process?  

Something else that is interesting is that my SRAM dump file is a complete match for the first 256Kbyte of the "Namco Museum (U) [!]" rom!? I thought games were only saved to the Flash chip, not SRAM? Is it possible the Neo2 Ultra Menu is dumping data from the PSRAM instead of SRAM? (I thought PSRAM was cleared once the console is turned off)

The SRAM dump and the Save backup contained no save data from any of the games I have previously played (Which is what further confirmed my "Two SRAM chips" theory)


Then I byte flipped the 256Kbit/32KByte .sra Save backup, and did a 'Resynchronizing Compare' to the 2Mbit/256KByte .bin SRAM data dump, and it appears that the save backup is mostly just a small part of the complete SRAM dump, it completely matched the data from offsets 8192 [0x00002000] to 32768 [0x00008000].

The strange thing is the Save backup appears to have the first 8192 bytes blank as' 00 FF', its like the first 8192 bytes of the SRAM data are purposefully cut off and then replaced with blank data by the Neo2 Ultra Menu when creating the Save Backup. It actually cuts off some important parts of the original Namco Museum 64 data.

Just to confuse matters a little more, the byte ordering for the SRAM dump and the Save backup files were not identical - I had to byte flip the SRAM dump as '16 Bit Unsigned Short' and byte flip the Save backup dump as '32 Bit Unsigned Long' so that they were 'human readable' and would match

I hope this info can maybe help someone fix some issues  

[f0rm0za]

I can not save and restore 16Kbit EEPROMS (Conker; Donkey Kong..., Etc.)
But 4 Kbit EPPROMS are saved and restored excellently.
Whether this problem in following upgrades will be solved?
 

[Conle]

I can not save and restore 16Kbit EEPROMS (Conker; Donkey Kong..., Etc.)
But 4 Kbit EPPROMS are saved and restored excellently.
Whether this problem in following upgrades will be solved?
 

Hopefully there will be a fix , but would be a cool addition for ChillyWilly's n64 menu