Forums

[Admin: split from http://www.smspower.org/forums/viewtopic.php?t=14663 as discussion became technical...]

How hard would be to build a page mapper circuit? I mean, one could make his own PCB with an EEPROM (or a Flash chip) and some other component (don't know which could be suitable...)

Easier than salvaging existing carts. Under 1usd CPLD and ~1usd custom made PCB, all one needs. Shells are a different story.

TmEE wrote

Easier than salvaging existing carts. Under 1usd CPLD and ~1usd custom made PCB, all one needs. Shells are a different story.

Have the SMS mappers been drawn using logic yet?
I assume that the mappers function in a fashion where a data byte is written to a certain address and the mapper switches banks, correct? that info is probably available in software tutorials.

conveniently...

http://www.smspower.org/Development/Mappers

TmEE wrote

Easier than salvaging existing carts. Under 1usd CPLD and ~1usd custom made PCB, all one needs. Shells are a different story.

With all the rage around 3D printing nowadays, I would have thought this would be the easy part.

the price is still high. I personally 3D printed shells, but the cost is higher for the shell than the circuit. In case someone is into 3d printing, I modeled both mark 3 and export sms carts. Just ask for the models, I have no problems making them available. I'd really like if someone started a kickstarter project to get molds made in china, and produce a batch of cell sufficient to cover the mold's price.

db-electronics wrote

conveniently...

http://www.smspower.org/Development/Mappers

I knew it would be out there somewhere. :P
I am glad to have that data, since I plan on teaching myself VHDL this month and there is a community who would really appreciate it.

kamillebidan wrote

the price is still high. I personally 3D printed shells, but the cost is higher for the shell than the circuit. In case someone is into 3d printing, I modeled both mark 3 and export sms carts. Just ask for the models, I have no problems making them available. I'd really like if someone started a kickstarter project to get molds made in china, and produce a batch of cell sufficient to cover the mold's price.

Why China? You seem to be located in Japan and the majority of interest for shells seems to be in Europe. A mold would be very expensive and I don;t know if a kickstarter would bring around enough funding...but maybe. If you were able to get some quotes, then maybe.

If someone can make new PCBs with compatible mappers, to fit standard cartridge cases, they'd sell well for homebrew and reproductions. Does anyone have experience to produce such a thing, and/or sell them internationally?

I thought a 3D printed shell would cost in the region of tens of dollars due to filament prices. You can buy common loose games for a lot less.

Maxim wrote

If someone can make new PCBs with compatible mappers, to fit standard cartridge cases, they'd sell well for homebrew and reproductions. Does anyone have experience to produce such a thing, and/or sell them internationally?

I thought a 3D printed shell would cost in the region of tens of dollars due to filament prices. You can buy common loose games for a lot less.

I have reproduced several PCBs; gameboy, NES, SNES, game gear, genesis, Atari, and some I forget. I actually have a large run of Genesis PCBs being printed right now. The only thing I am missing in my portfolio is FPGA design, which I plan to learn with the Sega mapper.

If anyone has ideas, they should get in contact.

Maxim wrote

If someone can make new PCBs with compatible mappers, to fit standard cartridge cases, they'd sell well for homebrew and reproductions. Does anyone have experience to produce such a thing, and/or sell them internationally?

I can definitely do this. I'm already setup for large PCB manufacturing, and I'm also exploring PCB assembly services to automate my entire process. The mappers are not that complicated, they'll easily fit in a small CPLD - I can write and test the mappers.

Ideally, we should all standardize around one mapper configuration to keep the hardware simple (and costs down). ROM is cheap nowadays, we can easily put on a 5V 8 Mega Power flash on the repro carts.

I was already toying with this idea in the last few weeks, my approach was going to be to create a burning system, and to create repro-capable carts with surface mount flash parts - this allows for the best price possible instead of relying on old EEPROM technology and EEPROM programmers. Having a fixed cart and burning system means you can reprogram your cart pretty easily (i.e. without having to pull out any ICs).

Let's all develop this together for SMSPower!

We should probably move this discussion to the Development forum?

Jazzmarazz wrote

Why China? You seem to be located in Japan and the majority of interest for shells seems to be in Europe. A mold would be very expensive and I don;t know if a kickstarter would bring around enough funding...but maybe. If you were able to get some quotes, then maybe.

I told China only because I think it's still the place where you can get plastic stuff built at the cheapest price. Clearly, it there was an US or EU based company which makes small (few hundreds) batches for a reasonable price, that could be a better option.

I was imagining about the features that such a cart should have.
- It should support up to 4Mbit, at least... 8 even better, if possible.
- It should support both EEPROM chips and Flash chips, once more if this is possible. Supporting also original SEGA MPR would be nice too.
- The mapper chip should be compatible with all the mappers known so far. If this is impossible to do, maybe there could be some jumper/dip switch to select the mapping mode.
- The mold could have an exclusive color, such as the blue background of this forum, for example, so to clearly recognize it. Its name ('SMSPower!' sounds good) could also be engraved/bezeled on it, if that doesn't make the cost raise.
- A computer cable (USB-to-Cart?) to program the memory in it without even opening the case would be a wonderful accessory :)

Am I dreaming too much? :) I'm just sorry I have really no experience that would help in the making of it.

sverx wrote

- It should support up to 4Mbit, at least... 8 even better, if possible.

Yes, memory is cheap nowadays. We can easily support 8 MEGA POWER!

sverx wrote

- It should support both EEPROM chips and Flash chips, once more if this is possible. Supporting also original SEGA MPR would be nice too.
- The mapper chip should be compatible with all the mappers known so far. If this is impossible to do, maybe there could be some jumper/dip switch to select the mapping mode.

I think a new homebrew repro cart should be standardized to just one configuration. This helps keeps costs down. Supporting multiple configurations always ends up in only one real configuration on any given final product which equals wasted resources.

It should support the Sega Mapper up to 8 Mega Power and have the option to add save data when required. Flash is cheaper nowadays, I can design this around a 5V 8MBit Flash.

I'd like to hear from the software writers on this matter...

sverx wrote

- The mold could have an exclusive color, such as the blue background of this forum, for example, so to clearly recognize it. Its name ('SMSPower!' sounds good) could also be engraved/bezeled on it, if that doesn't make the cost raise.

I don't personally work with 3D models, but I have friends in mechanical engineering who can offer those services.

sverx wrote

- A computer cable (USB-to-Cart?) to program the memory in it without even opening the case would be a wonderful accessory :)

I disagree with this feature. I think the goal of this project is to provide a physical release to homebrew software, not a developer's reprogrammable cart; people can buy an everdrive for that. A cart that only contains the absolute necessary components for gameplay will be much more affordable.

From a design and manufacturing point of view, I much prefer a cart which plugs in to some programming hardware. The programming hardware does not need to be part of every single cart.

sverx wrote

Am I dreaming too much? :) I'm just sorry I have really no experience that would help in the making of it.

No no, it's nice to dream. Engineers like myself sometimes tend to get caught up in specs too much and forget to look at features which people really want. A discussion such as this one is absolutely necessary and helps make a better product.

db-electronics wrote

sverx wrote

- A computer cable (USB-to-Cart?) to program the memory in it without even opening the case would be a wonderful accessory :)

I disagree with this feature. I think the goal of this project is to provide a physical release to homebrew software, not a developer's reprogrammable cart; people can buy an everdrive for that. A cart that only contains the absolute necessary components for gameplay will be much more affordable.

I understand but... how can the average guy (like me with a computer and no other specific hardware) upload its homebrew/modified ROM/repro into the cart? Should I order a cart with a Flash already programmed? I don't get it, sorry :|

sverx wrote

