Forums

I want to start a new clean thread dealing only with the electrical and mechanical design of the SMS Homebrew Carts system. The previous thread was starting to get filled with discussion unrelated to design which, in the future, should become part of a support thread.

As I wind down from the FM Power Base Converter, I am slowly getting back into the SMS Homebrew Carts design. A few months off of this project is akin to a fresh pair of eyes. Here's a few thoughts I've had:

I'm not so sure about being able to plug in the burner into the SMS anymore. I think this puts much mechanical stress on the burner PCB. It's been designed this way thus far to enable the burnt cart to be immediately tested on the SMS without constantly inserting and removing carts from the SMS (especially if you're burning a large batch). I'm thinking, is it really necessary to perform a SMS cart test after having already programmatically verified the burnt cart's content? If I were burning a large batch of carts, I would probably perform spot checks on a small percentage of burnt carts - for the rest I would rely on the verify feature.
Picture for reference
While the battery-backed SRAM is very important for compatibility with existing software, I think it would be wise for new software to use a sector of flash for save files. Not installing the battery and battery holder on a cart would reduce costs and help make the game more reliable. I have a lot of experience with these battery circuits (on my Sega CD Backup RAM Cart) and they are a real pain in the neck - on more than half of my units I had to clean them multiple times in order to get reasonable battery life.
Finally, I wonder if a few of you, when I have prototypes in hand, would be willing to take on a few units (free of charge of course) to perform some compatibility testing? I would send out a few carts, a burner, and the necessary programmers to update firmware as required.

If using a "custom" way to save games, either it's compatible with the Sega mapper (hard) or it's not, and emulators will need to be updated to be compatible. (You could, of course, support both in code...) Would you leave the battery as an option for any "reproductions" that need it (e.g. the Phantasy Star retranslation) or should we make people hack in the different save system? Would the RAM be present or not, for games that need it without a battery?

On the subject of writing to flash, would it be a case of writing the magic commands to the right addresses to erase a sector and then push bits into it? How big is a sector? Doing a read-modify-write on a sector gets hard due to the lack of RAM...

I think compatibility testing will cover two things:

- Testing on real hardware (SMS, GG, PBS, various generations thereof)
- Testing the cart features (compatibility with commercial games, feeling out any homebrew features in there)

Either way you need to test on real hardware, which I can't easily do these days...

Maxim wrote

If using a "custom" way to save games, either it's compatible with the Sega mapper (hard) or it's not, and emulators will need to be updated to be compatible. (You could, of course, support both in code...) Would you leave the battery as an option for any "reproductions" that need it (e.g. the Phantasy Star retranslation) or should we make people hack in the different save system? Would the RAM be present or not, for games that need it without a battery?

I want to leave my design as is and have the option to install the battery where required for compatibility. The RAM can still be installed where required as well. Basically, I would leave the PCB footprints for all of these parts intact, and simply encourage to use the Flash based storage instead due to reduced cost and higher reliability.

The Sega Mapper does have a "ROM Write Enable" bit, I think enabling this bit to write to flash maintains compatibility with the Sega Mapper since it doesn't require any "new" features to be added to the mapper to support writing to flash.

Maxim wrote

On the subject of writing to flash, would it be a case of writing the magic commands to the right addresses to erase a sector and then push bits into it? How big is a sector? Doing a read-modify-write on a sector gets hard due to the lack of RAM...

Yes that's basically it. A sector is 4KB, which I guess could feasibly be R-M-W'd using the internal RAM - else the external RAM chip could be installed for those developers who want it to do the R-M-W operations without disrupting internal RAM contents.

Apologies for briefness, I'm on a phone numpad.

A good reason to have the programmer in the console is rapid testing when writing homebrew. The faster we can iterate on real hardware, the better the code will be. This also benefits emulators because more code gets tested on real hardware.

By pogramming in the console you also know that ALL carts are tested, rather than only some of them, for really no loss in time.

I intend to support this cart with my Sonic 1 level editor so that rapid testing can be done on real hardware. Having to take the cart in and out every time kills the ability to rapidly iterate on design.

If the purpose of the cart is to ship homebrew for real hardware then as much hardware testing as possible needs to be done!

I'd be happy to support whatever save mechanism the cart requires, as long as we can detect the cart appropriately so as to support SRAM / emulators dynamically.

P.S. I'd kill to get my hands on one of these kits. I'm in the U.K., have an SMS2 in storage as well as a small Sony CRT TV. I'm interested in using the cart to work with my own assembler, sonic 1 disassembly and level editor.

db-electronics wrote

The Sega Mapper does have a "ROM Write Enable" bit, I think enabling this bit to write to flash maintains compatibility with the Sega Mapper since it doesn't require any "new" features to be added to the mapper to support writing to flash.

The "ROM Write Enable" bit is all about gating /WR between the cart port and the chip (probably multiple SRAMs on a devcart originally), isn't it? Assuming the flash chip has a write enable pin, is there any downside to leaving it always enabled, so just the magic commands will make the flash contents get modified? What conditions are there for writing - after erasing a sector, can I write bits in random order? My understanding is that erasing sets all the bits and writing resets bits, but the order doesn't matter - is that right? (You'd probably still do things in order, but it'd be nice to know the rules.)

I was expecting hardware-based iteration to happen on an Everdrive, either over USB or just with SD card swapping. Both avoid multiple cartridge insertions. I guess these carts can function as devcarts rather than homebrew carts if the iteration is not too painful - I've iterated on an SMS-PRO before and that was as bad as it might get. These days I tend not to iterate on hardware unless it's a tricky hardware feature I'm testing. Then again, my hardware compatibility track record is not great :)

Kroc, you make very good points and I agree fully - I'll keep that feature. Though it will also be possible to use the burner without an SMS. Also, an all RAM cart for developers would make your desired use scenario much more user friendly. SRAM is much more expensive than flash but load times would be shorter. Although, if you have a burning program coupled with your assembler which is smart enough to only write those sectors which have changed then burning to flash for iterative testing might not be lengthy after all.

Maxim wrote

The "ROM Write Enable" bit is all about gating /WR between the cart port and the chip (probably multiple SRAMs on a devcart originally), isn't it? Assuming the flash chip has a write enable pin, is there any downside to leaving it always enabled, so just the magic commands will make the flash contents get modified? What conditions are there for writing - after erasing a sector, can I write bits in random order? My understanding is that erasing sets all the bits and writing resets bits, but the order doesn't matter - is that right? (You'd probably still do things in order, but it'd be nice to know the rules.)

The "ROM Write Enable" is an additional safety precaution above and beyond the algorithm required to write to flash (see attached). There is no requirement to write a new sector sequentially. One thing to note however is that the Flash Write Algorithm uses address lines 14 to 0 with all higher address lines being "don't care". However, with the Sega Mapper only address lines 13 to 0 are hard-wired to the Flash, meaning that you'll constantly have to play with the mapper registers in order to write to Flash.

It is highly unlikely that the algorithm would be produced accidentally by runaway code, but still, I think it's best to keep it.

SST39Fcmd.png (49.34 KB)

Kroc wrote

If the purpose of the cart is to ship homebrew for real hardware then as much hardware testing as possible needs to be done!

Kroc, I've just routed all of the Z80 control signals from the cartridge to the microcontroller onboard the cartridge burner. I welcome anyone's recommendations for the lists below.

The following signals will be able to trigger interrupts in the microcontroller:

#MREQ
#IORQ
#JREAD
#M1
#INT
#NMI

On top of all the signals listed above, the cartridge burner will be able to read the state of:

#BUSACK
#RST
Data bus
Address bus

You'll be able to drive the following signals from the cartridge burner (aside from the obvious data and address bus + rd & wr):

#BUSREQ
#NMI
#JYDS
#WAIT
#RST
#INT
#IORQ
#MREQ

Initially we'll focus on getting the thing to burn carts, but as time progresses this platform could be used to produce something more powerful for hardware debugging.

Thanks for listening db, you are amazing.

I don't think the Everdrive is a good product, it's just the only one available. What good is it to test on different hardware than you are shipping on!?

I imagine a programmer that gets smarter over time and cartridge-blanks that get dumber (and cheaper) over time. That way homebrew developers can iterate and test on the hardware they're going to ship on. It is very important that What You Write Is What You Ship. It reduces mistakes and failures after-delivery. Everdrive just can't offer this.

I'm interested in testing it too. I live in the USA and have an SMS1 and a Genesis 1, 2, JVC/Xeye and Nomad with a homebrew PBC I could test it on as well.

Thanks for volunteering Kroc and Maraakate, I don't expect to have any boards for this project for another few months still but I will keep posting progress here and on my website's lab journal, as well as gathering your opinions on this forum!

Since this is intended to be an SMS community project, I've decided to share the schematics of the burner and the cart on this forum in order to get any feedback before I send off the PCBs for a first spin.

Here are a few noteworthy points:

On the Cart:

R102, R103, R104, R105, R106, R107 & R108 - when stuffed, permit the bare minimum cart (i.e. only 1 flash chip, 48K max, no mapper).
Battery circuit is same as my Sega CD Backup RAM Cart, I've measured that it should last over 10 years - one can swap the battery while the game is powered without losing anything

On the Burner

CON200 is equivalent to an SMS game edge, plugs into the SMS console (not required to plug into SMS for operation)
CON202 accepts the cart to be burned
Lower left - 16Mbit internal memory for batch programming away from PC
Upper right - USB to UART bridge, for PC comms and bootloader (firmware upgrades)
Interrupt Signals - NMI, MREQ, IORQ, JREAD, M1 and INT are connected to interruptable pins on the micro for future dev cart functionality
General Purpose Pushbutton - start a batch job?
Two status LEDs for whatever...
Burner can detect SMS presence by measuring the +5V from SMS through AN0 (pin 30 on micro)

The Cart PCB is completely done. The burner PCB is about 75% done; all tracks are routed and I'm performing straightening and general beautification.

Schematics_1408A21.zip (66.96 KB)

I know nothing about hardware, so I can't comment on the schematics, but I am a designer and I have a few suggestions and comments:

* Are the LEDs different colours? e.g. Red + Green. This would be best for providing status. The green light could blink during burning and then go solid for a verified burn or red for a failed burn, until the cartridge is removed

* The button is an excellent addition, it could be used to interrupt the SMS and allow debugging at some point in the future

* How does the burner appear to the PC over USB? I'm wondering what I'll need to learn to interface with it. The drag-n-derp Gameboy flash cart, and the PSP's UMD drive present themselves as a mounted removable drive that you can drag and drop the ROM file directly. If it were like this, then ROMs could be burnt with nothing more than a file-copy, something infinitely simple for any software to implement

* Would you be able to provide diagrams of what the cart would look like with the various configurations, and to confirm what those configurations are?

* You need an official name for your product. If people are going to start using and testing these then you need a consistent brand, e.g. Everdrive

I apologize in advance for the longest reply ever...

Kroc wrote

Are the LEDs different colours? e.g. Red + Green. This would be best for providing status. The green light could blink during burning and then go solid for a verified burn or red for a failed burn, until the cartridge is removed

They are now! Though in my defence I always put a green LED symbol everywhere and then stuff the needed colours.

Kroc wrote

The button is an excellent addition, it could be used to interrupt the SMS and allow debugging at some point in the future

That's an excellent idea for its use. I had envisioned that the user could download a game to the burner, then walk away from the PC (to some production area) and use the button to initiate each burning cycle. In Dev Cart mode, it can definitely be re-purposed for something more useful such as your suggetsion.

Kroc wrote

How does the burner appear to the PC over USB? I'm wondering what I'll need to learn to interface with it. The drag-n-derp Gameboy flash cart, and the PSP's UMD drive present themselves as a mounted removable drive that you can drag and drop the ROM file directly. If it were like this, then ROMs could be burnt with nothing more than a file-copy, something infinitely simple for any software to implement

Sadly it's not going to be that easy; the burner will appear as a standard serial port from the PC's point of view. I do intend this product be used by developers to release homebrew software and therefore am assuming that my target audience have basic programming skills and will know how to operate a serial port.

Essentially there will be a command set, something like:

cmd = command byte
s = sector address
dx = write data

Description - Length - CMD Code - Example Usage
Reset - 1 - 0x01 - cmd
CLR sector - 2 - 0x50 - cmd, s
WR sector - 4098 - 0x81 - cmd, s, d0, d1, [...] d4095

etc...

Kroc wrote

Would you be able to provide diagrams of what the cart would look like with the various configurations, and to confirm what those configurations are?

Do you mean you'd like to see what the board looks like? I have a preview of the Cart PCB on the front page of my website.

As for the configurations, they are:

Less than 48KB (1x 128KB flash)
between 48KB and 128KB (1x 128KB flash, CPLD (mapper), optional save SRAM)
between 128KB and 256KB (1x 256KB flash, CPLD (mapper), optional save SRAM)
between 256KB and 512KB (1x 512KB flash, CPLD (mapper), optional save SRAM)
between 512KB and 1MB (2x 512KB flash, CPLD (mapper), optional save SRAM)

Kroc wrote

You need an official name for your product. If people are going to start using and testing these then you need a consistent brand, e.g. Everdrive

I know, I'm very terrible with names. The only thing I've come up with for now is db Master Cart and db Master Burner. I'm all ears if anyone has suggestions...

Some name that recalls homebrew or repro?
ReproMaster Cart? Master Homebrew Cart? Just mixing up... let's see what comes out :)

I imagine someone will release a tool to push the file to the serial port. I did one for the SMSReader many years ago, but these days it ought to be pretty easy to come up with something to do the job either interactively or in a commandline.

Is the communication going to be two-way, so the programmer code can wait for the cart to say hello and find out its specs, rather than write blind?

Maxim wrote

Is the communication going to be two-way, so the programmer code can wait for the cart to say hello and find out its specs, rather than write blind?

There will be command acknowledges, especially since writing to Flash is not 100% deterministic time-wise.

I wonder if someone has any suggestions for a mechanism on the Homebrew Cart which would prevent the cart's contents from being dumped and played on an emulator - thus protecting the IP of the developer. Bits 5 & 6 of Sega Mapper register $FFFC are unused, perhaps I could use these to for the suggested protection scheme?

I'm not sure anything is feasible there. The CPU has to read the code that plays with the registers so the dumper can read the same code. It doesn't seem worth the trouble.

db-electronics wrote

I wonder if someone has any suggestions for a mechanism on the Homebrew Cart which would prevent the cart's contents from being dumped and played on an emulator - thus protecting the IP of the developer. Bits 5 & 6 of Sega Mapper register $FFFC are unused, perhaps I could use these to for the suggested protection scheme?

Some people will just desolder and dump the flash directly, and any documented mechanism will read like a how-to to defeat it. :)

