It is currently Mon Dec 10, 2018 6:57 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Fri Oct 05, 2018 10:51 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2119
Location: Fukuoka, Japan
I'm trying to find what is the cause that I cannot write to some flash eeprom and for now the only reason I can come with is:

1) the burner is not working fine anymore
2) the burner, which work only under xp, doesn't work fine inside virtual box (will test with new XP on different partition tonight)
3) the flash eeprom, after so many year, cannot be written to anymore

Some flash eeprom failed the first check inside program, all other fails at the writing phase. The first one I tried was still working inside the dev cart I didn't touch for 10 years so the chip itself seems fine.

I think the most probable cause is either 1 or 2 but I'm asking, just in case, if #3 would be a possibility.


Top
 Profile  
 
PostPosted: Fri Oct 05, 2018 10:57 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7804
Location: Seattle
I have successfully used two USB-based programmers under XP-on-VirtualBox-on-linux, but my first hunch is still that that's your problem.

How have you been storing the EEPROMs? Any possibility of static electricity damage?


Top
 Profile  
 
PostPosted: Fri Oct 05, 2018 10:58 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7006
Location: Canada
I have a TOP853 that I have used many times through the XP VM in Windows 7 Ultimate, so in my experience the VM has been fine. I think if you had a problem with the VM / device communication it would probably manifest as not connecting to the device at all.

There are lots of ways that EPROM and EEPROM can go bad though, that doesn't seem like an unusual thing to me.

Dunno anything about how often programmer hardware fails... I only have experience with a few but I've never seen one die yet.

So my vote is 3. Did you try more than one EEPROM?


Top
 Profile  
 
PostPosted: Sat Oct 06, 2018 12:03 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2119
Location: Fukuoka, Japan
@lidnariq

I will know tonight after installing a fast xp partition. As for how they were stored, the devcart itself that had eeprom still on it was in a box with other carts and stayed most of the time there since the move (more or less 7 years). I was under my desk and when I inserted it inside the famicom, the last thing I tested was still there so both eeprom on the cart seems to be readable. What I don't know about flash eeprom is if they can go bad for writing only. My guess would be that this probability is low but since I'm not knowledgeable on the subject, I kept it on my list of possible issues.

As for the other flash eeprom, they were on my desk since I moved and stayed in some plastic box that I received when I bought them. Is it appropriate storage? I hope so but cannot tell. They are near a monitor but I do not think that the heat could cause an issue.

@rainwarrior

Since the other flash eeprom failed the same way I decided to ask the question since it seemed odd and because I do not know much on the subject. Only one reacted differently so this one only could be broken per se.

I will try it tonight with xp and see the result. If the programmer is dead then it was quite an expensive use since I barely used it ^^;;;


Top
 Profile  
 
PostPosted: Sat Oct 06, 2018 12:22 am 
Online

Joined: Tue Aug 28, 2018 8:54 am
Posts: 100
Location: Edmonton, Canada
I've worked with just couple EEPROMs, they had ~10000 cycles (depends on memory type) per cell after which it is not guaranteed to read/write data without errors. Unless you were reprogramming your memory from the NES itself (like every frame) I doubt it failed you on that part. Some could loose data overtime, especially if not connected to power, but should work fine after read/write cycle.


Top
 Profile  
 
PostPosted: Sat Oct 06, 2018 8:56 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2119
Location: Fukuoka, Japan
I reinstalled a windows XP and tested it and the hardware is working fine. I'm now testing again in the VM.

After testing on XP, I found something by accident: the software is very un-intuitive and doesn't warn you if you forget to set a setting that is required to be done (for example, the chip maker/format you are going to write to) and just let you do without any warning. When you do so, it just fail without any error that make sense. I just found back the option by accident (clicked a button that didn't look like one..) and now with that option it seems to work under the VM too.

So I may be fine without a real XP after all but I just hate how those software are poorly written. I will test if the written chip is working fine but I think it now should.

I apologize for wasting time on a software issue that couldn't be guessed without knowing the actual software m (_ _) m

One thing for sure, I did enjoy to see again XP in classic mode, feel so familiar compared to windows 10 ^^;;;


Top
 Profile  
 
PostPosted: Sat Oct 06, 2018 9:24 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
I recently ran a bootable XP DVD for recovery purposes and damn, that thing was FAST! The mouse cursor was so incredibly smooth, and every window opened instantly! It would be so great if software didn't become bloated at the same rate as the hardware got more powerful so that we could get that kind of performance in current OSs...


Top
 Profile  
 
PostPosted: Sat Oct 06, 2018 9:35 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2119
Location: Fukuoka, Japan
The current build of Windows 10 (compared to the early one which were faster) only became better since I installed an ssd in my machine recently. It's need a faster hd so it can prepare all the telemetry it wants... XP, super fast on that old hd.

The dev cart was working before rewriting the chip (did a test before removing them) so either something is now wrong with the cart or the way I prepared the chr data is not appropriate. Testing in the VM or real WinXP for writing the eeprom gives the same result so maybe the content or cart is the issue.

What I did is took the CHR data and repeated it to fill the 512k chip. I just did a simple cat file file file > target to create the file so it should be fine (this is what I did for the PRG and the code is executing properly). I only see full colored screen like if no tile data existed at all.

I will try with another chip to see if it works better but waiting 5 minutes+ for every rewrite is awful ^^;;

edit:

Found the cause. Even though the mapper uses 256k, the chip 512k as to be fully filled with the same information. So it was not seeing the proper data. It's been a while so I forgot to use those eeprom too.

Thanks everyone for the support. I'm getting back on track now.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group