I understand but... how can the average guy (like me with a computer and no other specific hardware) upload its homebrew/modified ROM/repro into the cart? Should I order a cart with a Flash already programmed? I don't get it, sorry :|

Just like the old days!

You should develop your game on Meka ;) or using an Everdrive - these are already very well suited for that. Once you're satisfied and you want a physical release, you can place an order for X amount of carts with your software on them. This is why I want a standardized configuration - as a manufacturer I don't have to wait for an order before I stock carts, they can all be prepared and be ready to be burned.

Why not produce a SMSPower homebrew release spec? This spec would define in what mapper configuration a game must be in order to have a physical release... yes? no? maybe?

This allows anyone with PCB skills to produce and offer homebrew burning services, prevents a monopoly, and just plain makes sense if you ask me.

That way, I can offer the service and implement the homebrew spec however I chose with ICs of my liking. Someone else can do the same as well - competition is healthy.

Ideally, the mapper would support all of the below:

- Mapping in slot 2 via writes to $ffff (needed by all Sega games over 32KB)
- Mapping in slot 1 via writes to $fffe (needed by a significant fraction of Sega games)
- Save RAM in slot 2 via writes to $fffc (save games and RAM expansion; even better to use byte-writable NVRAM if possible)
- Mapping in slots 1 and 2 via writes to $4000 and $8000 (Codemasters compatibility; although they can be modified to use the standard addresses, it'd be useful for repros)
- Mapping in slot 0 in the slightly-different Sega and Codemasters ways (used by a tiny number of games; but useful for e.g. competition multigames like the one I made last year)

Supporting just the first would be enough for almost all homebrew purposes. Homebrew tends to stick to what works in emulators, which means the Sega mapper.

I wonder if the Retrode could do the programming duties?

If this does happen, I suspect the biggest hurdle will be the minimum production run. If we have to make 500 of them, someone has to eat the initial cost and then try to sell them on. On which note, gender adaptors are still available...

Maxim wrote

If this does happen, I suspect the biggest hurdle will be the minimum production run. If we have to make 500 of them, someone has to eat the initial cost and then try to sell them on. On which note, gender adaptors are still available...

I can produce PCB runs as small as 10 units - I use this for prototyping new products. The price is reduced to about half when increased to 100 unit builds.

I will move this project to near to the top of my to do list! It doesn't look very complicated from a hardware perspective.

Maxim wrote

I wonder if the Retrode could do the programming duties?

That would mean every customer with a retrode would have the ability to wipe out the cartridge. Repros should stick with non-reprogrammable roms imho. I'm using a Retrode instead of a Megadrive, simply because I don't have one at the moment and I would hate it if I were to accidentally remove the software from my Pier Solar Cartridge.

Quote

If this does happen, I suspect the biggest hurdle will be the minimum production run. If we have to make 500 of them, someone has to eat the initial cost and then try to sell them on. On which note, gender adaptors are still available...

Even though the problem of the initial cost etc. is similar, rom-free production cartridges would be much more versatile, the manufacturer could burn it whenever ordered and can provide a large library without additional cost. That's if I understood db-electronics project correctly.

I would welcome such a thing, I know I would buy select homebrews if provided with a physical release (box and cartridge). And I'd love a service to make personalised cartridges, as in I send in a rom and receive a cartridge: there are quite a few roms that I would like to have immortalised without keeping them in an everdrive (such as the patched BIOS version of Alex Kidd with inverted buttons and hamburgers, etc.)

jarreboum wrote

I'm using a Retrode instead of a Megadrive, simply because I don't have one at the moment and I would hate it if I were to accidentally remove the software from my Pier Solar Cartridge.

You'd really need all of the planets to line up correctly in order to "accidently" overwrite a flash chip! It would be fairly easy to make it highly unlikely that the Flash is ever erased.

My first thought would be to connect the #WR of the Flash directly to pin 1 or pin 35 of the SMS cartridge port (+5V). That would make it impossible for runaway SMS code to overwrite the Flash. Also, any programming device would have to purposely omit this +5V connection and replace it with a #WR signal in order to be able to burn the Flash.

I attached a typical Flash command set, to program each and every byte you need to go through the "Program" algorithm, and so on so forth...

flash_cmd.png (47.33 KB)

db-electronics wrote

You should develop your game on Meka ;) or using an Everdrive - these are already very well suited for that.

Yes, I'm doing that of course. But when done, I would love to be able to write my stuff to the SMSPower cart myself, that's what I meant...

Maxim wrote

Ideally, the mapper would support all of the below:
- Mapping in slot 2 via writes to $ffff (needed by all Sega games over 32KB)
- Mapping in slot 1 via writes to $fffe (needed by a significant fraction of Sega games)
[...]
Supporting just the first would be enough for almost all homebrew purposes. Homebrew tends to stick to what works in emulators, which means the Sega mapper.

In my homebrew I plan on using mapping on both slot 1 & slot 2... should I change my plans or I can expect that even slot 1 mapping will be easily supported?

As for the programmer, I built a single-chip USB one, able to program a flash behind the sega mapper. I attach the files.
Both the board and the software can be surely improved. It is just a first prototype, but it works.

m3readerEagle.tgz (50.31 KB)

schematic and board layout

m3readerSw.tgz (127.46 KB)

microcontroller code

sverx wrote

In my homebrew I plan on using mapping on both slot 1 & slot 2... should I change my plans or I can expect that even slot 1 mapping will be easily supported?

The Sega Mapper isn't very complicated, when I make this happen I will fully implement it as described here: http://www.smspower.org/Development/Mappers#TheSegaMapper

kamillebidan wrote

As for the programmer, I built a single-chip USB one, able to program a flash behind the sega mapper. I attach the files.
Both the board and the software can be surely improved. It is just a first prototype, but it works.

Good work! Glad to see there will be more than one solution available.

I'm always perplexed to see DIP components on new layouts - surface mount is so much cheaper both in terms of the cost of the component and in board space!

yes,I prefer SMD as well. But when I milled this, I had just a 0.8mm endmill, nothing smaller :D

kamillebidan wrote

As for the programmer, I built a single-chip USB one, able to program a flash behind the sega mapper.

You mean that this could be used to upload a binary to the homebrew cart? That would be fantastic!

yes, I have an header exactly the same of the mark III, I unplug the cartridge from the console, plug it into the writer and change the game without any additional cables or additional external pins.

Cleary all the credits go to the SMSReader and rewritable cart documentation, as well as to Enri's page.

Certainly, a USB-connected flashing device would be a nice optional extra for the flash cart. An Everdrive is going to be preferable in most cases, though. What I think we're going for here is write-once usage of the carts.

I've previously been lead to believe that the slot 0 first 1KB remaining fixed causes a lot of complications for the mapper chip, and only a couple of games ever use it (Space Gun is one). Also, the "bank shifting" features in the documentation are based on reverse engineering of the original chips; but no games ever use them, as far as I know. So these are optional (or not even useful) extras on top of the foundation of standard mapping in the upper banks.

For boxes and cartridge shells, I think common games are the best source we have until plastic manufacturing gets a lot cheaper. See also http://www.smspower.org/forums/viewtopic.php?t=13820 where a forum member was trying to make SG-1000 cartridge cases.

Maxim wrote

Certainly, a USB-connected flashing device would be a nice optional extra for the flash cart. An Everdrive is going to be preferable in most cases, though. What I think we're going for here is write-once usage of the carts.

Of course an everdrive would be a better choice for development... what I mean is that since we're discussing about something that still doesn't exists and that will probably have a 8Mbit Flash onboard, why not imagine also to make it possible for the average user to change Flash contents? I'm not saying he should, I'm saying don't make it impossible ;)

Maxim wrote