You could depend on Z80 signal behavior which dedicated readers will not produce accurately, such as the presence of refresh cycles, etc. or use of other pins typically not connected like M1, IORQ, etc. That would at least limit dumping to being done on the SMS itself.

Even then somebody would still connect the cart to the expansion slot, boot from the cart slot, and then read out the data out (or vice-versa).

I think the only workable approach is to not document what's being done, but then whomever uses the cartridge would have to know about the mechanisms involved and they'd have to not share that information.

Maybe put a unique ID in the CPLD that can be read out from a few I/O ports after an unlock sequence, and trust the author to convolute the code for both the unlocking and reading such that it wouldn't reveal anything. An emulator would need to have both the ID (from inside the CPLD) and unlock method known for the program to run. It's far from fool-proof, but would at least delay attempts.

The program would need to have many points of failure for an ID mismatch to prevent skipping all the checks as well. Maybe too much trouble for the programmer.

Maybe something as simple as making bits 5 & 6 of mapper register $FFFC toggle each time they are read. This behaviour would not be present in an emulator and thus the program could prevent itself from running when not on real hardware. It's no security monster and can, just like most security schemes, be broken; but at least it would be there and would deter such activity.

On that note, I've read somewhere that Krikzz has a built-in check on Everdrives to prevent the game Pier Solar from running.

I ordered a few burner and cart PCBs yesterday. I wasn't expecting to finish the designs for another month or so but I had quite a slow day at work Friday and got most of it done. The manufacturing turnaround time is usually 3-4 weeks until I receive bare boards.

During this time I intend to start writing the burner firmware.

db-electronics wrote

I wonder if someone has any suggestions for a mechanism on the Homebrew Cart which would prevent the cart's contents from being dumped and played on an emulator - thus protecting the IP of the developer.

