Forums

There's a kickstarter for a 3D printer for $300. https://www.kickstarter.com/projects/m3d/the-micro-the-first-truly-consumer-3d-p... (They've raised $1M on the first day!)

It's got a 109mm x 113mm x 116mm build area (Just wide enough for an SMS cartridge) and a 450 micron nozzle. Should be available by the end of the year.

Kroc wrote

There's a kickstarter for a 3D printer for $300. https://www.kickstarter.com/projects/m3d/the-micro-the-first-truly-consumer-3d-p... (They've raised $1M on the first day!)

It's got a 109mm x 113mm x 116mm build area (Just wide enough for an SMS cartridge) and a 450 micron nozzle. Should be available by the end of the year.

The Makibox is also in that price range and has a print bed large enough for an SMS cartridge. The problem with 3D printing is it's EXTREMELY slow!

I'm probably going to buy a Makibox in the next little while for other purposes, but I really don't think it's well-suited for small scale production like we're talking about here.

with 3D we already know each shell would have a too high cost, unless something changed since I read the last estimate.
Anyway, what are the numbers we expect in this 'small scale production'? Any idea?

Said Kickstarter is claiming that 5g = $0.25

sverx wrote

with 3D we already know each shell would have a too high cost, unless something changed since I read the last estimate.
Anyway, what are the numbers we expect in this 'small scale production'? Any idea?

At the Makibox store you can buy 1Kg of ABS for $16. If it could print fast and reliably, it would be ideal... But I figure it probably takes a couple of hours to print a shell.

Yes, but long-term, what's the demand going to be for these? Beyond an initial rush? A couple a month, perhaps?

Going the mould route would require a fundraiser (and a fairly significant one for this type of item) to make a large initial order. Batches thereafter become expensive though as demand dwindles, with potentially wasted stock.

With 3D-printing, one could limit pre-orders to x per month and keep the batches small with steady output and much lower initial upfront cost which the community would be far more capable of providing.

IMO that is. db-electronics is the one doing all the work and knows best. I recommend you put your logo on the PCB and embossed/raised on the back of the cart. You shouldn't leave yourself out of the work.

We've got a Ultimaker 2 printer at work - it would be able to print casing out of experience they would feel as nice and smooth as molded one. And I imagine it would take 2-3 hours to print each casing with it.

Kroc wrote

IMO that is. db-electronics is the one doing all the work and knows best. I recommend you put your logo on the PCB and embossed/raised on the back of the cart. You shouldn't leave yourself out of the work.

Thanks for this suggestion Kroc. I'm so absorbed in work (not just this project) that I completely forgot to ask my mechanical designers to emboss a simple "db" logo on the carts! I'll do something similar on the PCBs where it will be possible to identify my carts without taking the game apart.

sverx wrote

what are the numbers we expect in this 'small scale production'? Any idea?

No real idea, but for comparison, I've built about 400 Power Base Minis in the last year.

How many developers would find it useful to be able to make a small game that uses no mappers at all? I could add a few 0ohm resistors (i.e. soldered jumpers) that would enable a bare minimum cart with only 1 flash chip and no CPLD at all - it would be more cost effective for that size of game since it would be free of a 3.3V regulator and CPLD (few bucks cheaper per unit).

Total possible configurations would be:

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

If you bought a bare minimum 48KB cart, it would not be upgradeable to anything larger unless you soldered in a CPLD, programmed it with the mapper, etc... Likewise, to upgrade to the next level always requires some sort of soldering and cannot be switched on the fly (i.e. a cart without the saving feature will not have the SRAM chip, battery holder, and battery circuitry installed).

Plenty of homebrew is under 48KB, until you get a lot of graphics and data. However, by the time something is worth buying it might be on the large side, unless it's inherently a small game without superfluous graphics, like a Tetris type puzzler.

db-electronics wrote

I could add a few 0ohm resistors (i.e. soldered jumpers) that would enable a bare minimum cart with only 1 flash chip and no CPLD at all - it would be more cost effective

I thought it would not be possible so I didn't bother even to suggest it! :)

db-electronics wrote

sverx wrote

what are the numbers we expect in this 'small scale production'? Any idea?

No real idea, but for comparison, I've built about 400 Power Base Minis in the last year.

Not bad! Is it wrong to imagine that this production would be around 500 units then?
BTW, can't we run some crowdfunding to see if the mold could be effectively cheaper than the 3D print? With $4000 for 500 units would be $8 per piece, I hardly believe 3D print would beat that...

db-electronics wrote

Less than 48KB (1x 128KB flash)

I do like the idea of having this option, but I agree with the posts above that there might not be a whole lot of homebrew games that fit these boundaries.

Personally, for very small games, I'd find a Homebrew Sega Card much more interesting, but that would be a totally different project.

I've read the topic, pretty cool stuff is going on here.

One thing that I still can't understand, is the big connecter and SPI. Why ?
Make it so your FPGA/CPLD has a USART driver, add an FT232 chip and a micro or mini usb. That's all you need to reprogram your flash mem. Way more simple. It will remove the cost of the header connector , but mostly the cost of making a separate programmer, which sounds stupid IMO.

As for the cases, I have no idea.

I planned on doing a board with a CPLD (altera MAX II) but I never finished the project. (It was quite a while ago)
I still do want to make my own reprogrammable board, I just think that a fast, cheap microcontroller will be better for this.

Don't have enough time to do/start this though.

pyroesp wrote

I've read the topic, pretty cool stuff is going on here.

One thing that I still can't understand, is the big connecter and SPI. Why ?
Make it so your FPGA/CPLD has a USART driver, add an FT232 chip and a micro or mini usb. That's all you need to reprogram your flash mem. Way more simple. It will remove the cost of the header connector , but mostly the cost of making a separate programmer, which sounds stupid IMO.

The 2x5 header is the programming connector for the Altera CPLD. It's not actually soldered since programming the CPLD is only done once during assembly of the cart.

Making a separate programmer is far from stupid, it's extremely cost effective. By having a separate programmer, the cart itself only contains the necessary hardware to be a cart and does not contain any superflupus programming hardware which, for this product, would only be used once (remember this isn't meant for you to pirate games, it is meant for homebrewers to release and distribute their creations.)