For boxes and cartridge shells, I think common games are the best source we have until plastic manufacturing gets a lot cheaper. See also http://www.smspower.org/forums/viewtopic.php?t=13820 where a forum member was trying to make SG-1000 cartridge cases.

Wow, that's the blue color I was thinking about! :)

some really cool video footage here

Can I just add my 2 pence please.

There is a huge need for a development cart in a good case that can be rewritten. For beta-testing you may want to send carts to people and send them updated ROMs over time. An Everdrive is overpriced, overcomplicated and hardly pretty! We need something that is friendlier and a cross between development cart and distributable game.

For homebrew games we *need* SRAM. It goes without saying that non-developer players would greatly benefit from the ability for the game to save times. I'd love to add time-trialing to Sonic 1, but the mapper doesn't support 3 pages *and* SRAM, obviously. With saves readily available on new homebrew hardware we can develop longer, more feature-filled games.

Can I request that in designing the mapper, you keep it compatible with the Sega mapper (three pages), but also add the ability to page in a R/W RAM bank kept on the flash memory (or somesuch).

To solve the debate about writeable / unrwriteable, perhaps two versions could be produced with either a rewriteable flash chip or a pre-burned ROM chip plugged in and the USB-port removed, designed for mass-production. I don't know how feasible that is at all.

Kroc wrote

There is a huge need for a development cart in a good case that can be rewritten. For beta-testing you may want to send carts to people and send them updated ROMs over time. [...] We need something that is friendlier and a cross between development cart and distributable game.

I quote every single word!

Kroc wrote

To solve the debate about writeable / unrwriteable, perhaps two versions could be produced with either a rewriteable flash chip or a pre-burned ROM chip plugged in and the USB-port removed, designed for mass-production. I don't know how feasible that is at all.

I believe it's better to keep the cart very simple, so I would suggest no USB onboard. A separate USB-to-cart cable adapter would be all a developer would need, without making two separate cart versions and without add complexity to it, after all one of the original target is to send them preloaded with an homebrew game to players that won't probably never care about changing contents, right?

here is the reader/writer physical board, I guess it is difficult to reduce the number of components :)
actually in the next version I plan to add an sd, a display and a rotary encoder, to select the rom from the sd without the need to turn on the pc

image.jpg (1.45 MB)

Guys I "clonned" partially the 315-5235 back in 2001 and it went about like this:

It's that messy because there's a array of 74LS74s doing the registers (because it mimics the 315-5235 chip reset behavior of aligning the pages in sequence I had to use flipflops I could control the reset state) bits to control backup memory are implemented as well. So this thing can play Phantasy Star (and save the progress). The backup ram is not onboard at the moment, but there's a strobe in the board to control the save memory.

That design can be re-arranged in a much simpler way (by giving up of stuff like known reset state) and even further it could be simplified to a set of three to four chips if one were to re-design it using the mapping scheme the 315-5208 mapper chip uses.

Would a schematic of that thing be of interest for you guys ?

SMS_MPR_FRONT.JPG (141.26 KB)

front of the kludge

SMS_MPR_BACK.JPG (176.74 KB)

back of the kludge

l_oliveira wrote

Would a schematic of that thing be of interest for you guys ?

Yes. Yes it would. :P

I took a couple of minutes to write out the useful parts of the Sega Mapper in VHDL. Here is a functional simulation result - it doesn't show the full functionality but it's pretty demonstrative. I implemented ROM mapping in slots 0, 1 and 2. I also implemented RAM mapping (two 16K pages) in slot 2. Accesses to the first 1KB of ROM always return ROM page 0 regardless of the mapper setting.

The mapper takes inputs Address, Data, #WR and #CE from the SMS.
The mapper outputs ROMADDR1914 to the ROM, which can be thought of as a page number for the ROM.
The mapper outputs individual #CEs for the ROM and RAM on cart
The mapper outputs SRAMADDR_p, which selects one of two pages on the cart SRAM.

Quick explanation of what's going on per cycle#:

POR values - slot 0 = page 0, slot 1 = page 1, slot 2 = page 2, RAM = disabled
1 - access address 0x0000, romCE is selected, page 0 (1st 1K always page 0)
2,3 - access 1K boundary in slot 0
4 - write to mapper register 0xFFFD, set slot 0 to 0x05
5 - access 1st 1K of ROM, still returns page 0 even if slot 0 is set to page 5
6 - access 0x0400, above 1K boundary, slot 0 = page 5
7 - access start of slot 2, slot 2 = page 2 (reset value)
8 - write to ram mapper register 0xFFFC, enable RAM page 0 in slot 2
9 - access start of slot 2, now accesses RAM page 0 (SRAMADDR = 0)
10 - write to ram mapper register 0xFFFC, enable RAM page 1
11 - access start of slot 2, now accesses RAM page 1 (SRAMADDR = 1)
12 - write to ram mapper register 0xFFFC, disable RAM
13 - access start of slot 2, slot 2 = page 2

N.B. please don't pay attention to the timing values on the simulation output, I didn't bother to set real clock values as they don't really matter for a functional simulation.

mapper_sim.png (19.95 KB)

What software packages are you fond of for VHDL and the simulation? I need to get started with it myself.

Jazzmarazz wrote

What software packages are you fond of for VHDL and the simulation? I need to get started with it myself.

I do everything in Quartus, I've been using it for 10 years and I know nothing else. The simulation output I attached was generated using Quartus' built-in simulator which is OK for simple stuff. For more complex designs you really should use Modelsim.

db-electronics wrote

Jazzmarazz wrote

What software packages are you fond of for VHDL and the simulation? I need to get started with it myself.

I do everything in Quartus, I've been using it for 10 years and I know nothing else. The simulation output I attached was generated using Quartus' built-in simulator which is OK for simple stuff. For more complex designs you really should use Modelsim.

Excellent! I'm really excited to start learning...sadly I finished my undergrad before taking an FPGA course. I plan on goin back for my masters this year so I can't wait!

Jazzmarazz wrote

Excellent! I'm really excited to start learning...sadly I finished my undergrad before taking an FPGA course. I plan on goin back for my masters this year so I can't wait!

This mapper is a very good learning exercise, it's a rather simple VHDL project. When I have it tested and functioning on real hardware I will post the code; I just don't like to share anything that hasn't been tested yet. I live by: "If it's not tested then it doesn't work."

Even if I understand close to 0 all the things you're saying, I find this very interesting :)
Just my curiosity: which components will be on the PCB? I mean of course a Flash chip and a CPLD to emulate the mapper, and probably a separate chip for NVRAM... what else? And what is the cost of these components (save everything else I mean)? I'm trying to guess the total cost of one of these carts and also if it's worth or not to make some without NVRAM attached to save some components...

Would it add much complexity to emulate the Codemasters mapper too?

Some homebrew is not very copyright safe, and (for example) shipping an enhanced Sonic would be potentially troublesome. This would lead you to including a writer with the cartridge to shift responsibility onto the purchaser, but that does add a lot to the cost. On the other hand, you may not get any attention from lawyers.

db-electronics wrote

I took a couple of minutes to write out the useful parts of the Sega Mapper in VHDL. Here is a functional simulation result - it doesn't show the full functionality but it's pretty demonstrative. I implemented ROM mapping in slots 0, 1 and 2. I also implemented RAM mapping (two 16K pages) in slot 2. Accesses to the first 1KB of ROM always return ROM page 0 regardless of the mapper setting.

The mapper takes inputs Address, Data, #WR and #CE from the SMS.
The mapper outputs ROMADDR1914 to the ROM, which can be thought of as a page number for the ROM.
The mapper outputs individual #CEs for the ROM and RAM on cart
The mapper outputs SRAMADDR_p, which selects one of two pages on the cart SRAM.