I would keep this as a separate project. I mean, the ongoing demand it's on repro/homebrew carts, I don't see (yet?) any demand for commercial releases. Of course if such demand arises, one approach could be to write a different mapper so that dumping would be harder... and the dumped ROM would not be working on any (current) emulator. (but I also believe this won't last too long then...)

Half-baked DRM is a burden only to developers and legit users, it will never stop piracy. Wait until people are already publishing with the cart before soliciting feedback on DRM.

Personally I think commercial publishers need to accept that the number of people who want to play SMS games is greater than the number who own hardware, and that they expect to play on any device they want.

Giving the ROM file away is the best advert for the people who will want to buy hardware. This is how it is done in the C64 scene. Prince of Persia was ported to the C64 and released with Jordan Mercner's blessing. Canabalt and Super Hexagon have been released on cart too. DRM was not involved in any of these successes and would have only limited the reach of the impact.

A healthy community will support hardware releases as long as all involved are realistic about the scale of things, nobody can release new retro games like it's the '90s anymore. This is why it's critical IMO that we don't try ship Everdrives to everybody, the cartridge blanks need to be as dumb and cheap as possible so that everybody makes a profit, even if only 1 sells.

Did Digger Chan appear in GoodSMS lists yet?

I don't want to derail this topic but... how much is feasible to design a version of this repro/homebrew cart with FM chip onboard? I mean the FM chip to have FM audio for those SMS consoles lacking this circuit...

sverx wrote

I don't want to derail this topic but... how much is feasible to design a version of this repro/homebrew cart with FM chip onboard? I mean the FM chip to have FM audio for those SMS consoles lacking this circuit...

It would have to be something like this cart.

My experience thus far with the YM2413 is that the chips I have are EXTREMELY sensitive to noise. I'm going on my 3rd PCB spin for the FM Power Base Converter due to noise sensitivity. Also, viletim already has a solution for this (although it does require soldering skills).

My only real thought on this would be to produce another add-on module which plugs into the SMS expansion port and produces both FM and PSG audio, this would negate the need for soldering. But like you said, this is a whole other discussion - and I've got quite a few projects in my pipeline right now!

If there was a way to make the PLD transparent then the cartridge could be programmed with only an ordinary flash/EPROM programmer with a pin adapter. You could have the PLD look for some 'impossible' state of the control signals (eg. M0-7 and M8-B) asserted at the same time then pass A16-A18 through some of the control signal lines (eg. IORQ#, HALT#, INT#).

db-electronics wrote

[*]Finally, I wonder if a few of you, when I have prototypes in hand, would be willing to take on a few units (free of charge of course) to perform some compatibility testing? I would send out a few carts, a burner, and the necessary programmers to update firmware as required.
[/list]

I would really love to be one of those prototype testers. What are the requirements? :)

viletim wrote

If there was a way to make the PLD transparent then the cartridge could be programmed with only an ordinary flash/EPROM programmer with a pin adapter. You could have the PLD look for some 'impossible' state of the control signals (eg. M0-7 and M8-B) asserted at the same time then pass A16-A18 through some of the control signal lines (eg. IORQ#, HALT#, INT#).

That's a pretty good alternate programming idea, I'll have to route those signals to the CPLD on the next revision.

A few questions that occurred to me:

Since the game is able to rewrite portions of flash, will the burner also allow dumping of carts so that we can backup the self-modified ROM?
Will Bank Shifting be supported? E.g. for Competition Carts.
I assume this will be true, but will software on the PC be able to determine what features the cart has? I'd like MaSS1VE to auto detect the capacity and presence of SRAM and assemble the game to suit the specific hardware

Kroc wrote

will software on the PC be able to determine what features the cart has?

I believe you should instead order "tailor made" carts according to the ROM size and features (mapper/SRAM) you need...

No, what I'm asking is that MaSS1VE could be used by lots of different people who own different carts with different features. I'm not referring to only me. MaSS1VE needs to be able to detect the kind of cart being used so that it doesn't try and send 1 MB of data to a 512 KB cart, nor use SRAM features on a cart that doesn't have them.

Sorry, I never meant to say 'you'... I meant that when somebody builds up its homebrew, he knows if he's going to use or not some features and, probably, he also have an idea of the ROM size his work is going to need, thus knowing also if he does need a mapper or not. He then can order the carts according to his needs...

That's true, and it works both ways -- MaSS1VE will display the amount of memory being used by the project so that the author can order the right carts.

@db-electronics: Two more requests, please:

Allow the PC to detect if the burner is in the SMS and that the SMS is on. Reason: Instead of launching an emulator, I'd like MaSS1VE to send the ROM straight to the SMS if it's plugged in. This would be friendliest if this can be detected and all done automatically without having to involve UI
Allow the PC to request a checksum of the cartridge currently plugged in. Reason: To speed up burning we only want to write the cells that have changed, but we need to verify that the cart hasn't changed its contents since the last time (we wouldn't want to patch a ROM that isn't what we assume it to be). Even though it would be unusual to do, it's entirely possible to change the cart's contents inbetween playtesting sessions in MaSS1VE (certainly if the user has two copies of MaSS1VE open working on different projects)

Kroc wrote

Since the game is able to rewrite portions of flash, will the burner also allow dumping of carts so that we can backup the self-modified ROM?

Yes, the roadmap of features starts with basic burning and dumping.

Kroc wrote

Will Bank Shifting be supported? E.g. for Competition Carts?

I hope to have enough resources left in the CPLD to implement this; we'll find out soon enough as PCBs for this are currently on order!

Kroc wrote

I assume this will be true, but will software on the PC be able to determine what features the cart has? I'd like MaSS1VE to auto detect the capacity and presence of SRAM and assemble the game to suit the specific hardware

This is trickier, how to remain 100% compatible with existing mappers yet somehow indicate these features to the PC? Also, assuming the identification features are part of the CPLD, each different configuration would require a different firmware load.

Perhaps going on Viletim's suggestion, creating an impossible bus condition on the cart could be a way for the cart to broadcast information outside of the mapper definition.

Kroc wrote

That's true, and it works both ways -- MaSS1VE will display the amount of memory being used by the project so that the author can order the right carts.

@db-electronics: Two more requests, please:

Allow the PC to detect if the burner is in the SMS and that the SMS is on. Reason: Instead of launching an emulator, I'd like MaSS1VE to send the ROM straight to the SMS if it's plugged in. This would be friendliest if this can be detected and all done automatically without having to involve UI

Allow the PC to request a checksum of the cartridge currently plugged in. Reason: To speed up burning we only want to write the cells that have changed, but we need to verify that the cart hasn't changed its contents since the last time (we wouldn't want to patch a ROM that isn't what we assume it to be). Even though it would be unusual to do, it's entirely possible to change the cart's contents inbetween playtesting sessions in MaSS1VE (certainly if the user has two copies of MaSS1VE open working on different projects)

@Kroc

The burner can measure the +5V signal on the cartridge port, this will indicate whether or not the SMS is powered.

Checksum is also on the features roadmap. For iterative testing, it makes perfect sense to write only those 4K sectors which have changed since the last load.

If I'm not confused then exposing the cart features to the PC would be through a serial command, but if you wanted to expose the cart features to the Z80 easily, you could use the mirrors of the 3D register ($FFF8) at $FFF9/A/B which are unused by software.

db-electronics wrote

Kroc wrote

Will Bank Shifting be supported? E.g. for Competition Carts?

I hope to have enough resources left in the CPLD to implement this; we'll find out soon enough as PCBs for this are currently on order!

This feature is not used in any known software as it is of quite limited use. It also won't be of much help for competition carts because of the unmapped $400 bytes of the first slot. Is it really worth the trouble? Support for codemasters mapper and maybe Korean mapper should be more important.

A new mapping feature to apply a constant offset to the current paging registers, including the first 1KB, would make multi game cartridges possible. I can see a multi game homebrew cartridge selling better than a single game one. I'm not sure how safe it is to use any single address for this, so maybe an unlock command would be sensible.

I can't see the need to support non-SEGA mappers at all for homebrew. The Codemasters mapper is only of use to repros. The bank shifting feature would be far more actually useful for homebrew devs.

Maxim wrote

A new mapping feature to apply a constant offset to the current paging registers, including the first 1KB, would make multi game cartridges possible. I can see a multi game homebrew cartridge selling better than a single game one. I'm not sure how safe it is to use any single address for this, so maybe an unlock command would be sensible.

How aren't multi game homebrew cartridges possible without this feature? Can't you just design your multi game homebrew cartridge as a multi game homebrew cartridge from the beginning?

Kroc wrote

I can't see the need to support non-SEGA mappers at all for homebrew. The Codemasters mapper is only of use to repros. The bank shifting feature would be far more actually useful for homebrew devs.

But bank shifting only works with 512 KB and will keep the first bank fixed. Otherwise it would be a non-SEGA mapper as well as it would break the specs of the SEGA mapper. And you don't want the Cart to support non-SEGA mappers. Even worse, it would look like a SEGA mapper but behave differently making it harder for you to detect what cart your game is running on.
For ingame detection you should be relying on something that follows the specs because someone might as well just want to replace the ROM chip in one of his cartridges as a donor.
To detect SRAM you can simply activate the SRAM, write to it, read back and compare the values to see if the write succeeded.
To detect the number of banks you can set a high bank, read a value, mask out the highest bit, read a value, compare to see if they are the same. Theoretically you would need to compare the whole banks but practically it should be enough to just compare a few bytes. You could also start with 2 different high bank numbers.

Example:
Compare first byte of bank $3f with first byte of bank $1f with first byte of bank $f then compare first byte of bank $3e with first byte of bank $1e with first byte of bank $e. If both tests result in the first 2 bytes being equal but the third byte being different it is very likely that you have 32 banks in your rom.
If all banks are the same then it's very likely that you're not writing to a mapper register :D

Maxim wrote

A new mapping feature to apply a constant offset to the current paging registers, including the first 1KB, would make multi game cartridges possible

You mean putting a 'boot' homebrew in the first banks and from here being able to 'lauch' different homebrew? Do these needs to be aware of that system or not? I would be amazing if you can just put some 3 or 4 homebrew games in the same cart without having to patch them! :)

Calindro wrote

But bank shifting only works with 512 KB and will keep the first bank fixed. Otherwise it would be a non-SEGA mapper as well as it would break the specs of the SEGA mapper. And you don't want the Cart to support non-SEGA mappers. Even worse, it would look like a SEGA mapper but behave differently making it harder for you to detect what cart your game is running on.

No known software uses the feature, therefore there is no 'compatibility' to maintain. Those bits are free to use and the bank shifting can be implemented however is best for homebrewers to use.

(Also, bits 5 & 6 of the same register are 'officially unused', so a new Bank Shifting feature could be placed there)

Running existing commercial software on your hardware is the job of an Everdrive, not db's cart. This is for running original homebrew software and hacks, ideally for commercial release to users who will not be burning the cart themselves.

A lot of homebrew is quite small, and being able to fit multiple programs on one cart is immediately practical. To me removing Codemasters support from the CPLD and fitting in Bank Shifting is better for commercial homebrew releases.

Kroc wrote

A lot of homebrew is quite small, and being able to fit multiple programs on one cart is immediately practical. To me removing Codemasters support from the CPLD and fitting in Bank Shifting is better for commercial homebrew releases.

I believe one of the advantages of having a CPLD onboard is that we can have different 'software' configurations too, apart from the hardware ones (flash size, SRAM...). So we could have a "plain old SEGA mapper" one, a "bank shifting/multiHB support" one, a "minimum SEGA + CodeMaster mapper" one, a "DRM one"... etc etc, as long as it fits into the CPLD (and as long as it's something that actually someone requests).
In short: the product could really be "just what you need" both in terms of hardware onboard (and price) and both in terms of features.

Your schematics look great.
One thing I would change is the way you would update the firmware on the PIC18. I'd go for a bootloader instead of the ICSP header.

Big thumbs up to this thread.

Also, haven't searched the forum, but a little while ago I saw this on hackaday:
http://hackaday.com/2014/06/18/the-sega-mega-drive-dev-kit/

pyroesp wrote

Your schematics look great.
One thing I would change is the way you would update the firmware on the PIC18. I'd go for a bootloader instead of the ICSP header.

Big thumbs up to this thread.

Also, haven't searched the forum, but a little while ago I saw this on hackaday:
http://hackaday.com/2014/06/18/the-sega-mega-drive-dev-kit/

The ICSP is there for initial development to allow firmware debugging. I plan to use the bootloader to distribute firmware later on...

Edit: Notice the FET controlled by #RTS on the Burner schematic which can Reset the PIC18 - this is how the PIC18 bootloader is enabled

Kroc wrote

Calindro wrote

But bank shifting only works with 512 KB and will keep the first bank fixed. Otherwise it would be a non-SEGA mapper as well as it would break the specs of the SEGA mapper. And you don't want the Cart to support non-SEGA mappers. Even worse, it would look like a SEGA mapper but behave differently making it harder for you to detect what cart your game is running on.

No known software uses the feature, therefore there is no 'compatibility' to maintain. Those bits are free to use and the bank shifting can be implemented however is best for homebrewers to use.

But still there are mappers out there that use this feature. I still don't like the idea of breaking something that is there and is documented. But maybe it can be implemented in a way that will reflect the same behavior. I mean like "shift banks by 1/4 * (value of first 2 bits of this register) * (number of banks). This would maintain compatibility. In conjunction with a bit telling "also map the first 1KB of the first bank" it would provide quite powerful bank shifting.

Kroc wrote

(Also, bits 5 & 6 of the same register are 'officially unused', so a new Bank Shifting feature could be placed there)

I agree. Maybe one of these bits could be used as the bit proposed above. This would allow Codemasters style mapping. And therefor make actual Codemasters mapper support redundant.

Kroc wrote

Running existing commercial software on your hardware is the job of an Everdrive, not db's cart. This is for running original homebrew software and hacks, ideally for commercial release to users who will not be burning the cart themselves.

I thought this was clear from the beginning and doesn't need to be mentioned. For me running existing commercial software on my hardware doesn't make sense anyways because my controllers are both not fully functional.
Aren't you the one planning to involve users who will burn carts themselves? :P I mean users using MaSS1VE will most likely be people burning carts themselves to either run them on hardware themselves or let their friends play their cool new hacks on hardware.

Kroc wrote

A lot of homebrew is quite small, and being able to fit multiple programs on one cart is immediately practical. To me removing Codemasters support from the CPLD and fitting in Bank Shifting is better for commercial homebrew releases.

If they are quite small they won't be using any banking. If they aren't using banking they won't benefit from bank shifting. So being able to map the whole first bank would already suffice. With Codemasters support this would already work anyways. I don't care about Codemasters mapper support itself, it's just it's ability to map the whole first slot that I'm asking for.

I feel there is some confusion here.

Homebrew designed as-is will use the interrupt vectors. Making a multi-homebrew out of this will require one of two things:

1. Being able to page the first 1KB. Having the mapper apply an offset is the easiest way as it means any paging in the homebrew will still work with no modifications.
2. Have the homebrew written to support a known "framework" that lives in the first 1KB. This might simply hold a jump at every interrupt vector which jumps to a higher address, maybe above 1KB, maybe above 16KB, but this will impact any timing-sensitive effects. We could mandate such a thing for a competition but it's a bit annoying.

I believe no commercial software uses the bank shifting. It's a bit of a half-assed feature really.

If the mapper could support the funky byte-reversing Korean mapper, it would help out for sprite flipping :) That's got to be more useful.

People making repros of Codemasters games can use mapper hacks for most of them, only EDC is incompatible. However, homebrew exists that uses the CM mapper - namely, my competition cart so it's a shame not to support it. I'd like to give away competition carts as prizes, but Everdrives are a bit pricey :)