Your suggestion to include a UART driver and FTDI chip (and inherently, an oscillator) would add a lot of cost to the cart, cost which is unnecessary. For a developer releasing a decent number of games, having to pay for programmimg hardware only once (in the form of a separate programmer) makes alot more sense than paying for programming hardware on every cart (as you suggest). Moreover, it gives developers more control over their product, they can rest assured that they are delivering a static product, as opposed to a cart which could easily be reprogrammed for pirating.

Sorry if I sound harsh, I've been in the design industry for quite a long time. But then again, at least I don't describe your sugestion as stupid.

Sorry, didn't want to sound like I was berating your design, just that I think incorporating the programmer would be easier to test the homebrew on the sega.
I do program a lot, and I'm constantly programming - compiling - testing. I'd think it's the same for those who make homebrews, though they might use an emulator.

Quote

The 2x5 header is the programming connector for the Altera CPLD. It's not actually soldered since programming the CPLD is only done once during assembly of the cart.

But you still need the header connector to upload your homebrew, or am I wrong ?

Quote

Making a separate programmer is far from stupid, it's extremely cost effective. By having a separate programmer, the cart itself only contains the necessary hardware to be a cart and does not contain any superflupus programming hardware which, for this product, would only be used once (remember this isn't meant for you to pirate games, it is meant for homebrewers to release and distribute their creations.)

Oh... so it's only for a one time use. Must have missed this part when reading the posts here.

Quote

Your suggestion to include a UART driver and FTDI chip (and inherently, an oscillator) would add a lot of cost to the cart, cost which is unnecessary. ...

Just checked the datasheet of the FT232R and there's an internal oscillator. I don't think you need an external osc.
But if it's only for a one time use, then you are correct, it doesn't make sense to include the programmer on the board.

I was thinking to have something like an everdrive, which gives you the possibility to have multiple games/homebrews on one cartridge, which is a feature I would love to have.

Anyways, I'm thinking more like a 32bit MCU from STM, with USB and SD card. And then making the cartridge look like a mass storage device on the PC where you could just drag and drop whatever you want.

Yes, this is all about publishing homebrew in almost write once mode. Developers should use Everdrive.

If the programming hardware were itself a pass-through cartridge port with a cable hanging out of it, one could insert that into the SMS, then put the cartridge in and the developer could reprogram the cartridge regularly without having to remove it from the SMS.

As long as it would work also when not connected to the SMS...

That would be the idea. I think this would be the best design for a programming dongle beacuse:

1. Can easily program multiple carts one after the other without much fiddling - just pull the cart out of the programmer's slot and put another one in

2. Very quick validation -- just power on the SMS after each cart is programmed to check the burn is correct

pyroesp wrote

Just checked the datasheet of the FT232R and there's an internal oscillator. I don't think you need an external osc.

You still need separate timing source on the CPLD to control sending and receiving UART data to and from the FTDI chip.

Kroc wrote

If the programming hardware were itself a pass-through cartridge port with a cable hanging out of it, one could insert that into the SMS, then put the cartridge in and the developer could reprogram the cartridge regularly without having to remove it from the SMS.

I think this idea deserves more attention! I think using #BUSACK and #BUSREQ we can easily steal the bus from the Z80 to reprogram the flash in situ. Only question is, can the nRST signal on the cartridge port be used to reset the Z80, I'll test this over the weekend.

Kroc wrote

That would be the idea. I think this would be the best design for a programming dongle beacuse:

1. Can easily program multiple carts one after the other without much fiddling - just pull the cart out of the programmer's slot and put another one in

2. Very quick validation -- just power on the SMS after each cart is programmed to check the burn is correct

Kroc, point 2 is brilliant!

db-electronics wrote

I think using #BUSACK and #BUSREQ we can easily steal the bus from the Z80 to reprogram the flash in situ. Only question is, can the nRST signal on the cartridge port be used to reset the Z80, I'll test this over the weekend.

I think he meant to program the Flash while the SMS is switched off... :)
Nice idea that validation!

sverx wrote

I think he meant to program the Flash while the SMS is switched off... :)
Nice idea that validation!

There's no need to switch it on and off if we can reset the Z80 from the cartridge port. The thing could program the game and automatically vector to reset when done.

Here's my first impression of the Homebrew Burner PCB.

Mechanical Information

USB mini-B connector on the upper left
Bottom half of Burner has same form factor as a game and could potentially fit in a regular cartridge shell with a cut off top
Blank game connects protruding from the front, label side down (cartridge outline in yellow on silkscreen layer)

Electrical Information