Quick explanation of what's going on per cycle#:

POR values - slot 0 = page 0, slot 1 = page 1, slot 2 = page 2, RAM = disabled
1 - access address 0x0000, romCE is selected, page 0 (1st 1K always page 0)
2,3 - access 1K boundary in slot 0
4 - write to mapper register 0xFFFD, set slot 0 to 0x05
5 - access 1st 1K of ROM, still returns page 0 even if slot 0 is set to page 5
6 - access 0x0400, above 1K boundary, slot 0 = page 5
7 - access start of slot 2, slot 2 = page 2 (reset value)
8 - write to ram mapper register 0xFFFC, enable RAM page 0 in slot 2
9 - access start of slot 2, now accesses RAM page 0 (SRAMADDR = 0)
10 - write to ram mapper register 0xFFFC, enable RAM page 1
11 - access start of slot 2, now accesses RAM page 1 (SRAMADDR = 1)
12 - write to ram mapper register 0xFFFC, disable RAM
13 - access start of slot 2, slot 2 = page 2

N.B. please don't pay attention to the timing values on the simulation output, I didn't bother to set real clock values as they don't really matter for a functional simulation.

How about mapping Ram on the range $c000-$ffff. This would it add much complexity?

gvx32 wrote

How about mapping Ram on the range $c000-$ffff. This would it add much complexity?

How would one copy data from the RAM to the SRAM? It would be better to page the shadow at $E000-$FFFF, but what db-electronics has already done is still good enough (change the memory mapping from one without RAM to one with it).

There's many a good reason to allow reimaging of the cart by end-users. Copyright is one, but getting game updates is another one. Having a game bug permanently 'soldered' into a cart is not particularly nice and might put people off of wanting to by a boxed edition.

db-electronics wrote

I also implemented RAM mapping (two 16K pages) in slot 2.

I guess you just forgot of writing it, the RAM mapping should be made possible also in slot 1, if I read correctly. :)

Maxim wrote

Would it add much complexity to emulate the Codemasters mapper too?

In a previous post I was wondering the same, I believe some kind of switch would be needed since I think the codemaster mapper is incompatibile with the SEGA one and viceversa...

Kroc wrote

gvx32 wrote

How about mapping Ram on the range $c000-$ffff. This would it add much complexity?

How would one copy data from the RAM to the SRAM? It would be better to page the shadow at $E000-$FFFF, but what db-electronics has already done is still good enough (change the memory mapping from one without RAM to one with it).

There's many a good reason to allow reimaging of the cart by end-users. Copyright is one, but getting game updates is another one. Having a game bug permanently 'soldered' into a cart is not particularly nice and might put people off of wanting to by a boxed edition.

