doragasu wrote:MintyTheCat wrote:doragasu wrote:
The MD library internally will only access the WiFi Cart's UART registers, mapped at 0xA130C0, to send and receive data to/from the WiFi module. If you want to know how the UART works, you can google and read the SC16C550B datasheet. From there, it's just a matter about how I define the protocol between the module and the 68k, and which commands I implement in the module.
Once the thing is finished, I'd like to release the sources, so anyone can modify and build the library as he/she pleases.
I do not see why you would even need to use the WiFi Cart's UART to talk to the MD; you merely need a section of memory or a port that both can see.
Well, and where is that magic memory section that both the MD and the module can see? Unfortunately cheap WiFi modules I know do not have memory buses to map them on the MD memory. The module I use has UART and SPI hardware interfaces. So you need a UART/SPI chip to be able to communicate with it (or something much more expensive than the UART chip, like an FPGA or a processor with a parallel host port), unless you decide to go wild and try communicating them doing weird things, like bit banging the data through the GPIO pins.
BTW, CPLDs are not expensive (but are extremely limited to be useful for something more complex than a simple mapper implementation), and some fixed point DSPs are not expensive either. FPGAs are more expensive, and more power hungry, but smaller FPGAs are starting to be affordable (e.g. you can buy a single Xilinx XC6LX9 FPGA like the one included in Papilio DSKs for 15€ at Digikey).
Sorry, I was speaking in terms of a custom-cart for the MD; not specifically to the limitations on your WiFi project as we got into that topic along the way.
Yes, a more general solution would have pins available to connect to the 68K's busses. For the MD's case it is possible to experiment with a number of options bus wise: SPI, CAN, I2C or a traditional bus with all the pins for A23-A01 and the data bus.
€15 is a lot of money for a single unit I'm afraid. You would have to see what would be possible with a bulk purchase but as a very rough and ready calculation you never want your material costs and components combined to be more than 40% of the sale price:
I would suggest a price of around €60 for the game then add on P&P on top but strictly considering just the production and manufacturing costs, €60 might be 'ok' - none of this is Gospel.
today's rates: €60 : US$67 : GBP 46
67*0.4 = US$26.80 = €26.80
Personally, I would not spend 40% on components - more like 20%.
With that budget the designer would have to get the cart PCB, components, manual, cart case, cart box and have the cart manufactured - hopefully by machine and not by hand and then have it shrink-wrapped.
Partitioning the hardware for a typical prospective MD custom-cart:
[DSP]
Game ROM - the same as you would find in any MD cart
DSP
DSP's image ROM to load at boot time - will the DSP fetch its own image from ROM or will it require a uC as a boot-loader?
logic glue bits to connect it all together
ROM can be combined and using the glue we can put together some logic for the regions.
[FPGA]
Game ROM - may be part of the FPGA's image
uC as boot-loader or a ROM section for the FPGA's image to load
Hopefully no extra logic would be required or if so then only inexpensive components would be required
[uC]
Game ROM
uC
logic glue bits to connect it all together
ROM can be combined and using the glue we can put together some logic for the regions.
These are pretty rough but just to give some ideas. Note that it may well be that that the €15 FPGA or DSP component also requires a uC to act as a boot-loader which adds to the cost a bit - something very simple would do the job with a single SPI or I2C port - so a single pin would do the job to load the image into the device's memory.
So figure wise, as I am a software developer not a hardware developer; what sort of power consumption figures do you estimate for an FPGA, DSP and a uC? Just some typical examples to give us an idea if you can.
Might be an idea to put a graph together to show the power consumption vs. unit cost and then see what can be achieved for bulk orders.
This is all a question of *when* instead of *if* - eventually components will reach a price to make using any of the above a possibility.