USB Powered, MCP2200 serial port emulator
Cartridge pass-through to SMS port for quick cart testing
Internal 16Mbit serial memory (can load Burner with ROM and burn blanks away from a PC
PIC18F86K22 microcontroller (I apologize in advance for being a PIC guy!)

In terms of firmware, I can definitely write the embedded software required on the burner itself, but I'm no expert at writing applications on the PC. What I think I'll do is make a simple serial command set: read, write, verify, erase, etc... That way people more qualified than I can make a nicer interface on the PC side if they so desire.

I'd like to hear your thoughts, suggestions and ideas on this!

SMS-BBa.PNG (42.33 KB)

Looks very nice!
I suggest keeping those commands in your serial command set, but combine erase and write, so it always erases before writing.

Also, whats keeping you from making 'sure' it fits in a shell? A pass-through-cart similar to the Sonic & Knuckles design would look better sticking out of the console.

Jamarazz, this is what I initially did with my burner, but I then separated them. The reason is that when any error occurs, you may want just to restart writing from where the error occurred, and not rewrite anything once more.

For the PC side, is it going to just show up as a serial port? If so, it might be nice for the software to be able to autodetect it, maybe with a dedicated command. The verify might go faster with a checksum routine than a full comparison, depending on the calculation speed of the microcontroller. Adler32 is pretty fast, for example.

Maxim wrote

For the PC side, is it going to just show up as a serial port? If so, it might be nice for the software to be able to autodetect it, maybe with a dedicated command. The verify might go faster with a checksum routine than a full comparison, depending on the calculation speed of the microcontroller. Adler32 is pretty fast, for example.

Yes it'll look like a regular serial port. The MCP2200 from microchip is similar to the ubiquitous FTDI chips.

I was hoping to help identify the serial port by having the burner start in discovery mode where it expects a specific string from the PC, and issues a known response. Flash -> Thunder (if you're historically inclined!)

I like your suggestion of a checksum verify, this would be very useful when burning directly from a PC. Conversely, if the ROM is loaded into the onboard memory first, a full verify wouldn't take very long. Both options should be available in the command set.

I am wondering why it would need memory or a PIC onboard... given that it's connected to a PC do we really need those parts? Wouldn't it be sufficient some 'dumb' I/O controller and drive everything from the computer program?
Said that, I can help programming the stuff on the PC, if it's basically reading from a BIN file and writing correct data and command to a serial port... :)

I've never burnt any ROMs before, so I can't speak of any experience, but I too question having 'offline' burning. If the SMS already has to be plugged into the PC to receive the ROM and you're going to have swap cartridges regularly anyway, it's just not likely in this day and age that you'll want to do that with the PC off since you'll be doing other things in-between, like browsing / music.

The more that can be pushed to software, the more than can be improved and expanded over time. In due time to come I'll be looking to support such a custom cart with MaSS1VE as I want to be able to test on real hardware.

sverx wrote

I am wondering why it would need memory or a PIC onboard... given that it's connected to a PC do we really need those parts? Wouldn't it be sufficient some 'dumb' I/O controller and drive everything from the computer program?
Said that, I can help programming the stuff on the PC, if it's basically reading from a BIN file and writing correct data and command to a serial port... :)

I thought the onboard memory would be a nice feature, considering it costs less than 1 dollar for serial flash, when burning the same game multiple times successively. I'll elaborate more on this below.

The microcontroller is very necessary because the simplest interface to a PC, in my opinion, is the serial port. You therefore need some sort of device on the burner to understand the UART protocol. Standalone UART chips used to be popular in the 80's but even these devices require a master CPU of some kind in order to be of any use. The extreme low cost of today's microcontrollers makes this kind of chip obsolete.

Another very good reason to have a microcontroller on board is for verification. As Maxim suggested, we can speed up this process by having the onboard microcontroller calculate ADLER-32 or similar. If you re-read all bytes from the PC it would double the time it takes to burn and verify a game.

Example:
Suppose a 230400 baud 8N1 serial link. At this baud rate it takes approximately 45 seconds to download a 1MB (max size) rom to the burner.
In order for a PC controlled protocol to re-read all bytes for verify, it needs to again go through the serial link and needs ANOTHER 45 seconds to execute.
Conversely, a microcontroller has no such bottleneck and would effectively read all bytes and calculate the ADLER-32 in about 2-3 seconds.

Back to the onboard memory. The full 1MB of a cart can be rewritten in approximately 16 seconds (8 seconds if I can intelligently ping-pong writes) if the controller has unrestricted access to data. Again, the bottleneck here is the serial link if the PC is to be the controller. If the user is programming multiple carts, he/she will be saving a tremendous amount of time by downloading his ROM to the burner and writing from there instead (serial flash is VERY fast and does not bottleneck the write process at all).

I understand you guys want as much control as possible on the PC side, and really that is what you'll get. The controller firmware is going to be very minimalist: you'll even have to manually do the flash write commands and so on...

Edit: The microcontroller is in effect what you refer to as a "dumb controller", and probably the cheapest way of executing it too.

I understand, even if I believe even 2 minutes to prepare each single cart would be ok anyway. But after all if it isn't possible to make a very simple device and a PIC would be required anyway, you see there's no use in putting it in and not using it nicely :)

sverx wrote

you see there's no use in putting it in and not using it nicely :)

I'm not sure I understand this last part...

=if you have to include a microcontroller anyhow, it's better to expoit it as much as possible

kamillebidan wrote

=if you have to include a microcontroller anyhow, it's better to expoit it as much as possible

Ok that's what I thought. But what other task do we want the microcontroller to take on? The 18F86K22 is an 8bit 64k program flash 4k RAM device...

Yes, that's what I meant. Sorry, my English isn't perfect... and you haven't heard my French! ;)
BTW I was thinking... if it's theoretically possible to program the cart directly from the SMS, as we've discussed before, why it shouldn't be possible to program the cart from a USB-to-cart simple (dumb) device with no PIC on board? I mean, wouldn't some simple serial-to-parallel connection make it possible to program the cart from the PC? Then we would issue commands and send data as we would do from the Z80... or am I completely wrong?

sverx wrote

Yes, that's what I meant. Sorry, my English isn't perfect... and you haven't heard my French! ;)
BTW I was thinking... if it's theoretically possible to program the cart directly from the SMS, as we've discussed before, why it shouldn't be possible to program the cart from a USB-to-cart simple (dumb) device with no PIC on board? I mean, wouldn't some simple serial-to-parallel connection make it possible to program the cart from the PC? Then we would issue commands and send data as we would do from the Z80... or am I completely wrong?

Are you a hardware or software engineer? Or neither...

If I was either I would be probably able to suggest you HOW to do something instead of asking IF it's possible to do what I imagine it could be...
Said that, in my dumbness I imagined something that converts the serial data that comes from the USB to parallel bits that drives addresses and data. But if it isn't possible, just forgive my illiteracy.

The serial data stream needs some kind of protocol running through it, probably with bidirectional data flow. This means you need something somewhat intelligent at each end to implement this protocol.

For programming flash, there's a lot of set-address write-byte set-address write-byte stuff just to write a single byte (plus a bunch of stuff to perform erasure before writing). If all that had to be done over the serial link, it would severely impact on the volume of data required, and serial links just don't go as fast as you might expect. If you can have something cleverer at the other end, you can send a few commands like "erase the whole chip; write 512KB; <512KB of data>" and cut the time by a factor of 3 or 4. Since this is quite custom for this purpose, there aren't off-the-shelf chips to do this.

The microcontroller can implement different things over USB (even more than one at once). For example, the Retrode pretends to be a USB drive with a single file which is the game contents (plus a writeable savegame). This device could do that instead of the serial link, but that would preclude the flexibility that a serial interface gives you to send arbitrary commands down the line.

How hard would it be to make the programmer also act as a cart dumper? For compatibility it might need to drive more pins on the cartridge interface, but it's hard to precisely emulate the SMS host system.

Maxim wrote

How hard would it be to make the programmer also act as a cart dumper? For compatibility it might need to drive more pins on the cartridge interface, but it's hard to precisely emulate the SMS host system.

Having read and page-read functions on the burner gives it cart dumping capabilities. What other pins, aside from the obvious, would need to be driven for a high compatibility cart dumper?

I've read some documents on the Internet to help me explain better what was my idea, just to understand if it was really impossible or if it was just not practical. It turns out I was thinking of a serial-to-parallel IC, where some bits would select the bank, some would select the byte address (14) and the last 8 bits would be the data byte. Anyway I didn't find any IC with more than 24 bits, but probably one could turn a CPLD into an x-bit serial-to-parallel IC.
Of course I understand that this is probably too stupid, compared to having a small PIC and a nice serial protocol...

sverx wrote

I've read some documents on the Internet to help me explain better what was my idea, just to understand if it was really impossible or if it was just not practical. It turns out I was thinking of a serial-to-parallel IC, where some bits would select the bank, some would select the byte address (14) and the last 8 bits would be the data byte. Anyway I didn't find any IC with more than 24 bits, but probably one could turn a CPLD into an x-bit serial-to-parallel IC.
Of course I understand that this is probably too stupid, compared to having a small PIC and a nice serial protocol...

The problem is a CPLD is a blank slate, it understands no protocols off the shelf (you'd have to implement all timing manually) whereas microcontrollers have built-in peripherals with full (or nearly full) support of many protocols.

Reading and writing to the serial port on a microcontroller is as simple as reading and writing from memory-mapped I/O.

Moreoever, a reasonable CPLD is much more expensive than a microcontroller, not easily field update-able, and a million times less versatile.

I understand. Thanks for bearing with me :)

Received my 3D printed templates for SMS cartridge shells (and Genesis too!). I want to try to make a mold at home using Smooth-On products as described in this thread (pictures of 3D prints are in thread as well).

http://www.smspower.org/forums/viewtopic.php?p=79384#79384

Hi!
I'm a little late but I just read the discussion on Furrtek's project: http://www.yaronet.com/posts.php?sl=0&s=158110&p=1
He spoke about making a case with laser-cut acrylic layers, like this Raspberry Pi case: http://www.adafruit.com/blog/2013/04/12/new-products-pibow-vesa-mounting-layer-plate-and-modela-ninja-pibow-enclosure-for-raspberry-pi-model-a-computer/
He says it may cost about 10€/case.

Don't you think it may be a simple and interesting solution?
I think a homebrew cart with a new design would be great!

J'en ai discuté avec Furrtek il y a qq semaines et y'a plus de chance qu'il s'oriente vers un moule homemade (comme ici), le prix du moule et de revient de cartouche étant ce qu'il y a de plus bas pour les petites prod.

I've spoke with Furrtek about this few weeks ago and he will surely use homemade mold, because it's cheaper.

Ok merci !

You guys should join your efforts. There's little point in having every developer making their own cast, with all the hurdles that obviously come with it. Furrtek wants to make some, db is making some, dragonfeet is also making some, many others would like to have some but have to gut old games because of not enough demand... This needs convergence.

Author	Message
Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Wed Apr 09, 2014 1:41 pm
Kroc Joined: 08 Dec 2013 Posts: 200	There's a kickstarter for a 3D printer for $300. https://www.kickstarter.com/projects/m3d/the-micro-the-first-truly-consumer-3d-p... (They've raised $1M on the first day!) It's got a 109mm x 113mm x 116mm build area (Just wide enough for an SMS cartridge) and a 450 micron nozzle. Should be available by the end of the year.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Wed Apr 09, 2014 1:45 pm
	Kroc wrote There's a kickstarter for a 3D printer for $300. https://www.kickstarter.com/projects/m3d/the-micro-the-first-truly-consumer-3d-p... (They've raised $1M on the first day!) It's got a 109mm x 113mm x 116mm build area (Just wide enough for an SMS cartridge) and a 450 micron nozzle. Should be available by the end of the year. The Makibox is also in that price range and has a print bed large enough for an SMS cartridge. The problem with 3D printing is it's EXTREMELY slow! I'm probably going to buy a Makibox in the next little while for other purposes, but I really don't think it's well-suited for small scale production like we're talking about here.