I suggest that just to be more faitfull to the definition of the sega mapper. Aldo it´s not clear what the bit 4 of register $ffff will do. According to this definition (http://www.smspower.org/Development/Mappers), it says that RAM will be mapped just in the mirror page of ram. but in the next paragraph says that when the register $ffff is set to %---111--, you will have 32KB of CARTRIDGE ram exposed in the range $8000 - $ffff.

Any way, this RAM on the cartridge would be noj just usefull to save games, but also to supply more ram when 8KB is not enought.
Since this cartridge is meant for future homebrew games, who knows how much memory a game might use.
In fact, another sugestion is to support all memory that the sega mapper is conceptualy capable of support (32 mbit). Memory is cheap now days anyway.

I

If I were not at work, I would check myself but, what is the designator of the "Sega mapper" that we are discussing. Is it not a 315-xxxx?

Maxim wrote

Would it add much complexity to emulate the Codemasters mapper too?

Some homebrew is not very copyright safe, and (for example) shipping an enhanced Sonic would be potentially troublesome. This would lead you to including a writer with the cartridge to shift responsibility onto the purchaser, but that does add a lot to the cost. On the other hand, you may not get any attention from lawyers.

I'll do the codemasters mapper as well. I just wanted to quickly show that it wasn't a very complex thing to implement.

As for copyright issues, when I do start this service it'll be for original works only at first. Whether or not we move into other territory afterwards is still an open question...

gvx32 wrote

How about mapping Ram on the range $c000-$ffff. This would it add much complexity?

I did implement this, I just didn't demonstrate it in the simulation.

If we all agree on a standard for register 0xFFFC, we can always include more pages of RAM.

gvx32 wrote

In fact, another sugestion is to support all memory that the sega mapper is conceptualy capable of support (32 mbit). Memory is cheap now days anyway.

Going larger than 8Mbit almost assuredly means going to a 3.3V part, 8Mbit just happens to be a good trade-off in terms of density, 5V availability, and pricing. Besides, how many games will actually require more than 8Mbit?

db-electronics wrote

If we all agree on a standard for register 0xFFFC, we can always include more pages of RAM.

Yes, tha would be great, but it have to be a standart that doesnt break the compatibility with the original.
How is the implementation you working on? are you mapping in the entire "slot 3", or just in the mirror ram?

db-electronics wrote

Going larger than 8Mbit almost assuredly means going to a 3.3V part, 8Mbit just happens to be a good trade-off in terms of density, 5V availability, and pricing. Besides, how many games will actually require more than 8Mbit?

How about using more than one 8Mbit rom? The selector could be implemented in VHDL as a part of the mapper.

Micron makes new 16MBit 5V Flashes (for automotive industry)

Author	Message
sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	SMS Homebrew Carts Posted: Sun Mar 16, 2014 10:56 pm
	[Admin: split from http://www.smspower.org/forums/viewtopic.php?t=14663 as discussion became technical...] How hard would be to build a page mapper circuit? I mean, one could make his own PCB with an EEPROM (or a Flash chip) and some other component (don't know which could be suitable...)

TmEE Joined: 31 Oct 2007 Posts: 853 Location: Estonia, Rapla city	Posted: Mon Mar 17, 2014 4:05 pm
	Easier than salvaging existing carts. Under 1usd CPLD and ~1usd custom made PCB, all one needs. Shells are a different story.

Jazzmarazz Joined: 17 Sep 2013 Posts: 140 Location: TC, MI	Posted: Mon Mar 17, 2014 10:57 pm
	TmEE wrote Easier than salvaging existing carts. Under 1usd CPLD and ~1usd custom made PCB, all one needs. Shells are a different story. Have the SMS mappers been drawn using logic yet? I assume that the mappers function in a fashion where a data byte is written to a certain address and the mapper switches banks, correct? that info is probably available in software tutorials.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Tue Mar 18, 2014 1:37 am
	conveniently... http://www.smspower.org/Development/Mappers

jarreboum Joined: 11 Mar 2014 Posts: 91 Location: France	Posted: Tue Mar 18, 2014 5:03 pm
jarreboum Joined: 11 Mar 2014 Posts: 91 Location: France	TmEE wrote Easier than salvaging existing carts. Under 1usd CPLD and ~1usd custom made PCB, all one needs. Shells are a different story. With all the rage around 3D printing nowadays, I would have thought this would be the easy part.

kamillebidan Joined: 25 Feb 2013 Posts: 384 Location: Osaka	Posted: Tue Mar 18, 2014 6:08 pm
	the price is still high. I personally 3D printed shells, but the cost is higher for the shell than the circuit. In case someone is into 3d printing, I modeled both mark 3 and export sms carts. Just ask for the models, I have no problems making them available. I'd really like if someone started a kickstarter project to get molds made in china, and produce a batch of cell sufficient to cover the mold's price.

Jazzmarazz Joined: 17 Sep 2013 Posts: 140 Location: TC, MI	Posted: Tue Mar 18, 2014 6:32 pm
	db-electronics wrote conveniently... http://www.smspower.org/Development/Mappers I knew it would be out there somewhere. :P I am glad to have that data, since I plan on teaching myself VHDL this month and there is a community who would really appreciate it. kamillebidan wrote the price is still high. I personally 3D printed shells, but the cost is higher for the shell than the circuit. In case someone is into 3d printing, I modeled both mark 3 and export sms carts. Just ask for the models, I have no problems making them available. I'd really like if someone started a kickstarter project to get molds made in china, and produce a batch of cell sufficient to cover the mold's price. Why China? You seem to be located in Japan and the majority of interest for shells seems to be in Europe. A mold would be very expensive and I don;t know if a kickstarter would bring around enough funding...but maybe. If you were able to get some quotes, then maybe.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Tue Mar 18, 2014 7:16 pm
	If someone can make new PCBs with compatible mappers, to fit standard cartridge cases, they'd sell well for homebrew and reproductions. Does anyone have experience to produce such a thing, and/or sell them internationally? I thought a 3D printed shell would cost in the region of tens of dollars due to filament prices. You can buy common loose games for a lot less.

Jazzmarazz Joined: 17 Sep 2013 Posts: 140 Location: TC, MI	Posted: Tue Mar 18, 2014 7:36 pm
	Maxim wrote If someone can make new PCBs with compatible mappers, to fit standard cartridge cases, they'd sell well for homebrew and reproductions. Does anyone have experience to produce such a thing, and/or sell them internationally? I thought a 3D printed shell would cost in the region of tens of dollars due to filament prices. You can buy common loose games for a lot less. I have reproduced several PCBs; gameboy, NES, SNES, game gear, genesis, Atari, and some I forget. I actually have a large run of Genesis PCBs being printed right now. The only thing I am missing in my portfolio is FPGA design, which I plan to learn with the Sega mapper. If anyone has ideas, they should get in contact.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Tue Mar 18, 2014 8:47 pm
	Maxim wrote If someone can make new PCBs with compatible mappers, to fit standard cartridge cases, they'd sell well for homebrew and reproductions. Does anyone have experience to produce such a thing, and/or sell them internationally? I can definitely do this. I'm already setup for large PCB manufacturing, and I'm also exploring PCB assembly services to automate my entire process. The mappers are not that complicated, they'll easily fit in a small CPLD - I can write and test the mappers. Ideally, we should all standardize around one mapper configuration to keep the hardware simple (and costs down). ROM is cheap nowadays, we can easily put on a 5V 8 Mega Power flash on the repro carts. I was already toying with this idea in the last few weeks, my approach was going to be to create a burning system, and to create repro-capable carts with surface mount flash parts - this allows for the best price possible instead of relying on old EEPROM technology and EEPROM programmers. Having a fixed cart and burning system means you can reprogram your cart pretty easily (i.e. without having to pull out any ICs). Let's all develop this together for SMSPower! We should probably move this discussion to the Development forum?

kamillebidan Joined: 25 Feb 2013 Posts: 384 Location: Osaka	Posted: Wed Mar 19, 2014 6:39 am
	Jazzmarazz wrote Why China? You seem to be located in Japan and the majority of interest for shells seems to be in Europe. A mold would be very expensive and I don;t know if a kickstarter would bring around enough funding...but maybe. If you were able to get some quotes, then maybe. I told China only because I think it's still the place where you can get plastic stuff built at the cheapest price. Clearly, it there was an US or EU based company which makes small (few hundreds) batches for a reasonable price, that could be a better option.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Mar 19, 2014 8:34 am
	I was imagining about the features that such a cart should have. - It should support up to 4Mbit, at least... 8 even better, if possible. - It should support both EEPROM chips and Flash chips, once more if this is possible. Supporting also original SEGA MPR would be nice too. - The mapper chip should be compatible with all the mappers known so far. If this is impossible to do, maybe there could be some jumper/dip switch to select the mapping mode. - The mold could have an exclusive color, such as the blue background of this forum, for example, so to clearly recognize it. Its name ('SMSPower!' sounds good) could also be engraved/bezeled on it, if that doesn't make the cost raise. - A computer cable (USB-to-Cart?) to program the memory in it without even opening the case would be a wonderful accessory :) Am I dreaming too much? :) I'm just sorry I have really no experience that would help in the making of it.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Wed Mar 19, 2014 12:55 pm
	sverx wrote - It should support up to 4Mbit, at least... 8 even better, if possible. Yes, memory is cheap nowadays. We can easily support 8 MEGA POWER! sverx wrote - It should support both EEPROM chips and Flash chips, once more if this is possible. Supporting also original SEGA MPR would be nice too. - The mapper chip should be compatible with all the mappers known so far. If this is impossible to do, maybe there could be some jumper/dip switch to select the mapping mode. I think a new homebrew repro cart should be standardized to just one configuration. This helps keeps costs down. Supporting multiple configurations always ends up in only one real configuration on any given final product which equals wasted resources. It should support the Sega Mapper up to 8 Mega Power and have the option to add save data when required. Flash is cheaper nowadays, I can design this around a 5V 8MBit Flash. I'd like to hear from the software writers on this matter... sverx wrote - The mold could have an exclusive color, such as the blue background of this forum, for example, so to clearly recognize it. Its name ('SMSPower!' sounds good) could also be engraved/bezeled on it, if that doesn't make the cost raise. I don't personally work with 3D models, but I have friends in mechanical engineering who can offer those services. sverx wrote - A computer cable (USB-to-Cart?) to program the memory in it without even opening the case would be a wonderful accessory :) I disagree with this feature. I think the goal of this project is to provide a physical release to homebrew software, not a developer's reprogrammable cart; people can buy an everdrive for that. A cart that only contains the absolute necessary components for gameplay will be much more affordable. From a design and manufacturing point of view, I much prefer a cart which plugs in to some programming hardware. The programming hardware does not need to be part of every single cart. sverx wrote Am I dreaming too much? :) I'm just sorry I have really no experience that would help in the making of it. No no, it's nice to dream. Engineers like myself sometimes tend to get caught up in specs too much and forget to look at features which people really want. A discussion such as this one is absolutely necessary and helps make a better product.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Mar 19, 2014 1:16 pm
	db-electronics wrote sverx wrote - A computer cable (USB-to-Cart?) to program the memory in it without even opening the case would be a wonderful accessory :) I disagree with this feature. I think the goal of this project is to provide a physical release to homebrew software, not a developer's reprogrammable cart; people can buy an everdrive for that. A cart that only contains the absolute necessary components for gameplay will be much more affordable. I understand but... how can the average guy (like me with a computer and no other specific hardware) upload its homebrew/modified ROM/repro into the cart? Should I order a cart with a Flash already programmed? I don't get it, sorry :\|

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Wed Mar 19, 2014 1:22 pm
	sverx wrote I understand but... how can the average guy (like me with a computer and no other specific hardware) upload its homebrew/modified ROM/repro into the cart? Should I order a cart with a Flash already programmed? I don't get it, sorry :\| Just like the old days! You should develop your game on Meka ;) or using an Everdrive - these are already very well suited for that. Once you're satisfied and you want a physical release, you can place an order for X amount of carts with your software on them. This is why I want a standardized configuration - as a manufacturer I don't have to wait for an order before I stock carts, they can all be prepared and be ready to be burned.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Wed Mar 19, 2014 1:25 pm
	Why not produce a SMSPower homebrew release spec? This spec would define in what mapper configuration a game must be in order to have a physical release... yes? no? maybe? This allows anyone with PCB skills to produce and offer homebrew burning services, prevents a monopoly, and just plain makes sense if you ask me. That way, I can offer the service and implement the homebrew spec however I chose with ICs of my liking. Someone else can do the same as well - competition is healthy.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Wed Mar 19, 2014 1:41 pm
	Ideally, the mapper would support all of the below: - Mapping in slot 2 via writes to $ffff (needed by all Sega games over 32KB) - Mapping in slot 1 via writes to $fffe (needed by a significant fraction of Sega games) - Save RAM in slot 2 via writes to $fffc (save games and RAM expansion; even better to use byte-writable NVRAM if possible) - Mapping in slots 1 and 2 via writes to $4000 and $8000 (Codemasters compatibility; although they can be modified to use the standard addresses, it'd be useful for repros) - Mapping in slot 0 in the slightly-different Sega and Codemasters ways (used by a tiny number of games; but useful for e.g. competition multigames like the one I made last year) Supporting just the first would be enough for almost all homebrew purposes. Homebrew tends to stick to what works in emulators, which means the Sega mapper. I wonder if the Retrode could do the programming duties? If this does happen, I suspect the biggest hurdle will be the minimum production run. If we have to make 500 of them, someone has to eat the initial cost and then try to sell them on. On which note, gender adaptors are still available...

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Wed Mar 19, 2014 2:16 pm
	Maxim wrote If this does happen, I suspect the biggest hurdle will be the minimum production run. If we have to make 500 of them, someone has to eat the initial cost and then try to sell them on. On which note, gender adaptors are still available... I can produce PCB runs as small as 10 units - I use this for prototyping new products. The price is reduced to about half when increased to 100 unit builds. I will move this project to near to the top of my to do list! It doesn't look very complicated from a hardware perspective.

jarreboum Joined: 11 Mar 2014 Posts: 91 Location: France	Posted: Wed Mar 19, 2014 2:29 pm
jarreboum Joined: 11 Mar 2014 Posts: 91 Location: France	Maxim wrote I wonder if the Retrode could do the programming duties? That would mean every customer with a retrode would have the ability to wipe out the cartridge. Repros should stick with non-reprogrammable roms imho. I'm using a Retrode instead of a Megadrive, simply because I don't have one at the moment and I would hate it if I were to accidentally remove the software from my Pier Solar Cartridge. Quote If this does happen, I suspect the biggest hurdle will be the minimum production run. If we have to make 500 of them, someone has to eat the initial cost and then try to sell them on. On which note, gender adaptors are still available... Even though the problem of the initial cost etc. is similar, rom-free production cartridges would be much more versatile, the manufacturer could burn it whenever ordered and can provide a large library without additional cost. That's if I understood db-electronics project correctly. I would welcome such a thing, I know I would buy select homebrews if provided with a physical release (box and cartridge). And I'd love a service to make personalised cartridges, as in I send in a rom and receive a cartridge: there are quite a few roms that I would like to have immortalised without keeping them in an everdrive (such as the patched BIOS version of Alex Kidd with inverted buttons and hamburgers, etc.)

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Wed Mar 19, 2014 2:46 pm
	jarreboum wrote I'm using a Retrode instead of a Megadrive, simply because I don't have one at the moment and I would hate it if I were to accidentally remove the software from my Pier Solar Cartridge. You'd really need all of the planets to line up correctly in order to "accidently" overwrite a flash chip! It would be fairly easy to make it highly unlikely that the Flash is ever erased. My first thought would be to connect the #WR of the Flash directly to pin 1 or pin 35 of the SMS cartridge port (+5V). That would make it impossible for runaway SMS code to overwrite the Flash. Also, any programming device would have to purposely omit this +5V connection and replace it with a #WR signal in order to be able to burn the Flash. I attached a typical Flash command set, to program each and every byte you need to go through the "Program" algorithm, and so on so forth... flash_cmd.png (47.33 KB)

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Mar 19, 2014 2:49 pm
	db-electronics wrote You should develop your game on Meka ;) or using an Everdrive - these are already very well suited for that. Yes, I'm doing that of course. But when done, I would love to be able to write my stuff to the SMSPower cart myself, that's what I meant... Maxim wrote Ideally, the mapper would support all of the below: - Mapping in slot 2 via writes to $ffff (needed by all Sega games over 32KB) - Mapping in slot 1 via writes to $fffe (needed by a significant fraction of Sega games) [...] Supporting just the first would be enough for almost all homebrew purposes. Homebrew tends to stick to what works in emulators, which means the Sega mapper. In my homebrew I plan on using mapping on both slot 1 & slot 2... should I change my plans or I can expect that even slot 1 mapping will be easily supported?