Maxim wrote

I feel there is some confusion here.

I am also confused! Bank shifting, yes or no?

Maxim wrote

If the mapper could support the funky byte-reversing Korean mapper, it would help out for sprite flipping :) That's got to be more useful.

Tell me more about this as it does sound quite useful! My current hardware revision wouldn't be able to flip bytes but that could easily be added to revision 2. Byte-reversing is incredibly easy in hardware...

Author	Message
db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	SMS Homebrew Carts (design thread) Posted: Fri Aug 15, 2014 12:21 pm
	I want to start a new clean thread dealing only with the electrical and mechanical design of the SMS Homebrew Carts system. The previous thread was starting to get filled with discussion unrelated to design which, in the future, should become part of a support thread. As I wind down from the FM Power Base Converter, I am slowly getting back into the SMS Homebrew Carts design. A few months off of this project is akin to a fresh pair of eyes. Here's a few thoughts I've had: I'm not so sure about being able to plug in the burner into the SMS anymore. I think this puts much mechanical stress on the burner PCB. It's been designed this way thus far to enable the burnt cart to be immediately tested on the SMS without constantly inserting and removing carts from the SMS (especially if you're burning a large batch). I'm thinking, is it really necessary to perform a SMS cart test after having already programmatically verified the burnt cart's content? If I were burning a large batch of carts, I would probably perform spot checks on a small percentage of burnt carts - for the rest I would rely on the verify feature. Picture for reference While the battery-backed SRAM is very important for compatibility with existing software, I think it would be wise for new software to use a sector of flash for save files. Not installing the battery and battery holder on a cart would reduce costs and help make the game more reliable. I have a lot of experience with these battery circuits (on my Sega CD Backup RAM Cart) and they are a real pain in the neck - on more than half of my units I had to clean them multiple times in order to get reasonable battery life. Finally, I wonder if a few of you, when I have prototypes in hand, would be willing to take on a few units (free of charge of course) to perform some compatibility testing? I would send out a few carts, a burner, and the necessary programmers to update firmware as required.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Fri Aug 15, 2014 1:03 pm
	If using a "custom" way to save games, either it's compatible with the Sega mapper (hard) or it's not, and emulators will need to be updated to be compatible. (You could, of course, support both in code...) Would you leave the battery as an option for any "reproductions" that need it (e.g. the Phantasy Star retranslation) or should we make people hack in the different save system? Would the RAM be present or not, for games that need it without a battery? On the subject of writing to flash, would it be a case of writing the magic commands to the right addresses to erase a sector and then push bits into it? How big is a sector? Doing a read-modify-write on a sector gets hard due to the lack of RAM... I think compatibility testing will cover two things: - Testing on real hardware (SMS, GG, PBS, various generations thereof) - Testing the cart features (compatibility with commercial games, feeling out any homebrew features in there) Either way you need to test on real hardware, which I can't easily do these days...

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri Aug 15, 2014 1:54 pm
	Maxim wrote If using a "custom" way to save games, either it's compatible with the Sega mapper (hard) or it's not, and emulators will need to be updated to be compatible. (You could, of course, support both in code...) Would you leave the battery as an option for any "reproductions" that need it (e.g. the Phantasy Star retranslation) or should we make people hack in the different save system? Would the RAM be present or not, for games that need it without a battery? I want to leave my design as is and have the option to install the battery where required for compatibility. The RAM can still be installed where required as well. Basically, I would leave the PCB footprints for all of these parts intact, and simply encourage to use the Flash based storage instead due to reduced cost and higher reliability. The Sega Mapper does have a "ROM Write Enable" bit, I think enabling this bit to write to flash maintains compatibility with the Sega Mapper since it doesn't require any "new" features to be added to the mapper to support writing to flash. Maxim wrote On the subject of writing to flash, would it be a case of writing the magic commands to the right addresses to erase a sector and then push bits into it? How big is a sector? Doing a read-modify-write on a sector gets hard due to the lack of RAM... Yes that's basically it. A sector is 4KB, which I guess could feasibly be R-M-W'd using the internal RAM - else the external RAM chip could be installed for those developers who want it to do the R-M-W operations without disrupting internal RAM contents.

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Fri Aug 15, 2014 2:34 pm
Kroc Joined: 08 Dec 2013 Posts: 200	Apologies for briefness, I'm on a phone numpad. A good reason to have the programmer in the console is rapid testing when writing homebrew. The faster we can iterate on real hardware, the better the code will be. This also benefits emulators because more code gets tested on real hardware. By pogramming in the console you also know that ALL carts are tested, rather than only some of them, for really no loss in time. I intend to support this cart with my Sonic 1 level editor so that rapid testing can be done on real hardware. Having to take the cart in and out every time kills the ability to rapidly iterate on design. If the purpose of the cart is to ship homebrew for real hardware then as much hardware testing as possible needs to be done! I'd be happy to support whatever save mechanism the cart requires, as long as we can detect the cart appropriately so as to support SRAM / emulators dynamically.

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Fri Aug 15, 2014 3:04 pm
Kroc Joined: 08 Dec 2013 Posts: 200	P.S. I'd kill to get my hands on one of these kits. I'm in the U.K., have an SMS2 in storage as well as a small Sony CRT TV. I'm interested in using the cart to work with my own assembler, sonic 1 disassembly and level editor.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Fri Aug 15, 2014 4:13 pm
	db-electronics wrote The Sega Mapper does have a "ROM Write Enable" bit, I think enabling this bit to write to flash maintains compatibility with the Sega Mapper since it doesn't require any "new" features to be added to the mapper to support writing to flash. The "ROM Write Enable" bit is all about gating /WR between the cart port and the chip (probably multiple SRAMs on a devcart originally), isn't it? Assuming the flash chip has a write enable pin, is there any downside to leaving it always enabled, so just the magic commands will make the flash contents get modified? What conditions are there for writing - after erasing a sector, can I write bits in random order? My understanding is that erasing sets all the bits and writing resets bits, but the order doesn't matter - is that right? (You'd probably still do things in order, but it'd be nice to know the rules.) I was expecting hardware-based iteration to happen on an Everdrive, either over USB or just with SD card swapping. Both avoid multiple cartridge insertions. I guess these carts can function as devcarts rather than homebrew carts if the iteration is not too painful - I've iterated on an SMS-PRO before and that was as bad as it might get. These days I tend not to iterate on hardware unless it's a tricky hardware feature I'm testing. Then again, my hardware compatibility track record is not great :)

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri Aug 15, 2014 5:10 pm
	Kroc, you make very good points and I agree fully - I'll keep that feature. Though it will also be possible to use the burner without an SMS. Also, an all RAM cart for developers would make your desired use scenario much more user friendly. SRAM is much more expensive than flash but load times would be shorter. Although, if you have a burning program coupled with your assembler which is smart enough to only write those sectors which have changed then burning to flash for iterative testing might not be lengthy after all. Maxim wrote The "ROM Write Enable" bit is all about gating /WR between the cart port and the chip (probably multiple SRAMs on a devcart originally), isn't it? Assuming the flash chip has a write enable pin, is there any downside to leaving it always enabled, so just the magic commands will make the flash contents get modified? What conditions are there for writing - after erasing a sector, can I write bits in random order? My understanding is that erasing sets all the bits and writing resets bits, but the order doesn't matter - is that right? (You'd probably still do things in order, but it'd be nice to know the rules.) The "ROM Write Enable" is an additional safety precaution above and beyond the algorithm required to write to flash (see attached). There is no requirement to write a new sector sequentially. One thing to note however is that the Flash Write Algorithm uses address lines 14 to 0 with all higher address lines being "don't care". However, with the Sega Mapper only address lines 13 to 0 are hard-wired to the Flash, meaning that you'll constantly have to play with the mapper registers in order to write to Flash. It is highly unlikely that the algorithm would be produced accidentally by runaway code, but still, I think it's best to keep it. SST39Fcmd.png (49.34 KB)

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri Aug 15, 2014 6:25 pm
	Kroc wrote If the purpose of the cart is to ship homebrew for real hardware then as much hardware testing as possible needs to be done! Kroc, I've just routed all of the Z80 control signals from the cartridge to the microcontroller onboard the cartridge burner. I welcome anyone's recommendations for the lists below. The following signals will be able to trigger interrupts in the microcontroller: #MREQ #IORQ #JREAD #M1 #INT #NMI On top of all the signals listed above, the cartridge burner will be able to read the state of: #BUSACK #RST Data bus Address bus You'll be able to drive the following signals from the cartridge burner (aside from the obvious data and address bus + rd & wr): #BUSREQ #NMI #JYDS #WAIT #RST #INT #IORQ #MREQ Initially we'll focus on getting the thing to burn carts, but as time progresses this platform could be used to produce something more powerful for hardware debugging.

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Fri Aug 15, 2014 7:36 pm
Kroc Joined: 08 Dec 2013 Posts: 200	Thanks for listening db, you are amazing. I don't think the Everdrive is a good product, it's just the only one available. What good is it to test on different hardware than you are shipping on!? I imagine a programmer that gets smarter over time and cartridge-blanks that get dumber (and cheaper) over time. That way homebrew developers can iterate and test on the hardware they're going to ship on. It is very important that What You Write Is What You Ship. It reduces mistakes and failures after-delivery. Everdrive just can't offer this.