sverx Joined: 05 Sep 2013 Posts: 3936 Location: Stockholm, Sweden	Posted: Wed Apr 09, 2014 2:13 pm
	with 3D we already know each shell would have a too high cost, unless something changed since I read the last estimate. Anyway, what are the numbers we expect in this 'small scale production'? Any idea?

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Wed Apr 09, 2014 2:32 pm
Kroc Joined: 08 Dec 2013 Posts: 200	Said Kickstarter is claiming that 5g = $0.25

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Wed Apr 09, 2014 2:39 pm
	sverx wrote with 3D we already know each shell would have a too high cost, unless something changed since I read the last estimate. Anyway, what are the numbers we expect in this 'small scale production'? Any idea? At the Makibox store you can buy 1Kg of ABS for $16. If it could print fast and reliably, it would be ideal... But I figure it probably takes a couple of hours to print a shell.

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Wed Apr 09, 2014 2:53 pm
Kroc Joined: 08 Dec 2013 Posts: 200	Yes, but long-term, what's the demand going to be for these? Beyond an initial rush? A couple a month, perhaps? Going the mould route would require a fundraiser (and a fairly significant one for this type of item) to make a large initial order. Batches thereafter become expensive though as demand dwindles, with potentially wasted stock. With 3D-printing, one could limit pre-orders to x per month and keep the batches small with steady output and much lower initial upfront cost which the community would be far more capable of providing. IMO that is. db-electronics is the one doing all the work and knows best. I recommend you put your logo on the PCB and embossed/raised on the back of the cart. You shouldn't leave yourself out of the work.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8702 Location: Paris, France	Posted: Wed Apr 09, 2014 3:14 pm
	We've got a Ultimaker 2 printer at work - it would be able to print casing out of experience they would feel as nice and smooth as molded one. And I imagine it would take 2-3 hours to print each casing with it.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Wed Apr 09, 2014 4:24 pm
	Kroc wrote IMO that is. db-electronics is the one doing all the work and knows best. I recommend you put your logo on the PCB and embossed/raised on the back of the cart. You shouldn't leave yourself out of the work. Thanks for this suggestion Kroc. I'm so absorbed in work (not just this project) that I completely forgot to ask my mechanical designers to emboss a simple "db" logo on the carts! I'll do something similar on the PCBs where it will be possible to identify my carts without taking the game apart.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Wed Apr 09, 2014 11:35 pm
	sverx wrote what are the numbers we expect in this 'small scale production'? Any idea? No real idea, but for comparison, I've built about 400 Power Base Minis in the last year.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Thu Apr 10, 2014 1:41 am
	How many developers would find it useful to be able to make a small game that uses no mappers at all? I could add a few 0ohm resistors (i.e. soldered jumpers) that would enable a bare minimum cart with only 1 flash chip and no CPLD at all - it would be more cost effective for that size of game since it would be free of a 3.3V regulator and CPLD (few bucks cheaper per unit). Total possible configurations would be: Less than 48KB (1x 128KB flash) between 48KB and 128KB (1x 128KB flash, CPLD, optional save SRAM) between 128KB and 256KB (1x 256KB flash, CPLD, optional save SRAM) between 256KB and 512KB (1x 512KB flash, CPLD, optional save SRAM) between 512KB and 1MB (2x 512KB flash, CPLD, optional save SRAM) If you bought a bare minimum 48KB cart, it would not be upgradeable to anything larger unless you soldered in a CPLD, programmed it with the mapper, etc... Likewise, to upgrade to the next level always requires some sort of soldering and cannot be switched on the fly (i.e. a cart without the saving feature will not have the SRAM chip, battery holder, and battery circuitry installed).

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14939 Location: London	Posted: Thu Apr 10, 2014 6:52 am
	Plenty of homebrew is under 48KB, until you get a lot of graphics and data. However, by the time something is worth buying it might be on the large side, unless it's inherently a small game without superfluous graphics, like a Tetris type puzzler.