kamillebidan Joined: 25 Feb 2013 Posts: 384 Location: Osaka	Posted: Wed Mar 19, 2014 2:52 pm
	As for the programmer, I built a single-chip USB one, able to program a flash behind the sega mapper. I attach the files. Both the board and the software can be surely improved. It is just a first prototype, but it works. m3readerEagle.tgz (50.31 KB) schematic and board layout m3readerSw.tgz (127.46 KB) microcontroller code

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Wed Mar 19, 2014 2:54 pm
	sverx wrote In my homebrew I plan on using mapping on both slot 1 & slot 2... should I change my plans or I can expect that even slot 1 mapping will be easily supported? The Sega Mapper isn't very complicated, when I make this happen I will fully implement it as described here: http://www.smspower.org/Development/Mappers#TheSegaMapper

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Wed Mar 19, 2014 3:10 pm
	kamillebidan wrote As for the programmer, I built a single-chip USB one, able to program a flash behind the sega mapper. I attach the files. Both the board and the software can be surely improved. It is just a first prototype, but it works. Good work! Glad to see there will be more than one solution available. I'm always perplexed to see DIP components on new layouts - surface mount is so much cheaper both in terms of the cost of the component and in board space!

kamillebidan Joined: 25 Feb 2013 Posts: 384 Location: Osaka	Posted: Wed Mar 19, 2014 3:12 pm
	yes,I prefer SMD as well. But when I milled this, I had just a 0.8mm endmill, nothing smaller :D

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Mar 19, 2014 4:06 pm
	kamillebidan wrote As for the programmer, I built a single-chip USB one, able to program a flash behind the sega mapper. You mean that this could be used to upload a binary to the homebrew cart? That would be fantastic!

kamillebidan Joined: 25 Feb 2013 Posts: 384 Location: Osaka	Posted: Wed Mar 19, 2014 4:17 pm
	yes, I have an header exactly the same of the mark III, I unplug the cartridge from the console, plug it into the writer and change the game without any additional cables or additional external pins. Cleary all the credits go to the SMSReader and rewritable cart documentation, as well as to Enri's page.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Wed Mar 19, 2014 4:24 pm
	Certainly, a USB-connected flashing device would be a nice optional extra for the flash cart. An Everdrive is going to be preferable in most cases, though. What I think we're going for here is write-once usage of the carts. I've previously been lead to believe that the slot 0 first 1KB remaining fixed causes a lot of complications for the mapper chip, and only a couple of games ever use it (Space Gun is one). Also, the "bank shifting" features in the documentation are based on reverse engineering of the original chips; but no games ever use them, as far as I know. So these are optional (or not even useful) extras on top of the foundation of standard mapping in the upper banks. For boxes and cartridge shells, I think common games are the best source we have until plastic manufacturing gets a lot cheaper. See also http://www.smspower.org/forums/viewtopic.php?t=13820 where a forum member was trying to make SG-1000 cartridge cases.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Mar 19, 2014 4:41 pm
	Maxim wrote Certainly, a USB-connected flashing device would be a nice optional extra for the flash cart. An Everdrive is going to be preferable in most cases, though. What I think we're going for here is write-once usage of the carts. Of course an everdrive would be a better choice for development... what I mean is that since we're discussing about something that still doesn't exists and that will probably have a 8Mbit Flash onboard, why not imagine also to make it possible for the average user to change Flash contents? I'm not saying he should, I'm saying don't make it impossible ;) Maxim wrote For boxes and cartridge shells, I think common games are the best source we have until plastic manufacturing gets a lot cheaper. See also http://www.smspower.org/forums/viewtopic.php?t=13820 where a forum member was trying to make SG-1000 cartridge cases. Wow, that's the blue color I was thinking about! :)

