Forums

I've been trying to convert a spare Sonic 2 into a 32kbit EEPROM cart based on the little-scale blog post. I've been using a X28C256P-25 (250ns) EEPROM instead of a 27C256 EPROM because I don't want to accidentally destroy the universe by using one of the cheap erasers from China on ebay. There'll be no mapper, so I'm hoping that 32kb programs can run without changing pages. I'm using a PAL Master System II.

The cart works with certain things, but behaves very oddly otherwise. I can't link pictures yet though. :(

-

Working from Sonic 2 was a silly mistake because Sonic 2 is a 32pin rather than 28pin (I miscounted...), so I had to move some signals about. The board is 171-5507.

I also didn't have a pinout for the Sonic 2 chip pins, so I had to work backwards from the cart edge to see if enough holes matched up so that putting a 28-pin socket straight on top of it would be worth it. (According to the smsmap file which I only found after I'd done the work, this chip is MB832011)

It was mostly fine (is there a name for the standard ROM pinout layout?); I had to move some signals about, cut traces and expose vias to match the 28C256:

+5v had to be moved down two pins.
Cart !CE was moved up two pins to chip's !OE.
A14 had to be moved to the opposite side.
The 28c256 has a !WE signal that I've connected to +5 through 10k, and a !CE which I've grounded.

I didn't touch the original capacitors.

-

The first 32kbyte homebrew ROM I found, SMSPaint beta, works perfectly. (There seems to be a knack to putting the cartridge in. If I insert it completely, default Sonic comes up and waggles his finger at me, but if I lift up a couple of mm, the cart works. That's common to a lot of MS isn't it?)

Next, I tried a couple of SG1000 games (with a properly patched 7ff0-7fff), but they all hang at the SEGA logo.

I tried VDPTEST.sms and it showed a black screen, and then two columns of blue rectangles with garbage.

I tried Kunkun and Kokokun and the title screen displayed perfectly, the controls worked, but I couldn't walk more than 64 pixels to the right before my character was stopped at an invisible wall. (But not the game crashing.)

If I park the blob on the cell immediately to the right of the first descending hill, he flickers between being on the floor and being at an angle, as if the game can't decide whether or not that cell is flat floor or a / angle.

I figured that one of the address lines might be going wonky: If the level logic is malfunctioning, it might be that a read to level data at a high memory address is malfunctioning.

I wrote a short asm program that reads 16 bytes from the ROM every frame and gradually prints a hex dump. It keeps looping through the first 24 lines, so if there's an intermittent problem with the ROM reading, it should show up as unstable lines or patterns of characters. (How the program runs at all if reading from the ROM is wonky is assumed to be magic. I should really make the program self-copy into RAM or something first.) (MEKA, mednafen and Fusion all show the right output.)

At least, that was the theory.

If I make it so that it prints one hex byte every frame, the program prints unstable garbage. If I make it print one line every frame, it shows up a stable pattern of garbage (though its different on every boot). It's weird that the program seems to be running, but it doesn't like reading its own data.

I'm not used to z80 asm so my code could definitely be busted, but I'd have thought that one of the emulators would have picked that up.

Could it be a problem with ROM speed. Is my chip simply too slow? (I couldn't find much info about the correct MS rom speed, but I read that MB832011 is 250ns so my chip should be okay... though my suspect modifications might have pushed it over the edge.)

The manual action of inserting and removing the chip is taking its toll on the board too. The solder pads were coming apart from the board so it's become a bit MacGyver. Still boots SMSPaint, so I'm not giving up yet.

I'm wondering if there's a problem with leaving !CE grounded all the time. (The X28C256 datasheet doesn't show information for the behavior of the chip like that. I assumed it wouldn't touch the data lines until !OE is low.) Should I connect !CE and !OE together instead of grounding !CE?

I've seen there's been problems in the past with not using EPROMs... is the MS simply EEPROM unfriendly?

Cheers,
MrD

I'm totally talking out my ass here (never built one of these bad boys yet) but you said you have to slightly lift up the chip to get the one game to boot. Maybe one of the address lines isn't connected properly.

What's the size of your test program? Post the source so someone can analyze it and if it's also 32kb do you have to wiggle that too? I wonder when it's slightly pulled up that its omitting an address line that's not connected properly.

Lift up the whole cart I meant, not the chip itself. I think that problem is just my SMS' cart connector. I get 'SOFTWARE ERROR' when if I put normal games in too far.

I've uploaded a zip containing the stuff I was gonna link to (didn't think I could link or upload yet). It's got the test program in and some pics I was gonna link to.

