[WIP] Not a debug cart project!

For hardware talk only (please avoid ROM dumper stuff)
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Re: [WIP] Not a debug cart project!

Post by MintyTheCat » Fri Feb 05, 2016 11:47 am

Sik wrote:
MintyTheCat wrote:I think that there is some confusion here: I am speaking in general terms wrt a custom-cart for the MD that has more services to handle math and graphic type work to augment the MD.
OK that's a whole different matter then. If this was for wi-fi only then I'd argue it's overkill, but for something meant more as a general purpose add-on that kind of stuff makes sense.

Actually how did we get into discussing it as being wi-fi only? o.O
doragasu raised using a DSP in a MD cart:
doragasu wrote: @Sik Some years ago I was thinking about developing a DSP cart (with a TMS320VC5502), and that was the approach I was going to take, using the DSP HPI (Host Port Interface) to map its internal SRAM into the 68000 bus. Unfortunately, using this approach with this project would have raised cost and complexity a lot.
We found the same; DSPs, CPLDs and FPGAs are too expensive to put in a cart serving as a game cart which is why we opted to use an inexpensive uC.
UMDK Fanboy

doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

Re: [WIP] Not a debug cart project!

Post by doragasu » Fri Feb 05, 2016 1:35 pm

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).

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Re: [WIP] Not a debug cart project!

Post by MintyTheCat » Fri Feb 05, 2016 2:10 pm

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.
UMDK Fanboy

doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

Re: [WIP] Not a debug cart project!

Post by doragasu » Fri Feb 05, 2016 4:04 pm

Yo do not need extra memory or glue logic for DSPs (excepting level shifters) that have a host controller interface. They can be mapped on the console's memory and act as slaves: the 68k can acces the complete memory map of the DSP, upload the code and boot it.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Re: [WIP] Not a debug cart project!

Post by MintyTheCat » Fri Feb 05, 2016 4:09 pm

doragasu wrote:Yo do not need extra memory or glue logic for DSPs (excepting level shifters) that have a host controller interface. They can be mapped on the console's memory and act as slaves: the 68k can acces the complete memory map of the DSP, upload the code and boot it.
Ok, but would they also not need a uC to act as a boot-loader? The glue logic would be low cost components as it is either way so I was more interested in working out what the higher cost components would be first.

Yes, but you accept that for a custom-cart that you would need some ROM at the Game ROM right?

Also, can you come up with some power-consumption figure estimates for the hardware options listed above?

Cheers.
UMDK Fanboy

doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

Re: [WIP] Not a debug cart project!

Post by doragasu » Sun Feb 07, 2016 10:35 am

