I want to use the 74ls139 to wire up 8mbit eproms into a single superfx pcb, I found a way to romhack superfx games to run at unlimited speed, unfortunately doom is a 16mbit game. From my understanding I just wire the source chip enable line into one pin of the 139 and the other pins into the CE pins of the eproms? Anything else I need to do?
If I remember correctly you would connect the ROM CE line to the 1G input on the 74x139, ROM A20 to 1A on the 139, EPROM1 CE to 1Y0 and EPROM2 CE to 1Y1. All other 139 inputs to ground.
When you say unlimited speed, does this mean you have found a way to get SFX games to render more frames (game runs smoother but at same speed with less slowdown) or is the SFX still rendering the same frames? (game runs like its in fast forward and technically still slows down at busy points). I'm guessing that the first case would require access to Argonaut's proprietary SFX assembler software.
I suppose I should have posted this, superfx maskrom pinout:
No a20 on it. Guess with doom pcbs a20 is one of those 8 extra pins. I think I found the pin too since 7 out of 8 of the extra pins are grounded or connected to vcc and the 8th one connects to the gsu 2.
Unlimited overclock speed. The overall game speed as well as the framerate increase:
http://www.youtube.com/watch?v=Ydh_jvlrDrE&feature=youtu.bePerfectly playable as the control response is equally as sped up.
Drakon wrote:
I suppose I should have posted this, superfx maskrom pinout:
No a20 on it. Guess with doom pcbs a20 is one of those 8 extra pins. I think I found the pin too since 7 out of 8 of the extra pins are grounded or connected to vcc and the 8th one connects to the gsu 2.
Thats pretty much it. The surface mount mask roms pretty much match up to their DIP couterparts. The pinout for the 32Mbit maskrom should point you in right direction.
Quote:
Unlimited overclock speed. The overall game speed as well as the framerate increase:
http://www.youtube.com/watch?v=Ydh_jvlrDrE&feature=youtu.bePerfectly playable as the control response is equally as sped up.
So music out of sync, reflexes of a fly required, etc... Shame we can't overclock the average human response time the same way.
I suppose until we get out hands on said SFX assembler we pretty much won't ever see a
true overclock.
Also with the two eproms I just split the commercial rom into halves and burn each half to an eprom? Obviously after I remove any header. I wouldn't say the music is out of sync is still plays when it's supposed to. And no you don't need super reflexes because the control response is equally as sped up. Previously there was a delay with the control response in these games now there's no delay.
Yep, just split it in two. I'm guessing that Doom is 2MBit exact so a straight 50/50 split will do. Have you considered using 27c160s to cut down on complexity slightly?
Drakon wrote:
I suppose I should have posted this, superfx maskrom pinout:
IMAGE
No a20 on it. Guess with doom pcbs a20 is one of those 8 extra pins. I think I found the pin too since 7 out of 8 of the extra pins are grounded or connected to vcc and the 8th one connects to the gsu 2.
For reference:
Hojo_Norem wrote:
Have you considered using 27c160s to cut down on complexity slightly?
IIRC, the only way to use the 27C160 in 8bit mode is if you're switching between 8Mbit halves. Otherwise the EPROM is 16-bit. The 29F016 is 16Mbit and 8-bit, so that would be a better choice. And since you'd have to be wiring in the EPROM leg by leg anyway, you wouldn't have to bother getting one of those fancy SNES TSOP adapters, you could just grab a standard
32-pin 40-pin TSOP to DIP adapter from eBay or where ever.
Ziggy587 wrote:
Hojo_Norem wrote:
Have you considered using 27c160s to cut down on complexity slightly?
IIRC, the only way to use the 27C160 in 8bit mode is if you're switching between 8Mbit halves. Otherwise the EPROM is 16-bit. The 29F016 is 16Mbit and 8-bit, so that would be a better choice. And since you'd have to be wiring in the EPROM leg by leg anyway, you wouldn't have to bother getting one of those fancy SNES TSOP adapters, you could just grab a standard 32-pin TSOP to DIP adapter from eBay or where ever.
Odd. I always thought the 27c160 was 16/8bit. When you pull it's /BYTE line low it goes into 8 bit mode. I just wire the SNES A0 signal to the 27c160's A-1 line and then all my other address lines to Ax+1 (EPROM A0 to SNES A1, EPROM A19 to SNES A20 etc...) Ive done that successfully with the 5 projects I have used them in so far.
Thanks for pointing out those 29F016s tho, more available than 29F032s.
Ah, OK. I see now. In that case, I take back what I said. The 27C160 would be easier to use.
I have only used it in 16-bit mode, so I was unaware. I read the datasheet a while back, I guess I was thinking of this:
Quote:
The M27C160 has two organizations, Word-wide and Byte-wide. The organization is selected by the signal level on the BYTE VPP pin. When BYTE VPP is at VIH the Word-wide organization is selected and the Q15A–1 pin is used for Q15 Data Output. When the BYTE VPP pin is at VIL the Byte-wide organization is selected and the Q15A–1 pin is used for the Address Input A–1. When the memory is logically regarded as 16 bit wide, but read in the Byte-wide organization, then with A–1 at VIL the lower 8 bits of the 16 bit data are selected and with A–1 at V IH the upper 8 bits of the 16 bit data are selected.
Okay I'm new to this whole snes repro making business. Would it be at all possible you could make a wiring schematic for the 27c160 using this pinout:
?
If you're too busy I fully understand. Also to burn a 27c160 do I need to use an adapter? I'll check on the datasheet for it right now.
If anyone is curious what all this work is for. Here's stunt race fx running at 50 mhz recorded straight from my snes:
https://www.youtube.com/watch?v=UrqGAVmhs2wUnfortunately I need to patch the roms to make them run this fast, which is why I need to figure out how to wire up a 16mbit flash / eprom to a doom pcb.
I think this is what you want......
2 roms with a 139 decoder.
Can also use a tsop to dip adapter (29f032 adapter) and can reflash the tsop adapter in circuit. No desoldering.
http://youtu.be/MooCcCgfU34Version 2 is just a week away that uses a Doom cart as host and will have 3 flash roms so all the fx games will fit on 1 cart and also has a special SRAM adapter so it'll have 8 separate SRAM save files for the different games.
I'll post a video after my boards arrive and built.
Mark
Hojo_Norem wrote:
I'm guessing that the first case would require access to Argonaut's proprietary SFX assembler software.
How so? If you can write an emulator for a given CPU, you can write a disassembler. If you can write a disassembler, you can write a macro package to get ca65 or TASM to reassemble the code.
The music is out of sync. No question about that. It's noticeable on short themes when they don't complete. For many or all of these games, they will require reprogramming to actually render more frames rather than just rendering the same frames and displaying them in less time. This is like taking a film which runs at 24 frames per second and speeding up the projector to show 30 frames a second. No new frames are seen but it sure looks faster!
I can't even count how many times I have seem forum post from Drakon about overclocking Star Fox 2 (search on google, they're on EVERY single game related forum out there) and how many time I have read people trying to explain why it is not really rendering more frames and the game would no longer play at the intended speed or that the music get out of sync because of it. I'm pretty sure it won't deter him.
I understand how this is playing the same number of frames at a faster pace, but I don't understand how the argument that the sound is out of sync is relevant.
The music doesn't speed up or slow down to finish at the same time you do when your playing on a non modified cart, so why is this necessary for a modded cart? The music wouldn't finish at the same time if you finished the race in 1st place or 5th place because it took you a different amount of time to finish. When you see the sprite cross a time line or pic up an item the sound isn't delayed or at least does not appear to be in these videos.
Please explain this argument, for my curiosity and education.
Also the comment about needing lightening fast reflexes to play it now, I find irrelevant also. How is this any different to playing Super Mario Bros. with B button held down all the time to playing it without. You play accordingly.
marvelus10 wrote:
I understand how this is playing the same number of frames at a faster pace, but I don't understand how the argument that the sound is out of sync is relevant.
The music doesn't speed up or slow down to finish at the same time you do when your playing on a non modified cart, so why is this necessary for a modded cart? The music wouldn't finish at the same time if you finished the race in 1st place or 5th place because it took you a different amount of time to finish. When you see the sprite cross a time line or pic up an item the sound isn't delayed or at least does not appear to be in these videos.
Please explain this argument, for my curiosity and education.
The music sync issue isn't much an issue during gameplay, partially because the player is usually concentrating on plying the game. However the non-interactive bits are where this can become an issue. Some may argue for example that the first 'hit' of the Corneria bgm is times to when the player gains control just as Fox calls in. Other obvious issues include things like music being cut off too early. The Starfox 2 segment of the first vid is full of these. The music obviously sounds like it's building to a finish but gets cut off early. It just doesn't sound right imo.
Yes we aren't talking about gameplay background music themes. We are talking about musical themes that play during events like in Star Fox, after you defeat the boss. Or in Star Fox 2 when the ships are launching from Great Fox/The Carrier Ship. Star Fox 1 has a very noticeable one, the launch of the Arwings from the hanger tunnel. In overclocked execution this theme is no where close to completed when it cuts out.
It's not like it ruins everything, it's just one more point about how this is wrong. The best thing to do *once again* is to reprogram the game to render more frames so that the game moves at the same speed (music themes would be in sync) but thanks to additional frames being rendered you would have a smoother animation/frame rate. That would be cool.