Maraakate Joined: 05 Jun 2010 Posts: 757 Location: Pennsylvania, USA	Posted: Fri Aug 15, 2014 11:05 pm
	I'm interested in testing it too. I live in the USA and have an SMS1 and a Genesis 1, 2, JVC/Xeye and Nomad with a homebrew PBC I could test it on as well.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Sat Aug 16, 2014 4:01 am
	Thanks for volunteering Kroc and Maraakate, I don't expect to have any boards for this project for another few months still but I will keep posting progress here and on my website's lab journal, as well as gathering your opinions on this forum!

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Thu Aug 21, 2014 3:00 pm
	Since this is intended to be an SMS community project, I've decided to share the schematics of the burner and the cart on this forum in order to get any feedback before I send off the PCBs for a first spin. Here are a few noteworthy points: On the Cart: R102, R103, R104, R105, R106, R107 & R108 - when stuffed, permit the bare minimum cart (i.e. only 1 flash chip, 48K max, no mapper). Battery circuit is same as my Sega CD Backup RAM Cart, I've measured that it should last over 10 years - one can swap the battery while the game is powered without losing anything On the Burner CON200 is equivalent to an SMS game edge, plugs into the SMS console (not required to plug into SMS for operation) CON202 accepts the cart to be burned Lower left - 16Mbit internal memory for batch programming away from PC Upper right - USB to UART bridge, for PC comms and bootloader (firmware upgrades) Interrupt Signals - NMI, MREQ, IORQ, JREAD, M1 and INT are connected to interruptable pins on the micro for future dev cart functionality General Purpose Pushbutton - start a batch job? Two status LEDs for whatever... Burner can detect SMS presence by measuring the +5V from SMS through AN0 (pin 30 on micro) The Cart PCB is completely done. The burner PCB is about 75% done; all tracks are routed and I'm performing straightening and general beautification. Schematics_1408A21.zip (66.96 KB)

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Fri Aug 22, 2014 11:08 am
Kroc Joined: 08 Dec 2013 Posts: 200	I know nothing about hardware, so I can't comment on the schematics, but I am a designer and I have a few suggestions and comments: * Are the LEDs different colours? e.g. Red + Green. This would be best for providing status. The green light could blink during burning and then go solid for a verified burn or red for a failed burn, until the cartridge is removed * The button is an excellent addition, it could be used to interrupt the SMS and allow debugging at some point in the future * How does the burner appear to the PC over USB? I'm wondering what I'll need to learn to interface with it. The drag-n-derp Gameboy flash cart, and the PSP's UMD drive present themselves as a mounted removable drive that you can drag and drop the ROM file directly. If it were like this, then ROMs could be burnt with nothing more than a file-copy, something infinitely simple for any software to implement * Would you be able to provide diagrams of what the cart would look like with the various configurations, and to confirm what those configurations are? * You need an official name for your product. If people are going to start using and testing these then you need a consistent brand, e.g. Everdrive

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri Aug 22, 2014 1:26 pm
	I apologize in advance for the longest reply ever... Kroc wrote Are the LEDs different colours? e.g. Red + Green. This would be best for providing status. The green light could blink during burning and then go solid for a verified burn or red for a failed burn, until the cartridge is removed They are now! Though in my defence I always put a green LED symbol everywhere and then stuff the needed colours. Kroc wrote The button is an excellent addition, it could be used to interrupt the SMS and allow debugging at some point in the future That's an excellent idea for its use. I had envisioned that the user could download a game to the burner, then walk away from the PC (to some production area) and use the button to initiate each burning cycle. In Dev Cart mode, it can definitely be re-purposed for something more useful such as your suggetsion. Kroc wrote How does the burner appear to the PC over USB? I'm wondering what I'll need to learn to interface with it. The drag-n-derp Gameboy flash cart, and the PSP's UMD drive present themselves as a mounted removable drive that you can drag and drop the ROM file directly. If it were like this, then ROMs could be burnt with nothing more than a file-copy, something infinitely simple for any software to implement Sadly it's not going to be that easy; the burner will appear as a standard serial port from the PC's point of view. I do intend this product be used by developers to release homebrew software and therefore am assuming that my target audience have basic programming skills and will know how to operate a serial port. Essentially there will be a command set, something like: cmd = command byte s = sector address dx = write data Description - Length - CMD Code - Example Usage Reset - 1 - 0x01 - cmd CLR sector - 2 - 0x50 - cmd, s WR sector - 4098 - 0x81 - cmd, s, d0, d1, [...] d4095 etc... Kroc wrote Would you be able to provide diagrams of what the cart would look like with the various configurations, and to confirm what those configurations are? Do you mean you'd like to see what the board looks like? I have a preview of the Cart PCB on the front page of my website. As for the configurations, they are: Less than 48KB (1x 128KB flash) between 48KB and 128KB (1x 128KB flash, CPLD (mapper), optional save SRAM) between 128KB and 256KB (1x 256KB flash, CPLD (mapper), optional save SRAM) between 256KB and 512KB (1x 512KB flash, CPLD (mapper), optional save SRAM) between 512KB and 1MB (2x 512KB flash, CPLD (mapper), optional save SRAM) Kroc wrote You need an official name for your product. If people are going to start using and testing these then you need a consistent brand, e.g. Everdrive I know, I'm very terrible with names. The only thing I've come up with for now is db Master Cart and db Master Burner. I'm all ears if anyone has suggestions...

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Fri Aug 22, 2014 1:45 pm
	Some name that recalls homebrew or repro? ReproMaster Cart? Master Homebrew Cart? Just mixing up... let's see what comes out :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Fri Aug 22, 2014 1:49 pm
	I imagine someone will release a tool to push the file to the serial port. I did one for the SMSReader many years ago, but these days it ought to be pretty easy to come up with something to do the job either interactively or in a commandline. Is the communication going to be two-way, so the programmer code can wait for the cart to say hello and find out its specs, rather than write blind?

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri Aug 22, 2014 1:55 pm
	Maxim wrote Is the communication going to be two-way, so the programmer code can wait for the cart to say hello and find out its specs, rather than write blind? There will be command acknowledges, especially since writing to Flash is not 100% deterministic time-wise.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Sat Aug 23, 2014 7:01 pm
	I wonder if someone has any suggestions for a mechanism on the Homebrew Cart which would prevent the cart's contents from being dumped and played on an emulator - thus protecting the IP of the developer. Bits 5 & 6 of Sega Mapper register $FFFC are unused, perhaps I could use these to for the suggested protection scheme?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sat Aug 23, 2014 7:38 pm
	I'm not sure anything is feasible there. The CPU has to read the code that plays with the registers so the dumper can read the same code. It doesn't seem worth the trouble.

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Sat Aug 23, 2014 9:07 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	db-electronics wrote I wonder if someone has any suggestions for a mechanism on the Homebrew Cart which would prevent the cart's contents from being dumped and played on an emulator - thus protecting the IP of the developer. Bits 5 & 6 of Sega Mapper register $FFFC are unused, perhaps I could use these to for the suggested protection scheme? Some people will just desolder and dump the flash directly, and any documented mechanism will read like a how-to to defeat it. :) You could depend on Z80 signal behavior which dedicated readers will not produce accurately, such as the presence of refresh cycles, etc. or use of other pins typically not connected like M1, IORQ, etc. That would at least limit dumping to being done on the SMS itself. Even then somebody would still connect the cart to the expansion slot, boot from the cart slot, and then read out the data out (or vice-versa). I think the only workable approach is to not document what's being done, but then whomever uses the cartridge would have to know about the mechanisms involved and they'd have to not share that information. Maybe put a unique ID in the CPLD that can be read out from a few I/O ports after an unlock sequence, and trust the author to convolute the code for both the unlocking and reading such that it wouldn't reveal anything. An emulator would need to have both the ID (from inside the CPLD) and unlock method known for the program to run. It's far from fool-proof, but would at least delay attempts. The program would need to have many points of failure for an ID mismatch to prevent skipping all the checks as well. Maybe too much trouble for the programmer.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Sun Aug 24, 2014 12:36 pm
	Maybe something as simple as making bits 5 & 6 of mapper register $FFFC toggle each time they are read. This behaviour would not be present in an emulator and thus the program could prevent itself from running when not on real hardware. It's no security monster and can, just like most security schemes, be broken; but at least it would be there and would deter such activity. On that note, I've read somewhere that Krikzz has a built-in check on Everdrives to prevent the game Pier Solar from running.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Mon Aug 25, 2014 4:32 am
	I ordered a few burner and cart PCBs yesterday. I wasn't expecting to finish the designs for another month or so but I had quite a slow day at work Friday and got most of it done. The manufacturing turnaround time is usually 3-4 weeks until I receive bare boards. During this time I intend to start writing the burner firmware.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Aug 25, 2014 8:03 am
	db-electronics wrote I wonder if someone has any suggestions for a mechanism on the Homebrew Cart which would prevent the cart's contents from being dumped and played on an emulator - thus protecting the IP of the developer. I would keep this as a separate project. I mean, the ongoing demand it's on repro/homebrew carts, I don't see (yet?) any demand for commercial releases. Of course if such demand arises, one approach could be to write a different mapper so that dumping would be harder... and the dumped ROM would not be working on any (current) emulator. (but I also believe this won't last too long then...)

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Mon Aug 25, 2014 9:23 am
Kroc Joined: 08 Dec 2013 Posts: 200	Half-baked DRM is a burden only to developers and legit users, it will never stop piracy. Wait until people are already publishing with the cart before soliciting feedback on DRM. Personally I think commercial publishers need to accept that the number of people who want to play SMS games is greater than the number who own hardware, and that they expect to play on any device they want. Giving the ROM file away is the best advert for the people who will want to buy hardware. This is how it is done in the C64 scene. Prince of Persia was ported to the C64 and released with Jordan Mercner's blessing. Canabalt and Super Hexagon have been released on cart too. DRM was not involved in any of these successes and would have only limited the reach of the impact. A healthy community will support hardware releases as long as all involved are realistic about the scale of things, nobody can release new retro games like it's the '90s anymore. This is why it's critical IMO that we don't try ship Everdrives to everybody, the cartridge blanks need to be as dumb and cheap as possible so that everybody makes a profit, even if only 1 sells.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Mon Aug 25, 2014 1:13 pm
	Did Digger Chan appear in GoodSMS lists yet?

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Aug 25, 2014 1:39 pm
	I don't want to derail this topic but... how much is feasible to design a version of this repro/homebrew cart with FM chip onboard? I mean the FM chip to have FM audio for those SMS consoles lacking this circuit...

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Mon Aug 25, 2014 2:00 pm
	sverx wrote I don't want to derail this topic but... how much is feasible to design a version of this repro/homebrew cart with FM chip onboard? I mean the FM chip to have FM audio for those SMS consoles lacking this circuit... It would have to be something like this cart. My experience thus far with the YM2413 is that the chips I have are EXTREMELY sensitive to noise. I'm going on my 3rd PCB spin for the FM Power Base Converter due to noise sensitivity. Also, viletim already has a solution for this (although it does require soldering skills). My only real thought on this would be to produce another add-on module which plugs into the SMS expansion port and produces both FM and PSG audio, this would negate the need for soldering. But like you said, this is a whole other discussion - and I've got quite a few projects in my pipeline right now!