The test program is really small. It's just the Hello World program edited a bit. (Unmodified Hello World does work on hardware.)

07.png and 08.png was my first attempt at making the board go. 20120525 board.jpg is how it looks after having to solder directly to the socket pins because I kinda melted the board and loosened the solder pads when desoldering.

22.png is how the cart itself looks. (Apologies to Japanese speakers if I got it wrong :) 23.png is SMS paint running. hexdump.png is a screenshot of the rom running in emulator. disasterous is how the screen looked when ran on hardware.

sms.zip (516.95 KB)

I was referring to the cart about it having to go in so much.

All your other games work properly though? Because you may want to investigate why you can't set your games in the whole way before you go any further pulling your hair trying to find out why the flash cart is failing.

!CE and !OE should rather be tied together. You should use !M0-7 for !CE

Thank you, TmEE. I'll give that a go when I get the chance. Does that way have different timing somehow? Have you wired up a cart like this before with those connections?

Thinking about it, the board I'm working from didn't originally have anything connected to !M0-7 (no trace from the cart edge at all), but the old chip was connected to A15...

Does this mean my cart is acting funny because it's responding to reads in the full 0000h-ffffh space not just 0000h-7fffh? Because the !CE is active on all reads? (This is the first bit of hardware I've modified, so it's all new to me. :)

Edit - ah you've mentioned this exact thing before in this thread.

I've tried connecting edge !M0-7 to chip !CE and edge !CE to chip !OE and there was still a screen of garbage characters.

The same if I connect edge !CE to chip !CE and edge !M0-7 to chip !OE.

I'm going to try and find a different rom chip.

Is there a proper cart testing program I can try?

Edit - I decided my own program sucks and tried ZEXALL which ran perfectly and reported all OK, and then I tried a patched Star Jacker and it worked. HERO too! Yay!

Thank you again TmEE. It was using edge !M0-7 for cart !CE that did the trick.

I think there's some VDP timing mystery that I need to fully understand before I can really program anything myself. (I read somewhere that Retrocopy handles some stuff more accurately, but it's a bit of a big download.)

Shame there's no SMS/SG1000 Super Locomotive. That would be smashing.

28c256.png (19.21 KB)

Quote

I think there's some VDP timing mystery that I need to fully understand before I can really program anything myself.

The VDP timing can seem confusing, but when programming for the SMS there are just a few pointers about VDP timing:

1. Don't write to VRAM outside of V-Blank. If you have to, then turn the screen off first (register $81 bit #6)

2. Often V-Blank processing takes so long that it continues to run into the first few lines of the next frame. To verify if this is happening, turn the screen off at the start of V-Blank and turn it off before your interrupt handler returns. If you see the top of the screen getting cut off, then you know it's taking too long.

3. If you really insist on writing to the VDP during the active display, you need to follow the delay timing discussed elsewhere (all that push/pop ix stuff).

4. Writing to registers very rapidly won't work, a small delay is needed. This never comes up outside of trying to change a lot of registers during a line interrupt, and it's easy to fix by adding enough NOPs/reshuffling code to space out the port writes more.

5. The usual pitfalls of making sure VDP access can't be interrupted by an interrupt routine that changes the VDP state. It's easy enough to wrap your code in DI/EI to solve that.

I think those are the ones that seem to catch people most frequently.

I see, thanks.

Do emulators emulate these requirements correctly?

Generally, no. I suggest you try some known-good programs while trying to troubleshoot your cart - i.e. a commercial game.

Darn. That's a blow. I was hoping to not have to prise out the eeprom for every build.

The cart works fine now. It's my own programming that's the problem. :)

There are 8 access slots per scanline in active frame, so this means you need around 28 CPU cycles between writes.
However in VBL / Passive frame you get more slots than Z80 can handle so there is no limit on how fast you can do the writes to VRAM.
You should disable VDP when VBL starts, and enable again after your VRAM transfers are done, that way you will not get any graphical corruption.
VRAM reads should be avoided as much as possible, use RAM tables or such instead.