MintyTheCat wrote:
doragasu wrote:Yo do not need extra memory or glue logic for DSPs (excepting level shifters) that have a host controller interface. They can be mapped on the console's memory and act as slaves: the 68k can acces the complete memory map of the DSP, upload the code and boot it.
Ok, but would they also not need a uC to act as a boot-loader? The glue logic would be low cost components as it is either way so I was more interested in working out what the higher cost components would be first.
Again, NO. The C5000 DSPs have an internal boot ROM. You just use some resistors to configure them for HPI boot, and they can boot from the 68k directly (I suppose SEGA SVP did this also, but I haven't investigated). You only need level shifters to convert 5V 68k lines to 3.3V DSP lines. No external ROM (other than the game cart, of course), no extra uC, no extra nothing.

To sum it all, for the DSP enabled cart, you would need the following parts:
- The flash memory chip (to hold the rom). 32 megabits are very cheap as of today.
- The level translators (74lvc162245, cheap chips).
- A 5V --> 3.3V regulator (very very cheap part if you use a liner one).
- A bunch of passives (cost tends to 0 as volume increases).
- The DSP (the only part a bit expensive).

I have used TI low power DSPs (such as C5000 ones) on portable battery powered devices. Power consumption can be very low. At maximum speed (300 MHz, 600 MMACS per second), it's usually less than 300 mW. Of course usually you don't need 600 MMACS per second, so you can lower the clock, also reducing power consumption. The last design I did with one of these DSPs, was clocked at 80 MHz, and power consumption of the whole board (including the DSP, memory, a 24-bit dual channel audio DAC and some analog parts) was around 100 mW. As a reference, the WiFi chip I use on my WiFi cart draws more power...

Floating point DSPs (such as TI C6700 ones) are a lot more expensive and a lot more power hungry, but I don't see why we could need a floating point DSP on the MD. FPGAs are also a lot more power hungry.

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: [WIP] Not a debug cart project!

Post by Sik » Sun Feb 07, 2016 5:19 pm

The SVP doesn't even have its program in boot ROM, the 68000 just loads the program into SVP RAM and then tells the SVP to wake up. (incidentally, I think the SuperFX is like this as well)
Sik is pronounced as "seek", not as "sick".

doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

Re: [WIP] Not a debug cart project!

Post by doragasu » Mon Feb 08, 2016 8:00 am

Sik wrote:The SVP doesn't even have its program in boot ROM, the 68000 just loads the program into SVP RAM and then tells the SVP to wake up. (incidentally, I think the SuperFX is like this as well)
That's exactly what happens with TI DSPs if you configure them for HPI boot. The boot ROM does nothing in this mode. It is useful for other modes (like SPI memory boot or serial port boot), and also has some other useful features (like a 512 element sine LUT).

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Re: [WIP] Not a debug cart project!

Post by MintyTheCat » Mon Feb 08, 2016 3:13 pm

doragasu wrote:
MintyTheCat wrote:
doragasu wrote:Yo do not need extra memory or glue logic for DSPs (excepting level shifters) that have a host controller interface. They can be mapped on the console's memory and act as slaves: the 68k can acces the complete memory map of the DSP, upload the code and boot it.
Ok, but would they also not need a uC to act as a boot-loader? The glue logic would be low cost components as it is either way so I was more interested in working out what the higher cost components would be first.
Again, NO. The C5000 DSPs have an internal boot ROM. You just use some resistors to configure them for HPI boot, and they can boot from the 68k directly (I suppose SEGA SVP did this also, but I haven't investigated). You only need level shifters to convert 5V 68k lines to 3.3V DSP lines. No external ROM (other than the game cart, of course), no extra uC, no extra nothing.

To sum it all, for the DSP enabled cart, you would need the following parts:
- The flash memory chip (to hold the rom). 32 megabits are very cheap as of today.
- The level translators (74lvc162245, cheap chips).
- A 5V --> 3.3V regulator (very very cheap part if you use a liner one).
- A bunch of passives (cost tends to 0 as volume increases).
- The DSP (the only part a bit expensive).

I have used TI low power DSPs (such as C5000 ones) on portable battery powered devices. Power consumption can be very low. At maximum speed (300 MHz, 600 MMACS per second), it's usually less than 300 mW. Of course usually you don't need 600 MMACS per second, so you can lower the clock, also reducing power consumption. The last design I did with one of these DSPs, was clocked at 80 MHz, and power consumption of the whole board (including the DSP, memory, a 24-bit dual channel audio DAC and some analog parts) was around 100 mW. As a reference, the WiFi chip I use on my WiFi cart draws more power...

Floating point DSPs (such as TI C6700 ones) are a lot more expensive and a lot more power hungry, but I don't see why we could need a floating point DSP on the MD. FPGAs are also a lot more power hungry.
That is very promising to know and I am glad that they have made DSPs that require such low power consunmption - 100mW is great.

So price wise can we work out approximately how much it would cost for a single unit of each and then for larger bulk orders? To be honest it makes me wonder what sort of volume someone should aim for to work out the bulk purchases.

I am using a TI DSP dev environment that is actually free but often it was very difficult to get the toolchain and there were all sorts of issues in getting them.

For the type of problems that I had in mind to solve it really was a DSP that I would prefer to use but going on what db said it was elected to use a uC instead of a DSP.

Thanks for the info.
UMDK Fanboy

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Re: [WIP] Not a debug cart project!

Post by MintyTheCat » Mon Feb 08, 2016 3:15 pm

Sik wrote:The SVP doesn't even have its program in boot ROM, the 68000 just loads the program into SVP RAM and then tells the SVP to wake up. (incidentally, I think the SuperFX is like this as well)
Good for trivia fans, Sik :D But often you will find with FPGA and DSP projects that the devices require a boot-loader; my interest was to ascertain if one would be necessary as it impacts the BOM and therefore cost - I am aiming for a prospective cost analysis here you understand.
UMDK Fanboy

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: [WIP] Not a debug cart project!

Post by Sik » Mon Feb 08, 2016 5:31 pm

And I was pointing out that you could avoid the boot ROM if you could get the 68000 to do the bootstrap instead.

For a FPGA this is probably close to impossible (especially since most likely you're letting it act as the mapper as well, so it needs to be ready before the 68000), but for something like a DSP, it's way more feasible if you try to aim for it.

If you use a FPGA all rules go to the trashbin, just let the FPGA do everything =P
Sik is pronounced as "seek", not as "sick".

Oerg866
Very interested
Posts: 211
Joined: Sat Apr 19, 2008 10:58 am
Location: Frankfurt, Germany
Contact:

Re: [WIP] Not a debug cart project!

Post by Oerg866 » Mon Feb 08, 2016 6:28 pm

Putting the Boot ROM in the Block RAM (configured as ROM) of the FPGA does not add to the BOM cost :p

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Re: [WIP] Not a debug cart project!

Post by MintyTheCat » Tue Feb 09, 2016 10:43 am

In terms of cost and power-consumption it appears that an FPGA would be out of the question for a game to be released commercially - barring flash-carts, dev-carts, etc as they are not games but more over tools.

It still stands that a power-consumption vs. BOM cost would need to be done as a feasibility study and from this a suitable device elected - be that a uC or a DSP and then scaled according to bulk component purchases.

Then to determine the manufacturing costs. I would never wish to have things made by hand and would opt for a machine manufactured solution - but this again comes down to production level - are you planning on making 50 units or 5000?
UMDK Fanboy

doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

Re: [WIP] Not a debug cart project!

Post by doragasu » Mon Jul 25, 2016 4:39 pm

This project has been paused some time, because I had not too much spare time, and I'm also working on a NES cartridge XD. But I have been coding a bit lately and I have TCP sockets working!

A small video showing the console connecting to a echo server, sending a hello string and receiving the reply:

http://www.youtube.com/watch?v=pipjUaPvQ8I

This is the code actually used to get the output shown on that video (excluding the router connecting stuff):

Code: Select all

void MwTcpHelloTest(void) {
	MwMsgInAddr* addr = (MwMsgInAddr*)cmd.data;
	const char dstport[] = "1234";
	const char dstaddr[] = "192.168.1.10";
	const char helloStr[] = "Hello world, this is a MEGADRIVE!\n";
	char echoBuff[80];
	uint16_t len = 80 - 1;

	// Configure TCP socket
	cmd.cmd = MW_CMD_TCP_CON;
	// Length is the length of both ports, the channel and the address.
	cmd.datalen = 6 + 6 + 1 + sizeof(dstaddr);
	memset(addr->dst_port, 0, cmd.datalen);
	strcpy(addr->dst_port, dstport);
	strcpy(addr->data, dstaddr);
	addr->channel = TCP_TEST_CH;

	// Try to establish connection
	dtext("Connecting to host...", 1);
	MwCmdSend(&cmd);
	if (MwCmdReplyGet(&rep) < 0) {
		dtext("Connection failed!", 1);
		return;
	}
	// TODO check returned code
	dtext("Connecton established", 1);

	// Enable channel 1
	LsdChEnable(TCP_TEST_CH);
	// Send hello string on channel 1
	LsdSend((uint8_t*)helloStr, sizeof(helloStr) - 1, TCP_TEST_CH);
	// Try receiving the echoed string
	if (TCP_TEST_CH == LsdRecv((uint8_t*)echoBuff, &len, UINT32_MAX)) {
		echoBuff[len] = '\0';
		VDP_drawText("Rx:", 1, line);
		dtext(echoBuff, 5);
	} else {
		dtext("Error waiting for data", 1);
	}
	// Disconnect from host
	cmd.cmd = MW_CMD_TCP_DISC;
	cmd.datalen = 1;
	cmd.data[0] = TCP_TEST_CH;
	MwCmdSend(&cmd);
	if (MwCmdReplyGet(&rep) < 0) {
		dtext("Disconnect failed!", 1);
	} else {
		dtext("Disconnected from host.", 1);
	}
}
I might add another layer to make it more friendly (no MwCmdSend()/MwCmdReplyGet()/LsdSend()/LsdRecv()).

BTW, is there a way to embed a Youtube video on this forum?

doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

Re: [WIP] Not a debug cart project!

Post by doragasu » Tue Jul 26, 2016 7:34 am

BTW if anyone reading this is interested in adding MegaWiFi support to any emulator (multiplatform FOSS emulators preferred, but anyone is welcome), please contact me here or on Twitter (@doragasu). For what I'm hearing lately, not having support in any emulator is what is keeping most developers away from this cart.

Post Reply