viletim Joined: 24 Sep 2006 Posts: 191 Location: Sydney, Australia	Posted: Tue Aug 26, 2014 2:24 pm
	If there was a way to make the PLD transparent then the cartridge could be programmed with only an ordinary flash/EPROM programmer with a pin adapter. You could have the PLD look for some 'impossible' state of the control signals (eg. M0-7 and M8-B) asserted at the same time then pass A16-A18 through some of the control signal lines (eg. IORQ#, HALT#, INT#).

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Wed Aug 27, 2014 10:13 pm
Calindro Joined: 14 Apr 2013 Posts: 624	db-electronics wrote [*]Finally, I wonder if a few of you, when I have prototypes in hand, would be willing to take on a few units (free of charge of course) to perform some compatibility testing? I would send out a few carts, a burner, and the necessary programmers to update firmware as required. [/list] I would really love to be one of those prototype testers. What are the requirements? :)

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri Aug 29, 2014 2:28 am
	viletim wrote If there was a way to make the PLD transparent then the cartridge could be programmed with only an ordinary flash/EPROM programmer with a pin adapter. You could have the PLD look for some 'impossible' state of the control signals (eg. M0-7 and M8-B) asserted at the same time then pass A16-A18 through some of the control signal lines (eg. IORQ#, HALT#, INT#). That's a pretty good alternate programming idea, I'll have to route those signals to the CPLD on the next revision.

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Fri Aug 29, 2014 1:57 pm
Kroc Joined: 08 Dec 2013 Posts: 200	A few questions that occurred to me: Since the game is able to rewrite portions of flash, will the burner also allow dumping of carts so that we can backup the self-modified ROM? Will Bank Shifting be supported? E.g. for Competition Carts. I assume this will be true, but will software on the PC be able to determine what features the cart has? I'd like MaSS1VE to auto detect the capacity and presence of SRAM and assemble the game to suit the specific hardware

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Fri Aug 29, 2014 2:02 pm
	Kroc wrote will software on the PC be able to determine what features the cart has? I believe you should instead order "tailor made" carts according to the ROM size and features (mapper/SRAM) you need...

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Fri Aug 29, 2014 2:29 pm
Kroc Joined: 08 Dec 2013 Posts: 200	No, what I'm asking is that MaSS1VE could be used by lots of different people who own different carts with different features. I'm not referring to only me. MaSS1VE needs to be able to detect the kind of cart being used so that it doesn't try and send 1 MB of data to a 512 KB cart, nor use SRAM features on a cart that doesn't have them.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Fri Aug 29, 2014 2:45 pm
	Sorry, I never meant to say 'you'... I meant that when somebody builds up its homebrew, he knows if he's going to use or not some features and, probably, he also have an idea of the ROM size his work is going to need, thus knowing also if he does need a mapper or not. He then can order the carts according to his needs...

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Fri Aug 29, 2014 7:56 pm
Kroc Joined: 08 Dec 2013 Posts: 200	That's true, and it works both ways -- MaSS1VE will display the amount of memory being used by the project so that the author can order the right carts. @db-electronics: Two more requests, please: Allow the PC to detect if the burner is in the SMS and that the SMS is on. Reason: Instead of launching an emulator, I'd like MaSS1VE to send the ROM straight to the SMS if it's plugged in. This would be friendliest if this can be detected and all done automatically without having to involve UI Allow the PC to request a checksum of the cartridge currently plugged in. Reason: To speed up burning we only want to write the cells that have changed, but we need to verify that the cart hasn't changed its contents since the last time (we wouldn't want to patch a ROM that isn't what we assume it to be). Even though it would be unusual to do, it's entirely possible to change the cart's contents inbetween playtesting sessions in MaSS1VE (certainly if the user has two copies of MaSS1VE open working on different projects)

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri Aug 29, 2014 7:59 pm
	Kroc wrote Since the game is able to rewrite portions of flash, will the burner also allow dumping of carts so that we can backup the self-modified ROM? Yes, the roadmap of features starts with basic burning and dumping. Kroc wrote Will Bank Shifting be supported? E.g. for Competition Carts? I hope to have enough resources left in the CPLD to implement this; we'll find out soon enough as PCBs for this are currently on order! Kroc wrote I assume this will be true, but will software on the PC be able to determine what features the cart has? I'd like MaSS1VE to auto detect the capacity and presence of SRAM and assemble the game to suit the specific hardware This is trickier, how to remain 100% compatible with existing mappers yet somehow indicate these features to the PC? Also, assuming the identification features are part of the CPLD, each different configuration would require a different firmware load. Perhaps going on Viletim's suggestion, creating an impossible bus condition on the cart could be a way for the cart to broadcast information outside of the mapper definition.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri Aug 29, 2014 8:05 pm
	Kroc wrote That's true, and it works both ways -- MaSS1VE will display the amount of memory being used by the project so that the author can order the right carts. @db-electronics: Two more requests, please: Allow the PC to detect if the burner is in the SMS and that the SMS is on. Reason: Instead of launching an emulator, I'd like MaSS1VE to send the ROM straight to the SMS if it's plugged in. This would be friendliest if this can be detected and all done automatically without having to involve UI Allow the PC to request a checksum of the cartridge currently plugged in. Reason: To speed up burning we only want to write the cells that have changed, but we need to verify that the cart hasn't changed its contents since the last time (we wouldn't want to patch a ROM that isn't what we assume it to be). Even though it would be unusual to do, it's entirely possible to change the cart's contents inbetween playtesting sessions in MaSS1VE (certainly if the user has two copies of MaSS1VE open working on different projects) @Kroc The burner can measure the +5V signal on the cartridge port, this will indicate whether or not the SMS is powered. Checksum is also on the features roadmap. For iterative testing, it makes perfect sense to write only those 4K sectors which have changed since the last load.

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Sat Aug 30, 2014 8:26 am
Kroc Joined: 08 Dec 2013 Posts: 200	If I'm not confused then exposing the cart features to the PC would be through a serial command, but if you wanted to expose the cart features to the Z80 easily, you could use the mirrors of the 3D register ($FFF8) at $FFF9/A/B which are unused by software.

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Sat Aug 30, 2014 8:33 am
Calindro Joined: 14 Apr 2013 Posts: 624	db-electronics wrote Kroc wrote Will Bank Shifting be supported? E.g. for Competition Carts? I hope to have enough resources left in the CPLD to implement this; we'll find out soon enough as PCBs for this are currently on order! This feature is not used in any known software as it is of quite limited use. It also won't be of much help for competition carts because of the unmapped $400 bytes of the first slot. Is it really worth the trouble? Support for codemasters mapper and maybe Korean mapper should be more important.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sat Aug 30, 2014 11:00 am
	A new mapping feature to apply a constant offset to the current paging registers, including the first 1KB, would make multi game cartridges possible. I can see a multi game homebrew cartridge selling better than a single game one. I'm not sure how safe it is to use any single address for this, so maybe an unlock command would be sensible.

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Sat Aug 30, 2014 11:20 am
Kroc Joined: 08 Dec 2013 Posts: 200	I can't see the need to support non-SEGA mappers at all for homebrew. The Codemasters mapper is only of use to repros. The bank shifting feature would be far more actually useful for homebrew devs.

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Sat Aug 30, 2014 12:22 pm
Calindro Joined: 14 Apr 2013 Posts: 624	Maxim wrote A new mapping feature to apply a constant offset to the current paging registers, including the first 1KB, would make multi game cartridges possible. I can see a multi game homebrew cartridge selling better than a single game one. I'm not sure how safe it is to use any single address for this, so maybe an unlock command would be sensible. How aren't multi game homebrew cartridges possible without this feature? Can't you just design your multi game homebrew cartridge as a multi game homebrew cartridge from the beginning? Kroc wrote I can't see the need to support non-SEGA mappers at all for homebrew. The Codemasters mapper is only of use to repros. The bank shifting feature would be far more actually useful for homebrew devs. But bank shifting only works with 512 KB and will keep the first bank fixed. Otherwise it would be a non-SEGA mapper as well as it would break the specs of the SEGA mapper. And you don't want the Cart to support non-SEGA mappers. Even worse, it would look like a SEGA mapper but behave differently making it harder for you to detect what cart your game is running on. For ingame detection you should be relying on something that follows the specs because someone might as well just want to replace the ROM chip in one of his cartridges as a donor. To detect SRAM you can simply activate the SRAM, write to it, read back and compare the values to see if the write succeeded. To detect the number of banks you can set a high bank, read a value, mask out the highest bit, read a value, compare to see if they are the same. Theoretically you would need to compare the whole banks but practically it should be enough to just compare a few bytes. You could also start with 2 different high bank numbers. Example: Compare first byte of bank $3f with first byte of bank $1f with first byte of bank $f then compare first byte of bank $3e with first byte of bank $1e with first byte of bank $e. If both tests result in the first 2 bytes being equal but the third byte being different it is very likely that you have 32 banks in your rom. If all banks are the same then it's very likely that you're not writing to a mapper register :D

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Sat Aug 30, 2014 12:58 pm
	Maxim wrote A new mapping feature to apply a constant offset to the current paging registers, including the first 1KB, would make multi game cartridges possible You mean putting a 'boot' homebrew in the first banks and from here being able to 'lauch' different homebrew? Do these needs to be aware of that system or not? I would be amazing if you can just put some 3 or 4 homebrew games in the same cart without having to patch them! :)

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Sat Aug 30, 2014 1:29 pm
Kroc Joined: 08 Dec 2013 Posts: 200	Calindro wrote But bank shifting only works with 512 KB and will keep the first bank fixed. Otherwise it would be a non-SEGA mapper as well as it would break the specs of the SEGA mapper. And you don't want the Cart to support non-SEGA mappers. Even worse, it would look like a SEGA mapper but behave differently making it harder for you to detect what cart your game is running on. No known software uses the feature, therefore there is no 'compatibility' to maintain. Those bits are free to use and the bank shifting can be implemented however is best for homebrewers to use. (Also, bits 5 & 6 of the same register are 'officially unused', so a new Bank Shifting feature could be placed there) Running existing commercial software on your hardware is the job of an Everdrive, not db's cart. This is for running original homebrew software and hacks, ideally for commercial release to users who will not be burning the cart themselves. A lot of homebrew is quite small, and being able to fit multiple programs on one cart is immediately practical. To me removing Codemasters support from the CPLD and fitting in Bank Shifting is better for commercial homebrew releases.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Sat Aug 30, 2014 4:49 pm
	Kroc wrote A lot of homebrew is quite small, and being able to fit multiple programs on one cart is immediately practical. To me removing Codemasters support from the CPLD and fitting in Bank Shifting is better for commercial homebrew releases. I believe one of the advantages of having a CPLD onboard is that we can have different 'software' configurations too, apart from the hardware ones (flash size, SRAM...). So we could have a "plain old SEGA mapper" one, a "bank shifting/multiHB support" one, a "minimum SEGA + CodeMaster mapper" one, a "DRM one"... etc etc, as long as it fits into the CPLD (and as long as it's something that actually someone requests). In short: the product could really be "just what you need" both in terms of hardware onboard (and price) and both in terms of features.

pyroesp Joined: 14 Mar 2013 Posts: 62 Location: Belgium	Posted: Sat Aug 30, 2014 10:23 pm
pyroesp Joined: 14 Mar 2013 Posts: 62 Location: Belgium	Your schematics look great. One thing I would change is the way you would update the firmware on the PIC18. I'd go for a bootloader instead of the ICSP header. Big thumbs up to this thread. Also, haven't searched the forum, but a little while ago I saw this on hackaday: http://hackaday.com/2014/06/18/the-sega-mega-drive-dev-kit/

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Sun Aug 31, 2014 4:40 am Last edited by db-electronics on Sun Aug 31, 2014 5:03 pm; edited 1 time in total
	pyroesp wrote Your schematics look great. One thing I would change is the way you would update the firmware on the PIC18. I'd go for a bootloader instead of the ICSP header. Big thumbs up to this thread. Also, haven't searched the forum, but a little while ago I saw this on hackaday: http://hackaday.com/2014/06/18/the-sega-mega-drive-dev-kit/ The ICSP is there for initial development to allow firmware debugging. I plan to use the bootloader to distribute firmware later on... Edit: Notice the FET controlled by #RTS on the Burner schematic which can Reset the PIC18 - this is how the PIC18 bootloader is enabled

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Sun Aug 31, 2014 8:37 am
Calindro Joined: 14 Apr 2013 Posts: 624	Kroc wrote Calindro wrote But bank shifting only works with 512 KB and will keep the first bank fixed. Otherwise it would be a non-SEGA mapper as well as it would break the specs of the SEGA mapper. And you don't want the Cart to support non-SEGA mappers. Even worse, it would look like a SEGA mapper but behave differently making it harder for you to detect what cart your game is running on. No known software uses the feature, therefore there is no 'compatibility' to maintain. Those bits are free to use and the bank shifting can be implemented however is best for homebrewers to use. But still there are mappers out there that use this feature. I still don't like the idea of breaking something that is there and is documented. But maybe it can be implemented in a way that will reflect the same behavior. I mean like "shift banks by 1/4 * (value of first 2 bits of this register) * (number of banks). This would maintain compatibility. In conjunction with a bit telling "also map the first 1KB of the first bank" it would provide quite powerful bank shifting. Kroc wrote (Also, bits 5 & 6 of the same register are 'officially unused', so a new Bank Shifting feature could be placed there) I agree. Maybe one of these bits could be used as the bit proposed above. This would allow Codemasters style mapping. And therefor make actual Codemasters mapper support redundant. Kroc wrote Running existing commercial software on your hardware is the job of an Everdrive, not db's cart. This is for running original homebrew software and hacks, ideally for commercial release to users who will not be burning the cart themselves. I thought this was clear from the beginning and doesn't need to be mentioned. For me running existing commercial software on my hardware doesn't make sense anyways because my controllers are both not fully functional. Aren't you the one planning to involve users who will burn carts themselves? :P I mean users using MaSS1VE will most likely be people burning carts themselves to either run them on hardware themselves or let their friends play their cool new hacks on hardware. Kroc wrote A lot of homebrew is quite small, and being able to fit multiple programs on one cart is immediately practical. To me removing Codemasters support from the CPLD and fitting in Bank Shifting is better for commercial homebrew releases. If they are quite small they won't be using any banking. If they aren't using banking they won't benefit from bank shifting. So being able to map the whole first bank would already suffice. With Codemasters support this would already work anyways. I don't care about Codemasters mapper support itself, it's just it's ability to map the whole first slot that I'm asking for.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sun Aug 31, 2014 12:54 pm
	I feel there is some confusion here. Homebrew designed as-is will use the interrupt vectors. Making a multi-homebrew out of this will require one of two things: 1. Being able to page the first 1KB. Having the mapper apply an offset is the easiest way as it means any paging in the homebrew will still work with no modifications. 2. Have the homebrew written to support a known "framework" that lives in the first 1KB. This might simply hold a jump at every interrupt vector which jumps to a higher address, maybe above 1KB, maybe above 16KB, but this will impact any timing-sensitive effects. We could mandate such a thing for a competition but it's a bit annoying. I believe no commercial software uses the bank shifting. It's a bit of a half-assed feature really. If the mapper could support the funky byte-reversing Korean mapper, it would help out for sprite flipping :) That's got to be more useful. People making repros of Codemasters games can use mapper hacks for most of them, only EDC is incompatible. However, homebrew exists that uses the CM mapper - namely, my competition cart so it's a shame not to support it. I'd like to give away competition carts as prizes, but Everdrives are a bit pricey :)

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Sun Aug 31, 2014 2:53 pm
	Maxim wrote I feel there is some confusion here. I am also confused! Bank shifting, yes or no? Maxim wrote If the mapper could support the funky byte-reversing Korean mapper, it would help out for sprite flipping :) That's got to be more useful. Tell me more about this as it does sound quite useful! My current hardware revision wouldn't be able to flip bytes but that could easily be added to revision 2. Byte-reversing is incredibly easy in hardware...

Forums

View topic - SMS Homebrew Carts (design thread)