kamillebidan Joined: 25 Feb 2013 Posts: 384 Location: Osaka	Posted: Wed Mar 19, 2014 5:14 pm
	some really cool video footage here

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Wed Mar 19, 2014 6:13 pm
Kroc Joined: 08 Dec 2013 Posts: 200	Can I just add my 2 pence please. There is a huge need for a development cart in a good case that can be rewritten. For beta-testing you may want to send carts to people and send them updated ROMs over time. An Everdrive is overpriced, overcomplicated and hardly pretty! We need something that is friendlier and a cross between development cart and distributable game. For homebrew games we need SRAM. It goes without saying that non-developer players would greatly benefit from the ability for the game to save times. I'd love to add time-trialing to Sonic 1, but the mapper doesn't support 3 pages and SRAM, obviously. With saves readily available on new homebrew hardware we can develop longer, more feature-filled games. Can I request that in designing the mapper, you keep it compatible with the Sega mapper (three pages), but also add the ability to page in a R/W RAM bank kept on the flash memory (or somesuch). To solve the debate about writeable / unrwriteable, perhaps two versions could be produced with either a rewriteable flash chip or a pre-burned ROM chip plugged in and the USB-port removed, designed for mass-production. I don't know how feasible that is at all.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Mar 19, 2014 6:55 pm
	Kroc wrote There is a huge need for a development cart in a good case that can be rewritten. For beta-testing you may want to send carts to people and send them updated ROMs over time. [...] We need something that is friendlier and a cross between development cart and distributable game. I quote every single word! Kroc wrote To solve the debate about writeable / unrwriteable, perhaps two versions could be produced with either a rewriteable flash chip or a pre-burned ROM chip plugged in and the USB-port removed, designed for mass-production. I don't know how feasible that is at all. I believe it's better to keep the cart very simple, so I would suggest no USB onboard. A separate USB-to-cart cable adapter would be all a developer would need, without making two separate cart versions and without add complexity to it, after all one of the original target is to send them preloaded with an homebrew game to players that won't probably never care about changing contents, right?

kamillebidan Joined: 25 Feb 2013 Posts: 384 Location: Osaka	Posted: Wed Mar 19, 2014 8:41 pm
	here is the reader/writer physical board, I guess it is difficult to reduce the number of components :) actually in the next version I plan to add an sd, a display and a rotary encoder, to select the rom from the sd without the need to turn on the pc image.jpg (1.45 MB)

l_oliveira Joined: 29 Jan 2014 Posts: 95 Location: Brasilia, Brazil	Posted: Wed Mar 19, 2014 9:50 pm
	Guys I "clonned" partially the 315-5235 back in 2001 and it went about like this: It's that messy because there's a array of 74LS74s doing the registers (because it mimics the 315-5235 chip reset behavior of aligning the pages in sequence I had to use flipflops I could control the reset state) bits to control backup memory are implemented as well. So this thing can play Phantasy Star (and save the progress). The backup ram is not onboard at the moment, but there's a strobe in the board to control the save memory. That design can be re-arranged in a much simpler way (by giving up of stuff like known reset state) and even further it could be simplified to a set of three to four chips if one were to re-design it using the mapping scheme the 315-5208 mapper chip uses. Would a schematic of that thing be of interest for you guys ? SMS_MPR_FRONT.JPG (141.26 KB) front of the kludge SMS_MPR_BACK.JPG (176.74 KB) back of the kludge

Jazzmarazz Joined: 17 Sep 2013 Posts: 140 Location: TC, MI	Posted: Wed Mar 19, 2014 9:54 pm
	l_oliveira wrote Would a schematic of that thing be of interest for you guys ? Yes. Yes it would. :P

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Thu Mar 20, 2014 1:00 am
	I took a couple of minutes to write out the useful parts of the Sega Mapper in VHDL. Here is a functional simulation result - it doesn't show the full functionality but it's pretty demonstrative. I implemented ROM mapping in slots 0, 1 and 2. I also implemented RAM mapping (two 16K pages) in slot 2. Accesses to the first 1KB of ROM always return ROM page 0 regardless of the mapper setting. The mapper takes inputs Address, Data, #WR and #CE from the SMS. The mapper outputs ROMADDR1914 to the ROM, which can be thought of as a page number for the ROM. The mapper outputs individual #CEs for the ROM and RAM on cart The mapper outputs SRAMADDR_p, which selects one of two pages on the cart SRAM. Quick explanation of what's going on per cycle#: POR values - slot 0 = page 0, slot 1 = page 1, slot 2 = page 2, RAM = disabled 1 - access address 0x0000, romCE is selected, page 0 (1st 1K always page 0) 2,3 - access 1K boundary in slot 0 4 - write to mapper register 0xFFFD, set slot 0 to 0x05 5 - access 1st 1K of ROM, still returns page 0 even if slot 0 is set to page 5 6 - access 0x0400, above 1K boundary, slot 0 = page 5 7 - access start of slot 2, slot 2 = page 2 (reset value) 8 - write to ram mapper register 0xFFFC, enable RAM page 0 in slot 2 9 - access start of slot 2, now accesses RAM page 0 (SRAMADDR = 0) 10 - write to ram mapper register 0xFFFC, enable RAM page 1 11 - access start of slot 2, now accesses RAM page 1 (SRAMADDR = 1) 12 - write to ram mapper register 0xFFFC, disable RAM 13 - access start of slot 2, slot 2 = page 2 N.B. please don't pay attention to the timing values on the simulation output, I didn't bother to set real clock values as they don't really matter for a functional simulation. mapper_sim.png (19.95 KB)

Jazzmarazz Joined: 17 Sep 2013 Posts: 140 Location: TC, MI	Posted: Thu Mar 20, 2014 3:43 am
	What software packages are you fond of for VHDL and the simulation? I need to get started with it myself.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Thu Mar 20, 2014 3:46 am
	Jazzmarazz wrote What software packages are you fond of for VHDL and the simulation? I need to get started with it myself. I do everything in Quartus, I've been using it for 10 years and I know nothing else. The simulation output I attached was generated using Quartus' built-in simulator which is OK for simple stuff. For more complex designs you really should use Modelsim.

Jazzmarazz Joined: 17 Sep 2013 Posts: 140 Location: TC, MI	Posted: Thu Mar 20, 2014 4:04 am
	db-electronics wrote Jazzmarazz wrote What software packages are you fond of for VHDL and the simulation? I need to get started with it myself. I do everything in Quartus, I've been using it for 10 years and I know nothing else. The simulation output I attached was generated using Quartus' built-in simulator which is OK for simple stuff. For more complex designs you really should use Modelsim. Excellent! I'm really excited to start learning...sadly I finished my undergrad before taking an FPGA course. I plan on goin back for my masters this year so I can't wait!

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Thu Mar 20, 2014 4:11 am
	Jazzmarazz wrote Excellent! I'm really excited to start learning...sadly I finished my undergrad before taking an FPGA course. I plan on goin back for my masters this year so I can't wait! This mapper is a very good learning exercise, it's a rather simple VHDL project. When I have it tested and functioning on real hardware I will post the code; I just don't like to share anything that hasn't been tested yet. I live by: "If it's not tested then it doesn't work."

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Thu Mar 20, 2014 8:44 am
	Even if I understand close to 0 all the things you're saying, I find this very interesting :) Just my curiosity: which components will be on the PCB? I mean of course a Flash chip and a CPLD to emulate the mapper, and probably a separate chip for NVRAM... what else? And what is the cost of these components (save everything else I mean)? I'm trying to guess the total cost of one of these carts and also if it's worth or not to make some without NVRAM attached to save some components...

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Thu Mar 20, 2014 10:16 am
	Would it add much complexity to emulate the Codemasters mapper too? Some homebrew is not very copyright safe, and (for example) shipping an enhanced Sonic would be potentially troublesome. This would lead you to including a writer with the cartridge to shift responsibility onto the purchaser, but that does add a lot to the cost. On the other hand, you may not get any attention from lawyers.

