It is currently Wed Oct 18, 2017 3:23 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Wed Jul 03, 2013 9:11 pm 
Offline
User avatar

Joined: Fri Sep 02, 2011 8:34 pm
Posts: 476
lidnariq wrote:
bazz wrote:
Well, I thought it would necessary for fast pc->sram r/w, but please do correct me if I am wrong. I will have to see.

Doing the math: 140ns × 524288 bytes = 7.3ms. Also, the SNES can't read from anything in its cartridge slot in less than 140ns. (one read cycle at fastest is 3.6MHz; half of that is 140ns)

Pretending for the moment that you wanted to build a 12MB/95Mbit SNES RAM cartridge, that would still only be 1/5 of a second. Anything faster is entirely wasted.


The reason why I have a problem accepting your answer is because I do not see the full picture here of how this is associated with the yet to be found optimal USB transfer and how the speeds of that transfer are affected any way (such as micro controller speed?) This is all new to me so please be slow.

Also, in the GB Flasher, it used a crystal of 6Mhz with the FTDI chip, I wonder how that works and could it be sped up. I have yet to learn how it all works.

My gripe here is that I want to be sure I am venturing in the right direction. It takes a lot of learning . It would be nice to take the correct approach first.


Top
 Profile  
 
PostPosted: Wed Jul 03, 2013 9:14 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6277
Location: Seattle
Great. 4Mbit is 512KiB. You don't need to be faster than 200ms. (That's as fast as a nominal web page load). Doing the math: You don't need a write speed faster than 2.5MB/sec, or 20mbit/sec, or a byte every 400ns.

This is 1/20th of USB2.0 "high speed". It's about 2x USB1.1"full speed".


Top
 Profile  
 
PostPosted: Wed Jul 03, 2013 9:15 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6277
Location: Seattle
bazz wrote:
Also, in the GB Flasher, it used a crystal of 6Mhz with the FTDI chip, I wonder how that works and could it be sped up. I have yet to learn how it all works.

The 6MHz crystal is specifically used as the reference timebase for USB communication; it must be a factor of either 12MHz or 480MHz (depending on the specific variant of USB spoken)
The ratio is probably fixed in hardware.


Top
 Profile  
 
PostPosted: Wed Jul 03, 2013 9:20 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6277
Location: Seattle
bazz wrote:
My gripe here is that I want to be sure I am venturing in the right direction. It takes a lot of learning . It would be nice to take the correct approach first.

Let's try this: What Are You Really Trying To Do?
I'm guessing the answer is "build a really fast programmer", so if I'm right, let me follow that with:
What are you going to use that really fast programmer to do?


Top
 Profile  
 
PostPosted: Wed Jul 03, 2013 9:33 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19096
Location: NE Indiana, USA (NTSC)
From the moment I saw "EPROM emulator", I realized that the OP is trying to run a freshly built ROM image on hardware without having to pull the CF out of the PowerPak all the time. When the user clicks "Build and Run" in an IDE, the IDE rebuilds the ROM image from source code and then, instead of opening an emulator, sends it to the cart. Then the cart should write this image to SRAM or PSRAM, connect the RAM to the Super NES cart bus as if it were ROM, and reset the Super NES Control Deck.

Or are you asking what one is trying to do by developing software for the Super NES in the first place?


Top
 Profile  
 
PostPosted: Wed Jul 03, 2013 9:47 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6277
Location: Seattle
Ok, so then the next questions are:
How long do you think it will take to build said ROM image?
What percentage overhead is permissible to program a device relative to the time it takes to build said image?
Which of the many aspects of the obnoxiousness of removing the CF/SD card from the powerpak/everdrive are the ones you want to fix?
What if you had to pick only one of them?


Top
 Profile  
 
PostPosted: Wed Jul 03, 2013 10:08 pm 
Offline
User avatar

Joined: Fri Sep 02, 2011 8:34 pm
Posts: 476
tepples wrote:
From the moment I saw "EPROM emulator", I realized that the OP is trying to run a freshly built ROM image on hardware without having to pull the CF out of the PowerPak all the time. When the user clicks "Build and Run" in an IDE, the IDE rebuilds the ROM image from source code and then, instead of opening an emulator, sends it to the cart. Then the cart should write this image to SRAM or PSRAM, connect the RAM to the Super NES cart bus as if it were ROM, and reset the Super NES Control Deck.

