Well I haven't been very vocal about this project so far, I figure now is the time to spill the beans.
Pretty simple SNES flash cart. Only supports HiROM and LoROM with upper address mapping controlled by the CPLD. It's all new parts so the flash is obviously 3.3v. The CPLD is 5v tolerant, but drives the flash with 3.3v for A12-A22(23). Lower address bits A0-7 and data bus are shifted via a 16x level shifter, the CPLD controls the direction of the data bus through the shifter. Then the few address lines I didn't have room for I used a pair of 4x resistor arrays to level shift appropriately (A8-A11)
It uses Jim's Cool CIC of the SNES flavor. The battery backing is currently similar to NES style using schottky diodes. I might improve upon this, but it's pretty much the simplest solution and can work very well if done properly. If it proves to be a good solution then I'll stick with it long term. If not, I've got some other plans.
It supports up to TWO 8MB flash chips for 16MB total. And it has 128KB of SRAM. So there's quite a bit of room within the Hi-Lo ROM limitations. The CPLD can contain both Hi & Lo rom at the same time and be selectable via the solder jumper on the back to switch back and forth. I have thoughts to configure it for reset selectable multicart form with something like 2x LoROM and 2x HiROM.
It's designed to be programmed via the SNES edge connector. I've modified the
Kazzo to support. The side 10-pin connector is for programming the CPLD and CIC, and possibly accelerating the programming speed. The form factor still keeps it fitting in standard original SNES cases. I'm investigating some options to get new SNES cases made up to go along with them.
The flash is 90nsec so it should support fast-rom without much trouble.
Right now I'm pretty close to having it working. Got some bugs/kinks to work out as right now only ~90% of the bytes are actually getting programmed on the flash. DKC will actually boot though, has some graphics glitching and then crashes randomly in the title scene. Hoping to have it up and running 100% and order the first batch of boards this month.
I haven't settled on the price yet, it will depend on how much it costs me to have them assembled. My current target is ~$20 for a 8MB version fully assembled. The kazzo is around the same price, so it should make for a simple dev/flash cart setup for under $50.
I'd like to give a special thanks to nocash for his
spectacular documentation on the SNES and it's hardware. Because of that I was able to figure out everything I needed without reverse engineering it all for myself.
This looks pretty awesome!
Will it be compatible with the Pro Action Replay? No other flash cart is.
muckyfingers wrote:
Will it be compatible with the Pro Action Replay? No other flash cart is.
Probably not. I don't know much about how it works, but from what I can assume, I don't have enough hardware to support.
I should post clearer questions, the excitement got the better of me. I was asking if this would work physically on top of the Pro Action Replay.
I didn't mean to make it sound like, "Will the PAR be internally implemented?"
Your answer seems to indicate no either way.
Any chance you'd be willing to release your schematics/verilog? I've been slowly picking away at all of the info out there, as well as PCB scans for the SHVC-1A3M-XX/SHVC-1J3M-XX boards to try to achieve something similar, but with 5V parts (Altera MAX7000 PLD + ST M29F160F), and a hardware schematic would be incredibly helpful. Also, is there any reason your design couldn't be expanded to 32Mb, or is it just because you're using 8Mb ROM chips and adding 2 more would add a lot of tracing complexity? Since I'm using 16Mb chips, that would be less of an issue...
qwertymodo wrote:
because you're using 8Mb ROM chips
infiniteneslives wrote:
It supports up to TWO 8MB flash chips for 16MB total.
picture wrote:
SPANSION S29GL064N90TFI03
You got your bits/bytes backwards. He switched to 3V logic specifically to be able to buy the full size supported.
muckyfingers wrote:
I should post clearer questions, the excitement got the better of me. I was asking if this would work physically on top of the Pro Action Replay.
I didn't mean to make it sound like, "Will the PAR be internally implemented?"
Your answer seems to indicate no either way.
Oh I get ya now, I can't be sure, but I wouldn't be surprised if it DID work with the pro action replay. Logically my cart is pretty much identical to original Hi/LoROM boards. So Unless there is something funky about the PAR that keeps it from accepting 3.3v logic signals I'd guess it'll work.
Any idea why other flash carts don't work with the PAR? I'm guessing because the gui programming interface needs to interact with the flash cart for programming and the PAR gets in the way. If that is indeed the issue with other flash carts then mine is immune to that problem since it's programmed externally.
qwertymodo wrote:
Any chance you'd be willing to release your schematics/verilog? I've been slowly picking away at all of the info out there, as well as PCB scans for the SHVC-1A3M-XX/SHVC-1J3M-XX boards to try to achieve something similar, but with 5V parts (Altera MAX7000 PLD + ST M29F160F), and a hardware schematic would be incredibly helpful. Also, is there any reason your design couldn't be expanded to 32Mb, or is it just because you're using 8Mb ROM chips and adding 2 more would add a lot of tracing complexity? Since I'm using 16Mb chips, that would be less of an issue...
As linariq pointed out you've got your bits/bytes mixed up. MB=megaByte Mb=megabit. I support 16MB * 8(bit per byte) =128Mb, so actually the routing would have been simpler to 'expand' down to 32Mb
.
I don't really care to fully release the schematic and code. I've pretty much already explained all the details of the schematic in my original post. Converting nocash's docs into verilog is about as simple as programmable logic design gets. It's not that I'm not willing to share/help others, but I'd rather provide feedback as to why your code/schematic is flawed than help someone recreate/debug the design I've already made. You're going to have trouble sticking with 5v logic IMO. If you're having a hard time with schematics of Hi/LoROM then I suggest pulling out a multimeter and probing the board to gain it's schematic vice relying on scans alone.
If you'd like to know specific things about my schematic/code I'm willing to share, I don't want it to be a black box of magic to the user. But ask for something specific vice the enterty of my design.
Unrelatedly: INL, any thoughts about later using BGA for anything? Everything you have fits on one side (save the battery), so toaster oven reflow should be a reasonable plan, and it would dramatically decrease the footprint. (Maybe too much, maybe it'd require a 4 layer board, dunno. That'd probably undo any gains from shrinking them. )
Well the PCB is about as small as it could possibly get while still fitting the form factor of original cases. So unless I have new cases tailored to a smaller PCB there isn't much to gain for board size. These are still fairly simple for toaster oven reflow. I think you're right going to BGA and requiring 4 layers would be a deal breaker. The only thing that would push me to BGA is if I was looking to support something greater than Hi/LoROM to where components became more appealing or were restricted to BGA packaging.
EDIT: Additionally there are significantly smaller package sizes available for things like the CPLD and SRAM without taking the step to BGA. I've considered these, but coarser packages make for easier assembly and I was able to make them all fit so I took the benefit on the assembly side.
infiniteneslives wrote:
As linariq pointed out you've got your bits/bytes mixed up. MB=megaByte Mb=megabit. I support 16MB * 8(bit per byte) =128Mb, so actually the routing would have been simpler to 'expand' down to 32Mb
.
Oh, wow. Wasn't reading the part numbers closely enough. That definitely changes things.
infiniteneslives wrote:
I don't really care to fully release the schematic and code. I've pretty much already explained all the details of the schematic in my original post. Converting nocash's docs into verilog is about as simple as programmable logic design gets. It's not that I'm not willing to share/help others, but I'd rather provide feedback as to why your code/schematic is flawed than help someone recreate/debug the design I've already made. You're going to have trouble sticking with 5v logic IMO. If you're having a hard time with schematics of Hi/LoROM then I suggest pulling out a multimeter and probing the board to gain it's schematic vice relying on scans alone.
If you'd like to know specific things about my schematic/code I'm willing to share, I don't want it to be a black box of magic to the user. But ask for something specific vice the enterty of my design.
Fair enough, I just tend to make stupid mistakes when converting between text descriptions and schematics, less so comparing schematics visually. But I understand not wanting to release everything, just figured I'd ask. Once I get my schematic finished, I may send it your way to see if I've done anything stupid.
Quote:
Oh I get ya now, I can't be sure, but I wouldn't be surprised if it DID work with the pro action replay. Logically my cart is pretty much identical to original Hi/LoROM boards. So Unless there is something funky about the PAR that keeps it from accepting 3.3v logic signals I'd guess it'll work.
Any idea why other flash carts don't work with the PAR? I'm guessing because the gui programming interface needs to interact with the flash cart for programming and the PAR gets in the way. If that is indeed the issue with other flash carts then mine is immune to that problem since it's programmed externally.
I don't know why they don't work with the PAR. From what I've read it's because it patches codes in ram rather than rom and it interferes with way the flash carts load the roms.
Put me down for a set, I would love to test it. Even if it doesn't work with the PAR it is still useful and inexpensive.
I can think of two possibilities wrt the PAR not working with flashcarts, latency or power consumption. I know that the later revisions of the SNES reduced the power supplied to the cart bus to break the Game Genie because the Game Genie drew more power than a cart by itself. If power is the issue, it may work with older revision consoles.
muckyfingers wrote:
I don't know why they don't work with the PAR. From what I've read it's because it patches codes in ram rather than rom and it interferes with way the flash carts load the roms.
Put me down for a set, I would love to test it. Even if it doesn't work with the PAR it is still useful and inexpensive.
That is kinda what I was speculating as to why it doesn't work. Basically most flash carts need to write to ROM for flashing/communicating the game you're trying to play. The PAR was probably never designed for such a crazy newfangled type device. So when the SNES tries to write to cart the PAR prevents those commands from getting to the cart. I shouldn't have that problem, athough I can't be sure it's not something else without fully testing it out. I don't plan to aquire a PAR myself, so I'd be interested in having you test it out for me.
If power consumption is the issue I could be in trouble depending on how sensitive it is. I haven't measured what I'm consuming yet, but those CPLDs can be power hogs depending on how fast/much you've got them switching.
If it doesn't handle carts that write to ROM, how does it handle carts that write to SRAM?
tepples wrote:
If it doesn't handle carts that write to ROM, how does it handle carts that write to SRAM?
I was just speculating, but to speculate further: they probably expected the snes to write to sram. You can sense the difference, so they could have easily allowed sram to work.
How can the chip tell the difference? Only HiROM games have SRAM at $0x6000-$0x7FFF. As I understand it, LoROM games tend to have it in $700000-$7DFFFF, which overlaps where 32 Mbit HiROM games have ROM.
You could watch for which one of those areas the SNES wrote to first and then assume if it was Hi/LoROM based on that and continue to operate with that assumption. If they did something like that it would give even more reason as to why flash carts don't work.
Again all of this is only speculation, but they are things that could have happened that would break current flash carts.
Who knows perhaps the both the PAR and flash carts use the nn6000h-nn7FFFh expansion, something like that would also cause issues.
Hey IFL
Good work!!! If you are accepting orders (or preorders), I'd like to be on that list.
Please let me know.
Thanks!
Mark
Awesome project! Will certainly buy one at some point. And for your information, there are new SNES cart case available. A reproduction seller called Pachichi (you might remember him posting basic questions about repro and looking for programmer for random vapor-ware project) had mold made from the official cart and is now selling blank cases for 6$, maybe less if you buy in bulk. I'm definitively not affiliated with him but always welcome the use of new parts over destroying carts.
http://store.retroquestgames.com/I must say that your different projects are becoming more awesome every days!
Thanks guys.
Markfrizb wrote:
If you are accepting orders (or preorders), I'd like to be on that list.
Not formally, There will be plenty to go around. I'll put you down on the list so you can be one of the first to get one. I'll post here when they're ready.
SkinnyV wrote:
And for your information, there are new SNES cart case available.
I had heard about this, but I didn't have all the details so thanks for sharing. I just ordered a pair of his cases to see how they are. All I knew is someone supposedly had them and they were identical to the standard carts. So that's part of the reason I went with the original PCB form factor. They fit in the retrousb cases as well, but they are also not doing SNES repros anymore so I'd have to see if they still have cases around they'd like to part with.
Nice and compact, looks excellent paul!
I would imagine the PAR would work. I have a PAR MK3 I could try.
So every game up to 2MB in size, without using any special chips should work without a hitch?
mog123 wrote:
So every game up to 2MB in size, without using any special chips should work without a hitch?
16MB, I made the same mistake. Those are 8 megaBYTE ROM chips. And it depends on your definition of "without a hitch" since some games have copier protections and won't work on this because of the larger RAM size (Super Metroid, for one), but uCON64 is able to patch most of those...
The hardware on the cart could support SRAM size limiting. Only INL knows for sure.
Yeah we'll have to make sure someone with a PAR gets one in their hands to test em out when they're ready for full release. I appreciate the volunteers!
mog123 wrote:
So every game up to 2MB in size, without using any special chips should work without a hitch?
That's the goal, but actually all the way up to 128Mbit as qwertymodo pointed out. Which is somewhat of a lie, There's only ~90+ some Mbit addressable to the cart at one time due to the SNES memory map. But I can put a unique bit in every last bit of addressable ROM. To answer your question though, anything that works on a HiROM or LoROM board should be as 'hitchless' as possible.
As for the issue of some games having 'flash cart' protection like metroid, I can pretty much make any of the memories look as small as desired using the CPLD. So if something breaks with more than 64Mbit of SRAM I can 'trim' the SRAM down to 64Mbit to trick the rom. I can do similar things with the flash (or put a smaller flash chip on the board) if desired as well. Although choices like that may have to be made at time of purchase, not sure how configurable they'll be afterwards. I did add a slide switch to the final PCB that should allow for switching back and forth between Hi and Lo ROM on a single cart. There's enough space in the CPLD to support that.
In other news I did fix my bug with the programmer and have successfully tested out both Hi and Lo ROM games thus far. Still have some things to work on before I can test out 6MBYTE games, but they shouldn't be much trouble. I'm ordering the first 'official' batch of boards this evening, along with a big batch of kazzos to go along with em
Additionally I got a pair of the SNES cases, thanks for pointing them out to me SkinnyV. The good news is they're pretty awesome and I'm pretty impressed by the 'snap' open/close action of the cases. Honestly I wasn't expecting them to work well, but they're pretty great in practice. I'm actually planning on having a batch of those when the boards are ready to release so it can be a package deal with case and all right out the gate!
Would it be any cheaper to use an 8 MiB chip and a 4 MiB chip instead of two 8 MiB chips?
tepples wrote:
Would it be any cheaper to use an 8 MiB chip and a 4 MiB chip instead of two 8 MiB chips?
Yeah it would. I don't think there is any one game/hack that uses that much memory at the moment anyways though. Either way all the address lines for a 8MByte chip was already there so it only took another /CE pin on the mapper to expand up to 16MByte.
I'm not sure how many different flavors of memory sizes I'll sell it in, it'll kinda depend on what people request.
If you really wanted to test the full range of the mapping, the No-SDD1 Star Ocean hack would be just the thing...
Given the SNES memory layout, 4 MiB + 8 MiB could hold everything, even decompressed Star Ocean. It could use the 4 MiB chip for $xx0000-$xx7FFF, or for $008000-$3FFFFF and $808000-$BFFFFF.
Yeah I realize that. The difference between supporting a two 8MByte chips and 4+8MByte chips was routing a single trace on the board to connect A22 from the CPLD to both flash chips. So it was a no brainer to just have support up to 2x8MBtye chips which will inherently support 4+8MByte chips as well. At this point it's just a matter of what memories to solder on.
I'll probably offer a break down something like this:
lowest cost version: a single 4MByte (32Mbit) flash this will work for MOST production Hi/Lo ROM games. I could get/use smaller flash chips but I'm not sure it's really worth offering these options unless someone was looking for a large number of carts for a specific small homebrew game or something.
Double the memory: a single 8MByte (64Mbit) flash this will support nearly every Hi/Lo ROM game out there. With the one exception of decompressed star ocean.
Max addressable memory: one 4MByte + one 8MByte (96Mbits total). This would basically be targeted towards star ocean. Could also be used as some sort of hack/homebrew multicart that doesn't involve bankswitching.
Max the board: two 8Mbyte flash chips (128MBits total). You can't address all this at once. But with bankswitching and proper archiecture in the CPLD 'mapper' you could fill all 128Mbit with multiple games (both Hi and Lo ROM) and use the reset button to toggle through each game. This would also be able to support up to 16x (8KByte 64Kbit) battery backed save slots, which is plenty since the flash limitation would leave mean you'd have to be using 16x 1MByte (8Mbit) games which doesn't seem likely...
How about an option for no memory? I have a bunch of Micron M29W640G and M29W320G on hand, which are supposed to be a drop-in replacement for the Spansion S29GL064N/S29GL032N you're using (there are software differences, but nothing that should effect its usability here). I'm interested in buying a couple, so if I could get them a bit cheaper without the ROM chips, that would be awesome.
infiniteneslives wrote:
This would also be able to support up to 16x (8KByte 64Kbit) battery backed save slots, which is plenty since the flash limitation would leave mean you'd have to be using 16x 1MByte (8Mbit) games which doesn't seem likely...
You'd be surprised. Some people have a large collection of Super Mario World hacks, and SMW is 4 Mbit before expansion.
That's a good point about SMW hacks Tepples, I didn't realize that SMW was so small. A nice combo considering it's probably one of the most heavily hacked SNES games.
qwertymodo wrote:
How about an option for no memory?
Possibly by special request, but it's not something I'd list up for checkout by the general public... The biggest issue with that route and very fine pitched components is the challenge of soldering. Don't get me wrong it can be done, but there isn't much reason to go though that pain. Additionally it's pretty impossible to guarantee I'm delivering something fairly trouble free when it requires a high level of skill to assemble. Not only that, but it's hard for me to test that the board if fully operational when it's missing the flash.
But I may entertain such requests if the buyer was willing to accept responsibility for those risks.
EDIT: oh and the spansion chips have a buffered write which isn't on all pin compatible flash chips. The buffered writes does cut down on programming speed, so you'd have a time increase there. Additionally all the high level software and firmware support for reflashing the chips is designed with that buffer in mind, so you might have compatibility issues there if your flash doesn't support buffered writes.
infiniteneslives wrote:
qwertymodo wrote:
How about an option for no memory?
Possibly by special request, but it's not something I'd list up for checkout by the general public... The biggest issue with that route and very fine pitched components is the challenge of soldering. Don't get me wrong it can be done, but there isn't much reason to go though that pain. Additionally it's pretty impossible to guarantee I'm delivering something fairly trouble free when it requires a high level of skill to assemble. Not only that, but it's hard for me to test that the board if fully operational when it's missing the flash.
But I may entertain such requests if the buyer was willing to accept responsibility for those risks.
EDIT: oh and the spansion chips have a buffered write which isn't on all pin compatible flash chips. The buffered writes does cut down on programming speed, so you'd have a time increase there. Additionally all the high level software and firmware support for reflashing the chips is designed with that buffer in mind, so you might have compatibility issues there if your flash doesn't support buffered writes.
Well, when you have these ready for sale, I would be willing to buy a couple without memory installed. I understand you not wanting to do so in general, but I'd definitely be one to make that special request. I'm perfectly comfortable soldering 0.5mm pitch by hand, just did a few M29F160's yesterday. As for software support, that won't be an issue either, I'm currently in the process of building my own hardware for doing the flashing, and I'll be writing the software from the ground up as well. Anyway, the M29W640G is write-buffered as well, so no problems there...
In case you're interested:
http://www.micron.com/~/media/Documents ... 64Mbit.pdf
I just wanted to make mention that your products look amazing, and I'm excited for your work.
I got one of these SNES boards yesterday. After a little bit of tinkering, it's awesome. Much better than shoehorning eproms or flash into old PCBs. The only thing that's a bit of a downer is it can take awhile to program very large games. Otherwise it's pretty sweet. Any downside is more than made up for by never having to lift a soldering iron yourself.
Thanks Mottzilla, Yeah the bigger chips still take awhile to flash. It was even worse about a month ago. Once I get the firmware to automatically double up to fake the mirroring that'll speed things up quite a bit so you don't have to send data over USB several times. So that will make programming time more dependent on rom size vice chip size. The next step to up the speed is multi-task the mcu on the kazoo. Currently the firmware accepts 256 bytes and then flashes them 32bytes at a time with the associated wait while flashing. I'm going to step the packet size down to 32Bytes so that the mcu can accept the next packet of data while the flash is off programming the last 32bytes on it's own. Not sure how much that'll save exactly, but should be significant.
It currently takes ~2 1/2 mins to program a 4MB game onto a 4MB board. So something like 1.6KB/sec right now. Not that long ago it was about 3x that before I was doing 32byte buffered programming.
MottZilla wrote:
I got one of these SNES boards yesterday. After a little bit of tinkering, it's awesome. Much better than shoehorning eproms or flash into old PCBs. The only thing that's a bit of a downer is it can take awhile to program very large games. Otherwise it's pretty sweet. Any downside is more than made up for by never having to lift a soldering iron yourself.
Have you tested it with your SNES PAR MK3, to see it if works with it or not?
I have not yet but I plan to test it, and it's *very* likely to work just like a real cartridge. The INL SNES boards unlike Memory Card loading Flash cartridges (EverDrive or PowerPAK) should have no problems using Game Genie or PAR. They function pretty much the same as original cartridges as far as those cheat devices are concerned.
infiniteneslives wrote:
Thanks Mottzilla, Yeah the bigger chips still take awhile to flash. It was even worse about a month ago. Once I get the firmware to automatically double up to fake the mirroring that'll speed things up quite a bit so you don't have to send data over USB several times. So that will make programming time more dependent on rom size vice chip size. The next step to up the speed is multi-task the mcu on the kazoo. Currently the firmware accepts 256 bytes and then flashes them 32bytes at a time with the associated wait while flashing. I'm going to step the packet size down to 32Bytes so that the mcu can accept the next packet of data while the flash is off programming the last 32bytes on it's own. Not sure how much that'll save exactly, but should be significant.
It currently takes ~2 1/2 mins to program a 4MB game onto a 4MB board. So something like 1.6KB/sec right now. Not that long ago it was about 3x that before I was doing 32byte buffered programming.
I would love to hear more about your transfer protocol. the SNES Flasher I designed over this summer uses FTDI Usb UART transmit/receive. However, I do not yet have a packet protocol, I just send one byte at a time to the flasher. This means in my write routine, I am fetching a single at every iteration. Could this explain my insane long flash programming time? (1 hour for 32Mb) Note MCU is running at 16 Mhz, I flash using nested For Loops, I'm not even delaying or verifying the bytes have been programmed before moving on. Still so low? Makes no sense. Of course, I verify everything after programming is done, always a success.
bazz wrote:
I would love to hear more about your transfer protocol. the SNES Flasher I designed over this summer uses FTDI Usb UART transmit/receive. However, I do not yet have a packet protocol, I just send one byte at a time to the flasher. This means in my write routine, I am fetching a single at every iteration. Could this explain my insane long flash programming time? (1 hour for 32Mb) Note MCU is running at 16 Mhz, I flash using nested For Loops, I'm not even delaying or verifying the bytes have been programmed before moving on. Still so low? Makes no sense. Of course, I verify everything after programming is done, always a success.
Your code could probably use some optimization. I have a single-byte-at-a-time microcontroller flasher that uses latches for the address lines due to lack of I/O pins and I do wait for verification after each byte and I'm running about 20 minutes for 32Mbit.
My programmer is an adaptation of two separate
V-USB library projects that use an AVR micro-controller and a few discrete components for USB. The hardware is adapted from the
kazzo, and the software/firmware started off as the
EE-prog. If you want the nitty gritty details look into the code for the EE-prog, and ignore all the I2C programming protocol. Once I get things more polished and full line up operating as I'd like, I'll make my sources available. The only reason I'm not doing it now is that it's a little messy and not fully documented, I may also change the structure significantly and don't want to invalidate any work someone might choose to do for themselves. (If someones reading this a year from now, feel free to poke me and I'll share what I've got at that point.)
My software/firmware is setup to transfer 256Bytes over USB storing them in the mcu's ram until all 256Bytes of the 'packet' have been transferred over USB. At that point I call my programming function where those 256Bytes are written to the flash chip. Initially I programmed 1 byte at a time from my 256Byte 'packet'. At that point my programming speed was something like 10min for 32Mbits. As noted in the datasheet for the flash, 32byte buffered writes are drastically faster than individually programming 32Bytes. So you use one command to write a buffer of 32Bytes to the flash at once and then wait while the flash chip goes off on it's own to program those 32Bytes. That improvement cut me down to where I'm at currently with ~2.5min for 32Mbits.
Quote:
This means in my write routine, I am fetching a single at every iteration. Could this explain my insane long flash programming time?
YES.
There is a lot of time and code between accepting the byte over USB, and then actually writing that byte to flash. Programming byte by byte means that code is executed for every single byte. Going to the 256Byte packet size means that code is only executed once for every 256Bytes. That could explain some of the time difference between qwertymodo and my implementation. Yours too bazz, but taking 1hr for 32Mbits you've got to have a few other inefficiencies going on. Not sure how fast your UART is, I'd find out and ensure that it's not bottle necking you.
The two things that consume the most amount of time though are serial transfer over USB, and the flash chips programming time. There isn't a whole lot you can do about either of these. Faster USB would require dedicated components that don't justify the expense IMO. However figuring out a way to fetch new data over USB while waiting for the flash to write the old data. This would be difficult and most likely diminishing returns to perform on a byte level, however powered with 32Byte buffered flash writes I think the ~240usec write recovery time is sufficient time to go fetch a good chunk of data via USB. Adjusting the 256Byte packet size down match the 32Byte buffered write size would allow for this to happen. I'll just have to double buffer the writes and verify the old buffer just before writing the new buffer. Might get me under 2min for 32Mbits I'm thinking.
infiniteneslives wrote:
That improvement cut me down to where I'm at currently with ~2.5min for 32Mbits.
So that will be in the next update then? =) When I tried I roughly measured around 10 minutes for 32Mbits. 2.5min for 32Mbits is very acceptable.
MottZilla wrote:
infiniteneslives wrote:
That improvement cut me down to where I'm at currently with ~2.5min for 32Mbits.
So that will be in the next update then? =) When I tried I roughly measured around 10 minutes for 32Mbits. 2.5min for 32Mbits is very acceptable.
I ran 2.5min for 32Mbit when I made that post on the 25th. Have you updated your firmware recently? The 10min speed you've got sounds more like what I had with my release that was up in July. I need to start getting more formal with my releases. I'm adding new things every couple days so I just toss it up for download when I think it might be useful and stable enough for others.
I'll try updating the firmware but I thought I had the latest on there.
Update: My firmware and the INL programmer exe are the same as what I just downloaded from the website. It took approx 20~ mins to program 8 megabytes. I reuploaded the firmware with the batch file as well. Not sure why it's so slow. I am on the 64bit Vista. I never ran either "installer_x86" or x64. When I get a chance, I'll see if that's the issue.
Update: I tried everything I could think of. Programming the whole 8mbytes of flash takes roughly 20 minutes. The only other thing to try would be to try using my other PC. What's the normal programming time for 8 megabytes?
8MB boards are 5min currently, just verified that as well. Let me know how the other PC works out, might just send you a second board to see if that changes anything. Not sure what could be causing that though, make sure the .bat file is pointing to the firmware dated 8/19. Hopefully it's not a vista issue...
Has anyone tested this with the 96Mbit Star Ocean (no chip) patched rom?
I bought the 4MB board.. knew I should of spent a little extra
if it does, I think I'll get antoher
I believe I heard that Star Ocean does, or will work on the 12MB/16MB boards. The "uncompressed" Star Ocean hack is 12 megabytes I believe.
And how much will it cost? lol
Intothedark wrote:
And how much will it cost? lol
They're
currently available, and 12MB boards have been shipping for ~month now they're $26 each. I'm putting the finishing touches on the 16MB versions as well right now and am in process of getting the first of those out the door right now.
I want to thank everyone who supported this project in it's early release stages over the summer. I'm planning to end the 'pre-release' over the weekend as I've been able to build up stock on them so they can ship within a couple business days. In appreciation I've been giving free cases to everyone who's ordered during the pre-release. I have a good stock of the cases now from retroquest and will be offering the nice pop tab opening cases for $5 each when purchased with a board. I've also gotten a lot of requests for qty discounts. I expect by the end of the month I'll have enough stock on the shelf to allow for it, so you can expect to have the option to save some on bundles of ~5-12 carts.
The main hurdles to getting these things going was the assembly of the fine pitched parts with solder paste-toaster oven means of assembly. My buddy and I have gotten it pretty well down to a science by now though and been able to get the yields high enough to justify keeping the prices where they're at thankfully. I'm doing my best to keep the assembly in house in order to have rapid turn around times and flexibility of all the different options at a low price, that and it's always nice to keep the work from going overseas.
One other feature I was able to add makes use of a little more battery RAM. The basic setup is to have 32KB of sram, keep in mind some games that check for only 2KB will not like this. There are hacks to defeat that check, and the next revision I'm going to be adding jumpers to limit the visible size of the ram. Anyway, the thing I did was make two separate 32KB slots for the RAM based on the position of the Hi/Lo toggle switch. So what that allows to create a save of a LoROM game, reflash a HiROM game and make a separate save. You could then reflash the board to swap back and forth between the Lo and Hi ROM games while keeping the save intact for both. So it's nothing huge, but it was a free add so I went for it.
There are a ton of ways the 12-16MB boards can be diced up for creating a reset based multicart. I've got one general setup I'm going with, but if people have requests for specific setups I will entertain the ideas.
Next step is to make the firmware a little smarter and take care of the deinterleaving for 12MB gamedoctor files, and auto-doubling smaller rom images to fill the larger flash chips. I also need to figure out why two separate people have had issues with programming speeds. We've confirmed that it's not hardware releated, so probably something going on with the host application and the PC. The added challenge is that I haven't been able to recreate the issue myself, but I've got a few ideas of what might be going on.
In terms of SRAM, is there a way to limit the size seen on old boards? I haven't found a patch for Super Metroid or its hacks
UPDATE: uCON64 is an older but good way to get around that
Right now the only good way is to lift pins on the SRAM and ground them. I can tell you which ones if you'd like to give it a try. On my next version I'll add some jumpers to allow you to halve the SRAM. I can get it down to 4KB with the CPLD, so the jumper would take it down to 2KB. Although my standard SRAM configuration is now two slots of 32KB (one hi, one lo). So a 4KB SRAM board would have to be a separate CPLD configuration so halving would bring it to 2KB. That's about the best I can do without adding more hardware.
What is the multicart idea with this?
mcmustang51 wrote:
What is the multicart idea with this?
The idea is to use the reset signal to control a counter in the CPLD. I've tested it and got it working, but I'm having issues with the game I hoped people could use the 16MB boards for 4x4MB slots all sharing the same save slot.
I did have to put a low pass filter on the reset signal to get stable toggling from one rom to the next, but it's working in regards to the multicart feature. Having a multicart setup is a separate CPLD configuration though, and I haven't actually offered any reset based multicarts as of yet. I can, it's just a matter of explaining it all and putting the different options available for checkout. The 4-16MB and 128KB of ram can be sliced and diced into whatever config one would like, I will probably come up with some common ones to offer based on common requests.
Any thoughts about expanding this to other consoles? GB, GBA, N64?
For GBA, I thought Chinese flash carts were already cheap.
mcmustang51 wrote:
Any thoughts about expanding this to other consoles? GB, GBA, N64?
yeah I have dreams to do everything under the sun.
To leak a little info I will say I'm working on a GB prototype right now. that's a long way out though, still a lot of polish needed on my NES and SNES boards before GB gets going. That and GB cart connectors aren't easy to come by without harvesting them from dead GBs.
GBA would probably require stepping up to BGA packaged memories which I'm currently trying to avoid. I should be able to handle them someday, but GBA flash carts are dirt cheap...
n64 would require a cic, but that will be done eventually by someone.
infiniteneslives wrote:
That and GB cart connectors aren't easy to come by without harvesting them from dead GBs.
Correct me if I'm wrong but doesn't GB and GBA use the same connector?
if so wouldn't
http://dx.com/p/repair-parts-replacement-gba-game-cart-slot-for-nds-lite-37787 work?
Quote:
Correct me if I'm wrong but doesn't GB and GBA use the same connector?
if so wouldn't
http://dx.com/p/repair-parts-replacemen ... lite-37787 work?
Wow thanks! Yeah those should work, just ordered a few. I only looked breifly on ebay for a replacement, the GBA should work just fine. Never thought about looking somewhere that had GBA replacement parts.
infiniteneslives wrote:
Quote:
Correct me if I'm wrong but doesn't GB and GBA use the same connector?
if so wouldn't
http://dx.com/p/repair-parts-replacemen ... lite-37787 work?
Wow thanks! Yeah those should work, just ordered a few. I only looked breifly on ebay for a replacement, the GBA should work just fine. Never thought about looking somewhere that had GBA replacement parts.
Technically those are NDS parts. Yay, backwards compatibility
Oh NDS = Nintendo DS...
So they're GBA connectors for a DS, not GB connectors for a GBA. I'm guessing these won't work as I'm pretty sure GBA pitch is finer than GB pitch. Even if so, I might be able to be tricky and get them to work anyways. We'll see when they arrive.
If Game Boy Advance pitch were finer than Game Boy pitch, then how would Game Boy or Game Boy Color games fit in a Game Boy Advance or Game Boy Advance SP system? The GBA didn't add any pins; it just multiplexed signals over the pins that were already there.
tepples wrote:
If Game Boy Advance pitch were finer than Game Boy pitch, then how would Game Boy or Game Boy Color games fit in a Game Boy Advance or Game Boy Advance SP system? The GBA didn't add any pins; it just multiplexed signals over the pins that were already there.
Oh you're right, I was thinking about how the DS has two separate slots for backwards compatability for GBA. The GBA has backwards compatability with GB using the same slot.
So does the DS play original GB games then too? Guess I could try when I get home, never thought that was an option.
infiniteneslives wrote:
So does the DS play original GB games then too?
No, at least not with that cartridge slot.
The Nintendo DS and the Game Boy micro don't play the 8-bit games. They don't have the switch inside the slot that GB/GBC carts press.
The original NDS DOES play original GB games. They removed support in the DS Lite to support GBA only, and removed the port entirely in the DSi. In any case, the NDS Slot-2 port supports the original GB carts just fine, because the GBA supported them, so those parts you ordered should work.
The original DS does not support GB cartridges. I just tried. They don't fit; the two channels on the back side of the GBA cartridge are phyisical blocks, rather than switches as in the GBA.
Or wikipedia:
https://en.wikipedia.org/wiki/Nintendo_DS#Compatibility
But if you remove the case (or trim it slightly) it should fit the connector. If you don't want to remove the case or trim it you could just trim the connector itself
some references for how to use the DX NDS connector for reading GB carts (some modifications needed as pointed out above):
modifying the connector:
https://blog.thijsalkema.de/blog/2013/05/14/game-boy-cartridge-dumping-on-a-raspberry-pi-part-1/trimming the case:
http://www.insidegadgets.com/wp-content/uploads/2012/09/IMG_2511.jpg from the comments in
http://www.insidegadgets.com/2011/03/19/gbcartread-arduino-based-gameboy-cart-reader-%E2%80%93-part-1-read-the-rom/
The problem with cutting the cartridge is that now they won't work in a GBA (plain, player, or SP) anymore, because they no longer will hit the switch that configures it to boot using the GBZ80 and provide 5V instead of 3V.
good point, well, guess you need to trim the connector or remove the case when flashing it then
hyarion wrote:
good point, well, guess you need to trim the connector or remove the case when flashing it then
Either of those options is easily accepted when compared to the sacrilegious alternative of harvesting them from dead donor GBs. I'll post up pictures and stuff when I get them in a separate thread in attempts to stay on topic.
infiniteneslives wrote:
mcmustang51 wrote:
Any thoughts about expanding this to other consoles? GB, GBA, N64?
yeah I have dreams to do everything under the sun.
To leak a little info I will say I'm working on a GB prototype right now. that's a long way out though, still a lot of polish needed on my NES and SNES boards before GB gets going. That and GB cart connectors aren't easy to come by without harvesting them from dead GBs.
GBA would probably require stepping up to BGA packaged memories which I'm currently trying to avoid. I should be able to handle them someday, but GBA flash carts are dirt cheap...
n64 would require a cic, but that will be done eventually by someone.
this is great news! for n64 I suppose you could just leave the slot for someone to solder in
infiniteneslives wrote:
GBA would probably require stepping up to BGA packaged memories which I'm currently trying to avoid. I should be able to handle them someday, but GBA flash carts are dirt cheap...
IIRC, the largest memory supported by GBA is 256Mbit without bankswitching (and I don't know of any games that did that). Micron manufactures x8 and x16 Flash ROMs up to 1Gbit in TSOP.
Here's a listing on Digikey. They also sell 2Gbit, but those are BGA-only.
Hey everyone,
I have received a couple of these and am very happy. They seem to work well.
Just having trouble writing Hirom games which are larger than 4mb such as Tales Of Phantasia or CHrono Trigger Crimson Echoes.
My boards are 8mb ones.
I have tried expanding the roms to 8mb using Lunar Expand. This did not work. I also expanded the roms padding them with 0xff but this did not work either.
I know for other roms that are under 4mb I pad them to 4mb and then double them and this works fine. Obviously I can only pad the roms bigger than 4mb and cannot double them.
Anyone have a solution for this one?
When using 8MB boards you need to mirror the ROM image to fill it up to 8 megabytes. An easy example with a 2mbyte or 4mbyte game is to copy the rom data until it fills the whole 8mbytes. So copying a repeat of the ROM data 2 times with a 4mb file and 4 times for a 2mb file. I'm not sure about ToP which I think is 40 or 48 megabits? INL should have an idea. But basically it'll involve copying data from one part of the ROM to fill up the remaining area to reach 8 mbytes.
In general 6MB games:
People are used to splitting them into two files when using 4MB flash chips, one 2MB file, and one 4MB file. The 4MB file comes from the first 4MB of the 6MB rom. the 2MB file come from the last 2MB of the rom.
Start with empty file. Take the 2MB file (from end or rom) double it, put it as first 4MB of new file. Take 4MB file (from begining of 6MB file), place it at end of new file which should now be 8MB file. Program & Play. A future firmware revision will handle all that for you at a TBD date.
infiniteneslives wrote:
In general 6MB games:
People are used to splitting them into two files when using 4MB flash chips, one 2MB file, and one 4MB file. The 4MB file comes from the first 4MB of the 6MB rom. the 2MB file come from the last 2MB of the rom.
Start with empty file. Take the 2MB file (from end or rom) double it, put it as first 4MB of new file. Take 4MB file (from begining of 6MB file), place it at end of new file which should now be 8MB file. Program & Play. A future firmware revision will handle all that for you at a TBD date.
Perfect! That is exactly what I needed to know. Got Tales working perfect.
Tried Chrono Trigger Crimson Echoes and that worked but the save function was not holding. Anyway more experimenting to come.
Thanks again inifiniteneslives. Excellent product!
only 32kb ram? games like Chrono Trigger with 64kb used ram are not working / saving ?
digger wrote:
only 32kb ram? games like Chrono Trigger with 64kb used ram are not working / saving ?
No, 32KBYTE, not 32Kbit. If CT uses 64Kbit, then the 256Kbit I'm supplying should be ample.
Goes off to update things for the small b that SNES guys are used too...
I just got the inl programer and and 2 boards snes 8MB and 12MB the other day.
the 8MB board works great. I flashed ffv, dual orb 2 and dq6 and they worked great
I still could not get tales of phantasia to work using the method you suggested.
for the 12MB board it does not erase using the erase_snes12-16MB header.
it erases using the regular Erase_SNES.bin
Also does the Star Ocean 96Mbit no sdd-1 rom work on your boards? I could not get it to work.
I know the rom is good since it works on my SNES POWERPACK. I can get it to flash fully with out any errors and but it black screens. On my super wild card DX 2 it reads the rom internal data atleast.
i did remove the header and corrected the checksums. but still no go.
Is there a special way i have to split/combin the rom?
This is a great project your undertaking. these boards are great quality. i will be ordering more of them to make some carts for my friends who are big snes rpg fans. They want to play them on a real snes. Thankyou for all the time you spent on this
Yeah that game's format is typically interleaved, my current firmware release only works for de-interleaved roms. I should have my deinterleaving firmware out soon now that I found the bug plaguing my NES flashing code. Shoot me an email and I'll help you get those issues resolved.
paul@infiniteneslives.com
Wondering if someone can test something for me. Did a breath of Fire II using the German translation patch.
In an emulator it works perfectly.
Wrote it to one of the infinite cards and it starts up fine but just gets into a loop after you enter the characters name in and hit the start. Goes back into the enter characters name page.
Is it something to do with the way the save game works for this rom?
Can someone possibly test this and let me know?
Thanks
Try playing the unpatched version (NTSC or PAL, whichever matches your system) and see if the same thing occurs. It could be a problem with the translation. That's one way to maybe rule it out.
mamejay wrote:
In an emulator it works perfectly.
Which emulator?
Unless it's quite modern (i.e. snes9x/zsnes don't count), I wouldn't trust that to mean anything.
Using SNES9X emulator.
What other emulators are recommended to emulate as close to OG hardware as possible?
BSNES/higan is canonical.
lsnes is based on the bsnes core, so should be roughly as accurate, but might be better or worse from the UI point of view.
lidnariq wrote:
BSNES/higan is canonical.
lsnes is based on the bsnes core, so should be roughly as accurate, but might be better or worse from the UI point of view.
Just tested the rom using higan and it works fine.
If anyone else has inf card that they can test it with let me know.
Quote:
If anyone else has inf card that they can test it with let me know.
I've got a few INL cards...
I've confirmed the issue when programing it as a headerless 3MB file.
I'm guessing the issue is related to mirroring/location of the two chips in the memory map. I don't think I've actually tested a 3MB HiROM game before.
I'm not sure how the original carts were setup for these non-power of 2 sized games. One can assume there was a 1MB chip and a 2MB chip. Not sure which was first in the memory map. Either 1MB followed by a 2MB or vice versa. Wherever the 1MB chip is, we need to double it up.
I just tried doubling up the first 1MB and inserting it in the front of the rom image. That makes it act as if the 1MB chip was in the lower address half. That kinda booted, but was all glitched up...
Trying doubling up the last 1MB at the end of the file now. That's booting up nicely so far... And still no dice...
Actually I'm guessing it's an SRAM issue. The menu normally goes back in the menu after a new profile, but since the profile has been created it allows you to select it. So if things weren't getting saved in sram properly, then when it stepped back, the profile wouldn't be there.
I was originally testing on my v1.0 firmware release I believe. Updating to v1.1 brings some fixes on the SRAM sizing and toggling banks with the hi/lo switch. Giving v1.1 a try doesn't seem to fix the issue though either... I'm curious if giving the game TOO MUCH sram would cause this issue...
If the additional SRAM address lines are floating, that could cause issues.
I'm sure they aren't floating. Some games actually do have SRAM mapped a little bit differently. I think one of the Ys games is like that.
Yeah, getting it right all the time is not Ys-y.
I can give
this a try and see what happens.
I'll start off by saying thank you! These boards are excellent and I will be getting more in the future!
First, a pretty basic question....Does it matter if a rom is padded or doubled? I padded a 1.5MB file to 4MB yesterday and noticed no issues. Will the padding cause an issue later in the game or did I just get lucky?
If I do a doubled rom do I just use a basic joining program to put them together or is there a better way?
Captain N wrote:
Also does the Star Ocean 96Mbit no sdd-1 rom work on your boards? I could not get it to work.
I know the rom is good since it works on my SNES POWERPACK. I can get it to flash fully with out any errors and but it black screens. On my super wild card DX 2 it reads the rom internal data atleast.
i did remove the header and corrected the checksums. but still no go.
Is there a special way i have to split/combin the rom?
infiniteneslives wrote:
Yeah that game's format is typically interleaved, my current firmware release only works for de-interleaved roms. I should have my deinterleaving firmware out soon now that I found the bug plaguing my NES flashing code. Shoot me an email and I'll help you get those issues resolved.
paul@infiniteneslives.comI was wondering if this had been figured out yet. I was thinking of doing this rom soon myself.
Once again, thank you!
Padding is fine if you know in advance that the ROM does not depend on address mirroring. A few commercial games such as Mega Man X appear to use mirroring as weak copy protection.
tepples wrote:
Padding is fine if you know in advance that the ROM does not depend on address mirroring. A few commercial games such as Mega Man X appear to use mirroring as weak copy protection.
Thanks for the info! Still new to this and didn't know about address mirroring.....I'm really enjoying the learning process though and these boards are a great way to begin learning the basics.
For any ROM that is 4, 8, or 16 megabits, you should copy/duplicate the ROM data until it fills up the flash chip. Some games will function without doing this, but many will not.
Roms that are uneven sizes like 10, 12, 20, and 24 megabits may be a bit more complicated. There are also instructions somewhere for how to handle the 48mbit Tales of Phantasia and the 96mbit Star Ocean I think.
I think it's possible in some cases two games that are the same different size might expect different mirroring behavior as one might be using two ROM chips rather than one.
Hi guys,
I recently recieved my INL HiLoROM SNES 12MB Flash Cart and i am facing some problems:
Firstly, I can not use the flash cart on my pal snes without disabling the CIC. I tried to get some information on how to use the TENNIS JCIC properly, but i could not find any (might just be, that i can not set the region corresponding to my SNES).
Secondly, I can not play games that use more than 1MB (8MBit) of memory. I tried Super Mario World, it works flawlessly, even unpadded (just flashing the 512kb file). I also tried just for testing Axelay, which also worked without problems, same as before it also worked unpadded.
But if I try to flash Tales of symphonia, the way like mentioned some pages before with doubling last 2MB of the game and putting the first 4MB of the rom after the 2x2MB, it does not work. I thought it might be because of the uneven size which needs some trickery padding of the rom to fill the 12MB, but I had not luck with any game of a size from 2MB up to 12MB (like donkey kong country 2 or secret of mana which have even rom sizes, they also did not work padded to 12MB)
I would really appreciate help of you guys and i hope to get to play tales of symphonia on real hardware
If it helps, i have a super nintendo cart backup tool, which allows me to dump cartridges up to a size of 4MB (32mbit), might be helpful to analyze what is wrong.
Do you mean Tales of Phantasia? Since his instructions leave you with a 8MB ROM and you have 12MB of flash, you may need to copy more data around. Try copying the first 4MB of the 8MB ROM onto the back, that might work. If not then try copying the last half onto the back. I'd guess one of those might work.
SNgamer wrote:
Hi guys,
I recently recieved my INL HiLoROM SNES 12MB Flash Cart and i am facing some problems:
Firstly, I can not use the flash cart on my pal snes without disabling the CIC. I tried to get some information on how to use the TENNIS JCIC properly, but i could not find any (might just be, that i can not set the region corresponding to my SNES).
Yeah I've been getting mixed reports as of late as to whether the SNES JCIC is working on PAL consoles. It's supposed to region switch on reset. I think there's a variation in SNES PAL CIC's out there that's causing an issue for some people. I added support for the superCIC to my second revision of the boards which showed up last week. I'd be happy to swap it out with the new revision for you. Please email me to handle that.
Quote:
Secondly, I can not play games that use more than 1MB (8MBit) of memory. I tried Super Mario World, it works flawlessly, even unpadded (just flashing the 512kb file). I also tried just for testing Axelay, which also worked without problems, same as before it also worked unpadded.
But if I try to flash Tales of symphonia, the way like mentioned some pages before with doubling last 2MB of the game and putting the first 4MB of the rom after the 2x2MB, it does not work. I thought it might be because of the uneven size which needs some trickery padding of the rom to fill the 12MB, but I had not luck with any game of a size from 2MB up to 12MB (like donkey kong country 2 or secret of mana which have even rom sizes, they also did not work padded to 12MB)
Yeah right now the 12MB board is far from ideal to play anything other than lorom games or a full 12MB game. Someone has offered to help me with a new version of the host app to help resolve these issues. The main problem is there is no mirroring on a 12MB board, every rom address has a unique byte. So Hirom games need to be programmed into lorom space as well in an interleaved fashion to get things to work. Mottzilla's suggestion should help if you have a 8MB board. I'm expecting a beta release that I'll post here in the next week or so.
Quote:
I would really appreciate help of you guys and i hope to get to play tales of symphonia on real hardware
I don't know anything about that game. If you can provide details of the hardware config it expects I can help instruct you how to modify the rom image to support.
Quote:
I'd be happy to swap it out with the new revision for you. Please email me to handle that.
thanks for your offer, but If there is no need for chainging the pcb's layout or any parts besides the JCIC, then there is for me no need to get the new version.
if it is a common problem for the JCIC not to work properly on PAL snes, then i will hardwire a PAL CIC from some old sports game that no one will ever miss
But if your second version does handle bugs i am not aware of, then i might consider an exchange
Quote:
I'm expecting a beta release that I'll post here in the next week or so.
very good, i will then wait for it's release.
and I also now get why only the two lorom games work.
i will then try star ocean with the no-sdd1-patch and see if it works (it is a lorom game if i recall correctly)
Quote:
I don't know anything about that game. If you can provide details of the hardware config it expects I can help instruct you how to modify the rom image to support.
Whoops, sorry, i actually meant the game tales of phantasia
I accidently swapped the names because the new hd version of tales of symphonia is coming out soon (which i am awaiting it's release in order to play).
For what it's worth, I'm the 'someone' who has offered to work on the host app for INL's flash carts.
I go by Danin online, but my real name is Skylar. You can call me Skylar or Danin, doesn't much matter which. I've been hammering away at this app for just short of two weeks now, and I think progress has been pretty decent. I've rewritten it from scratch, using up-to-date libUSB libs, and crammed as many features as I can think of into it. INL or myself will be making a proper release thread for my new host app, and I'll be your friendly neighborhood dev. I'm not a pro, so there will be bugs. I'll come back here and edit in a URL for the new host app once it's posted.
Thanks Danin!
For anyone wanting to test out the beta release of his host app you can find it in his thread
here Discussions of the firmware and software for the kazzo retro programmer are probably best placed there for now. Specific things about my board here.
On that note, I got the next revision of my boards in last week. Not too many changes though:
*added support for ikari's superCIC as things weren't working for all those guys in PAL land. Need to get a PAL SNES for testing to help out Jim's Cool.
*added a jumper to support halving the SRAM. This will ground A11, the CPLD can be configured to limit SRAM to 4KByte (32Kbit), with that this jumper will trim down to 2KByte (16Kbits) as some games require.
*added placement for a low pass RC filter on the back of the board for the reset signal for better multicart switching.
*they turned out a little more orange than yellow for this batch... oh well.
so, it's me again.
First off, the new host app is very well done (i know it does not belong in this thread, but i had to say this
).
Now i have tested my 12mb HiLoRom board with some other games, but i can't get some of them to work...
I tested super metroid, which at first did not work and i found out that it checks for the size of the sram available onboard. as there is 32kb installed for LoRom games, i manually grounded A14 and A13 in order to have 8kb of sram. i checked again if the game starts, but blackscreen like before...
I also tried dezaemon (with normal 32kb sram setup on the board), which also ended in black screen and castlevania dracula x too...
i also tried star ocean, which fills all the 12mb space of the board, but here again, blackscreen (but i think it is because the patch seems to interleave the rom in gd3 format and i could not deinterleave it properly, but this is a minor issue to the main problem i have).
the only games i could get to work successfully were mario paint, super mario world and axelay.
All games i tested are LoRom games which should work on the 12mb board, but as i said, some of them do not seem to work...
of course, the switch is set to LoRom.
is there any chance of getting this thing to work properly?
SNgamer wrote:
so, it's me again.
First off, the new host app is very well done (i know it does not belong in this thread, but i had to say this :D).
Now i have tested my 12mb HiLoRom board with some other games, but i can't get some of them to work...
I tested super metroid, which at first did not work and i found out that it checks for the size of the sram available onboard. as there is 32kb installed for LoRom games, i manually grounded A14 and A13 in order to have 8kb of sram. i checked again if the game starts, but blackscreen like before...
I also tried dezaemon (with normal 32kb sram setup on the board), which also ended in black screen and castlevania dracula x too...
i also tried star ocean, which fills all the 12mb space of the board, but here again, blackscreen (but i think it is because the patch seems to interleave the rom in gd3 format and i could not deinterleave it properly, but this is a minor issue to the main problem i have).
the only games i could get to work successfully were mario paint, super mario world and axelay.
All games i tested are LoRom games which should work on the 12mb board, but as i said, some of them do not seem to work...
of course, the switch is set to LoRom.
is there any chance of getting this thing to work properly?
Sounds like discussion for the new app thread, since these questions are about the app not the hardware. However, here's my two bits:
Super Metroid does have flashcart protection that I haven't learned to patch out yet. I'm not sure if that's related to the current issue or not. If you can find me information on its protection I'll get right on that, otherwise it'll be the next thing I do after attempting to fix the 8MByte issue.
I've never tried Dezaemon or Castlevania Dracula X, so I can't answer those at the moment. I'll pin that.
There's a known issue posted (in the new host app's thread) about uploading games larger than 8MByte, so even if it was properly deinterleaved it wouldn't work with my app at present. The issue is changes in casting of USB packets in the up-to-date libraries. I'm working on a fix.
Got it working now thanks to a tip from Danin.
The problem was the size, the roms which did not work had to be padded to 8MB size (I use now LunarExpand for this), Super Metroid and also hacks do work flawlessly (if the sram is trimmed to 8KB by grounding A13 and A14 manually as i did in order to bypass the protection manually), Castlevania also works. So for others with the same or similar problem on 12MB Board, you might want to try this too.
Now there is only left the support for bigger files than 8MB and HiRom games
.
It is not that hard to break the SRAM based copy protections in the relatively few games that have them. Certainly easier than having to solder any jumpers. UCON64 usually does an ok job of cracking those protections.
MottZilla wrote:
It is not that hard to break the SRAM based copy protections in the relatively few games that have them. Certainly easier than having to solder any jumpers. UCON64 usually does an ok job of cracking those protections.
I tried ucon64 on some games, but it did only seem to get rid off the regionlock ingame, but the sram protection somehow did not patch out, even though ucon64 said so. this is why i did the manual mod to my board as i wanted to know if these games do work or not.
Does anyone know how to make this check for different sized SRAM show up on an emulator like bsnes or snes9x? I could find the routine if I can get it to show (I tried doubling the size of the SRAM file and it played fine) and make an IPS patch for anyone who needed it.
Well, UCON64 strips SRam checks. If it was as easy as "getting the check to show" it wouldn't be so hard to find the data for it. I'm working on a comprehensive disassembly of several games to catch patterns in SRAM checking behavior, I assure you that if you have to ask how to get it to show, it's very likely beyond your scope of patching. We're talking assembly-level opcalls..there's also no SRAM 'file' and it's not as easy as just changing a number..
Unless of course I'm completely misinterpreting your intention here. If so, I apologize, and will attempt to re-answer the question if you can clarify your meaning.
The question as I understand it involved how to configure the emulator with a wrong SRAM size so that one can trigger the code that draws the screen and then trace backward from that code.
Well then in that case, you're looking for BSNES as an emulator. We'll pretend we're using Starfox 2 - it's the only ROM I've processed with BSNES, as I was working on patching it in a manner that would work on real hardware, and BSNES is the most hardware-accurate emulator that I know of..
Make a folder, StarFox2.sfc (or similar) and put inside it program.rom (headerless ROM file, renamed) as well as a manifest.xml
Inside manifest.xml place the code for the original ROM - I forget what exactly goes there...it can be generated by the ROM purifier that comes with the app.. Following the example of Starfox 2..
Code:
<?xml version="1.0" encoding="UTF-8"?><cartridge region="NTSC">
<superfx revision="2">
<rom>
<map mode="linear" address="00-3f:8000-ffff"/>
<map mode="linear" address="40-5f:0000-ffff"/>
<map mode="linear" address="80-bf:8000-ffff"/>
<map mode="linear" address="c0-df:0000-ffff"/>
</rom>
<ram size="0x10000">
<map mode="linear" address="00-3f:6000-7fff" size="0x2000"/>
<map mode="linear" address="60-7f:0000-ffff"/>
<map mode="linear" address="80-bf:6000-7fff" size="0x2000"/>
<map mode="linear" address="e0-ff:0000-ffff"/>
</ram>
<mmio>
<map address="00-3f:3000-32ff"/>
<map address="80-bf:3000-32ff"/>
</mmio>
</superfx>
</cartridge>
Obviously you won't have the superfx sections for a normal ROM..the important part is changing ram size and adding mappings to reflect the increased size. Beyond that, a little Google-fu will probably clear it up. Perhaps get the RAM mappings from a game with larger RAM, and the rest from your target game? Hopefully that's a leg-up.
SNgamer wrote:
MottZilla wrote:
It is not that hard to break the SRAM based copy protections in the relatively few games that have them. Certainly easier than having to solder any jumpers. UCON64 usually does an ok job of cracking those protections.
I tried ucon64 on some games, but it did only seem to get rid off the regionlock ingame, but the sram protection somehow did not patch out, even though ucon64 said so. this is why i did the manual mod to my board as i wanted to know if these games do work or not.
There are atleast three different options in ucon64. One applies "slowrom fixes" which no one should need now. Another applies region lockout "fixes". Then the last is "cracks" which is option -k which deals with copy protections. I've not come across a single game that doesn't work.
Emulators are very easy to fool into having the wrong amount of SRAM available as they read the imbedded rom info/header at $FFC0 for that. Just change it and you can easily trip the protection. But you could always just check the source code for ucon64.
The problem with pattern searches though is if the pattern is too small you risk a false positive that might break a game. This chance is reduced if you aren't trying to patch every game, but instead only when you have problems. The better idea would be to check the game title string located at the imbedded info block and then searching for the pattern.
Infact you could just have a table of all the games that may need cracks and when a game is chosen to write you could prompt the user if the game detected has any patches available for region or protection cracking, asking them if they wish to use them.
There is not a huge number of games that need these cracks. This is from a list I have.
Breath of Fire II
Demon's Crest*
Donkey Kong Country 1,2,3*
Earthbound*
Front Mission - Gun Hazard (J) - Has a note about translated version I believe.
Killer Instinct*
Kirby's Dream Course
Lufia II - Rise of the Sinistrals
Mario no Super Picross
Mega Man X*
Super Mario All-Stars*
Super Mario All-Stars & World
Super Metroid*
Tetris Attack
Uniracers
Ofcourse this list is just some old list I found which may have some inaccuracies and may be incomplete. Those with * I know have protection for sure.
Danin wrote:
Well, UCON64 strips SRam checks. If it was as easy as "getting the check to show" it wouldn't be so hard to find the data for it. I'm working on a comprehensive disassembly of several games to catch patterns in SRAM checking behavior, I assure you that if you have to ask how to get it to show, it's very likely beyond your scope of patching. We're talking assembly-level opcalls..there's also no SRAM 'file' and it's not as easy as just changing a number..
Unless of course I'm completely misinterpreting your intention here. If so, I apologize, and will attempt to re-answer the question if you can clarify your meaning.
Don't assume because I have a low post count that I don't know what I'm talking about. I have cracked many Region checks and other protections on many of these retro systems ( I hack Game Genie assembly codes for years). I wanted to have find the routine easily instead of checking every conditional branch on the boot of the game.
I will try your method Mottzilla and if that doesn't work then I will try your suggestion Danin. Once I find the routine I plan to release a patch for that specific game and not an all in one because more than likely each game will have the check in different locations.
EDIT: Tried to look at the header and at $FFC0 and there is nothing there about the ram size in the Super Metroid (JU) rom, but it does show in other roms.
Helder wrote:
Don't assume because I have a low post count that I don't know what I'm talking about. I have cracked many Region checks and other protections on many of these retro systems ( I hack Game Genie assembly codes for years). I wanted to have find the routine easily instead of checking every conditional branch on the boot of the game.
Okay, it would appear that there's been a misunderstanding here - on my part, which I apologize for.
Don't get me wrong - I guessed because of your
wording that you didn't know what you were talking about. (And was wrong.) I don't care one bit about your post count - look at mine. Sounds to me - by your
second post - that you knew more than I do before you even signed up. I can admit that freely. I misunderstood your question, and incorrectly judged by it - and stated that it was possible that I may've done so. I apologize if you felt slighted, it was not my intention.
Though, I ask in all curiosity - why not just read the UCON64 source code, find the patching entries, and apply them to the ROM, then create an IPS for it? That seems much easier than disassembling protection routines, especially for games like Earthbound that have a ton of them that aren't always apparent and often called many times within the game's code. I definitely agree with your intention, but the means of going about it might be a little time-hungry.
Danin wrote:
Helder wrote:
Don't assume because I have a low post count that I don't know what I'm talking about. I have cracked many Region checks and other protections on many of these retro systems ( I hack Game Genie assembly codes for years). I wanted to have find the routine easily instead of checking every conditional branch on the boot of the game.
Okay, it would appear that there's been a misunderstanding here - on my part, which I apologize for.
Don't get me wrong - I guessed because of your
wording that you didn't know what you were talking about. (And was wrong.) I don't care one bit about your post count - look at mine. Sounds to me - by your
second post - that you knew more than I do before you even signed up. I can admit that freely. I misunderstood your question, and incorrectly judged by it - and stated that it was possible that I may've done so. I apologize if you felt slighted, it was not my intention.
Though, I ask in all curiosity - why not just read the UCON64 source code, find the patching entries, and apply them to the ROM, then create an IPS for it? That seems much easier than disassembling protection routines, especially for games like Earthbound that have a ton of them that aren't always apparent and often called many times within the game's code. I definitely agree with your intention, but the means of going about it might be a little time-hungry.
You are correct in it being time consuming but it's something I enjoy doing so to the average person it's time consuming but to me it's enjoyable plus I learn of how the game is programmed in the process.
UCON64 patches DO work on Super Metroid. I had to use it on the Zero Mission hack because I was triggering the SRAM protection. I don't remember which command-line switch you have to use though... -k maybe?
Helder wrote:
You are correct in it being time consuming but it's something I enjoy doing so to the average person it's time consuming but to me it's enjoyable plus I learn of how the game is programmed in the process.
Hey, I totally respect that. If you enjoy it, and enjoy learning how it all works, more power to you. The entire host app was basically "I'm bored, I want to improve this, let's do some learning." so I really can relate. If there's anything else I can help with, I'll be more than happy to do so. There's actually a build of SNES9X that has a builtin debugger too, if you're interested I'm sure I could find a URL someplace, but I think from here maybe PM would be better than flooding this thread. Drop me a line and I'll try to chase it down.
Thanks but that is what I use as well as M.E.S.S since that has an amazing debugger and here is the patch if someone would be willing to try it out on real hardware to see if it works. This patch if for a Headered (JU) rom and completely bypasses the check routine which runs literally thousands of times with various checks in between the routine to either erase the saves or show the piracy screen and also erase the saves. If this proves successful then if there are games with such protections that have no fix in Ucon64 then I can take a look for anyone who needs it.
GG code:
6D69-17AF
DF61-1DDF
IPS Patch with Checksum Fixed:
If the point of this is to load the game onto an INL cart, you should've used an unheadered ROM... *shrugs*
qwertymodo wrote:
If the point of this is to load the game onto an INL cart, you should've used an unheadered ROM... *shrugs*
How hard is it to patch the rom then remove the header? an extra 2 clicks of a mouse? But so no one cries about having to do it here is the unheadered version.
Helder wrote:
qwertymodo wrote:
If the point of this is to load the game onto an INL cart, you should've used an unheadered ROM... *shrugs*
How hard is it to patch the rom then remove the header? an extra 2 clicks of a mouse? But so no one cries about having to do it here is the unheadered version.
I'm not complaining that it's hard, I'm just of the opinion that headers are useless and still manage to create confusion to this day, and only continue to exist because of patches built against them... well, that and ROM sets that include them.
Helder wrote:
qwertymodo wrote:
If the point of this is to load the game onto an INL cart, you should've used an unheadered ROM... *shrugs*
How hard is it to patch the rom then remove the header? an extra 2 clicks of a mouse? But so no one cries about having to do it here is the unheadered version.
Confirmed working straight up, no game genie needed. Powered off system, had a nice breakfast, and came back to all save slots intact. Also can confirm it works with the Justin Bailey patch as well.
Great job
satashi26 wrote:
Confirmed working straight up, no game genie needed. Powered off system, had a nice breakfast, and came back to all save slots intact. Also can confirm it works with the Justin Bailey patch as well.
Great job
Thanks for confirming! Once the Rom is patched there is no need for any master codes if you do use the Game Genie.
These flash carts by infinetneslives really work wonders. Now with this new patch as well, I can finally have my own super metroid Justin Bailey rom hack on the actual SNES!
Too bad the artwork doesn't match the hack with the blue suit from Metroid Zero Mission.
Got some new carts in today! Thought I'd give a very quick review before plugging them in and working with Helder to see if we can tag-team crack some protection on these bad boys!
Shipping: Decently fast. It took 2-3 days for them to actually ship out to me, but that's fine considering they're probably made to order. They were shipped priority, in a good sturdy box, wrapped in newspaper. I have no complaints here at all.
Communication: I didn't talk with InfiniteNesLives much during this transaction, but on my first one he generally got back to me in a matter of hours. A+
Quality: These things are really sturdy, look good, and are clean as could possibly be. He even added in a free battery for every flash cart I got. Some might consider this a given, but in all honesty, I consider it a plus. That wasn't required, and I appreciate it.
All in all, it was a smooth purchase, fast delivery, and an all around pleasure to do business with. I've bought seven of these now, and will definitely buy more in the near future.
Need some help guys >_<
Can someone teach me how to mirror a rom file? I have a program that pads it to whatever size I want, but I have no clue how to mirror it. Anyone know of a tutorial or anything that can help me out? My games are playing for a minute or so then glitching out and stopping, we think it might be because they're not mirrored.
satashi26 wrote:
Need some help guys >_<
Can someone teach me how to mirror a rom file? I have a program that pads it to whatever size I want, but I have no clue how to mirror it. Anyone know of a tutorial or anything that can help me out? My games are playing for a minute or so then glitching out and stopping, we think it might be because they're not mirrored.
viewtopic.php?f=12&t=11020The new Host app. It auto-pads and auto-mirrors. Most LoROM games don't need mirroring though. Is it LoROM or HiROM?
satashi26 wrote:
Communication: I didn't talk with InfiniteNesLives much during this transaction, but on my first one he generally got back to me in a matter of hours. A+.
I wish I could say the same. I bought some boards more than a month ago and they didn't run on PAL SNES. I wrote some emails to InfiniteNESLives and it took more than a week to answer, and he didn't even answer my last email, written more than 2 weeks ago...
I'm still trying to get in touch with him, so I hope he reads this post.
Sorry results may vary at times. I've enlisted the help of friends and family on distribution of my volume products as I couldn't keep up with it all myself. Emails which require more than a minute or two often pile up till I have time on the weekends to catch up on the inbox. If you have technical questions on these boards which need addressed I recommend posting it here. As others might be able to lend suggestions, and I can share info with everyone, not just personal emails.
That said mango's issues are related to the CIC, so here is some info for all. I originally designed the boards to work with jim's cool SNES CIC. His CIC works great on NTSC consoles, and reports I got from PAL beta testers was all good. Later on some people started experiencing issues with the cic in PAL regions. I added support for ikari's superCIC with the non-pin compatible pic 12F629 with my second PCB revision. That revision is now in production and any board orders in PAL regions has been receiving the superCIC as of the past couple weeks. I'm not certain what the issue is wth jim's cool SNES cic, I'm half concerned it might be a power issue. The SNES notoriously has a noisy supply, and it could explain why some have issues and others not. I'm working on obtaining a PAL SNES which has the issues so I can debug the issue, but that hasn't been an expeditious process to say the least. So the superCIC saves the day for our PAL friends for now.
Danin wrote:
viewtopic.php?f=12&t=11020The new Host app. It auto-pads and auto-mirrors. Most LoROM games don't need mirroring though. Is it LoROM or HiROM?
HiROM, one is 2.5M and the other is 4M, both on a 4M board. I tried padding and still messes up in the same spot, give or take 5 seconds. Though would those files need to be mirrored? One already fills the whole board.
I just got a 4MB cart in the mail yesterday and am having trouble getting it to work. I think it might be an issue with HiROM games but I'm not sure what a good test set is for narrowing down issues, so any help would be appreciated.
Games tested so far:
Final Fantasy III US (4MB, patched with
http://www.romhacking.net/hacks/1386/) - crashes at scene transition during prologue
Final Fantasy III US (3MB, unpatched) - crashes at a different scene transition during prologue
Chrono Trigger US (4MB) - crashes during attract mode demo
Super Mario World US (512KB) - works (through first few levels at least)
All games tested run without crashing in higan. I've flashed FF3 using both the firmware linked on INL's site and Danin's new firmware and obtained identical results.
jbradfield wrote:
using both the firmware linked on INL's site and Danin's new firmware and obtained identical results.
Are you talking about the firmware (the part that you update on the Kazzo) or the host app (the part that runs on the PC) when you're testing with both? The
firmware won't fix crash issues, as the writes are handled the same for the most part. The host app may make some difference. Which release of my host app are you using? What are you using to apply the patch that you mentioned? It shouldn't be a HiROM
mapping issue, in theory, since it's a 4MByte Rom on a 4MByte cart, but do make sure you flipped the top switch to HiROM position.
I'm at work right now so I can't do too much testing for you, but if you provide that info, I'll do some checking when I get home (around 5:45pm MST) and get back with you on my results. A common issue seems to be cart centering - see the info in my host app thread for proper positioning (in the Quick Usage section) when inserting it into the Kazzo, since the socket and cart aren't perfect matches.
The main issue I have with getting you an answer right away is that I have not received a 4MByte board to test HiROM with, hopefully that will happen soon. Try to test several Roms that're LoROM and several that are HiROM, and let me know if the HiROM ones all fail, or which ones work and which fail (and what size they are,
specificaly Rom Size as listed in the host app) and I'll see what I can figure out on my end. Also, if a Rom fails, try without "Auto-Fix Protection" and see if that changes things...it's fairly safe, but there's a tiny chance that could cause issues.
Danin wrote:
Are you talking about the firmware (the part that you update on the Kazzo) or the host app (the part that runs on the PC) when you're testing with both? The firmware won't fix crash issues, as the writes are handled the same for the most part. The host app may make some difference.
Both. I tried the INL host app/firmware beta 1.1 and your host app/firmware release 10. They produced identical results (FF6 crashes in the same place).
Danin wrote:
Which release of my host app are you using? What are you using to apply the patch that you mentioned? It shouldn't be a HiROM mapping issue, in theory, since it's a 4MByte Rom on a 4MByte cart, but do make sure you flipped the top switch to HiROM position.
Release 10, as mentioned. I tried both a version pre-patched with SNES ROM Util, and patching the original ROM with the host app. The switch is set to HiROM (attempting to boot in LoROM just results in a black screen).
Danin wrote:
I'm at work right now so I can't do too much testing for you, but if you provide that info, I'll do some checking when I get home (around 5:45pm MST) and get back with you on my results. A common issue seems to be cart centering - see the info in my host app thread for proper positioning (in the Quick Usage section) when inserting it into the Kazzo, since the socket and cart aren't perfect matches.
I think I've been fairly careful with cart alignment while flashing (I noticed the alignment mismatch the second time I socketed the cart into the kazzo). If the cart was misaligned, I think the result would be more obvious corruption instead of "runs perfectly until the moment it crashes", but I dunno.
Danin wrote:
The main issue I have with getting you an answer right away is that I have not received a 4MByte board to test HiROM with, hopefully that will happen soon. Try to test several Roms that're LoROM and several that are HiROM, and let me know if the HiROM ones all fail, or which ones work and which fail (and what size they are, specificaly Rom Size as listed in the host app) and I'll see what I can figure out on my end. Also, if a Rom fails, try without "Auto-Fix Protection" and see if that changes things...it's fairly safe, but there's a tiny chance that could cause issues.
I'll find a list and see what results I get.
jbradfield wrote:
(snip) I'll find a list and see what results I get.
Thank you for your thorough reply. I appreciate that very much. I'll check into it tonight for sure, and I'll let you know what my results are compared to your own, however the only cart I have is the 12MByte so my results may be different.
I'm having the same issue actually, as the ones I was working on was final Fantasy VI, and Final Fantasy V. Part IV worked perfectly, but it's a LoROM game. The game glitches during the opening text in VI and same with V, although V lasts about 2 minutes longer before it crashes.
I've done Super Metroid on the 1.1 beta firmware and software, and it's a HiROM. Although I tried V and VI on the same setup and it didn't work so I upgraded to the newest version 10 and running the update with it .So I don't think it's ALL HiROM games...
@jbradfield: Looks like we're doing the same games. If I figure out a solution before you, I'll be sure to post here to let you know!
EDIT3: It was my SNES. The carts work fine in another one.
My final reply before I get home to actually do testing and checking: The firmware shipped with Release 10 will run perfectly with all previous releases. Downgrading firmware to A) Fix bugs, or B) use the old host app versions/original version/etc should never be required. I appreciate that you guys are thorough enough to test all of these scenarios, but I wanted to let you know that it isn't directly required to move between versions. New features are added in parallel with old features, and behavior is proven to be completely unchanged when using older/original software. That was a design goal I set for myself, actually - I didn't want people to have to mess with their firmware more often than necessary. ;)
Interesting that you two are having parallel problems...I wonder what's up there. I'll definitely look into it tonight.
satashi26 wrote:
I'm having the same issue actually, as the ones I was working on was final Fantasy VI, and Final Fantasy V. Part IV worked perfectly, but it's a LoROM game. The game glitches during the opening text in VI and same with V, although V lasts about 2 minutes longer before it crashes.
I've done Super Metroid on the 1.1 beta firmware and software, and it's a HiROM. Although I tried V and VI on the same setup and it didn't work so I upgraded to the newest version 10 and running the update with it .So I don't think it's ALL HiROM games...
@jbradfield: Looks like we're doing the same games. If I figure out a solution before you, I'll be sure to post here to let you know!
Super Metroid is a LoROM game, despite what you might intuit from its size.
I've tested the following games and logged the results. Games that didn't crash in the first 5-10 minutes of use are labeled as "works (apparently)" since a thorough test of stability is impractical.
Code:
Game Region Actual Size ROM Size Hi/Lo Speed Status
---- ---- ---- ---- ---- ---- ----
Final Fantasy VI (patched FF3) NA 4096 KB 4096 KB HiROM FastROM CRASH on scene transition during prologue
Final Fantasy III NA 3072 KB 4096 KB HiROM FastROM CRASH on scene transition during prologue
Chrono Trigger NA 4096 KB 4096 KB HiROM FastROM CRASH during attract mode
Super Mario World NA 512 KB 512 KB LoROM SlowROM Works (apparently)
Tactics Ogre JP 3072 KB 4096 KB LoROM FastROM Works (apparently)
Breath of Fire 2 NA 3072 KB 4096 KB HiROM FastROM Works (apparently)
Super Metroid NA 3072 KB 4096 KB LoROM FastROM Graphical corruption in background of Crateria (http://i.imgur.com/yHpsMYD.jpg)
Final Fantasy V JP 2048 KB 2048 KB HiROM SlowROM CRASH shortly after scene transition during prologue
There appears to be a recurring issue with Squaresoft HiROM games. Further test cases (FF4 and Secret of Mana come to mind) are probably warranted. The
Super Metroid result is particularly interesting; I'm not sure if its indicative of a poor flash or a potential hardware fault in the board.
I've checked Final Fantasy IV and it works fine. I'll try and get on Secret of Mana and Secret of Evermore later tonight/tomorrow. Also my Super Metroid worked, so you may want to try re-doing that one? ( and yeah it's LoROM my bad!)
Sorry this took so long, had a pet-related emergency to attend to, and now I'm just so worn out that I'm honestly not up to putting much effort into this, BUT I said I would, so here I am. First off. Thank you for the nice table and information and so forth, it really makes the lives of those trying to help much easier. I won't be taking the time to reciprocate on the nice fancy table right now, I just don't have the energy. I've done two tests, and that's as far as I'm getting tonight because I'm just exhausted after that whole ordeal.
Final Fantasy 3 (CRC32: C0FA0464) plays perfectly all the way through waking up and running from the dudes after having the crown removed or whatever. I wasn't paying attention, but it took like 15 minutes of half-attentive play to get there...
Chronotrigger (CRC32: 2D206BF7) has looped through its attract mode scenes probably ten times while I've been eating dinner/etc..
Both CRC32s are from my host app immediately after loading, on the Original buffer tab. (Suddenly I kind of want to add copy-to-clipboard support for those...)
I suspect one of two things. Bad ROMs (even if they play in emulators, because they use a lot of workarounds and silent fixes for bugs and bad dumps and such) OR something messed up with my HiROM mapping for the 4MByte carts (I'm using a 12MByte cart) or maybe SlowROM protection that's getting triggered by a slightly laggy flash chip maybe? I don't know. 4MByte HiROM shouldn't exactly be difficult, it's mirrored to where you should just have to write the file. If it's not an issue with the quality of the ROM file, I have no other idea for tonight. I'll look into it further tomorrow, but I have a feeling that anything more than a preliminary sniffing around is going to require me having access to a 4MByte cart.
I'll go back through the list and add CRCs tomorrow. I'm sure the FF3us ROM is canonical, at least (checked the CRC32 and MD5 before I patched it).
Edit: actually I guess I'll just do that now. Probably not going to get a chance tomorrow to test any additional games.
Notable: you're testing FF3us v1.1, I'm testing FF3us v1.0, hence the CRC32 mismatch. Both are canonical.
Code:
Game Region CRC32 Actual Size ROM Size Hi/Lo Speed Status
---- ---- ---- ---- ---- ---- ---- ----
Final Fantasy VI (patched FF3) NA 99D2799B 4096 KB 4096 KB HiROM FastROM CRASH on scene transition during prologue
Final Fantasy III NA A27F1C7A 3072 KB 4096 KB HiROM FastROM CRASH on scene transition during prologue
Chrono Trigger NA 2D206BF7 4096 KB 4096 KB HiROM FastROM CRASH during attract mode
Super Mario World NA B19ED489 512 KB 512 KB LoROM SlowROM Works (apparently)
Tactics Ogre JP DAF285A5 3072 KB 4096 KB LoROM FastROM Works (apparently)
Breath of Fire 2 NA 67CDACC5 3072 KB 4096 KB HiROM FastROM Works (apparently)
Super Metroid NA 806D0D0B 3072 KB 4096 KB LoROM FastROM Graphical corruption in background of Crateria (http://i.imgur.com/yHpsMYD.jpg)
Final Fantasy V JP A8E7DFFA 2048 KB 2048 KB HiROM SlowROM CRASH shortly after scene transition during prologue
Hope there's not any transcription errors in there.
Double-edit: my ROMs are all headered (CRC32s are pulled from the HeaderStrip tab of the host app). I assume since the ROMs all actually boot on the SNES that header stripping is an automated part of the process, right? That shouldn't break anything.
Header stip is indeed an automated process, and 100% required for any Rom to work on the SNES with any hardware. The header is 512 bytes of information that's not needed, and was added by cart dumpers, and only adds confusion when applying patch files because sometimes they're patched as headered, sometimes headerless, etc etc. Thanks for specifying where the CRCs (etc) are coming from, and for what it's worth, copy to clipboard will be in my next release. Here's something interesting, though;
I've tested it thoroughly with my 12MByte cart. Everything I've tried has worked fine. I have someone helping me beta and debug, and we're seeing breakage. I've confirmed that her cart is receiving the same data as mine (just 4MByte instead of the full 12MByte HiROM/mirroring stuff) and given that it's a 4MByte ROM on a 4MByte cart, it should be working. I've checked SRAM protection routines, region protection routines, I even added (and patched) SlowROM protection - I was sure that last one would fix it, since it found instances of SlowROM protection. Nothing we've done is working.
Since it works on a 12MByte cart (and I only have a 12MByte cart) I can't do any further testing. The only conclusion I can come to is that it's a bug in the CPLD someplace that only comes into play with the few ROMs you guys have mentioned issues with. I unfortunately will not be able to help with resolving these issues until one of two things happens, the timeframe of both of which are out of my control.
TL:DR - Seems to be a cart issue, works on 12MByte carts, not 4MByte carts. Can anyone with an 8MByte cart chime in? (I apologize if someone here HAS an 8MByte cart and has already weighed in, I've been under serious stress since Monday, so I may've missed/forgotten something...)
That's somewhat ironic, considering I got the 4MB cart on the expectation that I'd only be putting FF6 on it and thought a cart of the correct size would be less likely to cause problems. I guess I'll have to see about getting a different cart. If you can suggest any further testing in the meantime I'd be happy to fiddle with it.
This is all very uncomfirmed, so don't go spending money just yet unless you don't want to wait for better confirmation. This is initial speculation, nothing more. Also, while I am the Host App guy, I am NOT the hardware guy and have no direct affiliation with INL - my statements are not to be considered 'official' on anything except the host app. Please don't go flocking to him claiming my suggestions here as fact. I'll be receiving a 4MByte cart soon, and I'll do what further testing I can at that time. Furthermore, if the bug IS cart-side, I suspect there will be a fix made available. INL's design leaves room for fixes, as far as I can see. The problem is, you'll either need to be capable of programming a CPLD, or you will have to send it to someone who can.
IF we discover that it is a cart-side bug, I'll offer free programming service to those needing it, requiring only that you pay shipping to me and back.
Final Fantasy 6 should work fine on your 4megabyte/32mbit cartridge.
SlowROM is not protection. You should never apply SlowROM fixes today. The SlowROM fixes are related to very old copiers that presumably did not support FastROM access. By enabling FastROM these games would crash on Copiers that can't support FastROM timing. If you apply a SlowROM fix you will only introduce problems, not solve any. The INL carts certainly do support FastROM access timing.
I don't have time tonight to test FF6 on my own 4 megabyte cartridge, but I have tested similar games such as Terranigma which ran with no problems. It's the same setup except it has 1 megabyte of additional ROM storage.
Your problem doesn't sound like a problem with the INL cartridges as a group. Are you using an original SNES power supply or a third party supply? Are you using an original Nintendo manufactured system or a clone? Do any of the games that you have problems playing do you have an original cartridge of to try? Have you cleaned your system connector and ruled out a bad connection? Have you tried using the cartridge on another console?
When you say crash, does the screen go blank and the sound stop? If it does, I've had that problem too and solved it.
MottZilla wrote:
Final Fantasy 6 should work fine on your 4megabyte/32mbit cartridge.
Yes, that's exactly the basis of assessment I've used to raise the suspicion of the 4MByte cartridges being at fault. It's not working. It should work. Thus, there's a problem.
MottZilla wrote:
SlowROM is not protection. You should never apply SlowROM fixes today. The SlowROM fixes are related to very old copiers that presumably did not support FastROM access. By enabling FastROM these games would crash on Copiers that can't support FastROM timing. If you apply a SlowROM fix you will only introduce problems, not solve any. The INL carts certainly do support FastROM access timing.
I am well aware of the nature of SlowROM and that these carts support FastROM. I was trying to test the validity of the assumption that the carts -should- work with games that require FastROM, and see if maybe there was a timing-related issue with 4MByte cartridges that did not exist with 12MByte cartridges. I improperly stated it as SlowROM Protection, when what I was applying were in fact SlowROM "fixes" as prescribed by UCON64. Clearly some issue is possible using these fixes, which is why they aren't in the released versions of my app, I merely tried that to see if it improved or at all changed the behavior of the issues - it did not, and as such I've eliminated it (as I said) from suspicion.
MottZilla wrote:
I don't have time tonight to test FF6 on my own 4 megabyte cartridge, but I have tested similar games such as Terranigma which ran with no problems. It's the same setup except it has 1 megabyte of additional ROM storage.
I haven't heard one report of FF6 working on the 4MByte INL carts, which is the basis of this whole conversation - I'd be thrilled to hear back on your success with this though, IF it's an INL cart. I suspect the problem is with the INL cart specifically, as I've stated, so unless it's an INL 4MByte cart, I fully expect you'll report that it works.
MottZilla wrote:
Your problem doesn't sound like a problem with the INL cartridges as a group. Are you using an original SNES power supply or a third party supply? Are you using an original Nintendo manufactured system or a clone? Do any of the games that you have problems playing do you have an original cartridge of to try? Have you cleaned your system connector and ruled out a bad connection? Have you tried using the cartridge on another console?
It sounds exactly like a problem with the 4MByte INL cartridge as a group, as I have not heard a single report of success with specifically the 4MByte INL cart running specifically FF6. The carts play most games fine, but several (as listed on a previous post by a very thorough member) don't work on the 4MByte cart, and do work on the 12MByte cart as verified by myself and at least one other member.
MottZilla wrote:
When you say crash, does the screen go blank and the sound stop? If it does, I've had that problem too and solved it.
I haven't personally had the problem (yes I know you're not talking directly to me) thus my attempts to collate data, and I'm seeing a very specific pattern of games that don't work on INL 4MByte carts. What I find odd is the reports that they do work on 12MByte carts, and fail on 4MByte carts. As we've both stated, it -should- work, but it does not, thus identifying the definition of 'a problem' and not 'no problem'. I've received reports from no less than four individuals - one of whom has five INL 4MByte carts on her desk - who cannot get the ROMs listed previously to work on their cart(s), and counting myself, two others who CAN get them to work on 12MByte carts. Not to be considered 'statistically significant' so far as sample group sizing, but it's enough of a pattern with enough valid tests from experienced and intelligent users for me to determine that there's an issue that's not as simple as one might assume.
And like always, I'm going off of what I've seen. If I'm wrong about any of my statements, I'll readily admit it, but given the information I've collected from various reports in this thread and in PMs inspired BY this thread, it's a bit much to assume that they've all got bad power supplies that cause the SNES to have various errors on specific games with specific carts, or similar causes.
MottZilla wrote:
Your problem doesn't sound like a problem with the INL cartridges as a group. Are you using an original SNES power supply or a third party supply? Are you using an original Nintendo manufactured system or a clone? Do any of the games that you have problems playing do you have an original cartridge of to try? Have you cleaned your system connector and ruled out a bad connection? Have you tried using the cartridge on another console?
In addition to everything Danin said:
1) I'm running on all original hardware. I've used it to run something like a dozen commercial SNES carts and it works perfectly fine.
2) I own an original Chrono Trigger cart, and it runs without issue while the same game on the INL 4MB crashes very quickly. The Chrono Trigger ROM used in testing is canonical; the issue is almost certainly with the INL cart, and not with the console or the ROM.
I haven't had time to test yet, but have you been able to run Terranigma on your 32mbit cartridge? I know I have. I'll try to load up FF6/FF3 tonight and test it.
Update: Final Fantasy III works just fine on my 4 megabyte cartridge. My statement earlier that it's not a problem with the INL cartridges means I don't think it's a problem with the design, it might be a problem with the particular cartridge or something like that. Because obviously other people (such as myself) have had plenty of success with them.
Thanks everyone for researching and providing details on the issue here. I just tested FF3 on a 4MB board without any issues playing up to the first couple battles.
Can you confirm that you're using the current release of firmware and software on my site? I don't expect an issue with Danin's release, but to be safe, I'd like to confirm that you're using my build of things until I get some 4MB boards in Danin's hands at least. I just programmed the 3MB file as-is with the 3MB dropdown selection and played in HiROM. Nothing special on the setup programming, doesn't appear mirroring of the last 1MB is necessary at least up to the point where I played a few battles.
FWIW, paying my rom in an emu reports a good checksum of crc32:A27F1C7A which looks to match up with jbradfields report.
So if you can confirm the error on my firmware and app (perhaps you already have), let me know. Shoot me an email and I'll get you swapped out with replacements as it sounds like it's just your board.
So are both jbradfeild and satashi26 having the same exact issue still? That makes me a little curious. I'll have a fresh board pulled from the assembly line this weekend and see if anything similar is going on there.
If there is anything else you'd like me to try specifically let me know.
MottZilla wrote:
Update: Final Fantasy III works just fine on my 4 megabyte cartridge. My statement earlier that it's not a problem with the INL cartridges means I don't think it's a problem with the design, it might be a problem with the particular cartridge or something like that. Because obviously other people (such as myself) have had plenty of success with them.
Thank you for taking the time to test, however with more details we might come to an actual conclusion. IE, CRC value of your Rom, which software/firmware you were using, etc.
Information helps us determine the cause of the problem. In fact, other things such as the version number written on the cart might help. My 12MByte board says v1.1 in pen and that leads me to believe there is at least a v1.0 design out there, which may perform differently, or have some difference that is causing the trouble..or perhaps the v1.1 boards have a problem and the v1.0 board does not.
I simply find it difficult to believe that so many people are having problems with this specific set of Roms and that they all have a dirty socket/faulty power supply/etc causing only these games to not work. If you could be so kind, please share further information. If we can get to the bottom of this, and it's an issue with my firmware or software, I'd love the opportunity to fix it. Thank you.
Edit: Hey there INL, didn't see your reply there. If there's anything you'd like to know from my end, you know where to find me. I did some one-on-one with satashi and everything there checks out but it still won't run. From what I understand, satashi has five boards, but now that I think about it, I don't directly remember if the problem was encountered on multiple boards. I suspect so, but I'll check in and verify this unless we hear a report back before then.
FWIW I tested on a new 4MB board which should be equivalent to anything shipped in the past couple weeks. It's the newer pcb rev v1.1 (in silk), but the CPLD rev is 1.1 (pen) which should match everything shipped in the past 6 months or so. Mottzilla's might be older than that IIRC, I'm guessing he's got a v1.0 CPLD, I know he has a v1.0 pcb.
infiniteneslives wrote:
Can you confirm that you're using the current release of firmware and software on my site? I don't expect an issue with Danin's release, but to be safe, I'd like to confirm that you're using my build of things until I get some 4MB boards in Danin's hands at least.
Confirmed, I tried that and when it didn't work, I upgraded to the new stuff. I thought it was a problem with out dated things.
Quote:
I just programmed the 3MB file as-is with the 3MB dropdown selection and played in HiROM. Nothing special on the setup programming, doesn't appear mirroring of the last 1MB is necessary at least up to the point where I played a few battles.
My problem is with Final Fantasy VI, not 3. FF3 is 3MB in size, but VI is 4MB. I use:
http://coolrom.com/roms/snes/679/Final_ ... pan%29.phpQuote:
FWIW, paying my rom in an emu reports a good checksum of crc32:A27F1C7A which looks to match up with jbradfields report.
My crc32 is: BB80A273
Quote:
So are both jbradfeild and satashi26 having the same exact issue still? That makes me a little curious. I'll have a fresh board pulled from the assembly line this weekend and see if anything similar is going on there.
Yeah, we're crashing in the same spot.
EDIT: Just tried Final Fantasy 3 and it crashes immediately when I press a button to leave the title screen, which is about 30 seconds sooner than when I try FF VI.
EDIT2: Tried Chrono Trigger as well, but it worked perfectly all through the opening scenes before you press start, and played up till you crash into MArle at the fair. No problems there. Will try other games he had issues with when I get home from work.
EDIT3: It was my SNES. The carts work fine in another one.
infiniteneslives wrote:
Thanks everyone for researching and providing details on the issue here. I just tested FF3 on a 4MB board without any issues playing up to the first couple battles.
Can you confirm that you're using the current release of firmware and software on my site? I don't expect an issue with Danin's release, but to be safe, I'd like to confirm that you're using my build of things until I get some 4MB boards in Danin's hands at least. I just programmed the 3MB file as-is with the 3MB dropdown selection and played in HiROM. Nothing special on the setup programming, doesn't appear mirroring of the last 1MB is necessary at least up to the point where I played a few battles.
FWIW, paying my rom in an emu reports a good checksum of crc32:A27F1C7A which looks to match up with jbradfields report.
So if you can confirm the error on my firmware and app (perhaps you already have), let me know. Shoot me an email and I'll get you swapped out with replacements as it sounds like it's just your board.
So are both jbradfeild and satashi26 having the same exact issue still? That makes me a little curious. I'll have a fresh board pulled from the assembly line this weekend and see if anything similar is going on there.
If there is anything else you'd like me to try specifically let me know.
I tried the romhacked FF3us using your package, but I can't remember if I tried any of the canonical 24 Mb ROMs with it or not. It's
possible the issue only crops up when filling the cart to capacity, which Danin's package does automatically. I'll run a couple more tests when I get home tonight.
satashi26 wrote:
My problem is with Final Fantasy VI, not 3. FF3 is 3MB in size, but VI is 4MB. I use:
http://coolrom.com/roms/snes/679/Final_ ... pan%29.phpMy crc32 is: BB80A273
I don't think that's a canonical ROM; my dump of FF6 is 3MB with CRC32 45EF5AC8. To my knowledge FF3us/6j shipped on a 24 Mb cart in both territories.
jbradfield wrote:
I tried the romhacked FF3us using your package, but I can't remember if I tried any of the canonical 24 Mb ROMs with it or not. It's possible the issue only crops up when filling the cart to capacity, which Danin's package does automatically. I'll run a couple more tests when I get home tonight.
To be specific, my software pads the Rom (with 0xFF) to the size it reports that it is in the SNES header (not the 512-byte dumper header) before Mirroring or HiRom mapping it.
Of course, when uploading as HiRom it
always makes sure it's mapped right, so wether it needs direct remapping or not, it is always auto-padded to its reported size with HiROM. I may change this behavior if it's reported to cause these issues, but apparently even with the stock INL 1.1 software the same issue is present. In LoROM it doesn't bother filling the cart unless the user specifically requests Mirroring, though in HiROM it does fill the entire cart every time.
I don't think that has anything to do with the issues reported though, since the problems are reported with stock INL 1.1 software too. If we find I'm wrong, I'll change the behavior to whatever is needed.
For 24 Mbit games you might consider duplicating the last 8 Mbit instead of padding in case the game relies on address mirroring in the second PRG ROM chip. I know of at least one 10 Mbit game that relies on mirroring (hint: what's the Roman numeral for that many Mbit?).
tepples wrote:
For 24 Mbit games you might consider duplicating the last 8 Mbit instead of padding in case the game relies on address mirroring in the second PRG ROM chip. I know of at least one 10 Mbit game that relies on mirroring (hint: what's the Roman numeral for that many Mbit?).
Thank you for the information.
With that clarification, I will update the behavior of my app. I've been told where my logic was faulty - I improperly thought that a 3MByte game that reports as 4MByte was, in actuality, using a 4MByte Mask Rom with empty space at the end. In actuality, it's a 2MByte Mask Rom paired with a 1MByte Mask Rom. I'll further verify, if I can, wether this is universally the case, and update the program's behavior to reflect what I find. (Edit for incorrect wording.)
To relay the information as discussed in private (to avoid flooding the thread) for future reference:
tepples wrote:
Danin wrote:
I was under the impression that dumps were truncated to the length of valid data and the rest of the Mask ROM was empty, in the case of a 3MByte Rom from a 4MByte cart.
What does the hardware do when accessing "empty"?
These 24 Mbit games have two physical ROMs on the PCB: one 16 Mbit and one 8 Mbit. One of the address lines from the cart edge (A21 in HiROM) determines which ROM is used for a given access, and the address line connected to the 16 Mbit ROM's highest address input (A20 on the ROM and on the HiROM cart edge) isn't connected to the 8 Mbit ROM at all. This means the ROM ignores that bit of the address, and this ignoring behavior produces what the CPU sees as ROM mirroring.
tepples wrote:
Mask ROM has a cost per pin and a cost per megabit. Yields were such that the marginal cost per megabit of a 32 Mbit ROM over a 16 Mbit ROM exceeded the marginal cost of two ROMs over one. Remember that Famicom cassettes had two ROMs (PRG and CHR) in about the same board size as a Super Famicom cassette or Super NES Game Pak.
As such, the nature of my mistake was assuming a single 4MByte chip with blank space at the end that was truncated by the dumpers. My assumption was incorrect, as they use two chips to match the exact size of the ROM data - the larger first, smaller second, and since SNES read access to 'off-chip' space wrap backward (depending on configuration) the SNES CPU will receive - in the case of this situation - two 'mirrors' of the smaller chip's data.
Danin wrote:
I improperly thought that a 3MByte game that reports as 4MByte was, in actuality, using a 2MByte Mask Rom paired with a 1MByte Mask Rom.
It is! But it's EE-wise simpler to mirror than to leave memory as open bus, and in turn it's simpler to leave open bus than to pad with fixed contents.
I don't know that I am using the latest firmware. For the quick test I used the original application, not the new one. If I get more time I may be able to do more tests but in short, I don't have any problems with the games mentioned so I don't believe it is related to the games. Ofcourse if the hardware has been altered from what I have then my results don't necessarily apply.
infiniteneslives wrote:
Thanks everyone for researching and providing details on the issue here. I just tested FF3 on a 4MB board without any issues playing up to the first couple battles.
Can you confirm that you're using the current release of firmware and software on my site? I don't expect an issue with Danin's release, but to be safe, I'd like to confirm that you're using my build of things until I get some 4MB boards in Danin's hands at least. I just programmed the 3MB file as-is with the 3MB dropdown selection and played in HiROM. Nothing special on the setup programming, doesn't appear mirroring of the last 1MB is necessary at least up to the point where I played a few battles.
FWIW, paying my rom in an emu reports a good checksum of crc32:A27F1C7A which looks to match up with jbradfields report.
So if you can confirm the error on my firmware and app (perhaps you already have), let me know. Shoot me an email and I'll get you swapped out with replacements as it sounds like it's just your board.
So are both jbradfeild and satashi26 having the same exact issue still? That makes me a little curious. I'll have a fresh board pulled from the assembly line this weekend and see if anything similar is going on there.
If there is anything else you'd like me to try specifically let me know.
Just dumped FF3us v1.0 (CRC32 A27F1C7A) to the 4MB cart with no mirroring using the 1.1 beta firmware/programmer. Same results as before, crashes during the second scene transition of the prologue. I guess it's a board issue, I'll shoot you an email.
I finally got 12 MB board and are trying to get it working with Star Ocean.
For the life of me i cannot get it going.
Have tried a few patches but nothing seems to work.
Has anyone got this working? If so can you possibly PM and let me know which rom you use?(or send me the working rom:) )
mamejay wrote:
I finally got 12 MB board and are trying to get it working with Star Ocean.
For the life of me i cannot get it going.
Have tried a few patches but nothing seems to work.
Has anyone got this working? If so can you possibly PM and let me know which rom you use?(or send me the working rom:) )
Most of the Star Ocean decompressed Roms are interleaved. You'll need to find either a Delta patch that deinterleaves them, or the Deinterleaved Rom.
I'm spending a few minutes every now and then trying to figure out the pattern for deinterleaving properly, but it hasn't been fun so far, hahah. I'll spend a bit more time on it over the weekend here, see if I can add it to the host app as a special case load.
Danin wrote:
mamejay wrote:
I finally got 12 MB board and are trying to get it working with Star Ocean.
For the life of me i cannot get it going.
Have tried a few patches but nothing seems to work.
Has anyone got this working? If so can you possibly PM and let me know which rom you use?(or send me the working rom:) )
Most of the Star Ocean decompressed Roms are interleaved. You'll need to find either a Delta patch that deinterleaves them, or the Deinterleaved Rom.
I'm spending a few minutes every now and then trying to figure out the pattern for deinterleaving properly, but it hasn't been fun so far, hahah. I'll spend a bit more time on it over the weekend here, see if I can add it to the host app as a special case load.
That would be awesome!!
Btw I just downloaded you current flashing app and I must say I am very impressed. Very polished so far has worked for all roms have tried out. Excellent work and compliments the int board perfectly.
mamejay wrote:
That would be awesome!!
Btw I just downloaded you current flashing app and I must say I am very impressed. Very polished so far has worked for all roms have tried out. Excellent work and compliments the int board perfectly.
That's what I'm shooting for..hah.. And I'm glad to hear you enjoy it. I've put a lot of work into it, and I'm nowhere near done. There are certainly a few bugs, usually related to scenarios I can't test yet, since I don't have access to every set of boards...I'm working on it though, I should have the other boards fairly soon. I have big news for the next update that should come this weekend, and the larger your cart is, the better the news is. Keep an ear up for it over the next day or two.
I managed to get a working rom and also firmware to flash to the unit. Had to use a special 12mb file to perform the erase and then just the original flashing tool infinity supplied.
Danin. Can your tool perform the erase of the 12mb carts?
mamejay wrote:
I managed to get a working rom and also firmware to flash to the unit. Had to use a special 12mb file to perform the erase and then just the original flashing tool infinity supplied.
Danin. Can your tool perform the erase of the 12mb carts?
Sounds like a question better suited for the thread dedicated to that software...but yes. My software can erase any SNES INL cart, and
should program any Rom except the Star Ocean
interleaved Rom and similar one-off exceptions. A deinterleaved Star Ocean Rom should program just fine, in theory...though thinking back it might be 'Re-Addressed' and write all wrong. I'll double-check that, but I'm coming up on a significant increase over the weekend here, so wether it works or not as of Release 10, it will work with Release 11.. Can't promise Star Ocean
deinterleaving for Release 11, but we'll see how it goes. However, it's movie night, so further progress tonight will not happen. Enjoy your weekend guys!
I've been having trouble with the 12 mb snes boards. Last time I bought one, I ran into the same problems I was having now, but at some point it programmed randomly so I didn't look into the matter further.
I bought another two boards and am having trouble again. Everything goes well until for the erasing, but when I go to load star ocean, and hit write, it crashes after 5 seconds. It just says "not responding". The one time it did work, I never got a green bar, but I did get the data onto the board and the game worked. So i'm not sure what to do.
lordloss wrote:
it crashes after 5 seconds. It just says "not responding".
INL's stock app does this. It seemingly hangs during writes because there's no callback to the OS to tell it "I'm still alive" during its work loop - it literally just pretends it's locked up until it's done.
1) Just keep waiting until it finishes. It hasn't actually crashed. Don't click the window, don't press any keys, don't even move the mouse through the window. If Windows complains, tell it to wait. It'll take about 12 minutes to write a full 12MByte ROM to a 12MByte cart. I'm tempted to fix this issue and re-release it, simply so legacy users have something to use if mine fails.
2) Use my new host app. Star Ocean 12MByte
deinterleaved is untested, but should be supported. Star Ocean 12MByte
interleaved will fail.
Update to my problems:
Summary: A few games, specifically Hi-ROM ones, were freezing at certain points while playing. This included Final Fantasy 3, V and VI. After much testing and trouble shooting, Danin and I discovered the problem was with my SNES itself. We're not sure as of WHY yet, but we're positive that's it.
When I took my INL carts to my local game store to test there, they all worked perfectly (with and without an official power supply). I tried a cleaning kit and still no dice. So yeah, the INL carts work just fine. I'll update my old post shortly to make sure new people don't get discouraged.
satashi26 wrote:
After much testing and trouble shooting, Danin and I discovered the problem was with my SNES itself. We're not sure as of WHY yet, but we're positive that's it.
To further comment on this, here's my
current opinion as a preliminary diagnosis (as a repair tech without access to the device); it doesn't act up on normal games because the INL carts (and most other aftermarket carts) draw slightly more power from the system due to having more components (CPLD, level converters, etc) and consoles with aged and/or failing capacitors (either in the console or power supply itself) could introduce noise into the cart's power and subsequently all related systems (main processor, video ram, DSP, etc) due to power drain effecting other circuits) that cause instability. I'm not sure why some games cause problems and others don't - I suspect it has something to do with the intensity of processing operations. I'll update if I get the opportunity to do further investigation, but my current expectation is to see failing/failed capacitors either the PSU or console.
EDIT: I should also note that yes, I was incorrect with my suspicion of the carts themselves, but I had failed to consider the fact that these consoles are clearly quite old. I did jump the gun on diagnosis. Capacitors (yes, my current suspect) are typically an age-related failure, whereas the logic ICs and processors are low-speed (relatively) and low-heat devices and as such are suspect of a much lower failure rate, in my estimation. We'll see if/how this one pans out.
I know you said you had a tester fail to get the games in question working on a 4MB cart, but got them working on a 12MB one. Any guess as to why the larger cart would work but not the smaller one? I would assume (without knowing much about the hardware) that the larger cart would draw at least as much power as the smaller one.
In other news I think I may have fried my board by not paying attention and putting it into the kazzo backwards (the chips got hot enough to burn my finger on contact and failed to run in the SNES after I turned it around and wrote a ROM to it), so I might just have to order a new one anyways and I guess I'll get the 12MB and see if it changes anything.
Edit: also, any suggestions on testing for capacitor failure and replacing them if necessary?
jbradfield wrote:
I know you said you had a tester fail to get the games in question working on a 4MB cart, but got them working on a 12MB one. Any guess as to why the larger cart would work but not the smaller one? I would assume (without knowing much about the hardware) that the larger cart would draw at least as much power as the smaller one.
I did, but I should have clarified - it was two separate testers.
jbradfield wrote:
In other news I think I may have fried my board by not paying attention and putting it into the kazoo backwards (the chips got hot enough to burn my finger on contact and failed to run in the SNES after I turned it around and wrote a ROM to it), so I might just have to order a new one anyways and I guess I'll get the 12MB and see if it changes anything.
I'm not sure it will, but the added expense is small enough that it might help us test, if nothing else..
jbradfield wrote:
Edit: also, any suggestions on testing for capacitor failure and replacing them if necessary?
Well, the only effective way to test for bad caps is with an ESR meter, and they run about $80. If I find that they are a problem, I can offer repair service for them at low cost. Until then - and you have no reason to trust me so I don't assume there will be many takers - I'll examine one or two consoles sent to me
by people having this problem, repair them, and return them no charge. Well...you pay shipping both ways. But other than that, no charge. I'll also want the cart(s) that are having problems, programmed with a game that's having problems for testing before and after repairs. Again, nobody here necessarily has any reason to trust me, but I assure you I'm not the dishonest sort. If you're interested, PM me.
jbradfield wrote:
In other news I think I may have fried my board by not paying attention and putting it into the kazzo backwards (the chips got hot enough to burn my finger on contact and failed to run in the SNES after I turned it around and wrote a ROM to it), so I might just have to order a new one anyways and I guess I'll get the 12MB and see if it changes anything.
I did that once by being absent minded. Fortunately, it still worked afterwards. Also, my games all work on other systems, just not my own. Borrowing a power supply from a buddy Monday and testing it with my system then, will keep you all informed.
EDIT: The other power supply didn't fix the problem... My SNES itself is borked. Oh well... I AM going to get a Retron 5 when it finally comes out, so I'll be able to report if the boards work on those at least
My 4MB is well and truly fried so I ordered a 12MB cart. I'll resume testing when it shows up.
I'm really discouraged about INL boards... and I'll explain why:
They didn't work on ANY of my 5 PAL SNES, but InfiniteNesLives explained all about this issue, so I decided to use them on my japanese Super Famicom. First time I programmed the board, it didn't work, but after 3 or 4 attempts, it did. I updated the ROM I wanted to burn on it (I'm translating Romancing Saga 3 into spanish and I test it on the real thing when I compile a new patch) and the game didn't run after re-programming the board several times (7 or so). Annoyed about this, I tried with the new host app, and I finally got to work the board after changing some options.
All this occurred 2 weeks ago, but today I updated the ROM again and decided to play it on the Super Famicom: it has been more than an hour re-programming the board with the new host app, with the old host app, with any possible option checked and then uncheked and finally, after more than 10 attempts, I can conclude that these boards don't worth the effort nor the money.
Besides, the contact with InfiniteNesLives is ABSOLUTELY impossible: he takes weeks to answer, he reads my private messages but doesn't reply at all, and I guess he has no idea about what's happening with his own boards...
Really dissapointing...
So mainly you're having issues with the programming software? It can be a bit challenging to use. Once you had the cart programmed and it ran on the SFC, did you try it on any of your PAL systems? I think I read the PAL systems might have issues with the CIC, so you might need some form of playing NTSC imports for it to work.
I did read that some of the boards have PAL issues as well. I also remember something about the CIC chip on these (maybe it was some different boards?) using a Reset to switch regions but I'm not sure - have you tried programming the board, powering it up, waiting about a second, then holding reset for a second?
As a side note, programming the board repeatedly shouldn't change anything at all. Also, if I recall correctly, the SFC boards use a different slot from the SNES boards, and I'm not sure if special actions have to be taken on the host app's side to program SFC boards, so my host app may or may not work. I'm not sure if SFC boards require as careful insertion as the SNES boards, but I know the SNES boards do have to be placed carefully. The pins don't line up perfectly - the SNES edge socket and the SNES pad spacing is nonstandard, so Paul was unable to find a perfect match. My host app thread has a note on how to properly position them.
In my most recent release of the host app, with the most recent firmware, there is read support but it's somewhat hidden. Right-click Find Kazzo and click Test Read. When it's done, it'll load that Rom into the tab on the right - if it shows as invalid, it's not being written properly. If it shows as valid, click Save Buffer, save it someplace, and use a tool (WinHex, etc) to run a difference check on the Rom you wrote and the Rom you just saved. It'll have to be a headerless Rom and the buffer will have to be saved as headerless as well. If there are no differences between the dump and the Rom, it is being written correctly, and the issue lies in the hardware between the flash and the console, OR the CIC itself, in my opinion.
MottZilla wrote:
So mainly you're having issues with the programming software? It can be a bit challenging to use.
I don't know if the problem is the board or the programming software. I guess it's the board, but can't be 100% sure. In fact, I was playing Romancing Saga 3 on that very board almost everyday the past two weeks. But this evening, after programming the new ROM on the board, it never worked again.
MottZilla wrote:
Once you had the cart programmed and it ran on the SFC, did you try it on any of your PAL systems? I think I read the PAL systems might have issues with the CIC, so you might need some form of playing NTSC imports for it to work.
Yes I tried, but it didn't work on none of my 5 PAL SNES, nor in the Super Famicom nor in my modded SNES...
Danin wrote:
I did read that some of the boards have PAL issues as well. I also remember something about the CIC chip on these (maybe it was some different boards?) using a Reset to switch regions but I'm not sure - have you tried programming the board, powering it up, waiting about a second, then holding reset for a second?
Yes I did, but didn't work either...
Danin wrote:
As a side note, programming the board repeatedly shouldn't change anything at all. Also, if I recall correctly, the SFC boards use a different slot from the SNES boards, and I'm not sure if special actions have to be taken on the host app's side to program SFC boards, so my host app may or may not work. I'm not sure if SFC boards require as careful insertion as the SNES boards, but I know the SNES boards do have to be placed carefully. The pins don't line up perfectly - the SNES edge socket and the SNES pad spacing is nonstandard, so Paul was unable to find a perfect match. My host app thread has a note on how to properly position them.
I didn't know the SFC boards used a different slot from the SNES boards... What does that mean? The boards are different or the kazzo programmer is different? INL didn't tell me nothing about that...
As for programming repeatedly, I found it the only way to make the board work. The board only worked in two occasions and both were after programming repeately the board. Maybe it has to do with the board insertion on the programmer...
Danin wrote:
In my most recent release of the host app, with the most recent firmware, there is read support but it's somewhat hidden. Right-click Find Kazzo and click Test Read. When it's done, it'll load that Rom into the tab on the right - if it shows as invalid, it's not being written properly. If it shows as valid, click Save Buffer, save it someplace, and use a tool (WinHex, etc) to run a difference check on the Rom you wrote and the Rom you just saved. It'll have to be a headerless Rom and the buffer will have to be saved as headerless as well. If there are no differences between the dump and the Rom, it is being written correctly, and the issue lies in the hardware between the flash and the console, OR the CIC itself, in my opinion.
Thanks for the advice. I'm using release 11, so I'll try. The CIC is not the problem 100% certainly, since I tested the boards on PAL SNES, Super FAmicom, region-modded SNES, non-CIC SNES, PAL SNES with imported-games adapter (Honey Bee and Super Game Key) and Super Famicom with the same adapters...
magno wrote:
I didn't know the SFC boards used a different slot from the SNES boards... What does that mean? The boards are different or the kazzo programmer is different? INL didn't tell me nothing about that...
What it means is that I was remembering incorrectly. SFC uses the same Kazzo connector as the SNES, it's the Famicon that's different. My bad, ignore that bit. I was at work and unable to verify.
magno wrote:
As for programming repeatedly, I found it the only way to make the board work. The board only worked in two occasions and both were after programming repeately the board. Maybe it has to do with the board insertion on the programmer...
That's entirely likely, because alignment can be difficult on those. I've actually cut little spacers for mine from spare plastic bits. May wind up 3D printing 'shims' if I get industrious and bored enough to model them..
magno wrote:
Thanks for the advice. I'm using release 11, so I'll try. The CIC is not the problem 100% certainly, since I tested the boards on PAL SNES, Super FAmicom, region-modded SNES, non-CIC SNES, PAL SNES with imported-games adapter (Honey Bee and Super Game Key) and Super Famicom with the same adapters...
Let me know how that goes. Given your test grouping, I think you might be correct that it's not the CIC, which leaves odd issues and board spacing in the programmer as suspect. Or simply an issue with the board itself not properly programming. If that's the case, let me know and I'll see if there's anything I can do from my end to fix it. Maybe a program/verify pass or something..
Danin wrote:
Let me know how that goes. Given your test grouping, I think you might be correct that it's not the CIC, which leaves odd issues and board spacing in the programmer as suspect. Or simply an issue with the board itself not properly programming. If that's the case, let me know and I'll see if there's anything I can do from my end to fix it. Maybe a program/verify pass or something..
The option is grayed, so I can't read the flash... I'm using release 11... what could the problem be?
magno wrote:
The option is grayed, so I can't read the flash... I'm using release 11... what could the problem be?
Hm. Well, I intended to leave that enabled, but I forgot to leave the testing menus enabled with the release. I'll send you a version tonight after I get home from work with the test menus enabled. Sorry about the mix-up, I'm kinda scatter-brained sometimes..
Sorry this took so long, I broke the read code (while trying to optimize it and fix HiROM dumping) and had to rewrite it. Also, my desk situation is aggravating an old injury, so I took a break for a while. My apologies. Here's a new release with a few random small features and some unfinished code. It should be completely functional for what it is.
https://www.dropbox.com/s/vtb6tgenwxeqg ... e_11.5.zip
Developments!
Got my 12 MB cart in the mail and loaded the hacked FF6 onto it. It did NOT crash (!) at the same point as the previous cart, but instead made it all the way through the opening title crawl and town before finally crashing after arriving at the first save point and loading into the save menu. If we're operating on the current assumption that this is a capacitor issue, then it appears the 12 MB cart draws slightly less power (for whatever reason), but attempting to access the save RAM finally pushes it over the edge and crashes the system.
I'll have a friend bring over their SNES this week and test it on that. If it works on their system, I'll to look into the process of replacing SNES capacitors; assuming they're sufficiently cheap, and the process is sufficiently simple, it seems worth it to just replace them without expending the much larger effort of testing them for failure, and seeing if that changes the stability of the game.
So, I started a complete rewrite of the firmware with some optimizations and tweaks. THERE IS NO NES SUPPORT IN THIS FIRMWARE, YET. I'll post the link for this firmware in my host app thread. Anyone interested in giving it a test run, please report any bugs IN MY THREAD FOR THE HOST APP or directly to me via PM.
Tested the FF6 romhack on another SNES and the game ran fully stable through removing the slave crown. The cart even had a the save file from the point where the game crashed on my SNES (uncorrupted, so the game successfully saved before crashing). It's pretty clearly a console-level issue, and the capacitor explanation seems likely.
I forget: does the PCB itself have reasonable caps on it? I seem to remember
one board that didn't.
tepples wrote:
I forget: does the PCB itself have reasonable caps on it? I seem to remember
one board that didn't.
I don't have the values on hand, but it has bypass caps and a decently-sized one at board-entry VCC/GND, so I'd say yes but can't confirm that completely.
Hey guys,
I was wondering is anyone has any ideas on how we could get BS Zelda Ancient Stone Tablets onto one of these flash carts possibly using the reset but to cycle through the 4 different weeks of the game.
Has anyone has any luck doing this?
That would be awesome. I have looking at making one using eproms but using one of these carts would be ideal.
mamejay wrote:
Hey guys,
I was wondering is anyone has any ideas on how we could get BS Zelda Ancient Stone Tablets onto one of these flash carts possibly using the reset but to cycle through the 4 different weeks of the game.
Has anyone has any luck doing this?
That would be awesome. I have looking at making one using eproms but using one of these carts would be ideal.
To my knowledge: As designed, there is potential for multi-ROM carts, but it is not implemented at present time. It would require custom CPLD firmware (not open source at this time) or hardware-level modification to do this.
That's an interesting idea but it sounds like you'd need to do some pretty heavy modifications to the rom file to get it to work. Not an expert on BS Zelda but there are a ton of different hacks out there for it, most of them revolving around the timer. Is there already something available that lets you choose the week?
Has anyone tested Rockman & Forte / Megaman & Bass on the INL 4MB boards ? I've tried various methods and while the programmer does write the rom correctly, it will not boot.
I've been testing with Danin's new 11.5 release which works great with every other game I've tested BTW, thank you Danin! Using the IPS patching function I was able to safe the buffer of what it had written to the 4MB board and test it on BSnes/Higan and it played back correctly. Anyone have any thoughts about why Rockman & Forte / Megaman & Bass won't boot off the 4MB INL board ?
Thanks!
I can give it a go tomorrow. Can you post the exact rom file name so I make sure I'm using the same version you are?
Sure, let me know if you need any other info, Thank you!
Rockman & Forte (J) [!].smc
MD5 (Rockman & Forte (J) [!].smc) = 55d9cdb05f53a3f7a5e3eacb81b28f09
CRC32 (Rockman & Forte (J) [!].smc) = 5047e0d4
Thanks for testing. Hopefully someone else can make a suggestion.
Anyone maintaining a list of titles that do not work with the INL boards or list of instructions and reasons to make rare case games work ? Something like this would be helpful for many like me who don't want to use an emu and don't want to break out the soldering iron every time we get the itch for some new fun on our favorite hardware
Rockman and Forte works on my 12M board with the aeon genesis patch applied.
Thanks! That's very interesting though, why would a 32Mbit game need a 96Mbit cart though?
aupton wrote:
Thanks! That's very interesting though, why would a 32Mbit game need a 96Mbit cart though?
Wiggle room?
Honestly, I don't know. I can try the non-patched version. I think the FFVI issue on the 4MB carts was solved (bad caps?). Have you tried yours in a different console?
UPDATE: Same result on Super Famicom version, only issue is I have no idea what anything says.
Tested as Me...Rock Man that time. Wow, he sucks compared to Forte.
Also, here's a pic taken with a potato showing my cart mod. It's very precise.
I'll test it on my 12MB cart tonight. At least I'll be able to check it out. Would still love to know if this is a limitation of the boards, INL software, or firmware, or both ? Hopefully its correctable in the future.
aupton wrote:
I'll test it on my 12MB cart tonight. At least I'll be able to check it out. Would still love to know if this is a limitation of the boards, INL software, or firmware, or both ? Hopefully its correctable in the future.
Well when you get back here let us know which firmware and your results. I went ahead and ordered an 8MB and 4MB so I'll have all the variations to play with. Right now I'm totally geeking out on this, and I can't wait for the sram reading and writing. I've tested probably 10 SNES games and too many SFC to recall. So far I've only had issues with FFV.
Rockman & Forte should work fine. Games that won't work include the usual suspects like games using SA-1 (Super Mario RPG, Kirby SS, Kirby DL3), Cx4 (MMX2,MMX3), and Super FX (Star Fox, Yoshi's Island). Other games that might not work are games that use more than the available amount of SRAM.
INL I think said that he currently limits the 128KB SRAM to 8KB. This would mean the few games that need 32KB will not work. Very few games fall in that category. Games that use SRAM based copy protection will need patches unless they are checking for 8KB of SRAM.
Generally speaking, INL's carts will run any game as long as they don't require additional hardware of a chip such as SA-1. People can experience problems ofcourse and may experience it with certain games and blame the game. But it's not like that game won't work, it's some other problem that the user is experiencing.
I can confirm that both original and patched Rockman & Forte/Megaman & Bass work when writing it to a INL 12MB cart with a 4MB data type and auto-fix protection enabled.
I can now enjoy the game, thanks for the tip skot85!
I'd still really like to know why this particular game wont run on a properly sized 4MB board ? What's special about this 32Mbit/4MB game ?
aupton wrote:
I can confirm that both original and patched Rockman & Forte/Megaman & Bass work when writing it to a INL 12MB cart with a 4MB data type and auto-fix protection enabled.
I can now enjoy the game, thanks for the tip skot85!
I'd still really like to know why this particular game wont run on a properly sized 4MB board ? What's special about this 32Mbit/4MB game ?
There have been issues (some widespread) with certain games on the 4MByte boards. We have yet to determine exactly what's causing it, but it's suspected that the consoles are at fault. Here's the current thinking; Different power loads from different computational processes tend to trigger it. This is unconfirmed, I've yet to personally have access to one of these trouble devices, wether it be cart or console, so I can't finish troubleshooting. It's a strange issue that's been hard to nail down - we have various reports of some Final Fantasy series games and Crimson Echoes and a few others being problematic, however, all of the ones I've been able to test have worked fine with the 4MByte board. Fruther testing is required, my first recommendation would be to try another SNES, or another power supply for the SNES. Yes, I know, other things work, that's why this is such a problematic diagnosis.
Thanks Danin, I've tested this out on 2 different SNES systems and 2 different Superboy systems and it did not work on any of the 4 systems.
I have been trying to get Crimson Echoes to work as well, but I hear the rom needs to be reordered, which I've done but I suspect I'm using the wrong source file... Perhaps It would be helpful to keep track of working crc/md5 checksums and report if an invalid or untrusted checksum is found in a future software release ?
aupton wrote:
Thanks Danin, I've tested this out on 2 different SNES systems and 2 different Superboy systems and it did not work on any of the 4 systems.
I have been trying to get Crimson Echoes to work as well, but I hear the rom needs to be reordered, which I've done but I suspect I'm using the wrong source file... Perhaps It would be helpful to keep track of working crc/md5 checksums and report if an invalid or untrusted checksum is found in a future software release ?
I've heard the same about Crimson Echoes, but I haven't looked into what has to be done. I've been working on some manner of tracking for source files, and some of the infrastructure within the app is already in place. The problem is that the best infrastructure for that would be a centralized database and a report system, and that's a bit beyond my scope right now. I don't have the means to run tests on such a bulk of sources, and GoodTools/No-Intro would be a valid source, but to my knowledge they lack data on data ordering and so forth, so all I'd have there is a database of valid ROMs and their checksum data. That would help avoid the whole situation of having an outright bad ROM, but wouldn't help terribly when it comes to "this ROM needs to be re-ordered before write" and I'd have to fall back to the same case-by-case exceptions, of which I already support several. The real problem comes in that once I find a ROM that needs a special-case exception, I have to find out what that exception is - most ROM info tends to be for emulators, and tends to be along the lines of "XX emulator supports this, use that instead." Not very helpful for us real-hardware people, hah..
I really like the idea of keeping a list of successes/ailures as far as getting games to work on INL boards. I've been doing that myself but would be interested in pooling with others.
My failures:
Classic Kong -
http://blog.supergnes.com/?p=295FFV w/RPGe patch -
http://www.romhacking.net/translations/353Zelda Parallel Worlds -
http://www.romhacking.net/hacks/197There was a few more that I can't recall (been flashing games like CRAZY everyday after work) but I'm mostly having issues with translation patches. I did get Front Mission to work with a patch, but it was a pre-patched rom, so I might be doing something wrong here. Classic Kong tho, thats complete homebrew with no ipas, so I dunno why it wont work. Anyway, the client (11_5) crashes when this happens.
@ skot85 - I have Classic Kong working properly on a 4MB v1.1 INL board using Danin's 11.5 release.
MD5 (Classic Kong.smc) = 848c7da7ef1b38025e4c25032c57e399
crc32 (Classic Kong.smc) = f08a96ba
Data Type=1MB
Cart Size = 4MB
Auto Fix Protection = On
Auto Erase = On
I'm going to try FFV w/RPGe patch later tonight. Will report back my results.
Hmmm... Every attempt at writing FFV+RPGe patch to a 4MB INL v1.1 board fails and results in a crashed retro-prog.exe (Crash details below).
The patch pads the original 2.0MB file to a 2.56MB file and the data type used was 3MB SNES* on the 4MB board.
Code:
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: retro-prog.exe
Problem Signature 02: 1.0.5183.1010
Problem Signature 03: 531ebc54
Problem Signature 04: mscorlib
Problem Signature 05: 4.0.30319.18063
Problem Signature 06: 526766b5
Problem Signature 07: 190
Problem Signature 08: 0
Problem Signature 09: System.ArgumentException
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
I also tried to pad the 2.56MB RPGe rom up to 4.0MB with Lunar Expand. Then program as a 4MB data type on the 4MB board. The programmer software DID NOT crash, but the game did not boot...
HOWEVER... If I take the 4.0MB expanded rom and load it on a 12MB board, it works just fine...
I really think its the 4.0MB boards that are defective in design or the way the firmware writes HiRom games to the boards... I'm starting to think the pack of 10x4.0MB boards that I bought is a waste of money for anything other than LoRom games, which frankly aren't the games I want to play...
Then perhaps I need to learn Super NES programming and make a tool to autodetect the way a game is actually getting written to a cart, similar to my Holy Diver Batman tool for NES.
The 4MB boards are fine. Maybe something is wrong with the program. I've had no issues with my 4MB board and HiROM games. If I have time I can try to test a few titles you think are problems. I recommend trying INL's original software for programming as well incase the problem is in the new software.
@MottZilla - Maybe you're on to something. Here's what I tried on the 4MB INL board.
1) FFV+RPGe patch padded to 4MB using original INL retro firmware and INL retro prog. 4MB SNES data type = FAIL
The programmer software did not report any errors but the game did not boot.
2) FFV+RPGe patch using 2.56MB rom and original INL retro firmware and INL retro prog. 3MB SNES data type = SUCCESS
The programmer software DID report "Error in page: 0" but the game DOES boot!
Seems like we have lots of variations to test going forward.
Wondering if anybody else has ran into the same issue. Decided on a whim to load up Zelda:AST on my 12mb cart. The game works fine, the problem is the character sprite is bugged out, along with actually picking a gender. The roms work fine on emulators and I have tried multiple different versions. All lead to the character sprite being bugged out. The game otherwise works perfectly fine. Any help here?
@DarkAries - Have you tried it in BSnes or it's successor, Higan ?
http://byuu.org/higan/ '
Both offer greater emulation accuracy that may expose the same problem with the source rom and not the INL board.
Once I can track down the translated 4, 4MB parts of Zelda:AST I'll give it a try myself.
I got them from the "official" source here
http://bszelda.zeldalegends.net/sekibanfiles.shtmlI tried in snes9x and snesGT. I'll try again in higan since I forgot about that one.
Edit: Opened it up in Higan Accuracy. Works fine. I know it also works fine on a sd2snes so I have no clue what my issue could be.
DarkAries wrote:
I got them from the "official" source here
http://bszelda.zeldalegends.net/sekibanfiles.shtmlI tried in snes9x and snesGT. I'll try again in higan since I forgot about that one.
Edit: Opened it up in Higan Accuracy. Works fine. I know it also works fine on a sd2snes so I have no clue what my issue could be.
Used the prepatched rom for week 1 on my 12M cart and works fine using danin's latest release to flash.
Interesting results.
I too have found that the 'official' INL programmer seems to work better for me in most cases but Danin's has done a couple that I couldn't get to work any other way. I have FFV patched to ENG working on a 4MB board, seems to be solid.
I've written a couple guides so far (I'm new here, where do you guys upload/post stuff?) that I was planning to share. I'm working on a few more about padding ROMS and splitting for 6/8MB games.
I will also post my success/fail list here this weekend likely. Maybe we should start another thread for that stuff?
skot85 wrote:
My failures:
Zelda Parallel Worlds -
http://www.romhacking.net/hacks/197Thank you for the short list. I have two things to note;
First, I personally spent some time in Zelda Parallel Worlds, with a 12MByte cart, so I know it works at least in some configurations.
Second, if you could include the cart size you're using with those tests it would be more useful - some games seem to dislike the 4MByte carts for some unknown reason, so knowing and comparing your cart size to that of others with matching/different results would be useful.
Danin wrote:
skot85 wrote:
My failures:
Zelda Parallel Worlds -
http://www.romhacking.net/hacks/197Thank you for the short list. I have two things to note;
First, I personally spent some time in Zelda Parallel Worlds, with a 12MByte cart, so I know it works at least in some configurations.
Second, if you could include the cart size you're using with those tests it would be more useful - some games seem to dislike the 4MByte carts for some unknown reason, so knowing and comparing your cart size to that of others with matching/different results would be useful.
ATM Just 12M, but got the email today that my 4M and 8M are on the way, so I'll do some more testing when they arrive. I'll add that most of the problems I've been having are with patched roms. I will give ZPW another try tomorrow. Honestly it may be something I'm doing wrong here, but 90% of the time patched roms crash your client and don't give me much of an error report like the one I posted previously.
skot85 wrote:
ATM Just 12M, but got the email today that my 4M and 8M are on the way, so I'll do some more testing when they arrive. I'll add that most of the problems I've been having are with patched roms. I will give ZPW another try tomorrow. Honestly it may be something I'm doing wrong here, but 90% of the time patched roms crash your client and don't give me much of an error report like the one I posted previously.
I haven't had any reports or personal experience with patched ROMs causing host app crashes. If you could PM me with specifics (patch source URL, target ROM including CRC32 or MD5 or any of the calculated checksums) I can run some tests to see what's up..
skot85 wrote:
Used the prepatched rom for week 1 on my 12M cart and works fine using danin's latest release to flash.
I have no clue what I'm doing wrong then. I've used both of Danin's download links, did every combination of AP fix and auto mirroring and nothing. I'm thinking I'm just going to mirror the thing myself to fill the full 12 and see what happens at this point. There has to be something stupid I'm missing at this point.
aupton wrote:
@MottZilla - Maybe you're on to something. Here's what I tried on the 4MB INL board.
1) FFV+RPGe patch padded to 4MB using original INL retro firmware and INL retro prog. 4MB SNES data type = FAIL
The programmer software did not report any errors but the game did not boot.
2) FFV+RPGe patch using 2.56MB rom and original INL retro firmware and INL retro prog. 3MB SNES data type = SUCCESS
The programmer software DID report "Error in page: 0" but the game DOES boot!
Seems like we have lots of variations to test going forward.
That error might go away if you padded the ROM up to 3MB. I'm not sure if the software reads the internal rom info but in FFV RPGe they did not correct the ROM size, it still says 16mbit and not 32mbit (the next size up). This does cause issues for some copiers and flash carts. I don't know that it is needed for INL's carts. I should really try to make time to test more games. Unfortunately for me it takes awhile to program the full 4MB of flash.
Well, got my 64Mbit board, then promptly destroyed it. I brilliantly put it in the kazzo backwards, now it only works with loRom games. I have tried both inl's and danin's fw and programmer respectively, with many many roms and always achieve the same result. I am open to suggestions(about the device, not my brain damage).
Are you sure the issue isn't with the HiROM/LoROM switch? I'm not sure if inserting it backwards would damage it or not.
MottZilla wrote:
Are you sure the issue isn't with the HiROM/LoROM switch? I'm not sure if inserting it backwards would damage it or not.
Broke out the meter...holy shit. Warming up iron, will update.
...
Well, that didn't seem to change anything. And after doing the same continuity test on my 12meg board, I was wrong. This switch apparently doesn't work how I thought it should. Oh well. Thanks for the idea!
Hello!
I pretty much joined today because I ordered some of INL's v1.0 boards last year and recently got another ten v1.1 a week ago. Thanks INL for making these (and that free SNES mold last year too)! This is one of the few threads I follow here at the moment and just wanted to share my thoughts.
I have had no issues thus far programming any of the 4MB boards with HiROM/LoRom Slow/Fast or combination thereof. Secret of Mana and Mega Man 7 work great, for example. I've been using INL Retro-Prog with the regular firmware to erase and write (nothing of Danin's), used SNEStuff v1.2.1 to expand these to fit the 4MB board, wrote the ROM, set the slide switch to HiROM and these games seem to work just fine.
The only thing I've had issues with so far, which I think I will have resolved today, is getting Demon's Crest to work. I had it written previously to a v1.0 board and thought it was working well, but I didn't check very far into the game and I found that the protection either stopped me at the dragon or Arma (guy who gives you earth power). I've taken the advice of Mottzilla and used UCon64 to crack the ROM, then I expanded it with SNEStuff and tried it in bsnes. It seemed to work great in the emulator whereas the other times I tried it would get stuck or have issues like with real hardware. Crossing my fingers this is the last time I need to reflash that board.
I think it's worth reiterating that UCon64 can also deinterleave ROMs for those interested in the Star Ocean decompressed hack. I know Danin works hard to put a lot of features in his program, but I like to stick with what works for me. After I fill the rest of those 4MB boards, I will probably buy a 12MB one to try that out.
Aside from that I wanted to ask a couple things that I've seen mentioned in this thread or in Danin's software topic.
Danin mentioned Dracula X needed mirroring? Is this true for only his software? I have this on a 4MB flash and it seems to work flawlessly for the first few levels. Mottzilla had his own list of ROMs that needed some protection bypassed. I was looking at Earthbound and a translated Front Mission: Gun Hazard -- what kind of issues do those have? Terranigma is on my list for tonight as well -- I initially had problems getting that board to work because of region restrictions, I'll try UCon64 on it with the -f switch/option. I remember INL had something about hitting reset to bypass stuff?? Don't remember, but I tried and it still wouldn't work (region problem).
Probably not the best place for this but it pertains to his dumper/programmer so...in case INL reads this...
I'm interested in a couple NES boards as well; particularly the FME-7. It looks like I need to modify my NES to get that full sound? Will the game still have sound (but limited) if I don't add the synth chip option? I assume Gimmick was the target for adding the chip option in the first place and Batman RotJ is the only other one with the FME-7? Also, I see VRC is under the future features/support. Any one else generate enough interest in Akumajo Densetsu just for the sound and extra pretty?
Edit: Oh, Mottzilla, whatever your stance is on anything here I'm going to side with you because of the Raziel -- I've been a long fan of LoK. Also, your name reminds me of mozzarella cheese and Mozilla and these are both good things in my mind.
Also, if anyone wants me to test a specific ROM or translation, I can do so to help troubleshoot. I won't be using Danin's stuff though, so keep that in mind.
Demon's Crest does have copy protection. I'm certain it has ROM mirroring protection and I think it also has SRAM based protection too. Both of these will trip on INL's board so you need to use the crack.
Castlevania Dracula X, I'm not aware of any protection but it might have SRAM based copy protection. As for needing mirroring it depends on how memory is mapped and accessed. The 4MB board might not need any mirroring. However the proper thing to do to ensure no problem is to copy data till it fills up the flash chip.
Earthbound has copy protection and may require a crack. However that protection is SRAM based I believe, and the game expects 8KB of SRAM which is what INL's boards are setup to do right now.
Front Mission Gun Hazard I'm not aware of any issues, it's always possible SRAM based copy protection might be used. But I'm not aware of it.
Terranigma has a regional lockout. I don't think it has any copy protection. There is no hardware bypass for regional lockout unless you modify your console. Using UCON64 you can generally remove any regional lockouts.
About FME-7, there are more games than just those two. There are maybe about 8 games that use it. Some are just the Japanese version of a game that used MMC3 in the US. Also, a US prototype of Gimmick exists that doesn't require the expansion audio. It still sounds great. Without the added synth, the Japanese version of Gimmick will have some missing sounds. I'd advise using the US version if you don't get the synth for the Japanese version.
I think he has plans to support the VRC series, probably atleast VRC2 / VRC4. It'd be nice to see VRC6 supported, I think a couple games use it. I'm not sure how much interest there is for it.
I'm also a fan of the LoK series. Glad you noticed the avatar, I've been using it here for a long time.
Just an update from what I tried:
Demon's Crest seems to work without issue after using UCon64. Likewise Earthbound and Terranigma (after fixes), and then some other 4MB LoROM also work just fine. I did have a funny issue with two games that may be unrelated to the boards/programming because I have yet to duplicate them.
Two ROMs, The NinjaWarriors and Front Mission: Gun Hazard (a translated version) both cut out on me while playing. When I say this, I don't mean a black screen like a crash or when you don't have a cart inserted. It goes straight to a blue screen/random noise/snowy screen (depending on your TV!).
This happened multiple times while playing NinjaWarriors the first day I wrote the ROM happening at random times during play. Sometimes only a minute or two in, other times not until later -- and didn't seem related to gameplay. Gun Hazard did something similar but I let the game sit in the intro/attract mode and it did the same thing after a short time.
To describe the issue a bit more -- the SNES power stayed on, but the signal completely cut out. Cycling the power on the console restarted the game like normal, so I know it's not the AV connection.
Oddly, this has not happened since. I played NinaWarriors for about a half hour without issues, same for Gun Hazard. It's very possible it could be my SNES I guess, but I haven't once had an issue with it. The timing seems all too coincidental when I try to play a few games I thought I might end up having issues with. They just presented rather strangely. As for now there seems to be no lasting issues, I suppose. Out of sight out of mind.
Josh86 wrote:
Two ROMs, The NinjaWarriors and Front Mission: Gun Hazard (a translated version) both cut out on me while playing. When I say this, I don't mean a black screen like a crash or when you don't have a cart inserted. It goes straight to a blue screen/random noise/snowy screen (depending on your TV!).
This happened multiple times while playing NinjaWarriors the first day I wrote the ROM happening at random times during play. Sometimes only a minute or two in, other times not until later -- and didn't seem related to gameplay. Gun Hazard did something similar but I let the game sit in the intro/attract mode and it did the same thing after a short time.
To describe the issue a bit more -- the SNES power stayed on, but the signal completely cut out. Cycling the power on the console restarted the game like normal, so I know it's not the AV connection.
Oddly, this has not happened since. I played NinaWarriors for about a half hour without issues, same for Gun Hazard. It's very possible it could be my SNES I guess, but I haven't once had an issue with it. The timing seems all too coincidental when I try to play a few games I thought I might end up having issues with. They just presented rather strangely. As for now there seems to be no lasting issues, I suppose. Out of sight out of mind.
This happened to me too. What power supply are you using? I was experiencing the problem with a 3rd party (radioshack) power supply. The problem went away when I got an official Nintendo power supply.
MottZilla wrote:
Josh86 wrote:
Two ROMs, The NinjaWarriors and Front Mission: Gun Hazard (a translated version) both cut out on me while playing. When I say this, I don't mean a black screen like a crash or when you don't have a cart inserted. It goes straight to a blue screen/random noise/snowy screen (depending on your TV!).
This happened multiple times while playing NinjaWarriors the first day I wrote the ROM happening at random times during play. Sometimes only a minute or two in, other times not until later -- and didn't seem related to gameplay. Gun Hazard did something similar but I let the game sit in the intro/attract mode and it did the same thing after a short time.
To describe the issue a bit more -- the SNES power stayed on, but the signal completely cut out. Cycling the power on the console restarted the game like normal, so I know it's not the AV connection.
Oddly, this has not happened since. I played NinaWarriors for about a half hour without issues, same for Gun Hazard. It's very possible it could be my SNES I guess, but I haven't once had an issue with it. The timing seems all too coincidental when I try to play a few games I thought I might end up having issues with. They just presented rather strangely. As for now there seems to be no lasting issues, I suppose. Out of sight out of mind.
This happened to me too. What power supply are you using? I was experiencing the problem with a 3rd party (radioshack) power supply. The problem went away when I got an official Nintendo power supply.
Wish that fixed my problem. I have five of the 4MB boards and three of the 12MB ones. All of them don't work for me for specific games, they just cut out at sometimes static places, sometimes random. Tried literally 12 different systems (thanks to my Local Game X Change!) and different set ups like the retrobit power cord, some weird one that has the same plug in, and official cords as well. All fail in the same spot.
I'm debating trying on a 3rd party system, but don't want to shell out sixty bucks just to try and make these things work >.<
@satashi26 - Do the roms cut out when playing on BSNES/Higan? Maybe its a copy protection routine ?
If the signal to the TV cuts out, it's not software related at all. It's related to the lockout chip. The lockout chip losing communication will hold the PPU in Reset State until the console is reset. When the PPU is in its reset state there is no picture output. So if he sees his TV telling him "no signal", then it's lockout chip related.
One thing you could do if you wanted would be to install a switched lockout bypass mod. It would in theory prevent this issue from happening. Oh and when I had this issue, I too thought it was software related as it seemed to like to crash in the same spots. But it's some sort of odd coincidence. The fact is it's the lockout chip.
I don't get the "no signal" sign, but instead I just get a gray screen with weird lines on it. No picture or sounds, kinda of like if you just pull up on a game and the screen messes up. When I power off, I go to the no signal part. Just tried Higan, and it worked.
So if it is the lockout chip, why would these boards work flawlessly on some games, and not on others?
I thought you had said you got no signal suddenly. If you are getting glitched graphics, that's some other problem than the lockout chip. It sounds like the game or system is crashing. Maybe you have some defective or damaged carts. It's all just speculation at this point.
I can see how that could be confusing, since TVs do say "no signal" sometimes XD. I should have said "and I lost picture" or something like that.
I really really want to test these on a 3rd party machine, or even A snes mini... The Retron 5 keeps getting pushed back, so I don't even know what to think about that anymore.
Quote:
What power supply are you using?
Everything with my SNES is stock/original. Same one I've had since that one Christmas where I got it with Link to the Past
. It could still be power related I suppose, but I doubt it. I get right around 120V in my upstairs office that off a subpanel circuit -- but power could always fluctuate. The SNES could probably operate just fine within a 110-130V (then dropped down by AD to DC adapter) range as most non-sensitive electronics do.
Quote:
If the signal to the TV cuts out, it's not software related at all. It's related to the lockout chip.
...
One thing you could do if you wanted would be to install a switched lockout bypass mod.
Pretty much what I'm seeing. Thanks for pointing this out. I haven't had the issues since however *shrug* I've read the lockout chip can sometimes prevent games from working consistently. If I ever do want to mod it, I will probably also cut out the tabs that prevent SFC games from being inserted as well (I don't think I'll ever buy any NTSC SFC games though).
I'd also assume that if I got a black, gray, or garbled screen -- it's a game crash due to bad programming, some kind of copy protection, or the like. This was not my case, however.
This is something else that happened to me that is related to lockout chip problems. One day I was playing Kid Icarus. I was playing trying to complete it start to finish in one long session. I guess I was on the 3rd world when all of a sudden it reset, and then started the blinking reset pattern you get sometimes with a dirty or bad connection. It's worth noting I was playing with my PowerPAK and not an original cartridge. It was really irritating. It had me considering doing a lockout chip mod at the time. I haven't yet though.
Hello all, first post here. Please forgive my ignorance, but I just stumbled upon this board and I am quite intrigued. I have some questions regarding the use of the flash cart.
Edit: After extensive browsing of this site during some fine time at work, I've managed to gain the knowledge I previously lacked. Ordered up my cart and writer today. Can't wait to test it out!
Checking in to see if anyone figured out the error in which games randomly shut off with these boards yet? Messaged INL about 8 times through email and just sent a PM here with no reply. I'm sitting on five 4MB boards and three 12MB boards that won't work....
The problem you describe I had when using a 3rd party power supply.
Yeah but that's not the case unfortunately. It's not the system or the power supply.
Josh86 wrote:
Quote:
What power supply are you using?
Everything with my SNES is stock/original. Same one I've had since that one Christmas where I got it with Link to the Past
. It could still be power related I suppose, but I doubt it. I get right around 120V in my upstairs office that off a subpanel circuit -- but power could always fluctuate. The SNES could probably operate just fine within a 110-130V (then dropped down by AD to DC adapter) range as most non-sensitive electronics do.
Quote:
If the signal to the TV cuts out, it's not software related at all. It's related to the lockout chip.
...
One thing you could do if you wanted would be to install a switched lockout bypass mod.
Pretty much what I'm seeing. Thanks for pointing this out. I haven't had the issues since however *shrug* I've read the lockout chip can sometimes prevent games from working consistently. If I ever do want to mod it, I will probably also cut out the tabs that prevent SFC games from being inserted as well (I don't think I'll ever buy any NTSC SFC games though).
I'd also assume that if I got a black, gray, or garbled screen -- it's a game crash due to bad programming, some kind of copy protection, or the like. This was not my case, however.
Got to try my hands on some third party consoles, mainly the retro portable. Boards seemed to work fine, as they didn't crash in the usual places. I only got to test and not really play so I'm not 100% sure. So this could be the lock out chip....If that's the case, I'd have to warn anyone who would consider buying these boards that they seem to randomly work and randomly not work on official hardware. In other words:
These flash carts don't normally work on official SNES hardware ( most likely due to lock out chip ) If you are considering buying these, then be aware it probably won't work on your official system
That's not the case with many other people. As I said I had problems where the screen went black because the lockout chip decided to stop. This problem went away for me with a different (official) power supply. One thing you could do on your console having problems would be to perform the CIC mod to disable it. Then you could see if it still has problems. Another path, if you could obtain a power supply that you could hookup to your SNES and provides more power it could help.
All you said was "it's not the system or power supply". You did not say what you tried or how you decided that. It could indeed be your system or the power supply for it. Again, many people are using these carts and they work great. And they are using original hardware.
Also many people are using them and they don't work great. The main problem I'm having is lack of support or contact from the creator of the carts. They just don't work right. It could be a new batch. When the carts first came in, he responded with "Take a picture of the compasitors as clear as you can for me" like he's had this problem before. I think he just had a bad batch made.
Here's what I've done:
I've used three different official power supplies
I've used a Yobo power supply
I've used a Retro AC power supply
I've used a 3-in-1 power supply (don't know the name brand on this)
I've used all the above randomly on 16 different SNES consoles.
None of this worked on 4MB or 12MB boards.
Put a few in a retro hand held device and they worked. Tried in a Retro Duo and it worked.
If we can come up with anything else, I would LOVE it. I really want these to work.
Can you try the cartridges with a system that has the lockout disabled or by using a device that allows you to use a second cartridge's CIC instead of the one from the game you wish to play? Some import adapters allow you to plug in one cart for the console matching CIC and the other for the game you want to play. Working on clones, maybe the CIC on those isn't present or isn't allowed to reset the machine when it fails.
One thing you could check is what kind of CIC is used on your boards. Some of them have the Jims Cool AVR CIC, and others have the PIC12F629 running the SuperCIC. I know INL had noticed issues with the Jims Cool CIC on PAL systems, not sure if maybe there was something else involved there. I know I've had quite a few of his boards, and I've never had a single problem with any of them on any of my systems which include a SNES 1, Snes Jr, Super Famicom and a PAL Snes. I've used all of his different board sizes as well, again without issues.
EDIT: Also, just wanted to note that the only systems of mine running on 1st party power supplies are the SNES 1 and SFC. The others are running on 3rd party PS.
is it possible to play Tales Of Phantasia with this Hirom/lorom 8MByte (64 Mbit) ?
Yes, ToP should work. Like Star Ocean though, it might require some data reordering.But the hardware should be able to support the game.
arf i buy it juste for that game and gimmick
I don't understand what you mean. ToP will work. It just might take a few tries to figure out how to load it onto the cartridge.
I've been testing the game is 6Mbyte with 8MByte card, so I extended the Rom with lunar expend but black screen: (
Rom running under bsnes?
You don't want to use Lunar Expand with ToP.
For ToP you might need to copy the last 2MB of ROM data onto the end of the ROM to make it 8MB. But this is just a guess. I did not find any exact instructions on how you need to map data for ToP. But once the data is in the right place the game will surely run.
thanks MottZilla for reply i test it and tell you the result
i have tested black screen under inl snes 8Mbyte card ?
the rom is good under Bsnes:
the rom:
Copie de tales2.7z - 4.0 MB
all is good now
How can I get one of this cart with a programmer ? I use windows PC and wish to program some roms from the web to test out my SNES machine.
EDIT : I think I found the website in this thread and placed my order.. waiting for them now...
Hi Guys
I'm having real trouble getting star ocean working on my 12mb inl board.
I seam to have gotten various roms working (DKC Comp, Translated Back to the future 2, Various RPGs), however the star ocean will not boot.
I have tested it with both the interlaced and deinterlaced rom (patched from
http://www.nintendoage.com/forum/messag ... did=120150). Any one able to point me in the right direction of a known working patch?
Thanks
infiniteneslives wrote:
In general 6MB games:
People are used to splitting them into two files when using 4MB flash chips, one 2MB file, and one 4MB file. The 4MB file comes from the first 4MB of the 6MB rom. the 2MB file come from the last 2MB of the rom.
Start with empty file. Take the 2MB file (from end or rom) double it, put it as first 4MB of new file. Take 4MB file (from begining of 6MB file), place it at end of new file which should now be 8MB file. Program & Play. A future firmware revision will handle all that for you at a TBD date.
Sorry if this is stupid, I just want to confirm I did everything correctly.
I took a headerless Tales of Phantasia ROM (6MB), and copied a block from offset 400000 - 5FFFFF.
Pasted that twice in to a new file, adding up to a file that ends at 3FFFFF.
After that, I copied offsets 00000000 - 3FFFFF from the original file to 400000 in the new file, so it ends at 7FFFFF.
File doesn't boot in bsnes, doesn't work when flashed.
Where did I go wrong?
Jockel, are you using a 8MB board, 12MB? I think those instructions were intended for 8MB. It may not work for 12MB boards.
Sure, it's an 8MB board. When I tried expanding with Lunar expander (before reading this thread) it would at least boot up in bsnes, but not on hardware. I even tried another 8MB board to rule out a faulty flash chip, but nope.
If someone could PM me some 'detailed instructions' I'd be really thankful.
So after fiddling around a bit and dumping the ROM again, it seems like every bit is 8 too high. When I compare the ROM I tried to write to the dump, values that should be 11 are 19, 35 becomes 3D and so on.
What could cause this?
FYI, I'm using the alternative writer with its supplied firmware.
Will it ever be possible to add on enhancement chips to these carts?
No, never. Is it possible to make a flash cart with them, yes it's possible. But I think it's safe to say, INL does not ever plan to make one supporting the extra chips.
Thanks!
I am sure there are lots of issues with the special chips. I am sure they are proprietary, so you can't just ask some company to make several hundred for you to put into your custom made carts, so that makes sense. You would probably have to cannibalize several hundred carts to get that many chips.
I was trying to find a way to put some hacks onto carts without paying the usual high cost that people charge for repros. I was also hoping to get the write/rewrite capability that FLASH gives you. Specifically, I was hoping to do some Mario Kart editing and put those onto carts, but it looks like the only way to do that would be to make repros or buy an SD2SNES, which doesn't really fit with the writing/rewriting that I would want to do with the hacks or keeping it cheap.
Thanks again!
Why not just mount a ZIF socket on a Mario kart cartridge to do your testing? Use the "tsop to snes mask rom" adapter that you can program and reprogram. Then it's just a matter of popping it in the ZIF socket to test. Can your programmer program 27c322's EPROMs? Or 29F032's? Mario mart is so small, the 27c080 would work too.
Since we are on the subject, what can the max size of a Mario kart program be?
It has 36 pins for a mask rom buy only uses 32 mask roms. Can it be bigger than 1mbyte?
My programmer is a big fat nothing right now. I am still futzing around with hacks, but I have been talking to my friends about putting stuff on carts and we all think it would be really fun to play on actual hardware. Right now I don't have the tools required to do hardware work. INL's boards and programmer looked like an ideal solution, but I will look into the other FLASH alternatives to see if I can get something that will work for us--that is unless there is a way to make the INL boards compatible with the chips.
DSP1 games could possibly be playable with an adapter to use the DSP chip from an original game in conjunction with the flash cartridge. This is the only chip that this can be done with though. This led to many people incorrectly believing it could be done with any chip game. It is only DSP1 that this can work with.
For other games with chips that have hacks, your options are SD2SNES if it supports it, or emulation.
Lyjal wrote:
My programmer is a big fat nothing right now. I am still futzing around with hacks, but I have been talking to my friends about putting stuff on carts and we all think it would be really fun to play on actual hardware. Right now I don't have the tools required to do hardware work. INL's boards and programmer looked like an ideal solution, but I will look into the other FLASH alternatives to see if I can get something that will work for us--that is unless there is a way to make the INL boards compatible with the chips.
There is no way the infl. Cart can run Mario kart. That just won't happen. 32 pin ZIF (ZIF is zero insertion socket) sockets are plentiful and cheap. Even the cheapest programmer can burn 27c080 EPROMs which is what you'd use unless the program grew bigger than 1 megabyte. This is just an easy way to run your protos. Of course some of the other flash carts can run DSP games so you may want to consider those. PowerPak and maybe the everdrive. These would be a good way to test also.
I just don't know, Mark. Making a repro just seems like it takes a lot of technical skills and whenever I had read about people wanting to make them the advice tends to be: don't. I have only ever soldered a few things before (though one of them was a GBA Afterburner front light...), but just from all of the troubleshooting people look like they go through, it just seems like it would be very difficult to try to learn how to get the board, destroy boards learning how to solder, screw up a hundred times with the programmer, etc. INL's boards looked pretty easy. It's not that I am unwilling to learn, but we were searching for a cheap, immediate solution. Even buying a programmer, donor cart, soldering iron, and EPROMs would be more expensive than a flash cart and Kazzo programer.
Maybe we can try hacking games that are just HiROM or LoROM. Most games look like they don't use special chips. I might just end up doing SMW hacks instead for things we will try to put on carts.
I was hoping there would be an easier solution that wasn't $150 for an SD2NES, but it looks like not.
On the other hand, if I ever decided to make more than 5-10 carts, the programmer would seem like the way to go. I just don't foresee myself needing that many hacked carts at one time, and I don't even know if I would be able to do that hardware modding.
MottZilla wrote:
DSP1 games could possibly be playable with an adapter to use the DSP chip from an original game in conjunction with the flash cartridge. This is the only chip that this can be done with though. This led to many people incorrectly believing it could be done with any chip game. It is only DSP1 that this can work with.
For other games with chips that have hacks, your options are SD2SNES if it supports it, or emulation.
What kind of adapter would you need? Is this something that is commercially available for cheap or extremely cheap/easy to make? (I am guessing no on both counts)
Your best bet is to get a Super Everdrive then. It can run the DSP1 (you need to solder one in there), and its only around $80.
Lyjal wrote:
What kind of adapter would you need? Is this something that is commercially available for cheap or extremely cheap/easy to make? (I am guessing no on both counts)
This is the one I was thinking of that *might* work.
http://www.tototek.com/store/index.php? ... ucts_id=40
MottZilla wrote:
I was thinking along this lines for a superFX "piggy back"....not sure if it would work though. Although I was thinking of using a import adapter.
thebigman1106 wrote:
MottZilla wrote:
I was thinking along this lines for a superFX "piggy back"....not sure if it would work though. Although I was thinking of using a import adapter.
I already stated, you cannot "piggyback" a Super FX game. It will not work. The "piggy back" method only works on the DSP chips.
Anyone have luck running the software on Linux? I have Windows 8.1, but do my coding in Arch Linux, and would like to flash from there. I ordered a programmer board with an SNES port, and an SNES flash cart (A dead DKC2 cart will serve as its case), and am looking forward to use it for my homebrew projects, and maybe play some games that the board supports.
On that front, is there a list of games that will work? I would assume anything with an extra chip wouldn't, just curious.
Pretty much any game not using any extra coprocessors will work. Games that feature software based protections of SRAM or ROM mirroring nature may require a simple patch with a program like UCON64. Games over 32 megabits might be slightly tricky to get programmed due to the arrangement of data, but they do work.
So the games left out are the same games left out on most other flash carts and copier machines. No Super FX, SA-1, SDD-1, etc.
Well, I seem to be having an issue with the flasher. Upon selecting a ROM, and clicking "Write to Kazoo", the program will automatically get the "Not Responding" look, and a "Not working" box which will of course close the program.
Attempting to erase the cart gives me this:
Code:
[WriteHeaderToKazzo=>WriteBufferToKazzo] <WriteBufferToKazzo:0,0> Could not load type 'System.Runtime.CompilerServices.IAsyncStateMachine' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.
[EraseCart=>EraseCart] Failed to send Erase header. Cart may not be inserted or Kazzo may not be ready. Reseat/Reset and try again!
[handleEraseThreaded=>EraseCart_Threaded] Operation time: 0.41 seconds.
The cart is facing properly, (battery away from the board), I have inserted it completely, and it seems to detect the cart size, but cannot write it. The firmware was updated using the included bat.
Did you try both the original and the new program for programming? Here is the thread for the newer one.
viewtopic.php?f=12&t=11020
So after all my troubles with my boards and the INL in general, I took a long break from using it out of sheer frustration. Now, coming back, I try to do a simple write to make sure everything was ok. I attempted to do E.V.O and after it wrote I tested it to have Super Mario World on the cart. Thought it was weird and tried Chrono Trigger. Same thing. Super Metroid; same thing. So I thought it wasn't writing or even erasing. After 4 or 5 attempts, I'm getting the error:
[btnEraseClick=>handleEraseThreaded] Erasing cart.
[ThreadStart_Context=>EraseCart] Erasing single-chip SNES Cart.
[EraseCart=>EraseCart] Sending erase header to cart. Header index:0
[EraseCart=>WriteHeaderToKazzo] Called with HeaderID 0.
[WriteHeaderToKazzo=>WriteBufferToKazzo] Device is open.
[WriteHeaderToKazzo=>WriteBufferToKazzo] Writing page 1 of 1.
[WriteHeaderToKazzo=>WriteBufferToKazzo] Transfer failed, retrying...
[WriteHeaderToKazzo=>WriteBufferToKazzo] <WriteBufferToKazzo:0,0> Transfer failed at page 0!
[EraseCart=>EraseCart] Failed to send Erase header. Cart may not be inserted or Kazzo may not be ready. Reseat/Reset and try again!
[handleEraseThreaded=>EraseCart_Threaded] Operation time: 10.28 seconds.
So I tried redoing the firmware, using original firmware, re-doing everything, trying different boards, everything I could think of. BOTH my Kazoos won't even recognize there's a board in them anymore.... anyone have any ideas or had something similar happen?
(quit edit: yes the board is inserted properly.
)
EDIT: Fixed with a good cleaning
After you tell it to erase, how long are you waiting? Erasing can take awhile depending on how big the flash is on your cartridge. The LED as I recall is supposed to help you know when erasing has completed. To be safe, tell it to erase and then wait atleast 1 minute. Then after that you can try to program another ROM image.
Also, what size is your cartridge? 4MB, 8MB, 12MB?
4 MB board, and it takes the normal amount of time to erase. The light dimmed before and stayed dim for a minute or so. But currently it won't even do that since it won't recognize the boards anymore.
Also the firmware update doesn't seem to want to hold either. Like I'll update it, the program recognizes the update, then after a few failed attempts it stops working and when I reset it or ask it to find the kazoo, it says I need to update the firmware again... Happens on both my kazoos.
EDIT: Fixed with a good cleaning
The light if I recall first dims but it's not done till the light goes out. If you fail to wait long enough it won't erase or program as you want it to.
If you're having trouble getting the boards recognized you might just not have them seated in the connector correctly. It's not a perfect connector. I think it needs the pcb all the way to one side. And I assume you don't have them in a cartridge case while trying to program them right? They won't fit in right if you have them cased I believe.
Programming the firmware shouln't be a big deal. I think you just set the switch to the BL/Boot Loader position before plugging it in. Then you run the right batch file to upload the firmware. When it's done you push that switch out of the boot loader position, or else the next time it boots up it'll again be in boot loader mode.
After I program the firmware I change the switch from BL to Run (I think it's called run) then unplug it or hit the reset button.
Thanks a lot for the advice, but unfortunately I've done several writing processes before. I helped Danin test the software and new firmware upgrades before he released them and generally anything he needed me to write. I have 6 boards left over from the several that I bought, and know how to seat them... I wish it was that simple.
In a nutshell, I really appreciate the help but not putting it in right isn't the problem
I'm sadly leaning to the conclusion that both my kazoos are dead now for some reason?
EDIT: After an alcohol bath and some serious cleaning, it seems to work again. I had it stored in a sealed box, but somehow something must have gotten in it. At any rate, at least it works again ^_^ Thanks Danin!
Sorry for double post, but figured if anyone was following this thread, they'd want to see this too. A few others have had my problems too and I found a solution that I wanted to share incase anyone else comes here for it:
The issue with the games suddenly stopping and getting a black screen have been resolved with a very simple trick: Put them in a game genie and run it like that. I have no idea why this works, but it does. All the games I had issues with suddenly started working correctly after this. I hope this helps anyone who had this problem as well!
Another note, I ran into a new problem that is making me scratch my head again. For some reason, a few games won't boot up when I write them to my board. Strangely enough, its some that used to work. Final Fantasy VI/III, Lennus II, and now the BS-Zelda real hardware patch. It writes fine, no errors, the Lo/Hi rom is in the right place.... Just gives a black screen when it's turned on in the console. Anyone have this problem before?
What tools should I be using to remove the header and pad the rom? I'm trying to get an English Seiek Densetsu 3 going on an 8MB cart, but so far I've had no luck.
I have however gotten SMW to run on it without modifying the rom
Ok, I figured it out. Instead of using lunar expand, I used the CMD to mirror the rom up to 8MB and it worked. LunarExpand only fills the rom with 0s.
Hey guys. I am trying to write 6mb game to a 12mb cart. I have not had any luck. The game is Crimson echoes. I have no problem writing it to a 8mb board but I have none left.
How do I place the rom? I have tried heaps of combinations including doubling the rom, splitting it and putting the last 2mb at the start etc.
I have special firmware someone game me on Nintendo Age including the 12-16mb Erase file which works perfect for Star Ocean.
I am using the original software as I have not had much luck using the Retro-Prog.
Any advice on this one?
Thanks
If you run this test ROM on your 12 MB cart and take a screenshot, perhaps I can figure out how you'll need to rearrange a 6 MB ExHiROM (mapper $25) to fit.
From what I understand, INL programs those boards differently to handle the 96Mbit rom space. I don't know if they are really compatible with a regular game without some data rearranging... But I believe it's split into 3 32Mbit chunks.
Maybe it's similar to how his 8MB boards work, by cutting the last 16Mbit of the rom space and doubling it up in the beginning of the rom using a hex editor. I remember having to do that with some games to get them to work. Maybe the 12MB board is the same?
My test ROM will at least tell you in what order the CPU is seeing the chunks, so that you can figure out in what order to write them.
tepples wrote:
If you run this test ROM on your 12 MB cart and take a screenshot, perhaps I can figure out how you'll need to rearrange a 6 MB ExHiROM (mapper $25) to fit.
Thanks so much for that. Here are the screenshots
Lorom switch setting
Hirom switch setting
The 3-digit hex numbers on the screen show which 32 KiB bank of the file is mapped to each 32 KiB chunk of Super NES address space. This tells me that in the HiROM switch setting, the 12 MiB cart is mapping the test ROM's 384 banks as follows:
- $008000: 64 banks of LoROM
- $808000: 64 banks of LoROM
- $400000: 64 banks of HiROM
- $C00000: 64 banks of HiROM
I can't tell what's going on in the LoROM setting, as it's displaying out-of-bounds bank values. So I'll use the HiROM setting and reshuffle the banks so that the game ends up in the parts of memory where it expects to be.
To run the 6 MiB ExHiROM game, you'll need to break the .sfc file (of size 6291456 bytes) into three 2 MiB (2097152 byte) segments, titled part_1, part_2, and part_3.
- part_1: $000000-$1FFFFF in file; $C00000-$DFFFFF in memory
- part_2: $200000-$3FFFFF in file; $E00000-$FFFFFF in memory
- part_3: $400000-$5FFFFF in file and memory
You'll also need to make files mirror_1, mirror_2, and mirror_3 that contain only the second half of each 65536 byte bank. Then join them in this order:
mirror_3, mirror_3, mirror_1, mirror_2, part_3, part_3, part_1, part_2
These steps, especially creating the mirror_* files, might require a small piece of software. Does your PC run Windows, OS X, or Linux?
tepples wrote:
The 3-digit hex numbers on the screen show which 32 KiB bank of the file is mapped to each 32 KiB chunk of Super NES address space. This tells me that in the HiROM switch setting, the 12 MiB cart is mapping the test ROM's 384 banks as follows:
- $008000: 64 banks of LoROM
- $808000: 64 banks of LoROM
- $400000: 64 banks of HiROM
- $C00000: 64 banks of HiROM
I can't tell what's going on in the LoROM setting, as it's displaying out-of-bounds bank values. So I'll use the HiROM setting and reshuffle the banks so that the game ends up in the parts of memory where it expects to be.
To run the 6 MiB ExHiROM game, you'll need to break the .sfc file (of size 6291456 bytes) into three 2 MiB (2097152 byte) segments, titled part_1, part_2, and part_3.
- part_1: $000000-$1FFFFF in file; $C00000-$DFFFFF in memory
- part_2: $200000-$3FFFFF in file; $E00000-$FFFFFF in memory
- part_3: $400000-$5FFFFF in file and memory
You'll also need to make files mirror_1, mirror_2, and mirror_3 that contain only the second half of each 65536 byte bank. Then join them in this order:
mirror_3, mirror_3, mirror_1, mirror_2, part_3, part_3, part_1, part_2
These steps, especially creating the mirror_* files, might require a small piece of software. Does your PC run Windows, OS X, or Linux?
OK. I am using a file splitting app and just plain windows copy command with the binary switch. So just to break it down.
I split the file into 3 x 2mb parts
I am just confused on the mirror parts. So is this just the second 1mb half of each of the 3 2mb parts? It would make sense as this would add up to the 12mb.
Sorry I am not referring to the parts in hex. I am new to this game
The mirrors are: Take each 2MiB slice. Divide that into sixty-four 32 KiB slices. Concatenate every second 32 KiB slice.
This is involved enough that tepples is (appearing to?) offering to write a tool to do it for you.
mamejay wrote:
windows
Lidnariq guessed right. Go to
Python.org and grab the MSI installer for the latest version of Python 3 for Windows. Let me know when you've installed it.
tepples wrote:
mamejay wrote:
windows
Lidnariq guessed right. Go to
Python.org and grab the MSI installer for the latest version of Python 3 for Windows. Let me know when you've installed it.
Already got it installed. Send your wonderful script over to me please
I noticed you're familiar with the command prompt, as you previously used copy /b.
This zipfile contains a Python 3 program and a 6 MB build of my bank diagnostic ROM. Try using the program to expand the ROM to 12 MB and run it on your cart. I'd try it myself, but I don't have an INL Hi/LoROM cart of my own.
tepples wrote:
I noticed you're familiar with the command prompt, as you previously used copy /b.
This zipfile contains a Python 3 program and a 6 MB build of my bank diagnostic ROM. Try using the program to expand the ROM to 12 MB and run it on your cart. I'd try it myself, but I don't have an INL Hi/LoROM cart of my own.
I am at work at the moment but will test this out tonight once I get home.
OK just tried you script. Success!!
The rom seems to be working perfectly.
Thank you so much for your help on this one Tepples
Is anyone still following this thread? I had some questions about the kazoo programmer, and the INL SNES boards. I am working with HME to create a custom Harvest Moon Hack for the SNES. I can play the game in an emulator, but am really a newb when it comes to putting it on a real cartridge to test it.
Is this a good option for doing so, and if so, how would I do it?
Anyone got this running on an unmodded PAL SNES, it runs fine on my PAL SNES with built in supercic but not on my unmodded PAL SNES.
Has any more work been put into limiting the sram to 8 kbit of 4kbit since lots of games like earthbound use this as copy protection.
QB14 wrote:
Has any more work been put into limiting the drama to 8 kbit of 4kbit since lots of games because games like earthbound use this as copy protection.
You can limit it with some soldering work, but the easier solution is to use something like UCon64 or my flasher app/firmware. My app also should work with stock firmware, albeit MUCH more slowly. My flasher app actually patches out protections automatically, though there are some titles that it argues with. That's planned as a fix for the next release I've been working on when I have time, which (sorry) is frankly not often.
Danin wrote:
You can limit it with some soldering work, but the easier solution is to use something like UCon64 or my flasher app/firmware. My app also should work with stock firmware, albeit MUCH more slowly. My flasher app actually patches out protections automatically, though there are some titles that it argues with. That's planned as a fix for the next release I've been working on when I have time, which (sorry) is frankly not often.
Thanks for responding sorry I was typing on my iPhone (lots of autocorrect)
Is your flasher application available for download if so what is its name
I've been thinking of including a means to trim the SRAM on the board and allowing people to designate the size of SRAM they'd like with the purchase of the board.
I've gotten a large number of requests for differing values of SRAM that are actually desired though, including some from people I think may be confused on KByte vs Kbit. If I'm not mistaken the majority of copy protected games demand 8KByte (64Kbit) of SRAM, however there are others which require as little as 2KByte (16Kbit) as well. Adding all those options along with everything in between, and as much as 32KByte (256Kbit) which some games also need is a bit of a challenge though without going crazy with solder jumpers..
Why don't people just patch the games? It's not a big deal. Do they just not understand how to do that?
I think most games use 8 Kilobytes of SRAM. I think the Donkey Kong Country series uses 2 Kilobytes and does copy protection checks if more is there. Killer Instinct will trip if any SRAM is there at all. I think Mega Man X and Demon's Crest also will.
So not only would you need SRAM sizing but plain old SRAM Enable/Disable. Or people could just use UCON64 and patch the games.
Just my two cents. When I first got the software and chips it was quite daunting after several stupid questions and lots of trial and error I finally got the hang of the SNES side. A member sent me Danin's version of the software and it automatically pads the roms and whatnot. It really did simplify the whole process. Perhaps just screw with the base software slightly? Again I know nothing in comparison to the average person on this site but it seems like less work to just mod the software.
Also so far every single game has functioned properly burning using Danin's software except for Star Ocean. For whatever reason a member and I tried dozens of failed burns and the culprit was the software. When I used the stock software it burned just fine.
NYMike wrote:
Also so far every single game has functioned properly burning using Danin's software except for Star Ocean. For whatever reason a member and I tried dozens of failed burns and the culprit was the software. When I used the stock software it burned just fine.
Thanks for the help! I found Danin's software and it works great. One problem I have been facing is when I burn earthbound I can't play fine with some audio glitches but then at a random point the audio will stop and the game will play fine until the next room I will enter/exit or if I kill and enemy the game will freeze up and I have to restart the console. Has this been happening to anyone else? Is because of the copy protection or something else?
If you think it might be copy protection related you could try using UCON64 with the -k option. Also if you are using a PAL console that could be causing issues.
Earthbound for the NES has multiple layers of protection as well. EB and Breath of Fire II have some of the most pita protection I have run across yet. I still have no clue how I got the Breath of Fire 2 remastered with "Through The Fire and Flames" intro to run 100% correctly on a INL cart on a SNES but I love it!
MottZilla wrote:
If you think it might be copy protection related you could try using UCON64 with the -k option. Also if you are using a PAL console that could be causing issues.
Thanks for the advice, I use a ntsc console so that is not the issue, unfortunately I don't know how to use UCON64 I have just been using danin's firmware which patches out the copy protection. I will try to learn how to use UCON64 then come back with the results.
QB14 wrote:
MottZilla wrote:
If you think it might be copy protection related you could try using UCON64 with the -k option. Also if you are using a PAL console that could be causing issues.
Thanks for the advice, I use a ntsc console so that is not the issue, unfortunately I don't know how to use UCON64 I have just been using danin's firmware which patches out the copy protection. I will try to learn how to use UCON64 then come back with the results.
Ucon64 has a front end loader if you are not a fan of dos like commands. It is pretty good I have been able to crack BoF 2, Metroid, and several others with it. The only games off the top of my head that I could not crack with it are Fire Emblem 776? and Tetris and Dr. Mario.
The old Tototek Super Flash carts allowed multiple games on a single cart through a type of boot loader menu to select a game. Do these carts have any similar function to take advantage of the additional space if not loading large ROMs?
XTElite1 wrote:
The old Tototek Super Flash carts allowed multiple games on a single cart through a type of boot loader menu to select a game. Do these carts have any similar function to take advantage of the additional space if not loading large ROMs?
Not currently. Though I think it might be possible to have two games on the cartridge. Or maybe that was just some talk. But there isn't a writable register like the TTT Super Flash for mapping in different games and having a menu program to handle that.
What is the official word about this feature being added? While I did not like the mandatory menu on the Tototek model, the option of loading multiple games would be quite nice. Hopefully it could be implemented in a manner that doesn't require even single title carts to have a menu.
All that aside I ordered a 8MB version to play with and am looking forward to it. Thanks for all the hard work for this product.
Allowing multiple games on the same cartridge is on the 'nice to have, maybe I'll get to it at some point' so it's rather low on my priority list..
I added placement for a low pass filter on the bottom of the PCBs for the reset pin to toggle between roms. I tested it to make sure it worked and it did. But the main hold up at this point is redoing the host app to be more user friendly. In it's current state it would have required users to assemble one large binary file on their own and flash it all on at once. I've realized that's a little too much of an advanced user feature to permit me to offer currently without having excessive customer service headaches on my hands..
The other issue was as things are currently designed a multicart would be excessively rigid, forcing something like 4MB rom slots with half fixed to lorom and other half hirom or something to that effect. I'm planning to make the kazzo able to reflash the CPLD to make the configuration more flexible based on exactly what the customer needs after purchase vs prior to purchase.
I know you just got done saying multi-cards are low on your priority, but as someone who personally bought close to 40+ carts from you, I could easily see myself buying another batch like this with this ability. As long as like you just said it is a semi easy process or has very specific instructions to ensure this happens correctly.
Thanks NYMike, I appreciate your feedback.
I received my 8MB and kazzo today (shipped fast, thanks!). These little carts are great. So great that my wife authorized me to buy two more. One for her, and one for a game together.
I concur with NYMike that if you get multi-cart working in a sane way, I could see myself buying more. Great work, thanks again, and to anyone reading, I highly recommend these little guys. Just be sure and lookup Danin's host app here:
viewtopic.php?f=12&t=11020
I have noticed that every HiROM game works fine, but every LoROM game I have tried does not work. I am toggling the switch to LoROM but at best I get garbled graphics but mostly I get a blank screen. Do I have a defective board? I am using Danin's host app.
I can't speak for Danin's app other than I know it works well for a lot of ppl.
It would be difficult for a board to have a defect that allowed HiROM to work, but not LoROM, unless something like the Hi/Lo switch was broken and always was set to HiROM. If you try to play a HiROM game with the switch in LoROM does it still work? If so, perhaps the switch is broken, if not I'm guessing the switch is fine.
I would recommend a simple small LoROM game like SMW to test LoROM operational. SMW isn't very picky and doesn't require the rom image to fill the entire 4/8/12MB on the board. You can simply flash the 512KB headerless rom image to the board with my app and hopefully prove the board working.
An even better idea would be to flash Tepples'
Holy Batman Striker test rom onto the board to test the board, the test rom works in both LoROM and HiROM but will have differing outputs based on the position of the switch.
infiniteneslives wrote:
I can't speak for Danin's app other than I know it works well for a lot of ppl.
It would be difficult for a board to have a defect that allowed HiROM to work, but not LoROM, unless something like the Hi/Lo switch was broken and always was set to HiROM. If you try to play a HiROM game with the switch in LoROM does it still work? If so, perhaps the switch is broken, if not I'm guessing the switch is fine.
I would recommend a simple small LoROM game like SMW to test LoROM operational. SMW isn't very picky and doesn't require the rom image to fill the entire 4/8/12MB on the board. You can simply flash the 512KB headerless rom image to the board with my app and hopefully prove the board working.
An even better idea would be to flash Tepples'
Holy Batman Striker test rom onto the board to test the board, the test rom works in both LoROM and HiROM but will have differing outputs based on the position of the switch.
As it turns out, the issue was with Danin's host app. I mirrored the games myself and they are working fine. As I mentioned before this is LoROM games only as HiROM games seem to write fine on my 8MB board.
Interesting. I burned Chrono Trigger Retranslation, Crimson Echoes and Prophets Guile (All 8mb boards) on Danins software as well. Only the Retranslation works. CE and PG gives me similar graphical errors an hour or two into gameplay or straight out locks up on one of them. When I get some free time I will have to try burning them again with the stock software and see if I can get past this point.
NYMike wrote:
Interesting. I burned Chrono Trigger Retranslation, Crimson Echoes and Prophets Guile (All 8mb boards) on Danins software as well. Only the Retranslation works. CE and PG gives me similar graphical errors an hour or two into gameplay or straight out locks up on one of them. When I get some free time I will have to try burning them again with the stock software and see if I can get past this point.
Try using Lunar Expand to make your 8MB ROM file, use ucon64 to patch out any protections and fix checksum, and burn it with the stock app.
Stupid question time! Can I have danin's software in one folder and the stock INL software in another folder and run on the same computer? Or because I flashed the bios will they conflict. All I remember was trying to install INL on my laptop which is Windows 8 was down right brutal.
NYMike wrote:
Stupid question time! Can I have danin's software in one folder and the stock INL software in another folder and run on the same computer? Or because I flashed the bios will they conflict. All I remember was trying to install INL on my laptop which is Windows 8 was down right brutal.
I'm using both on my Surface Pro 4 running Windows 10. I just use Danin's drivers since they are a slightly newer version.
OK so I set aside some time today for a test run. So far I am 1 hour 45 mins into Chrono Trigger Crimson Echoes and I just passed the place that I vaguely remember constantly crashing at. Its been a year since I played this last and my memory is foggy. However, I am thinking that this is another game that does not want to play nice with Danin's software version. I will put another hour or two in and if this changes I will post here and eventually update the chart I started working on here
viewtopic.php?f=28&t=12963&start=15
Quick question, has anyone been able to get Final Fight 3 to work? I've tried a couple of different roms, both the original and the Danin software, and different ways of padding the file to 4MB and nothing seems to work. It's the only game that I haven't been able to figure out so far.
I'd have to open my cartridge to check but Final Fight 3 should be "padded" by copying the first 1 megabyte of data to the end of the 3 megabyte file to make a 4 megabyte ROM. Then if your INL board is 8MB or 16MB you just copy the 4 megabyte ROM to fill up the entire flash ROM capacity.
I'm unaware of whether or not Final Fight 3 features any copy protection measures. If it does you may need to patch the ROM.
Thanks, I'll try it out. I padded the file but not exactly the way you said so maybe that was my problem. I'm more familiar with NES carts, this SNES business is new to me.
I've checked it with a few different utilities, nothing seems to detect copy protection in this game, but it was a later Capcom game so who knows. I'll report back.
GohanX wrote:
Thanks, I'll try it out. I padded the file but not exactly the way you said so maybe that was my problem. I'm more familiar with NES carts, this SNES business is new to me.
I've checked it with a few different utilities, nothing seems to detect copy protection in this game, but it was a later Capcom game so who knows. I'll report back.
Final Fight 3 does have sram detection/protection. It'll be a black screen if it detects sram.
Mark, you are absolutely correct! I removed the sram chip altogether and the game works perfectly now. Thanks!
I have an 12MB Snes INL Board that I had previously programmed with star ocean and had gotten to work, last time I tried to use the cart, I got lots of graphical errors and now this time SNES is just giving me a black screen (non repro's work fine). I've tried flashing the cart again with the star ocean and another rom using both Danin's tool and the INL tools, but I've had no luck. Anyone know how I can figure out whats wrong?
Dakkon426, Some things to check/verify. All this guidance assumes you're using my firmware and app as I'm not familiar enough with Danin's release to provide adequate support.
-Make sure your board and SNES connector are cleaned well, possible this is why you had initial graphic glitches with a board that was working fine months ago. But now we'll need to make sure it's getting reprogrammed properly.
-update your kazzo to the most recent release on my webpage and try again. Depending on how how your firmware is, your kazzo might not be reporting an error if it fails to flash properly leading you to believe it flashed properly when it didn't. This issue was corrected awhile back with a firmware update.
-Make sure you're using the ERASE_SNES_12-16MB.bin file and selecting header in the pull down when erasing the board. Also, verify you're getting the dim LED for ~40sec while the board erases. And don't attempt to flash the board until the LED goes out.
-Try flashing a small LoROM game like SMW onto the board. Using my app you'll only have to flash the 512KB rom image and it should boot just find on a 12MB board with the switch in LoROM. If that's working well, then try SO again, and make sure you've got a deinterleaved copy of the rom.
If the conclusion is the board is damaged, submit a ticket on my support page and we can repair/replace it for you at no charge.
Thanks for the Help! Console's cart connector is definitely clean, I have no problems with any if my original carts though I only have the one repro cart to check.
As per your suggestion, I have updated to the newest firmware using the load retroprogrammer batch file. Followed instructions to Erase with the 12MB erase rom waiting 40 sec for LED to go out. While attempting to flash a small LoRom Game I encountered Error -116 and -5. Also Tried SO again and received the same Errors.
Any Ideas?
Sounds like the board is erasing properly, but something is going wrong during the flashing process. If the board is working properly, it's hard to make a user error and have that result unless you have the wrong item selected in the pulldown menu. Make sure header is selected for the erase file (sounds like you did that fine since you had dim LED what took ~40sec to go out.) Just make sure you have 12MB SNES selected in the pull down when writing SO. You can use 12MB SNES in the pull down for smaller roms, it'll just report "error in page 0" if you do so which is expected if you select pull down size larger than loaded rom.
When writing, does the error -116/-5 show up immediately? Or does it take a few sec/min to show up?
Assuming you've got the 12MB SNES selected when writing SO as described it does sound like your board has failed for some reason. If you contact me via email/ticket system I'll provide you with the return address and we'll repair/replace it for you at no charge.
So after digging into some of roms people have had problems with I'm realizing much of it is simply fixed with only providing 64kbit (8KByte) of SRAM. There's only a couple games which require 128-256kbit of SRAM, so I'm planning to change the default offerings for boards we sell as 64kbit instead of 256kbit as we have to date. we'll still have 256kbit available, just won't be there unless you're specifically choosing it.
One of the big ticket games it fixes is Zelda AST series, as the main character is all garbled if >64kbit SRAM is provided. With this 'fix' now in place I can finally get around to offering multicart options to toggle through the different weeks with the reset button while maintaining the same save data for all weeks.
If anyone has some specific games with issues they'd like me to check out let me know. The 64kbit SRAM trimming resolves most of the ones I heard reports about. I'm kicking around the idea of overhauling my design for the next board revision to allow the multicarting settings and SRAM sizing to be configurable in the user's hands through the kazzo programmer instead of at time of manufacture/purchase. But won't be focusing on that until I release my overhauled firmware and host app. So there some time for feature requests if anyone has them.