gvx32 Joined: 17 Sep 2013 Posts: 128 Location: Gravataí, RS, Brazil	Posted: Thu Mar 20, 2014 11:32 am
	db-electronics wrote I took a couple of minutes to write out the useful parts of the Sega Mapper in VHDL. Here is a functional simulation result - it doesn't show the full functionality but it's pretty demonstrative. I implemented ROM mapping in slots 0, 1 and 2. I also implemented RAM mapping (two 16K pages) in slot 2. Accesses to the first 1KB of ROM always return ROM page 0 regardless of the mapper setting. The mapper takes inputs Address, Data, #WR and #CE from the SMS. The mapper outputs ROMADDR1914 to the ROM, which can be thought of as a page number for the ROM. The mapper outputs individual #CEs for the ROM and RAM on cart The mapper outputs SRAMADDR_p, which selects one of two pages on the cart SRAM. Quick explanation of what's going on per cycle#: POR values - slot 0 = page 0, slot 1 = page 1, slot 2 = page 2, RAM = disabled 1 - access address 0x0000, romCE is selected, page 0 (1st 1K always page 0) 2,3 - access 1K boundary in slot 0 4 - write to mapper register 0xFFFD, set slot 0 to 0x05 5 - access 1st 1K of ROM, still returns page 0 even if slot 0 is set to page 5 6 - access 0x0400, above 1K boundary, slot 0 = page 5 7 - access start of slot 2, slot 2 = page 2 (reset value) 8 - write to ram mapper register 0xFFFC, enable RAM page 0 in slot 2 9 - access start of slot 2, now accesses RAM page 0 (SRAMADDR = 0) 10 - write to ram mapper register 0xFFFC, enable RAM page 1 11 - access start of slot 2, now accesses RAM page 1 (SRAMADDR = 1) 12 - write to ram mapper register 0xFFFC, disable RAM 13 - access start of slot 2, slot 2 = page 2 N.B. please don't pay attention to the timing values on the simulation output, I didn't bother to set real clock values as they don't really matter for a functional simulation. How about mapping Ram on the range $c000-$ffff. This would it add much complexity?

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Thu Mar 20, 2014 11:46 am
Kroc Joined: 08 Dec 2013 Posts: 200	gvx32 wrote How about mapping Ram on the range $c000-$ffff. This would it add much complexity? How would one copy data from the RAM to the SRAM? It would be better to page the shadow at $E000-$FFFF, but what db-electronics has already done is still good enough (change the memory mapping from one without RAM to one with it). There's many a good reason to allow reimaging of the cart by end-users. Copyright is one, but getting game updates is another one. Having a game bug permanently 'soldered' into a cart is not particularly nice and might put people off of wanting to by a boxed edition.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Thu Mar 20, 2014 12:32 pm
	db-electronics wrote I also implemented RAM mapping (two 16K pages) in slot 2. I guess you just forgot of writing it, the RAM mapping should be made possible also in slot 1, if I read correctly. :) Maxim wrote Would it add much complexity to emulate the Codemasters mapper too? In a previous post I was wondering the same, I believe some kind of switch would be needed since I think the codemaster mapper is incompatibile with the SEGA one and viceversa...

gvx32 Joined: 17 Sep 2013 Posts: 128 Location: Gravataí, RS, Brazil	Posted: Thu Mar 20, 2014 1:10 pm
	Kroc wrote gvx32 wrote How about mapping Ram on the range $c000-$ffff. This would it add much complexity? How would one copy data from the RAM to the SRAM? It would be better to page the shadow at $E000-$FFFF, but what db-electronics has already done is still good enough (change the memory mapping from one without RAM to one with it). There's many a good reason to allow reimaging of the cart by end-users. Copyright is one, but getting game updates is another one. Having a game bug permanently 'soldered' into a cart is not particularly nice and might put people off of wanting to by a boxed edition. I suggest that just to be more faitfull to the definition of the sega mapper. Aldo it´s not clear what the bit 4 of register $ffff will do. According to this definition (http://www.smspower.org/Development/Mappers), it says that RAM will be mapped just in the mirror page of ram. but in the next paragraph says that when the register $ffff is set to %---111--, you will have 32KB of CARTRIDGE ram exposed in the range $8000 - $ffff. Any way, this RAM on the cartridge would be noj just usefull to save games, but also to supply more ram when 8KB is not enought. Since this cartridge is meant for future homebrew games, who knows how much memory a game might use. In fact, another sugestion is to support all memory that the sega mapper is conceptualy capable of support (32 mbit). Memory is cheap now days anyway. I

Jazzmarazz Joined: 17 Sep 2013 Posts: 140 Location: TC, MI	Posted: Thu Mar 20, 2014 1:47 pm
	If I were not at work, I would check myself but, what is the designator of the "Sega mapper" that we are discussing. Is it not a 315-xxxx?

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Thu Mar 20, 2014 5:55 pm
	Maxim wrote Would it add much complexity to emulate the Codemasters mapper too? Some homebrew is not very copyright safe, and (for example) shipping an enhanced Sonic would be potentially troublesome. This would lead you to including a writer with the cartridge to shift responsibility onto the purchaser, but that does add a lot to the cost. On the other hand, you may not get any attention from lawyers. I'll do the codemasters mapper as well. I just wanted to quickly show that it wasn't a very complex thing to implement. As for copyright issues, when I do start this service it'll be for original works only at first. Whether or not we move into other territory afterwards is still an open question... gvx32 wrote How about mapping Ram on the range $c000-$ffff. This would it add much complexity? I did implement this, I just didn't demonstrate it in the simulation. If we all agree on a standard for register 0xFFFC, we can always include more pages of RAM. gvx32 wrote In fact, another sugestion is to support all memory that the sega mapper is conceptualy capable of support (32 mbit). Memory is cheap now days anyway. Going larger than 8Mbit almost assuredly means going to a 3.3V part, 8Mbit just happens to be a good trade-off in terms of density, 5V availability, and pricing. Besides, how many games will actually require more than 8Mbit?

gvx32 Joined: 17 Sep 2013 Posts: 128 Location: Gravataí, RS, Brazil	Posted: Thu Mar 20, 2014 8:39 pm
	db-electronics wrote If we all agree on a standard for register 0xFFFC, we can always include more pages of RAM. Yes, tha would be great, but it have to be a standart that doesnt break the compatibility with the original. How is the implementation you working on? are you mapping in the entire "slot 3", or just in the mirror ram? db-electronics wrote Going larger than 8Mbit almost assuredly means going to a 3.3V part, 8Mbit just happens to be a good trade-off in terms of density, 5V availability, and pricing. Besides, how many games will actually require more than 8Mbit? How about using more than one 8Mbit rom? The selector could be implemented in VHDL as a part of the mapper.

TmEE Joined: 31 Oct 2007 Posts: 853 Location: Estonia, Rapla city	Posted: Thu Mar 20, 2014 10:40 pm
	Micron makes new 16MBit 5V Flashes (for automotive industry)

Forums

View topic - SMS Homebrew Carts