sverx Joined: 05 Sep 2013 Posts: 3936 Location: Stockholm, Sweden	Posted: Thu Apr 10, 2014 7:59 am
	db-electronics wrote I could add a few 0ohm resistors (i.e. soldered jumpers) that would enable a bare minimum cart with only 1 flash chip and no CPLD at all - it would be more cost effective I thought it would not be possible so I didn't bother even to suggest it! :)

sverx Joined: 05 Sep 2013 Posts: 3936 Location: Stockholm, Sweden	Posted: Thu Apr 10, 2014 8:09 am
	db-electronics wrote sverx wrote what are the numbers we expect in this 'small scale production'? Any idea? No real idea, but for comparison, I've built about 400 Power Base Minis in the last year. Not bad! Is it wrong to imagine that this production would be around 500 units then? BTW, can't we run some crowdfunding to see if the mold could be effectively cheaper than the 3D print? With $4000 for 500 units would be $8 per piece, I hardly believe 3D print would beat that...

Kagesan Joined: 01 Feb 2014 Posts: 895	Posted: Thu Apr 10, 2014 5:24 pm
Kagesan Joined: 01 Feb 2014 Posts: 895	db-electronics wrote Less than 48KB (1x 128KB flash) I do like the idea of having this option, but I agree with the posts above that there might not be a whole lot of homebrew games that fit these boundaries. Personally, for very small games, I'd find a Homebrew Sega Card much more interesting, but that would be a totally different project.

pyroesp Joined: 14 Mar 2013 Posts: 62 Location: Belgium	Posted: Fri Apr 11, 2014 12:41 am
pyroesp Joined: 14 Mar 2013 Posts: 62 Location: Belgium	I've read the topic, pretty cool stuff is going on here. One thing that I still can't understand, is the big connecter and SPI. Why ? Make it so your FPGA/CPLD has a USART driver, add an FT232 chip and a micro or mini usb. That's all you need to reprogram your flash mem. Way more simple. It will remove the cost of the header connector , but mostly the cost of making a separate programmer, which sounds stupid IMO. As for the cases, I have no idea. I planned on doing a board with a CPLD (altera MAX II) but I never finished the project. (It was quite a while ago) I still do want to make my own reprogrammable board, I just think that a fast, cheap microcontroller will be better for this. Don't have enough time to do/start this though.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri Apr 11, 2014 1:41 am
	pyroesp wrote I've read the topic, pretty cool stuff is going on here. One thing that I still can't understand, is the big connecter and SPI. Why ? Make it so your FPGA/CPLD has a USART driver, add an FT232 chip and a micro or mini usb. That's all you need to reprogram your flash mem. Way more simple. It will remove the cost of the header connector , but mostly the cost of making a separate programmer, which sounds stupid IMO. The 2x5 header is the programming connector for the Altera CPLD. It's not actually soldered since programming the CPLD is only done once during assembly of the cart. Making a separate programmer is far from stupid, it's extremely cost effective. By having a separate programmer, the cart itself only contains the necessary hardware to be a cart and does not contain any superflupus programming hardware which, for this product, would only be used once (remember this isn't meant for you to pirate games, it is meant for homebrewers to release and distribute their creations.) Your suggestion to include a UART driver and FTDI chip (and inherently, an oscillator) would add a lot of cost to the cart, cost which is unnecessary. For a developer releasing a decent number of games, having to pay for programmimg hardware only once (in the form of a separate programmer) makes alot more sense than paying for programming hardware on every cart (as you suggest). Moreover, it gives developers more control over their product, they can rest assured that they are delivering a static product, as opposed to a cart which could easily be reprogrammed for pirating. Sorry if I sound harsh, I've been in the design industry for quite a long time. But then again, at least I don't describe your sugestion as stupid.