Or are you asking what one is trying to do by developing software for the Super NES in the first place?

You are hitting the nail on the head, except no PowerPak.

lidnariq wrote:
Ok, so then the next questions are:
How long do you think it will take to build said ROM image?

Beats me. It's supposed to go hand-in-hand with a game I am writing in C++ and SDL. So I imagine a multi-platform release with a SNES version to go along.

Quote:
What percentage overhead is permissible to program a device relative to the time it takes to build said image?

Very interesting question. I am just enjoying learning. I am not too worried about the relationship between the overhead, because it is teaching me to be patient.[/quote]

Quote:
Which of the many aspects of the obnoxiousness of removing the CF/SD card from the powerpak/everdrive are the ones you want to fix?


I have never tried these devices, so I am not sure. I have a variety of goals that if I organized in serial fashion would be this.

1) Get money
2) Purchase assorted supplies for:
3) Building a Gameboy Cartridge flasher
a) learn about electronics
b) learn about micro-controllers
c) learn about USB (2.0)
d) figure out best approach or design that is the best
e) clean, simple, fast,
f) be happy

4) make modifications and boards for snes flasher
a) modify firmware / software to reflect SNES aspects
b) possibly segment the software into a combination software for one unit that can do both

5) I am still interested. Make Eprom Emulator for the perfect explanation Tepples gave as reason for its existence.

6) Work on my incompleted SNES VRAM organizer software for importing graphics and exporting VRAM binary for direct DMA. here is a writeup on it, and github: http://www.bazz1.com/snes-gfx-edit/

That has to be determined whether to continue in QT, or I can program in an easier and more intuitive environment. This will involve learning more about graphics file formats such as PNG.

7) Work on SNES game

There's more to it. Ok I'll keep going

8) Minimalize SDL version of the game, ensure raw graphics are directly usable for harmless intuition of use with both SNES and ports. Harmonized to use SVG graphics format with a multi platform SVG->PNG conversion that is in the works, allows exporting SVG at any scale with no less in quality. http://www.youtube.com/watch?v=70YGaHByQSQ
This may or may not help with different screen resolutions. Inconclusive, yet seems to be safest approach. However, I do not know how friendly SVG format is with pixel artist types.

9) Get in touch more with graphics artists. Tighten up art specifications for enemies and objects.
10) Get money

11) Continue programming game in SNES and SDL. Stay happy. Have fun.
12) We'll get there.


Top
 Profile  
 
PostPosted: Thu Jul 04, 2013 3:16 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6277
Location: Seattle
Sounds like a great plan!

One of the best rules of thumb of inexpensive¹ engineering is: build the simplest thing that could possibly work. Figure out what you like, or don't like about it.

Once you've got something to compare to, and with the experience of having built something, you'll now have the experience to know what to change, how to change, and where you need to do further research.

¹ Inexpensive means "in terms of human life" or "lawsuits", so e.g. the space shuttle, medical research, and bridges don't count. Software, most electrical engineering, some bioengineering and mechanical engineering does.


Top
 Profile  
 
PostPosted: Thu Jul 04, 2013 4:01 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
I suggest cutting all the superfluous complicated electronics and just stick with the basics:
bazz wrote:
1) Get money
...
f) be happy
...
10) Get money
...
11) Stay happy. Have fun.


On a serious note, one thing to consider for target times is the erase time of the memory you're considering. Large flash chips take ~1min or more to erase. So in that situation having a 2 second programmer is kind of pointless. Not that large flash is bad, or 2 seconds isn't valuable time savings. But I'd consider things like that when considering the speed of the overall design. If you've settled on slow erasing flash chips, then there isn't much point to jump through a bunch of hoops for sub-10second USB speeds.

In regards to flash writing speeds using a chip with buffered writes can drastically reduce programing speeds. I went from ~12min to ~3min with this switch on one of my projects just due to buffered writes alone. It's also much more stable and reliable than programing individual bytes.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Thu Jul 04, 2013 5:35 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19096
Location: NE Indiana, USA (NTSC)
infiniteneslives wrote:
On a serious note, one thing to consider for target times is the erase time of the memory you're considering. Large flash chips take ~1min or more to erase.

I think that's why the OP is going with RAM instead: erase happens in the same 140 ns it takes to program each byte.

