Hi, Can I use a 2 mb donor pcb with battery for a game without saving option?. For example: I want make probotector repro in a NHL 94 pcb, with a 27c160 eprom, it's possible?. must be wired anything?.
thanks.
Printable View
Hi, Can I use a 2 mb donor pcb with battery for a game without saving option?. For example: I want make probotector repro in a NHL 94 pcb, with a 27c160 eprom, it's possible?. must be wired anything?.
thanks.
Yes you can. The SRAM will never be addressed so you can either leave it in or take it out. The battery can be removed too.Quote:
Originally Posted by eterno002
Thank you, very much for your help ,Jazzmarazz.
Quote:
Originally Posted by Jazzmarazz
Hi, I soldered eprom in the pcb and I only obtain screen with sega enterprises message and them black screen.
I checked the soldering and continuity is all right.I remove battery also, Can anyone help me?.
I attach a picture of my pcb.
Attachment 47465
alright so I got a good deal on many 27c322 eproms and want to only use those. the first board I found as my first test was an acclaim 670128 that can be changed into a 32Mb board. I switched the jumper to J1 but it's still not working. while searching online I found an image of this board being used for a 32Mb game from default and it seems like it has some kind of resistor instead of the pure metal jumper
Attachment 47901
I programmed the unpadded rom (as people have been saying its not needed) and it doesnt work. I desoldered the rom and read it and did a hex compare to the original rom and they were the same.
1. That is not a resistor, it is a jumper. You can tell becusse of the single black stripe. You're probably thinking "that's odd" but it was quite common to use since pick-and-place machines could grab them and place them.Quote:
Originally Posted by Lotaphi
2. Did you "byte-swap" the rom image before programming it?
Nope. This is the first I have heard of doing this. I do this with my SNES repros but I don't know how to do it with genesis. can you help me please?Quote:
Originally Posted by Jazzmarazz
Never mind. I went back and reread your stop about the software and read about how to byte-swap there! works perfectly now!. I skipped that step beffore because we have different programmers so I thought it was going to be specific to your programmer. dumb me. thanks for the great guide!
Great work! What programmer do you have? I just got a new gq-4x for all of my repro needs. My tutorials may be based on that from now on.Quote:
Originally Posted by Lotaphi
Is there some sort of newbie's guide to what is needed to start doing your own repo's and DIY flash carts)? I am slowly getting out of console modding (TSOP Xbox's, GameCube XenoGC's, Dreamcast HDD mods, etc), and want to get into doing my own repo's and DIY flash carts.
That's what I have and it worked great. one of the burns I did though didn't burn the chip correctly for some reason. it was my 2nd eprom I tried where I padded the rom thinking that was the problem. it had a bunch of FF randomly in the wrong places when I hex compared it. other then that one time they have worked well.Quote:
Originally Posted by Jazzmarazz
What kind of power supply are you using for writing eproms?Quote:
Originally Posted by Lotaphi
none, havent needed it yet as far as I know. I was going to attempt an atari repro once but it said I needed a power supply when i picked the chip for that. other then that it hasnt said I needed one for any of the chips I burnQuote:
Originally Posted by Jazzmarazz
Seriously? Just USB power for a 27c322? That is great. The uv-eproms need high voltage for their vpp pin. That's great that usb power can handle these chips.Quote:
Originally Posted by Lotaphi
yep, so far the only ones that it said it needs power for are actually the older smaller chips for atari 2600 sized games. Though I haven't researched wether or not using power for things that don't need it adds any benefits such as faster burning or more stability.Quote:
Originally Posted by Jazzmarazz
Jazzmarazz, I have a question. I have a bunch of genesis boards with batteries on them and a lot of 27c322 eproms. how do I get this to work right? it didn't seem to work as easily as getting a non sram game working. most of the boards with batteries are all different too. Is there some universal way to get 27c322 to work on any of them to make games that need save functions?
Edit: So this was once again an issue with my not remembering/fully reading things again and it was because I didn't wire A20 (pin 32) of the 27C322 to pin 5 of the 74H00 IC. Now I need to see if I can get it to save (which I haven't tested yet, but it works now)
Edit 2: After testing it a few times it doesn't seem like it's saving correctly. I think the battery is working as it reads 3v using my multimeter so I'm not sure at this point what to do as I can't find any info on save issues using 27c322
Looking back on my tutorial, that may be the problem. My statement is ambiguous as to whether the eeprom connects to pin 5 of the logic or if the cart edge connects to the logic.Quote:
Originally Posted by Lotaphi
Pin 5 of the 74xx00 is an input, not an output. So what we are doing here is connecting two inputs together - nothing happens.
http://ecx.images-amazon.com/images/I/41E6KV2dn-L.jpg
The 74xx00 is being used as a simple logic-based memory mapper comprised of only NAND gates (not and). The locations within the memory map for each IC can be determined with some logic equations. For example (not literally, but probably close):
IC_ROM = ~(CE*A20)
IC_RAM = ~CE*A20
So (still not being literal) when CE is low and A20 is low, ROM is enabled. When CE is low and A20 is high, RAM is enabled (ROM is disabled). That being said, we should be using A21 and not A20 if you want 2MBytes of ROM. A20 on the cart edge is actually A21 and 2^21 equals 2Mbytes which is split in half for each IC. The first 1Mbyte is allocated to ROM and the second 1MByte is allocated to RAM. I realize this is a bit much and difficult to explain.
What I mean to say is that I should edit my tutorial and be more clear. no one has questioned it before, so I guess it stayed incorrect for a long time. hehe
So.....
To clear everything up, first, what game are you trying to burn? How big is it? Does it only fill half of the 27c322? If the game is only 1Mbyte, we can connect pin A20 of your eeprom to ground and solve the issue. I think.
If your game is actually 2Mbytes, we will have to work a little harder.
Thanks for the info. So it seems like every game so far that I want to make is 2Mbytes unfortunately.
Ok, that's fine. What we should do is figure out how they are being mapped.
Lets start by choosing one board, looking at the 74hc00 IC and trace back all of the inputs and outputs. Please look at that diagram I posted above and write down where each pin goes:
1 - GND
2 -
3 -
4 -
5 -
6 -
7 -
8 -
9 -
10 -
11 -
12 -
13 -
14 - VCC
Then we can determine which ones to lift and rewire. It should be pretty simple if you have a multimeter with continuity checker. Some of the inputs may be bridge together and connected to address pins on the cart edge. Some may simply be connected to either vcc or gnd with the outputs floating, but we won't know until you check.
Do you know what a truth table is? It looks like so:
http://sub.allaboutcircuits.com/imag...z/02772x02.png
we will make one of our own that pertains to our project once you trace those pins for us.
So what two points am I checking for continuity for? between the 74HC00 and the sram, board connections or eprom?
I would like to know where all of the pin on the 74hc00 go:Quote:
Originally Posted by Lotaphi
1 - GND
2 -
3 -
4 -
5 -
6 -
7 -
8 -
9 -
10 -
11 -
12 -
13 -
14 - VCC
This will tell us how the board is mapping the locations of ROM and RAM, then we can modify the map for 2MBytes of ROM and keep the RAM after it.
I assume you will find cart edge pins like A21 and ~CE connecting to some of the inputs of the 7400. Some of the outputs from the 7400 will connect to ~CE of ROM and ~CE of RAM.
updated photos in original post.
Hello there.. Thanks for all the info, it has been very useful. Can I buy a Japanese phantasy star IV cartridge and put the English version on it ? Are the PCB the same? I understand there is 2 mask ROMs so how do I go about splitting the ROM to put it on 2 EPROMS? Any help would be much appreciated
You could do that if you wanted to. It is likely that you could use most any cartridge that you could find for much cheaper. Lets have a look at the game in question. According to uCON64:Quote:
Originally Posted by wal666
The information above shows that the game seems pretty typical. 24MegaBits, or 3MBytes starting at address 0x00000000 to 0x002fffff and has SRAM. However, SRAM is located at 0x00200001 to 0x00203FFF. You'll notice that SRAM overlaps with the ROM, so you'll need a slightly different cart. One such cart is descirbed in detail here:Quote:
uCON64 2.0.0 Win32 (MinGW) 1999-2005
Uses code from various people. See 'developers.html' for more!
This may be freely redistributed under the terms of the GNU Public License
C:\Users\Jordan\Desktop\Phantasy Star IV (USA).md
Magicom/BIN/RAW
00000100 53 45 47 41 20 47 45 4e 45 53 49 53 20 20 20 20 SEGA GENESIS
00000110 28 43 29 53 45 47 41 20 31 39 39 34 2e 4e 4f 56 (C)SEGA 1994.NOV
00000120 50 48 41 4e 54 41 53 59 20 53 54 41 52 20 54 68 PHANTASY STAR Th
00000130 65 20 65 6e 64 20 6f 66 20 74 68 65 20 6d 69 6c e end of the mil
00000140 6c 65 6e 6e 69 75 6d 20 20 20 20 20 20 20 20 20 lennium
00000150 50 48 41 4e 54 41 53 59 20 53 54 41 52 20 54 68 PHANTASY STAR Th
00000160 65 20 65 6e 64 20 6f 66 20 74 68 65 20 6d 69 6c e end of the mil
00000170 6c 65 6e 6e 69 75 6d 20 20 20 20 20 20 20 20 20 lennium
00000180 47 4d 20 4d 4b 2d 31 33 30 37 20 2d 30 30 05 cb GM MK-1307 -00..
00000190 4a 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 J
000001a0 00 00 00 00 00 2f ff ff 00 ff 00 00 00 ff ff ff ...../..........
000001b0 52 41 f8 20 00 20 00 01 00 20 3f ff 20 20 20 20 RA. . ... ?.
000001c0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
000001d0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
000001e0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
000001f0 34 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 4
Genesis/Sega Mega Drive/Sega CD/32X/Nomad
PHANTASY STAR The end of the millennium
Sega
Brazil
3145728 Bytes (24.0000 Mb)
Padded: Maybe, 46572 Bytes (0.3553 Mb)
Interleaved/Swapped: No
Backup unit/emulator header: No
Japanese game name: PHANTASY STAR The end of the millennium
Date: 1994.NOV
Internal size: 24.0000 Mb
ROM start: 00000000
ROM end: 002fffff
Cartridge RAM: Yes, 15 kBytes (backup)
RAM start: 00200001
RAM end: 00203fff
Product type: Game
I/O device(s): 3 Button Pad
Modem data:
Memo:
Product code: MK-1307
Version: 1.00
Checksum: Ok, 0x05cb (calculated) == 0x05cb (internal)
Checksum (CRC32): 0xfe236442
http://forums.nesdev.com/viewtopic.p...11615&start=15
So the Japanese copy would probably be easiest to mod. I don't see many carts like that one. In fact I don't have any as far as I know. if you come across another cartridge with two ROMs, one SRAM a 74ls74 and 74ls139, let me know. We can rewire it if need be.
Wow thanks for the reply. I'm not home at the moment but I'm pretty sure I have one similar (2 mask ROMs, SRAM and a couple of other chips). I will take pics when I can. Its a baseball game I think
The Story Of Thor and Phantasy Star 4 are the only 2 that have this board apparently
[ATTACH=CONFIG]48174[/ATTACH
Attachment 48175
That is world series baseball 95. According to my ROMs list this is 3mb, could this possibly be reworked?
Reworking any cart for 3MBs with no RAM is easy. Reworking a random cart to "hide" the RAM location within the ROM location is the hard part unless it has the RAM already mapped to the right location with logic.
Lets look at World Series Baseball '95 in uCON64. This time I will remove the useless info:
Comparing this game to PS4, we can see that the ROM and RAM are in fact mapped to the same locations. The SRAM included in the baseball game is much larger, but that is not a bad thing since the extra room will just be ignored.Quote:
Internal size: 24.0000 Mb
ROM start: 00000000
ROM end: 002fffff
Cartridge RAM: Yes, 63 kBytes (backup)
RAM start: 00200001
RAM end: 0020ffff
tl;dr
Yes, I think so. It looks like the lower ROM is the first 2MBytes and the higher ROM is the third MByte. Does the back of your cart look like this:
http://forums.nesdev.com/download/fi...1966&mode=view
Attachment 48178
Yes they are the same except my board has an extra chip in the top left
That extra chip should be a low power reset circuit. It disabled ram when the power is turned off so it doesn't lose save data. I think the picture I showed had the chip removed.
Awesome! So all I need to do is split the ROM into 2mb and 1mb and use a 27c160 and 27c800?
I'm confident writing the chips with gq4x. Just not sure how or where to split the ROM
Thats easy. You could use a hex editor (my fav is HxD) or you can download and configure uCON64 to do it. uCON64 is hard to configure but I still suggest it.Quote:
Originally Posted by wal666
For using HxD, open the file and click Extras > File Tools > split...
Where it says "Base name for partial files" just click on the ... button and choose your desktop and name it something. (the file (.bin) type isn't necessary since it will put numbers at the end of it)
Choose the dot for "Number consecutively"
Then use the drop down to choose MB and put in 2. Since its only 3MBs, the first file will be 2 and the last will be 1.
hit "OK"
Attachment 48179
Updated step 6 in the first post for those using the GQ-4x programmer instead of the Old Willem.
EDIT: Added a very short list of "hidden" sram games to OP.
An observation and a question here,
It seems the music is stored on the bottom ROM. I forgot to put the top ROM in and I got music and no video haha!
I used 2 27c160 eproms because that's all I had and this works!
I tried to make the image region free but wrecked it every time so I must be doing something wrong.
I entered JUE in the correct spot but how do I check checksum?
Great, so it works 100%?Quote:
Originally Posted by wal666
I use uCON64 to fix checksums, but this looks like a simpler program:
http://segaretro.org/ESE_FixCheckSum
My guess is that the graphics are stored in the upper ROM and when the console enables it, the internal pull up resistors trick the console into reading all 1's or all black for graphics. This is merely speculation, But an interesting find none the less. Actually...now that I think about it, the SNES version of Phantasy Star uses two 16-bit roms on the original japanese game. Surprisingly the translators found that the english text was stored only one ONE of the ROMs, which meant making a repro of that only needed one ROM switched. Sorry for that aside.
In any case, I changed the region for my ps4 ROM around a couple times and it seems that the header does not effect the checksum. Oddly, the game has Brazil as the only region but I ran it on my USA-only BIOS and it runs perfectly. I even went as far as to change it to Europe and it still ran on a USA BIOS. The fact that you got sound and did not change the region says something about the game: Apparently it doesn't care what the region is. :shrug: I have never come across a game like that.
Where did you edit checksum? It should be at the check-mark and not the X:
Spoiler warning:
Instead of J or U or E all the version I looked at had 4. They wouldn't run with a European Bios. Only USA. I was in a hurry so I just split and burned it anyway. YES 100% working on a genesis but not Megadrive. Savegame works and everything. I will try to region free the ROM and get it working with a European bios.
I just replaced the 4 with J and followed by UE
I edited where you showed me, checksum was OK. Still won't boot in Euro
It must one of those few games that determines Region from another location. I just tested the JAP ROM of the game on a Euro BIOS and it runs, so I am currently looking th the hex differences between the two ROMs.Quote:
Originally Posted by wal666
EDIT: So I started analyzing the hex of each ROM; J and U. I started looking at the code after the header where it starts to change. I believe that code starts running at 0x200, so the first difference from that point is at 0x358, wherein the U version performs several register compares, branch-if's and even some jump to subroutines before the code matches the J version. At 0x3F8 in Uv, the code matches the Jv at 0x359, but soon becomes different once again, but only slightly. I believe that it is around this area that the ROM is performing a region check but I am not familiar enough with 680000 op codes to hazard a guess.
Here is the extra code found in the Uv:
Code:0C B8 69 6E 69 74 FF FC 67 16 41 F8 FF 00 3E 3C 00 3F 42 98 51 CF FF FC 21 FC 69 6E 69 74 FF FC 33 FC 01 00 00 A1 11 00 08 39 00 00 00 A1 11 00 66 F6 41 F9 FF FF 00 00 3E 3C 3F BF 42 98 51 CF FF FC 4E B9 00 04 22 92 4E B9 00 04 22 A8 42 38 EC C5 48 E7 FF FE 4E B9 00 0D 00 04 4C DF 7F FF 31 FC 4E F9 EC B0 21 FC 00 00 07 58 EC B2 46 FC 21 00 4E B9 00 00 03 F8 30 38 EF 00 20 7B 00 06 4E 90 60 F4 00 04 10 3A 00 04 24 D4 00 05 17 90 00 05 19 9A 00 00 69 02 00 00 09 3A 00 00 0A C2
Another thing worth mentioning of the Uv, is that when the emulator displays the "NTSC only" message, the Pointer Counter remains in a very small loop forever. This program is located at 0x42076 - 0x4207A. Here is that code:
which translates to:Code:4A 38 EF 12 66 FA
So it looks like it is testing Register B with the data $EF12 and if it not equal, it will branch back to 0x42076 forever.Code:TST.B $EF12.W
BNE $42076
I speculate that if we could locate the main loop we could branch into that, but this is a lot of hex editing and I am not really prepared for that.
I was using Regen emulator and viewing the 680000 dump while I also had both ROMs open in H x D to view.
EDIT2:
The infinite loop taht we get stuck in is a dead end. I edited it to break the loop and the console hangs. We need to hack the hex so that we never get in this loop in the first place.
which translates to:Code:4A 38 EF 12 66 FA
I first altered the data at $EF12 to 00, so it would not be not-equal. :P - then it brokeCode:TST.B $EF12.W
BNE $42076
Then I tried to change the hex from 66FA to 67FA, which is BEQ instead of BNE. It again, broke.
Im gonna see if I can change 66FA to Jump to subroutine or Jump address and see if we can get out of the loop and continue code at 0x3
I just settler with the European ROM. Chips are soldered in now so that's how its gonna be.
One thing I noticed is that both the PAL and NTSC ROM used the numbers instead of J,U OR E.
On another note I have a database of all Genesis/Megadrive games that have saving capability as well as ROM size. I haven't sorted into different types of saving yet as I'm not 100% sure on some. It would be very helpful to the cart mod/repro community if this was made available somewhere.
Wait, there is a PAL/European ROM? All I have in my collection is a U and J version so I assumed there wasn't one. Why am I missing it? :???Quote:
Originally Posted by wal666
Could you add your PAL ROM as an attachment for me? If you click go advance, there is a little paperclip button.
That saving info would be helpful to share. From what I understand, those carts that "Hide" the RAM location are actually compatible with most any ROM that requires saving. Location of RAM is dependant on the end address of ROM, but a rewire of the highest address pins makes them all compatible. This of course excludes SSF2 and Serial eeprom-ram, but these only take up about 1% of all games and even then some of those serial eeprom games have mods to make them SRAM compatible.
Sure thing, I will upload PAL ROM when I get home. For my next endeavour I would like to try and put an English SMS Phantasy Star ROM on a genesis cartridge, I can't figure out how to enable master system mode on the Megadrive.
Haha, now thats gonna be a tough one. If you want that, you'll have to hand wire EVERY pin but I can try to help you. Not only that, but you will need one of the official mapper chips from an SMS or GG game and SRAM. If you don't have the mapper, you can only address 32KBytes of ROM and no RAM.Quote:
Originally Posted by wal666
I have only recently started exploring this kind of mod. What you want is the schematic of one of the official converters:
http://www.raphnet.net/electronique/...d/index_en.php
Raph here designed a simple passthrough based on one of the official passthrough carts. He open sourced the schematic too. Refer to the Schem: You'll notice that on the genesis side, /CART-IN and /S_RESET are both grounded. Normally only /CART-IN would be grounded. This is what I believe enables SMS mode, or z80 mode. Also A21 is pulled high and A22 is grounded. A23 is also pulled high and connected to an open button. Some of these address pins being pulled one way or the other may be associated with the pause button and not enabling SMS mode, however I cannot say which ones are which. It might just be best to follow them all.
Here is what work I have done on this project:
Attachment 48247
I haven't tested it yet, but this is my design of a Mega Drive game with the ROm of an SMS game. Currently it only supports 32KBytes ROM until I can find donors for the mapper chip. I also don't know if it works as it is untested.
EDIT: Sorry if the ROm area looks messy. I designed the cart to support a wide variety of EPROMs.
Attachment 48256
I have a few spare Master system carts with mappers.
MAPPERS I HAVE ARE
315-5235
315-5208
315-5365
Could I use SRAM from a Genesis cartridge because I have HEAPS spare
Im not scared to put the hours in to this!
I found a photo here, you'll need to use the 315-5235 mapper.Quote:
Originally Posted by wal666
http://www.smspower.org/forums/15351...USBEPROMWriter
http://www.smspower.org/forums/files...pcb_01_487.jpg
Did the SMS version of phantasy Star come out for MegaDrive too?
Yeah, any 6264 SRAM should work. Larger would work too, but you'll have to tie the higher address pins to either gnd or vcc. You can also see some extra resistors, diodes, capacitors and a transistor. I think this is for enabling/disabling the SRAM in low power mode. Do you have an extra BA6162? You can see that chip in one of those photos. It is a reset IC found on most saving-type SMD carts. That should be able to replace the extra components.
Heres the pinout of the mapper:
http://www.smspower.org/Development/MapperPinouts
Also, take a good close look at the PS for SMD in those photos. You can see which pins are connected to VCC and which are connected to GND on the cart edge.
Do you see that PLS153N, labelled "315-5342"?
That is a commercially available PLA. It looks like they mention it in taht thread too. I have to sleep now but see if you can find more info on that chip. Has the hex been dumped? They could easily be reproduced for development or flash carts so we could make ANY SMS game on SMD.
I'll have to buy myself a PS for SMD now.
Info on 315-5342
http://www.smspower.org/forums/14084...eConverterInfo