pyroesp Joined: 14 Mar 2013 Posts: 62 Location: Belgium	Posted: Fri Apr 11, 2014 2:48 am
pyroesp Joined: 14 Mar 2013 Posts: 62 Location: Belgium	Sorry, didn't want to sound like I was berating your design, just that I think incorporating the programmer would be easier to test the homebrew on the sega. I do program a lot, and I'm constantly programming - compiling - testing. I'd think it's the same for those who make homebrews, though they might use an emulator. Quote The 2x5 header is the programming connector for the Altera CPLD. It's not actually soldered since programming the CPLD is only done once during assembly of the cart. But you still need the header connector to upload your homebrew, or am I wrong ? Quote Making a separate programmer is far from stupid, it's extremely cost effective. By having a separate programmer, the cart itself only contains the necessary hardware to be a cart and does not contain any superflupus programming hardware which, for this product, would only be used once (remember this isn't meant for you to pirate games, it is meant for homebrewers to release and distribute their creations.) Oh... so it's only for a one time use. Must have missed this part when reading the posts here. Quote Your suggestion to include a UART driver and FTDI chip (and inherently, an oscillator) would add a lot of cost to the cart, cost which is unnecessary. ... Just checked the datasheet of the FT232R and there's an internal oscillator. I don't think you need an external osc. But if it's only for a one time use, then you are correct, it doesn't make sense to include the programmer on the board. I was thinking to have something like an everdrive, which gives you the possibility to have multiple games/homebrews on one cartridge, which is a feature I would love to have. Anyways, I'm thinking more like a 32bit MCU from STM, with USB and SD card. And then making the cartridge look like a mass storage device on the PC where you could just drag and drop whatever you want.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14939 Location: London	Posted: Fri Apr 11, 2014 7:01 am
	Yes, this is all about publishing homebrew in almost write once mode. Developers should use Everdrive.

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Fri Apr 11, 2014 8:21 am
Kroc Joined: 08 Dec 2013 Posts: 200	If the programming hardware were itself a pass-through cartridge port with a cable hanging out of it, one could insert that into the SMS, then put the cartridge in and the developer could reprogram the cartridge regularly without having to remove it from the SMS.

sverx Joined: 05 Sep 2013 Posts: 3936 Location: Stockholm, Sweden	Posted: Fri Apr 11, 2014 11:29 am
	As long as it would work also when not connected to the SMS...

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Fri Apr 11, 2014 1:47 pm
Kroc Joined: 08 Dec 2013 Posts: 200	That would be the idea. I think this would be the best design for a programming dongle beacuse: 1. Can easily program multiple carts one after the other without much fiddling - just pull the cart out of the programmer's slot and put another one in 2. Very quick validation -- just power on the SMS after each cart is programmed to check the burn is correct

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri Apr 11, 2014 1:48 pm
	pyroesp wrote Just checked the datasheet of the FT232R and there's an internal oscillator. I don't think you need an external osc. You still need separate timing source on the CPLD to control sending and receiving UART data to and from the FTDI chip. Kroc wrote If the programming hardware were itself a pass-through cartridge port with a cable hanging out of it, one could insert that into the SMS, then put the cartridge in and the developer could reprogram the cartridge regularly without having to remove it from the SMS. I think this idea deserves more attention! I think using #BUSACK and #BUSREQ we can easily steal the bus from the Z80 to reprogram the flash in situ. Only question is, can the nRST signal on the cartridge port be used to reset the Z80, I'll test this over the weekend.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri Apr 11, 2014 1:50 pm
	Kroc wrote That would be the idea. I think this would be the best design for a programming dongle beacuse: 1. Can easily program multiple carts one after the other without much fiddling - just pull the cart out of the programmer's slot and put another one in 2. Very quick validation -- just power on the SMS after each cart is programmed to check the burn is correct Kroc, point 2 is brilliant!

sverx Joined: 05 Sep 2013 Posts: 3936 Location: Stockholm, Sweden	Posted: Fri Apr 11, 2014 3:44 pm
	db-electronics wrote I think using #BUSACK and #BUSREQ we can easily steal the bus from the Z80 to reprogram the flash in situ. Only question is, can the nRST signal on the cartridge port be used to reset the Z80, I'll test this over the weekend. I think he meant to program the Flash while the SMS is switched off... :) Nice idea that validation!

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri Apr 11, 2014 4:00 pm
	sverx wrote I think he meant to program the Flash while the SMS is switched off... :) Nice idea that validation! There's no need to switch it on and off if we can reset the Z80 from the cartridge port. The thing could program the game and automatically vector to reset when done.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Tue Apr 22, 2014 1:51 am
	Here's my first impression of the Homebrew Burner PCB. Mechanical Information USB mini-B connector on the upper left Bottom half of Burner has same form factor as a game and could potentially fit in a regular cartridge shell with a cut off top Blank game connects protruding from the front, label side down (cartridge outline in yellow on silkscreen layer) Electrical Information USB Powered, MCP2200 serial port emulator Cartridge pass-through to SMS port for quick cart testing Internal 16Mbit serial memory (can load Burner with ROM and burn blanks away from a PC PIC18F86K22 microcontroller (I apologize in advance for being a PIC guy!) In terms of firmware, I can definitely write the embedded software required on the burner itself, but I'm no expert at writing applications on the PC. What I think I'll do is make a simple serial command set: read, write, verify, erase, etc... That way people more qualified than I can make a nicer interface on the PC side if they so desire. I'd like to hear your thoughts, suggestions and ideas on this! SMS-BBa.PNG (42.33 KB)

Jazzmarazz Joined: 17 Sep 2013 Posts: 140 Location: TC, MI	Posted: Tue Apr 22, 2014 4:19 pm
	Looks very nice! I suggest keeping those commands in your serial command set, but combine erase and write, so it always erases before writing. Also, whats keeping you from making 'sure' it fits in a shell? A pass-through-cart similar to the Sonic & Knuckles design would look better sticking out of the console.