In any case, if you're not using all the RAM in the console, there's always the option to make a cart that just receives 184 KiB of data, stashes it in $7E2000-$7FFFFF and VRAM $0000-$7FFF, and redirects the interrupt vectors. That might be the simplest thing that could possibly allow testing 1-level builds of your game.


Top
 Profile  
 
PostPosted: Thu Jul 04, 2013 11:17 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
Yes RAM is a nice option when considering writability/erasability. But it has it's drawbacks of being volatile, cost, and easy corruption. When I realized my programming options were not going to cheaply/easily reach USB 2.0 programming speeds, RAM started loosing it's edge.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Thu Jul 04, 2013 1:12 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19096
Location: NE Indiana, USA (NTSC)
If it takes only one to three seconds to reprogram the RAM while the cart is connected to a PC that's providing power, you don't really need to worry about volatility so much.


Top
 Profile  
 
PostPosted: Thu Jul 04, 2013 5:56 pm 
Offline
User avatar

Joined: Fri Sep 02, 2011 8:34 pm
Posts: 476
Can you fellas remind me of the most important speed factors in accomplishing a speedy upload/download of Flash Memory? Assuming this setup is through USB (hiSpeed, or Full), and uses a microcontroller. I can't be much more clearer than that (literally)


Top
 Profile  
 
PostPosted: Thu Jul 04, 2013 6:14 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
I'm not sure what you're looking for exactly... Speed factors? What kind of details are you asking for? I've tried to provide general input on the matter. So if you can explain how that input isn't what you're looking for, or what kind of 'factors' your asking about perhaps I can re-direct my answer.

Things to consider that might answer your question:

*Using a micro-controller to receive data serially in any fashion will be slower than if the mcu can get data in byte chunks from what ever is handling the USB comms. The less time the mcu has to handle recieving data, the more time it can devote to pumping data into the flash.

*Writing to flash is gernally slow, especially old ones. Current day chips (ones which are still in production) often have means to improve the programming time. As I pointed out previously buffered writes is one of these tactics. Another is accelerated voltage for faster programming, this is generally 12v you can apply to a specific pin for faster writes.

*Optimizations can make a big difference depending on the application. If you're developing a game, each build won't likely need the entire chip erased and reprogrammed. If you do the extra work to sense what bytes/sectors were affected, then you could just transfer the data needed to make those modifications and reflash the needed sectors only.

Some other optimizations could be taking advantage of the time the mcu is waiting on the flash chip to finish it's write. Instead of sitting there and polling the flash for several micro-seconds, the mcu could be making use of that 'down time' to fetch the next chunk of serial data.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Thu Jul 04, 2013 6:31 pm 
Offline
User avatar

Joined: Fri Sep 02, 2011 8:34 pm
Posts: 476
infiniteneslives wrote:

*Using a micro-controller to receive data serially in any fashion will be slower than if the mcu can get data in byte chunks from what ever is handling the USB comms. The less time the mcu has to handle recieving data, the more time it can devote to pumping data into the flash.


Get the data in byte chunks. What is this called? I am investigating High-Speed USB support with microcontrollers, and I started learning about USB specification, for instance Bulk transfer and - isochronous - is faster but not guaranteed, bulk is always guaranteed. I figured to go with Bulk for my first time around. Now I feel as to try isochronous. However, I don't very much understand the difference between serial transfer and receiving in byte chunks as you suggest. I don't even know where to start.[/quote]
Quote:
*Writing to flash is gernally slow, especially old ones. Current day chips (ones which are still in production) often have means to improve the programming time. As I pointed out previously buffered writes is one of these tactics. Another is accelerated voltage for faster programming, this is generally 12v you can apply to a specific pin for faster writes.

Interesting,
Quote:
*Optimizations can make a big difference depending on the application. If you're developing a game, each build won't likely need the entire chip erased and reprogrammed. If you do the extra work to sense what bytes/sectors were affected, then you could just transfer the data needed to make those modifications and reflash the needed sectors only.

My plans exactly. Let's not forget I am programming a flasher first, and not the Eprom Emulator. Therefore, this method will only be useful for the RAM method. However, it could still be used to possibly narrow down segments of flash as well.[/quote]
Quote:
Some other optimizations could be taking advantage of the time the mcu is waiting on the flash chip to finish it's write. Instead of sitting there and polling the flash for several micro-seconds, the mcu could be making use of that 'down time' to fetch the next chunk of serial data.
no comment


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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