I'm not doing anything that intense just yet. :) I'm still working on getting this hex dump thing working. I'm sure I'm doing it in the VBlank right (by coincidence, it's exactly how kunkun does it), but the output is wrong. I'd just like to write a single line of legible text...

And the answer was... the high byte of my Counter variable was uninitialised! MEKA, mednafen, Fusion and SMS Plus all seem to have initial zeroed RAM, but my real SMS 2 doesn't do that.

I changed the variable from a byte to a word at some point but for some reason didn't change its initialisation to match. It holds the current y I'm dumping text to and is used to calculate an offset into the nametable. An arbitrary value in the high byte meant that most of the time I was clobbering tile graphics data and that's why I was getting solid black tiles appearing everywhere (which I thought was weird because I don't have one of those in the tileset) and very rarely any legible text.

I was worried for a while that there'd be some awful trickiness needed in just putting some tiles on the screen in a loop!

Author	Message
MrD Joined: 25 May 2012 Posts: 22	Please help troubleshoot my EEPROM MS cartridge conversion Posted: Fri May 25, 2012 6:31 pm
MrD Joined: 25 May 2012 Posts: 22	I've been trying to convert a spare Sonic 2 into a 32kbit EEPROM cart based on the little-scale blog post. I've been using a X28C256P-25 (250ns) EEPROM instead of a 27C256 EPROM because I don't want to accidentally destroy the universe by using one of the cheap erasers from China on ebay. There'll be no mapper, so I'm hoping that 32kb programs can run without changing pages. I'm using a PAL Master System II. The cart works with certain things, but behaves very oddly otherwise. I can't link pictures yet though. :( - Working from Sonic 2 was a silly mistake because Sonic 2 is a 32pin rather than 28pin (I miscounted...), so I had to move some signals about. The board is 171-5507. I also didn't have a pinout for the Sonic 2 chip pins, so I had to work backwards from the cart edge to see if enough holes matched up so that putting a 28-pin socket straight on top of it would be worth it. (According to the smsmap file which I only found after I'd done the work, this chip is MB832011) It was mostly fine (is there a name for the standard ROM pinout layout?); I had to move some signals about, cut traces and expose vias to match the 28C256: +5v had to be moved down two pins. Cart !CE was moved up two pins to chip's !OE. A14 had to be moved to the opposite side. The 28c256 has a !WE signal that I've connected to +5 through 10k, and a !CE which I've grounded. I didn't touch the original capacitors. - The first 32kbyte homebrew ROM I found, SMSPaint beta, works perfectly. (There seems to be a knack to putting the cartridge in. If I insert it completely, default Sonic comes up and waggles his finger at me, but if I lift up a couple of mm, the cart works. That's common to a lot of MS isn't it?) Next, I tried a couple of SG1000 games (with a properly patched 7ff0-7fff), but they all hang at the SEGA logo. I tried VDPTEST.sms and it showed a black screen, and then two columns of blue rectangles with garbage. I tried Kunkun and Kokokun and the title screen displayed perfectly, the controls worked, but I couldn't walk more than 64 pixels to the right before my character was stopped at an invisible wall. (But not the game crashing.) If I park the blob on the cell immediately to the right of the first descending hill, he flickers between being on the floor and being at an angle, as if the game can't decide whether or not that cell is flat floor or a / angle. I figured that one of the address lines might be going wonky: If the level logic is malfunctioning, it might be that a read to level data at a high memory address is malfunctioning. I wrote a short asm program that reads 16 bytes from the ROM every frame and gradually prints a hex dump. It keeps looping through the first 24 lines, so if there's an intermittent problem with the ROM reading, it should show up as unstable lines or patterns of characters. (How the program runs at all if reading from the ROM is wonky is assumed to be magic. I should really make the program self-copy into RAM or something first.) (MEKA, mednafen and Fusion all show the right output.) At least, that was the theory. If I make it so that it prints one hex byte every frame, the program prints unstable garbage. If I make it print one line every frame, it shows up a stable pattern of garbage (though its different on every boot). It's weird that the program seems to be running, but it doesn't like reading its own data. I'm not used to z80 asm so my code could definitely be busted, but I'd have thought that one of the emulators would have picked that up. Could it be a problem with ROM speed. Is my chip simply too slow? (I couldn't find much info about the correct MS rom speed, but I read that MB832011 is 250ns so my chip should be okay... though my suspect modifications might have pushed it over the edge.) The manual action of inserting and removing the chip is taking its toll on the board too. The solder pads were coming apart from the board so it's become a bit MacGyver. Still boots SMSPaint, so I'm not giving up yet. I'm wondering if there's a problem with leaving !CE grounded all the time. (The X28C256 datasheet doesn't show information for the behavior of the chip like that. I assumed it wouldn't touch the data lines until !OE is low.) Should I connect !CE and !OE together instead of grounding !CE? I've seen there's been problems in the past with not using EPROMs... is the MS simply EEPROM unfriendly? Cheers, MrD

Maraakate Joined: 05 Jun 2010 Posts: 551 Location: Pennsylvania, USA	Posted: Sat May 26, 2012 1:35 am
	I'm totally talking out my ass here (never built one of these bad boys yet) but you said you have to slightly lift up the chip to get the one game to boot. Maybe one of the address lines isn't connected properly. What's the size of your test program? Post the source so someone can analyze it and if it's also 32kb do you have to wiggle that too? I wonder when it's slightly pulled up that its omitting an address line that's not connected properly.

MrD Joined: 25 May 2012 Posts: 22	Posted: Sat May 26, 2012 1:45 am
MrD Joined: 25 May 2012 Posts: 22	Lift up the whole cart I meant, not the chip itself. I think that problem is just my SMS' cart connector. I get 'SOFTWARE ERROR' when if I put normal games in too far. I've uploaded a zip containing the stuff I was gonna link to (didn't think I could link or upload yet). It's got the test program in and some pics I was gonna link to. The test program is really small. It's just the Hello World program edited a bit. (Unmodified Hello World does work on hardware.) 07.png and 08.png was my first attempt at making the board go. 20120525 board.jpg is how it looks after having to solder directly to the socket pins because I kinda melted the board and loosened the solder pads when desoldering. 22.png is how the cart itself looks. (Apologies to Japanese speakers if I got it wrong :) 23.png is SMS paint running. hexdump.png is a screenshot of the rom running in emulator. disasterous is how the screen looked when ran on hardware. sms.zip (516.95 KB)

Maraakate Joined: 05 Jun 2010 Posts: 551 Location: Pennsylvania, USA	Posted: Sat May 26, 2012 3:36 am
	I was referring to the cart about it having to go in so much. All your other games work properly though? Because you may want to investigate why you can't set your games in the whole way before you go any further pulling your hair trying to find out why the flash cart is failing.

TmEE Joined: 31 Oct 2007 Posts: 480 Location: Estonia, Rapla city	Posted: Sat May 26, 2012 7:24 pm
	!CE and !OE should rather be tied together. You should use !M0-7 for !CE

MrD Joined: 25 May 2012 Posts: 22	Posted: Sun May 27, 2012 12:24 am
MrD Joined: 25 May 2012 Posts: 22	Thank you, TmEE. I'll give that a go when I get the chance. Does that way have different timing somehow? Have you wired up a cart like this before with those connections? Thinking about it, the board I'm working from didn't originally have anything connected to !M0-7 (no trace from the cart edge at all), but the old chip was connected to A15... Does this mean my cart is acting funny because it's responding to reads in the full 0000h-ffffh space not just 0000h-7fffh? Because the !CE is active on all reads? (This is the first bit of hardware I've modified, so it's all new to me. :) Edit - ah you've mentioned this exact thing before in this thread.

MrD Joined: 25 May 2012 Posts: 22	Posted: Sun May 27, 2012 4:27 am
MrD Joined: 25 May 2012 Posts: 22	I've tried connecting edge !M0-7 to chip !CE and edge !CE to chip !OE and there was still a screen of garbage characters. The same if I connect edge !CE to chip !CE and edge !M0-7 to chip !OE. I'm going to try and find a different rom chip. Is there a proper cart testing program I can try? Edit - I decided my own program sucks and tried ZEXALL which ran perfectly and reported all OK, and then I tried a patched Star Jacker and it worked. HERO too! Yay! Thank you again TmEE. It was using edge !M0-7 for cart !CE that did the trick. I think there's some VDP timing mystery that I need to fully understand before I can really program anything myself. (I read somewhere that Retrocopy handles some stuff more accurately, but it's a bit of a big download.) Shame there's no SMS/SG1000 Super Locomotive. That would be smashing. 28c256.png (19.21 KB)

Charles MacDonald Joined: 28 Sep 1999 Posts: 1013	Posted: Tue May 29, 2012 12:17 am
Charles MacDonald Joined: 28 Sep 1999 Posts: 1013	Quote I think there's some VDP timing mystery that I need to fully understand before I can really program anything myself. The VDP timing can seem confusing, but when programming for the SMS there are just a few pointers about VDP timing: 1. Don't write to VRAM outside of V-Blank. If you have to, then turn the screen off first (register $81 bit #6) 2. Often V-Blank processing takes so long that it continues to run into the first few lines of the next frame. To verify if this is happening, turn the screen off at the start of V-Blank and turn it off before your interrupt handler returns. If you see the top of the screen getting cut off, then you know it's taking too long. 3. If you really insist on writing to the VDP during the active display, you need to follow the delay timing discussed elsewhere (all that push/pop ix stuff). 4. Writing to registers very rapidly won't work, a small delay is needed. This never comes up outside of trying to change a lot of registers during a line interrupt, and it's easy to fix by adding enough NOPs/reshuffling code to space out the port writes more. 5. The usual pitfalls of making sure VDP access can't be interrupted by an interrupt routine that changes the VDP state. It's easy enough to wrap your code in DI/EI to solve that. I think those are the ones that seem to catch people most frequently.

MrD Joined: 25 May 2012 Posts: 22	Posted: Tue May 29, 2012 2:26 am
MrD Joined: 25 May 2012 Posts: 22	I see, thanks. Do emulators emulate these requirements correctly?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 9014 Location: London	Posted: Tue May 29, 2012 6:53 am
	Generally, no. I suggest you try some known-good programs while trying to troubleshoot your cart - i.e. a commercial game.

MrD Joined: 25 May 2012 Posts: 22	Posted: Tue May 29, 2012 9:12 pm
MrD Joined: 25 May 2012 Posts: 22	Darn. That's a blow. I was hoping to not have to prise out the eeprom for every build. The cart works fine now. It's my own programming that's the problem. :)

TmEE Joined: 31 Oct 2007 Posts: 480 Location: Estonia, Rapla city	Posted: Tue May 29, 2012 9:41 pm
	There are 8 access slots per scanline in active frame, so this means you need around 28 CPU cycles between writes. However in VBL / Passive frame you get more slots than Z80 can handle so there is no limit on how fast you can do the writes to VRAM. You should disable VDP when VBL starts, and enable again after your VRAM transfers are done, that way you will not get any graphical corruption. VRAM reads should be avoided as much as possible, use RAM tables or such instead.

MrD Joined: 25 May 2012 Posts: 22	Posted: Wed May 30, 2012 6:03 am
MrD Joined: 25 May 2012 Posts: 22	I'm not doing anything that intense just yet. :) I'm still working on getting this hex dump thing working. I'm sure I'm doing it in the VBlank right (by coincidence, it's exactly how kunkun does it), but the output is wrong. I'd just like to write a single line of legible text... And the answer was... the high byte of my Counter variable was uninitialised! MEKA, mednafen, Fusion and SMS Plus all seem to have initial zeroed RAM, but my real SMS 2 doesn't do that. I changed the variable from a byte to a word at some point but for some reason didn't change its initialisation to match. It holds the current y I'm dumping text to and is used to calculate an offset into the nametable. An arbitrary value in the high byte meant that most of the time I was clobbering tile graphics data and that's why I was getting solid black tiles appearing everywhere (which I thought was weird because I don't have one of those in the tileset) and very rarely any legible text. I was worried for a while that there'd be some awful trickiness needed in just putting some tiles on the screen in a loop!

Forums

View topic - Please help troubleshoot my EEPROM MS cartridge conversion