Open Source Flash Cart
Started by Delicon, Feb 28 2005 2:21 PM
110 replies to this topic
#26
Posted Tue Mar 15, 2005 8:57 PM
The problem is getting the logic out of the cpld. There's not enough pins to do everything you want to do.
#27
Posted Tue Mar 15, 2005 9:06 PM
batari said:
Quote
there will be no 3F bankswitching
Really? According to Kevin Horton's bankswitching document, 3F can be implemented with a single chip - a 74LS173. I can't imagine that any TTL chip could be that complicated, but maybe I'm wrong.
Dav has it right. It has nothing to do with how difficult or easy the task is. I simply dont have any more pins on the CPLD. 3F is different than the other bankswitchings in that it uses the data lines to tell what bank to go to. The CPLD right know doesnt have any data lines running to it. No more pins. I am drawing up the SMT version right now. I dont think I will have it routed tonight, but I should have the schematic up. The SMT version will be 64K flash, support 3F, and have a usb interface. I am about halfway done. I have a couple more library entries to make first. They always take the longest.
The files I posted are in Xilinx's schematic data format. You need to use Xilinx's software to view them.
The files are viewable right?
Thanks,
Vern
#28
Posted Tue Mar 15, 2005 11:03 PM
Delicon said:
The files are viewable right?
Thanks,
Vern
Thanks,
Vern
Yep, opened right up. Didn't actually try to figure anything out though.
#29
Posted Wed Mar 16, 2005 12:00 AM
[quote]I simply dont have any more pins on the CPLD[/quote]
That's a shame... Since I think you need just two: for D0 and D1. I wonder if there's a compromise, like to combine some of the upper address lines by adding a few well-placed resistors to free up two pins? I guess it would depend on what the CPLD considers a valid low and high and whether one would be willing to deal with a half-dozen resistors or so just to get a few games to work.[/quote]
That's a shame... Since I think you need just two: for D0 and D1. I wonder if there's a compromise, like to combine some of the upper address lines by adding a few well-placed resistors to free up two pins? I guess it would depend on what the CPLD considers a valid low and high and whether one would be willing to deal with a half-dozen resistors or so just to get a few games to work.[/quote]
#30
Posted Wed Mar 16, 2005 1:41 AM
batari said:
Quote
I simply dont have any more pins on the CPLD
I cant cut the pins any more without cutting the flash and RAM sizes. I am not sure what you mean with the resistors.
There are two other possible solutions. One possibility is to up the CPLD package size to a PLCC84, this would give us plenty of pins, but the downside is that cartridge case modifications would be needed to fit the board in. It wouldnt be too bad really. The other possibility is to up the package to a PLCC84 again, but do it without a socket. This would make the case modification unneeded, but would require a higher soldering skill. At that point it would almost be surface mount soldering.
To be honest, I would like to scrap the through hole design and go only with the surface mount. Its so much nicer. USB interface, no power supply, no extra parts, everything is in the cart. With surface mount its possible to go up to 1Meg of flash. All the bankswitching would be supported. Its just so much nicer.
Vern
#31
Posted Wed Mar 16, 2005 2:21 AM
I haven't really looked at what your doing closely but, it kind of looks like you have the full 32k of ram available? I can't imagine anyone needing more than 2k. btw, I think they've extended the 3f banking in some of the new dev carts to more than 2 bits. not sure if anyone's using it though.
I agree though, going to surface mount is a good solution.
I agree though, going to surface mount is a good solution.
#32
Posted Wed Mar 16, 2005 2:39 AM
Try Xilinx webpack, its a free d/l and its a damned nice package!
Curt
Curt
#33
Posted Wed Mar 16, 2005 9:25 AM
Dav said:
I haven't really looked at what your doing closely but, it kind of looks like you have the full 32k of ram available? I can't imagine anyone needing more than 2k. btw, I think they've extended the 3f banking in some of the new dev carts to more than 2 bits. not sure if anyone's using it though.
I agree though, going to surface mount is a good solution.
I agree though, going to surface mount is a good solution.
The full 32K of ram is available, though none of the bankswitching takes advantage of it. The only reason that I have used 32K and not 2K is price. They cost the same, actually, 2K costs more in the DIP package. So why not just put the bigger one on the board. Maybe somebody could use it. Going to 2K doesnt save pins, flash and ram share the same address bus in my design.
I used to be deathly afraid of surface mount. While on a contract job I met a Tech that was soldering stuff by hand that I thought could only be done by a machine. After talking to him for a while and about one half an hour of demonstrations I realized that its all in the tools (and you need ok eye sight). The tools you need are tweezers, flux, fine wire solder, a soldering iron with a fine tip (1mm max), and a hotair rework station. With these tools I havent run into anything I havent been able to stick to the board, including recently figuring out MLF and BGA. I will admit I had a little trouble with them in the beginning, but I worked them out, and the solution was simple. No need to mess with solder paste and ovens.
Tools can be a little pricey, with hotair being the biggest I think. Its really not that bad if you look around a little. I spent $150 on mine and it is as good as the Tech's mentioned above that cost well over $800. For $185 you can get the same hotair with a soldering iron.
Surface mount coming real soon.
Vern
#34
Posted Wed Mar 16, 2005 5:45 PM
Frankly, I'm very afraid of surface mount. My eyesight is not too good and my manual dexterity is limited. I can barely do the 0.1" pins from the sockets.
Anyway, What I meant by combining some of the upper address lines is, since they are essentially connected to an AND gate, you can use some small-signal diodes (forgot about these) and resistors. I remember once using something like the circuit that I'll attempt to post (although I might be wrong, my memory is bad.) Anyway, combining A11 and A12 to free up a pin might go like the pic. Of course the CPLD will need to consider around 1V as low to work, which might be a deal-breaker.
Anyway, What I meant by combining some of the upper address lines is, since they are essentially connected to an AND gate, you can use some small-signal diodes (forgot about these) and resistors. I remember once using something like the circuit that I'll attempt to post (although I might be wrong, my memory is bad.) Anyway, combining A11 and A12 to free up a pin might go like the pic. Of course the CPLD will need to consider around 1V as low to work, which might be a deal-breaker.
#35
Posted Wed Mar 16, 2005 6:51 PM
Actually, looking at this again, I'm not sure that the 1k resistors are even necessary. Are they? If not, the low would go to 0.7V and thus be much more likely to work, plus you could add A10 in there too with another diode and free up the two pins with only three diodes and one resistor.
Can anyone see any reason why this wouldn't work?
Can anyone see any reason why this wouldn't work?
#36
Posted Wed Mar 16, 2005 8:00 PM
I feel really silly, but I cant see how this helps. I hope it does. Please explain more.
Here is the problem I see. I need to filter out certain addresses for different bank switching schemes. An example address might be 0x1FF8, another is 0x1000. So, if I am using your circuit as a wired AND, I would be able to detect the first address, but not the second. I may not be understanding you correctly.
I think I know a way to free up a few pins, but man what a headache it would be. In the current design, there are two separate address busses. One is the VCS address bus (A0-A12) and one is the modified larger bankswitching address bus (A0-A14). I call them AVCS and ACART respectively. They are completely separate with only the CPLD as a bridge. Its not really necessary to have them completely separate, because many of the bits are never modified by any of the different bankswitching schemes. In a perfect world I could just bridge them directly and save myself some pins. But the show stopper is flash programming.
In order to program the flash, a microcontroller needs access to the full ACART. There is no way for a microcontroller to have access to the ACART when it doesnt live on the cart, so I made the CPLD act as a bridge for it also. The microcontroller serially shifts in a 15 bit address that gets placed on the ACART.
What I think I can do is to do a direct bridge of a couple pins, and then have the microcontroller shift in one or two less bits along with changing the direct bridge bit. So for example, (this bit wont work in real life, its just for ease of demonstration) directly bridge bit 0. That would remove two pins AVCS0 and ACART0. Then when programming, the microcontroller now shifts in 14 bits (A1-A14) and manually changes bit 0 through the direct A0 bridge.
This leads to a nightmare, because the real bits would be like bit3 and bit5, and goes against the KISS (keep it simple stupid) principle. I think it would work, but I am not sure I want to try right now.
Let me know if I made no sense at all and I will try to explain better.
Vern
Here is the problem I see. I need to filter out certain addresses for different bank switching schemes. An example address might be 0x1FF8, another is 0x1000. So, if I am using your circuit as a wired AND, I would be able to detect the first address, but not the second. I may not be understanding you correctly.
I think I know a way to free up a few pins, but man what a headache it would be. In the current design, there are two separate address busses. One is the VCS address bus (A0-A12) and one is the modified larger bankswitching address bus (A0-A14). I call them AVCS and ACART respectively. They are completely separate with only the CPLD as a bridge. Its not really necessary to have them completely separate, because many of the bits are never modified by any of the different bankswitching schemes. In a perfect world I could just bridge them directly and save myself some pins. But the show stopper is flash programming.
In order to program the flash, a microcontroller needs access to the full ACART. There is no way for a microcontroller to have access to the ACART when it doesnt live on the cart, so I made the CPLD act as a bridge for it also. The microcontroller serially shifts in a 15 bit address that gets placed on the ACART.
What I think I can do is to do a direct bridge of a couple pins, and then have the microcontroller shift in one or two less bits along with changing the direct bridge bit. So for example, (this bit wont work in real life, its just for ease of demonstration) directly bridge bit 0. That would remove two pins AVCS0 and ACART0. Then when programming, the microcontroller now shifts in 14 bits (A1-A14) and manually changes bit 0 through the direct A0 bridge.
This leads to a nightmare, because the real bits would be like bit3 and bit5, and goes against the KISS (keep it simple stupid) principle. I think it would work, but I am not sure I want to try right now.
Let me know if I made no sense at all and I will try to explain better.
Vern
#37
Posted Wed Mar 16, 2005 8:33 PM
Yes, it is just an AND of those upper addresses. I forgot about the need for lower addresses to access superchip RAM, plus I didn't realize you were bridging all of the address lines. This definitely requires that you connect them all.
I was just looking for a quick fix - I'd rather that you got this thing going without 3F if it means we'll be able to build our own sooner.
I was just looking for a quick fix - I'd rather that you got this thing going without 3F if it means we'll be able to build our own sooner.
#38
Posted Wed Mar 16, 2005 9:00 PM
I have been thinking about this more and I think I can do it. Someone help me out, I have been staring at all the bankswitching methods, and to my knowledge, none of them modify bits 0-6. Someone double check me please. If this is the case then the solution I mentioned above wont be too difficult. It was only going to be a pain when the bits were mixed in the middle somewhere, but if they are the end bits, it wont be that hard.
Let me know and I will work on a new design that will handle this 3F problem and give us back the 32K of lost flash.
Thanks,
Vern
Let me know and I will work on a new design that will handle this 3F problem and give us back the 32K of lost flash.
Thanks,
Vern
#39
Posted Wed Mar 16, 2005 9:44 PM
I agree witht that. If the minimum block size by any method is 128 bytes, then A0-A6 will be completely unaffected and do not need to be bridged by the CPLD. With 7 extra pins, you could also support 3F extended to 32k, I think.
#40
Posted Wed Mar 16, 2005 9:54 PM
batari said:
I agree witht that. If the minimum block size by any method is 128 bytes, then A0-A6 will be completely unaffected and do not need to be bridged by the CPLD. With 7 extra pins, you could also support 3F extended to 32k, I think.
Thanks for the check, thats what I thought. I am only actually going to bridge bits 0-2. That frees up 6 pins. One pin will give me back 64K of flash and 4 pins for data bit 0-3. That will let 3F address all 64K of flash. One extra pin left. I would bridge all 7 bits, but I have just enough pins on my programmer now that I added the 3 extra above.
I am working on it right now.
Vern
#41
Posted Wed Mar 16, 2005 10:43 PM
Ok you lost me here. You are still bridging a0,a1,a2? If you drop the bridge for a3-a6 you still want inputs, so that frees up 4 pins right?
#42
Posted Wed Mar 16, 2005 11:01 PM
Dav said:
Ok you lost me here. You are still bridging a0,a1,a2? If you drop the bridge for a3-a6 you still want inputs, so that frees up 4 pins right?
If I do a direct bridge between address bits 0-2 (not using the CPLD anymore). That means I dont need an AVCS0, AVCS1, AVCS2, or ACART0, ACART1, ACART2 pins on the CPLD. 6 pins free.
I am not touching address bits 3-6, I am leaving them the same, letting the CPLD bridge them. The reason I am not touching them is because for every address bit I bridge directly, I need a pin on the programming microcontroller to make up for it. I dont have 7 extra pins on the microcontroller, just 3.
Of the 6 free pins I am going to use 5 of them. 4 pins for D0-D3 and 1 pin for A15 on the flash (to get back all 64K).
Anyone know if I do a copper pour on the top and bottom of the board tied to GND, will this help eliminate some noise???
Thanks,
Vern
#43
Posted Wed Mar 16, 2005 11:27 PM
a0 from the vcs still needs to go into the cpld so you can tell the difference between 1ff8 and 1ff9 right? or am I missing something? I haven't looked at your design so this might be a silly question.
#44
Posted Wed Mar 16, 2005 11:37 PM
Dav said:
a0 from the vcs still needs to go into the cpld so you can tell the difference between 1ff8 and 1ff9 right? or am I missing something? I haven't looked at your design so this might be a silly question.
Dav, I dont know what I was thinking. You are right. I guess, just to be safe, all VCS address bits need to go into CPLD, if not for bankswitching now, maybe for a new one in the future.
So I guess, that only give me 3 free pins if I do AVCS0-AVCS2. I will look at my programmer and see if I can get a couple pins from it. I am using an Atmel ATMega8 right now. Maybe a have to upgrade to a Mega that has more IO.
Thanks for pointing that out, I will make the changes. Any thoughts on the copper pour?
Vern
#45
Posted Thu Mar 17, 2005 12:16 AM
I figured it out. I am going to multiplex the three pins on the microcontroller that are connected to the CPLD JTAG pins. It all works out. I will post schematics tonight, I will get to the board in the morning.
Vern
Vern
#46
Posted Thu Mar 17, 2005 4:49 AM
OK, its 3:30am and I think I have a solution for everybody. This is a new version of the through hole design that now supports 3F and 64K flash. Now for the surface mount fans, I added the programmer and a USB interface also. So the board has the best of both worlds. If you want you can only do the through hole, but you will need to program with an external programmer, and power source. If you do the surface mount stuff also, you get the programmer, USB, and power supply built in.
I let the software do the routing because there wasnt a chance in hell I was routing this bastard. So who knows if noise will be a problem.
I havent had a chance to double check the connection, so dont go ordering these, I just want them out there for you guys to look over if you wanted. I will check and order tomorrow.
Also, think about how you want the external programmer setup. Do you want a cartridge slot style thing, I can get connectors (different than the VCS connectors, see the second picture I posted in this thread)? I could also do like a ribbon cable type connector to the cartridge. Do you want it in a plastic enclosure or just open? If so, suggest an enclosure so I can design for it.
Good night,
Vern
I let the software do the routing because there wasnt a chance in hell I was routing this bastard. So who knows if noise will be a problem.
I havent had a chance to double check the connection, so dont go ordering these, I just want them out there for you guys to look over if you wanted. I will check and order tomorrow.
Also, think about how you want the external programmer setup. Do you want a cartridge slot style thing, I can get connectors (different than the VCS connectors, see the second picture I posted in this thread)? I could also do like a ribbon cable type connector to the cartridge. Do you want it in a plastic enclosure or just open? If so, suggest an enclosure so I can design for it.
Good night,
Vern
Attached Files
#47
Posted Thu Mar 17, 2005 12:51 PM
Vern !
>Any thoughts on the copper pour?
I would copper pour top and bottom layer. AFAIK the main reason
for copper pouring is noise reduction. I do it in all my designs.
I can not tell you what the difference is, but I am almost sure it will
help. :wink:
>Any thoughts on the copper pour?
I would copper pour top and bottom layer. AFAIK the main reason
for copper pouring is noise reduction. I do it in all my designs.
I can not tell you what the difference is, but I am almost sure it will
help. :wink:
#48
Posted Thu Mar 17, 2005 1:32 PM
Kroko said:
I would copper pour top and bottom layer. AFAIK the main reason
for copper pouring is noise reduction. I do it in all my designs.
I can not tell you what the difference is, but I am almost sure it will
help. :wink:
for copper pouring is noise reduction. I do it in all my designs.
I can not tell you what the difference is, but I am almost sure it will
help. :wink:
Thanks, I was thinking it was to get rid of gound loops. I dont think it will do much good for me in this design. It is far too dense, the polygons keep getting broken up. I think I am going to scrap the thought hole, surface mount mix idea. Its just too much on a small board. I think two designs will be much cleaner.
I may have found an enclosure for the programmer, I have one of the smaller sizes and they are really nice. Let me know what you think.
http://www.pactecenclosures.com/Plastic-En...osures/PPL.html
Vern
#49
Posted Thu Mar 17, 2005 4:15 PM
If I build the through hole design, I would put the external programmer in a free drive bay on my computer, I think that would look really cool. Plus, you can pull power from the pc's power supply.
#50
Posted Thu Mar 17, 2005 9:32 PM
Tsukasa said:
If I build the through hole design, I would put the external programmer in a free drive bay on my computer, I think that would look really cool. Plus, you can pull power from the pc's power supply.
That would be pretty neat. Do you have any ideas on mounting the board? I think the hard part might be to mount the connector for the cartridge. The circuit is tiny, just a microcontroller, an oscillator, and an RS232 level concerter so thats not an issue. I did a quick search to see if someone sells a plastic enclosure that would mount in a drive bay, but I couldnt find one.
Cool idea,
Vern
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users