kamillebidan Joined: 25 Feb 2013 Posts: 387 Location: Osaka	Posted: Tue Apr 22, 2014 5:08 pm
	Jamarazz, this is what I initially did with my burner, but I then separated them. The reason is that when any error occurs, you may want just to restart writing from where the error occurred, and not rewrite anything once more.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14939 Location: London	Posted: Tue Apr 22, 2014 10:09 pm
	For the PC side, is it going to just show up as a serial port? If so, it might be nice for the software to be able to autodetect it, maybe with a dedicated command. The verify might go faster with a checksum routine than a full comparison, depending on the calculation speed of the microcontroller. Adler32 is pretty fast, for example.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Thu Apr 24, 2014 12:42 pm
	Maxim wrote For the PC side, is it going to just show up as a serial port? If so, it might be nice for the software to be able to autodetect it, maybe with a dedicated command. The verify might go faster with a checksum routine than a full comparison, depending on the calculation speed of the microcontroller. Adler32 is pretty fast, for example. Yes it'll look like a regular serial port. The MCP2200 from microchip is similar to the ubiquitous FTDI chips. I was hoping to help identify the serial port by having the burner start in discovery mode where it expects a specific string from the PC, and issues a known response. Flash -> Thunder (if you're historically inclined!) I like your suggestion of a checksum verify, this would be very useful when burning directly from a PC. Conversely, if the ROM is loaded into the onboard memory first, a full verify wouldn't take very long. Both options should be available in the command set.

sverx Joined: 05 Sep 2013 Posts: 3936 Location: Stockholm, Sweden	Posted: Wed Apr 30, 2014 7:57 pm
	I am wondering why it would need memory or a PIC onboard... given that it's connected to a PC do we really need those parts? Wouldn't it be sufficient some 'dumb' I/O controller and drive everything from the computer program? Said that, I can help programming the stuff on the PC, if it's basically reading from a BIN file and writing correct data and command to a serial port... :)

Kroc Joined: 08 Dec 2013 Posts: 200	Posted: Wed Apr 30, 2014 8:38 pm
Kroc Joined: 08 Dec 2013 Posts: 200	I've never burnt any ROMs before, so I can't speak of any experience, but I too question having 'offline' burning. If the SMS already has to be plugged into the PC to receive the ROM and you're going to have swap cartridges regularly anyway, it's just not likely in this day and age that you'll want to do that with the PC off since you'll be doing other things in-between, like browsing / music. The more that can be pushed to software, the more than can be improved and expanded over time. In due time to come I'll be looking to support such a custom cart with MaSS1VE as I want to be able to test on real hardware.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Wed Apr 30, 2014 11:04 pm
	sverx wrote I am wondering why it would need memory or a PIC onboard... given that it's connected to a PC do we really need those parts? Wouldn't it be sufficient some 'dumb' I/O controller and drive everything from the computer program? Said that, I can help programming the stuff on the PC, if it's basically reading from a BIN file and writing correct data and command to a serial port... :) I thought the onboard memory would be a nice feature, considering it costs less than 1 dollar for serial flash, when burning the same game multiple times successively. I'll elaborate more on this below. The microcontroller is very necessary because the simplest interface to a PC, in my opinion, is the serial port. You therefore need some sort of device on the burner to understand the UART protocol. Standalone UART chips used to be popular in the 80's but even these devices require a master CPU of some kind in order to be of any use. The extreme low cost of today's microcontrollers makes this kind of chip obsolete. Another very good reason to have a microcontroller on board is for verification. As Maxim suggested, we can speed up this process by having the onboard microcontroller calculate ADLER-32 or similar. If you re-read all bytes from the PC it would double the time it takes to burn and verify a game. Example: Suppose a 230400 baud 8N1 serial link. At this baud rate it takes approximately 45 seconds to download a 1MB (max size) rom to the burner. In order for a PC controlled protocol to re-read all bytes for verify, it needs to again go through the serial link and needs ANOTHER 45 seconds to execute. Conversely, a microcontroller has no such bottleneck and would effectively read all bytes and calculate the ADLER-32 in about 2-3 seconds. Back to the onboard memory. The full 1MB of a cart can be rewritten in approximately 16 seconds (8 seconds if I can intelligently ping-pong writes) if the controller has unrestricted access to data. Again, the bottleneck here is the serial link if the PC is to be the controller. If the user is programming multiple carts, he/she will be saving a tremendous amount of time by downloading his ROM to the burner and writing from there instead (serial flash is VERY fast and does not bottleneck the write process at all). I understand you guys want as much control as possible on the PC side, and really that is what you'll get. The controller firmware is going to be very minimalist: you'll even have to manually do the flash write commands and so on... Edit: The microcontroller is in effect what you refer to as a "dumb controller", and probably the cheapest way of executing it too.

sverx Joined: 05 Sep 2013 Posts: 3936 Location: Stockholm, Sweden	Posted: Thu May 01, 2014 6:49 pm
	I understand, even if I believe even 2 minutes to prepare each single cart would be ok anyway. But after all if it isn't possible to make a very simple device and a PIC would be required anyway, you see there's no use in putting it in and not using it nicely :)

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Thu May 01, 2014 8:57 pm
	sverx wrote you see there's no use in putting it in and not using it nicely :) I'm not sure I understand this last part...

kamillebidan Joined: 25 Feb 2013 Posts: 387 Location: Osaka	Posted: Fri May 02, 2014 3:29 am
	=if you have to include a microcontroller anyhow, it's better to expoit it as much as possible

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri May 02, 2014 3:35 am
	kamillebidan wrote =if you have to include a microcontroller anyhow, it's better to expoit it as much as possible Ok that's what I thought. But what other task do we want the microcontroller to take on? The 18F86K22 is an 8bit 64k program flash 4k RAM device...

sverx Joined: 05 Sep 2013 Posts: 3936 Location: Stockholm, Sweden	Posted: Fri May 02, 2014 7:43 am
	Yes, that's what I meant. Sorry, my English isn't perfect... and you haven't heard my French! ;) BTW I was thinking... if it's theoretically possible to program the cart directly from the SMS, as we've discussed before, why it shouldn't be possible to program the cart from a USB-to-cart simple (dumb) device with no PIC on board? I mean, wouldn't some simple serial-to-parallel connection make it possible to program the cart from the PC? Then we would issue commands and send data as we would do from the Z80... or am I completely wrong?

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri May 02, 2014 11:02 am
	sverx wrote Yes, that's what I meant. Sorry, my English isn't perfect... and you haven't heard my French! ;) BTW I was thinking... if it's theoretically possible to program the cart directly from the SMS, as we've discussed before, why it shouldn't be possible to program the cart from a USB-to-cart simple (dumb) device with no PIC on board? I mean, wouldn't some simple serial-to-parallel connection make it possible to program the cart from the PC? Then we would issue commands and send data as we would do from the Z80... or am I completely wrong? Are you a hardware or software engineer? Or neither...

sverx Joined: 05 Sep 2013 Posts: 3936 Location: Stockholm, Sweden	Posted: Fri May 02, 2014 12:00 pm
	If I was either I would be probably able to suggest you HOW to do something instead of asking IF it's possible to do what I imagine it could be... Said that, in my dumbness I imagined something that converts the serial data that comes from the USB to parallel bits that drives addresses and data. But if it isn't possible, just forgive my illiteracy.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14939 Location: London	Posted: Fri May 02, 2014 12:30 pm
	The serial data stream needs some kind of protocol running through it, probably with bidirectional data flow. This means you need something somewhat intelligent at each end to implement this protocol. For programming flash, there's a lot of set-address write-byte set-address write-byte stuff just to write a single byte (plus a bunch of stuff to perform erasure before writing). If all that had to be done over the serial link, it would severely impact on the volume of data required, and serial links just don't go as fast as you might expect. If you can have something cleverer at the other end, you can send a few commands like "erase the whole chip; write 512KB; <512KB of data>" and cut the time by a factor of 3 or 4. Since this is quite custom for this purpose, there aren't off-the-shelf chips to do this. The microcontroller can implement different things over USB (even more than one at once). For example, the Retrode pretends to be a USB drive with a single file which is the game contents (plus a writeable savegame). This device could do that instead of the serial link, but that would preclude the flexibility that a serial interface gives you to send arbitrary commands down the line. How hard would it be to make the programmer also act as a cart dumper? For compatibility it might need to drive more pins on the cartridge interface, but it's hard to precisely emulate the SMS host system.

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri May 02, 2014 12:42 pm
	Maxim wrote How hard would it be to make the programmer also act as a cart dumper? For compatibility it might need to drive more pins on the cartridge interface, but it's hard to precisely emulate the SMS host system. Having read and page-read functions on the burner gives it cart dumping capabilities. What other pins, aside from the obvious, would need to be driven for a high compatibility cart dumper?

sverx Joined: 05 Sep 2013 Posts: 3936 Location: Stockholm, Sweden	Posted: Fri May 02, 2014 1:14 pm
	I've read some documents on the Internet to help me explain better what was my idea, just to understand if it was really impossible or if it was just not practical. It turns out I was thinking of a serial-to-parallel IC, where some bits would select the bank, some would select the byte address (14) and the last 8 bits would be the data byte. Anyway I didn't find any IC with more than 24 bits, but probably one could turn a CPLD into an x-bit serial-to-parallel IC. Of course I understand that this is probably too stupid, compared to having a small PIC and a nice serial protocol...

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Fri May 02, 2014 1:25 pm
	sverx wrote I've read some documents on the Internet to help me explain better what was my idea, just to understand if it was really impossible or if it was just not practical. It turns out I was thinking of a serial-to-parallel IC, where some bits would select the bank, some would select the byte address (14) and the last 8 bits would be the data byte. Anyway I didn't find any IC with more than 24 bits, but probably one could turn a CPLD into an x-bit serial-to-parallel IC. Of course I understand that this is probably too stupid, compared to having a small PIC and a nice serial protocol... The problem is a CPLD is a blank slate, it understands no protocols off the shelf (you'd have to implement all timing manually) whereas microcontrollers have built-in peripherals with full (or nearly full) support of many protocols. Reading and writing to the serial port on a microcontroller is as simple as reading and writing from memory-mapped I/O. Moreoever, a reasonable CPLD is much more expensive than a microcontroller, not easily field update-able, and a million times less versatile.

sverx Joined: 05 Sep 2013 Posts: 3936 Location: Stockholm, Sweden	Posted: Fri May 02, 2014 1:42 pm
	I understand. Thanks for bearing with me :)

db-electronics Joined: 06 Dec 2013 Posts: 335 Location: Canada	Posted: Sun May 11, 2014 7:58 pm
	Received my 3D printed templates for SMS cartridge shells (and Genesis too!). I want to try to make a mold at home using Smooth-On products as described in this thread (pictures of 3D prints are in thread as well). http://www.smspower.org/forums/viewtopic.php?p=79384#79384

jmimu Joined: 06 May 2012 Posts: 53 Location: France	Posted: Tue May 13, 2014 2:32 pm
jmimu Joined: 06 May 2012 Posts: 53 Location: France	Hi! I'm a little late but I just read the discussion on Furrtek's project: http://www.yaronet.com/posts.php?sl=0&s=158110&p=1 He spoke about making a case with laser-cut acrylic layers, like this Raspberry Pi case: http://www.adafruit.com/blog/2013/04/12/new-products-pibow-vesa-mounting-layer-plate-and-modela-ninja-pibow-enclosure-for-raspberry-pi-model-a-computer/ He says it may cost about 10€/case. Don't you think it may be a simple and interesting solution? I think a homebrew cart with a new design would be great!

ichigobankai Joined: 04 Jul 2010 Posts: 546 Location: Angers, France	Posted: Tue May 13, 2014 10:02 pm
	J'en ai discuté avec Furrtek il y a qq semaines et y'a plus de chance qu'il s'oriente vers un moule homemade (comme ici), le prix du moule et de revient de cartouche étant ce qu'il y a de plus bas pour les petites prod. I've spoke with Furrtek about this few weeks ago and he will surely use homemade mold, because it's cheaper.

jmimu Joined: 06 May 2012 Posts: 53 Location: France	Posted: Wed May 14, 2014 7:46 am
jmimu Joined: 06 May 2012 Posts: 53 Location: France	Ok merci !

jarreboum Joined: 11 Mar 2014 Posts: 91 Location: France	Posted: Wed May 14, 2014 10:22 am
jarreboum Joined: 11 Mar 2014 Posts: 91 Location: France	You guys should join your efforts. There's little point in having every developer making their own cast, with all the hurdles that obviously come with it. Furrtek wants to make some, db is making some, dragonfeet is also making some, many others would like to have some but have to gut old games because of not enough demand... This needs convergence.

Forums

View topic - SMS Homebrew Carts