[WIP] Not a debug cart project!

For hardware talk only (please avoid ROM dumper stuff)
User avatar
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 » Wed Feb 03, 2016 8:26 pm

TmEE co.(TM) wrote:Those TI DSPs are garbage, ADI ones are waaaaaaay better.
That hardly matters. A DSP is a DSP and for MD work ANYTHING would be an improvement :D

Edit: I have in my travels work wise heard the term soft DSP used but to be more general let's just use the term Processor here.
From work that was done and discussions with db we felt that a uC would be more fitting due to the combination of cost and power consumption and speed. At present a CPLD or FPGA and most likely a DSP would be a on the high side price wise for a commercial MD cart. With UMDK it is meant to be used as a development tool so any costs are offset by use but this does not scale to a commercial release.

Mind you, having said it entails that people have to get creative fairly early on but no where near as early as on the NES.
Last edited by MintyTheCat on Thu Feb 04, 2016 2:06 pm, edited 1 time in total.
UMDK Fanboy

User avatar
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 » Wed Feb 03, 2016 8:29 pm

Sik wrote:Actually, my idea for the DSP was that it just acts as a bridge since it can push data to the UART much faster than the 68000 ever could (and can safely spend all its time polling if needed). For all we know the DSP program could reside in ROM =P
You would have a section for control and status with the DSP receiving work to carry out.

You would also have a ROM that was partially for the extra processor and the the standard 68K and Z80 code on the MD side.
From what we found last time though a DSP would be just too expensive for a commercially sold MD title.

Using one of the pins we can set it to act as a capture-compare or perhaps link into some kind of IRQ.
We can imagine configuring the State-Machine to count the number of H/V-Interrupts then signal to the custom cart to carry out its next action and thereby remove the need to sit polling.
Last edited by MintyTheCat on Wed Feb 03, 2016 8:44 pm, edited 1 time in total.
UMDK Fanboy

User avatar
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 » Wed Feb 03, 2016 8:39 pm

doragasu wrote:@MintyTheCat: I think there might be a confusion. When I talk about using the UART, I mean the UART chip inside my WiFi Cart (that is wired to the 68k bus and has the 16 byte FIFOs and the RTS/CTS signals wired to the WiFi module). Using the internal 7.61 MHz clock signal, it can achieve up to 7610/16 = 475 kbps (and I can mount a crystal oscillator in case I need a bigger UART bitrate or in case the WiFi module UART cannot sync to this strange bitrate). Way faster than the 4.8 kbps UART on the gamepad ports!
Please in future mention that you are referring to the WiFi cart's UART and not the MD's 1/2-3 :D
ANYTHING is faster than the MD's UART for serial :D Mind you the UART can be used to get directly inside the MD without too man tools - I first began my MD work using the RS232 port and a Command-Monitor before I got a USB Everdrive and then UMDK; I only use UMDK these days.
doragasu wrote: BTW: what made me forget about designing a DSP enabled cart, is the fact that nobody would use it. Although you can code in C, to take advantage of fixed point DSPs such as the mentioned TMS320VC5502, usually requires to learn its (sometimes strange) architecture and code in assembly language. Otherwise it's difficult to take advantage of things like the accumulator guard bits, instruction buffer queue + loop instructions, fractional modes, rounding instructions, saturation, etc... Also you cannot easily test code on an emulator (unless someone takes on the non trivial task of emulating the DSP).

If anyone is seriously willing to learn how to code for these DSPs, I might design the cartridge ;)
That is not strictly true: When I looked at it last time I was interested in math services and from that graphic transformation services with the MD submitting jobs for the processor to carry out.
For a start you will NOT be writing any DSP type code in C :D Assembly all the way. I have yet to meet anyone working on DSPs who writes in C - it is all Assembly.

I was able to add in soft math services for fixed-point math work and most of it boils down to handling matrices on the inactive V-Blank then passing the results back to the MD in time. We also discussed having a frame-buffer set too.

An Emulator would be completely out of the question on the MD side but there are tools available on the Processor side - I say Processor as it could be one of uC/CPLD/FPGA/DSP.

The advantage of having a DSP is that it comes with many useful tools for optimising the code and DSPs are really to be thought of as a piece of magic hardware I feel. At present, a designer could use a decent RISC cheap uC to perform enough of the DSP like services that the MD would routinely need. You have to assess the type of activities that the MD would carry out and then work out how best to support the meagre MD :D

Some time ago this was raised and as per usual no one did anything on here. Let me know if anyone fancies working on a more powerful MD Cart as I would be happy to contribute.
UMDK Fanboy

User avatar
Sik
Very interested
Posts: 714
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: [WIP] Not a debug cart project!

Post by Sik » Wed Feb 03, 2016 9:38 pm

MintyTheCat wrote:You would also have a ROM that was partially for the extra processor and the the standard 68K and Z80 code on the MD side.
From what we found last time though a DSP would be just too expensive for a commercially sold MD title.
Let's forget about the DSP as that would be just an implementation detail. The 68000 just needs to be able to 1) establish a connection and 2) send and receive packets (possibly over a buffer). Could be done through a DSP or a FPGA or whatever. I just guess that something running software would be probably the cheapest option.

On that note, did you ever think how programming would work from the 68000's viewpoint? (even if just a mockup idea)
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 » Wed Feb 03, 2016 10:09 pm

Sik wrote:On that note, did you ever think how programming would work from the 68000's viewpoint? (even if just a mockup idea)
Yep. I have in mind implementing an API that let's you do:
- WiFi stuff: scanning, configuring connection parameters (SSID, pass, DHCP/Static IP, etc.).
- Socket stuff: Creating TCP & UDP sockets, sending and receiving data through them.
- Others: SNTP (time sync), WiFi module flash memory program and read (the module includes a 4 MiB flash memory chip), etc.
- No IPv6 support (sorry about that!).

To implement this all I have to code a firmware for the wifi module, and a library for the MD. To communicate the module and the MD API, I want to use a very simple (SLIP like) protocol that let's you multiplex the channel without adding too much overhead (as bandwith is low and it's not advisable reducing it even more). I might also implement a transparent mode that allows only using one socket at a time (higher bandwidth if you only need one socket).

For complex games, if developers want to get their hands dirty, network logic and maybe other heavy operations can be uploaded to the CPU in the wifi module. Unfortunately the SDK of the wifi module is an event-driven pile of crap...

User avatar
Sik
Very interested
Posts: 714
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: [WIP] Not a debug cart project!

Post by Sik » Thu Feb 04, 2016 12:12 am

You could probably solve the IPv6 issue by just letting the 68000 take care of it? Like, 68000 builds the packet, module just sends it over. I think the only real issue would be checksum calculation (possible but a waste of time as it needs to examine the whole packet, maybe this could be automated as a convenience).

I was thinking more about things like addresses and such. I program the MD in asm and would rather know how to use the hardware directly (especially if the provided library is not built with optimizations! yes I've seen such a thing in the past, it was awful)
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 » Thu Feb 04, 2016 7:47 am

I do not want the 68k to handle low level network stuff (like building packets for the transport layer and below). Let the 68k handle the game, and the CPU in the WiFi module handle communications! So IPv6 stuff should be done in the WiFi module. But right now, IPv6 is not supported by esp-open-sdk (the SDK I'm using to build the firmware for the WiFi module).

The MD library internally will only access the 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.

User avatar
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 » Thu Feb 04, 2016 12:29 pm

Sik wrote:
MintyTheCat wrote:You would also have a ROM that was partially for the extra processor and the the standard 68K and Z80 code on the MD side.
From what we found last time though a DSP would be just too expensive for a commercially sold MD title.
Let's forget about the DSP as that would be just an implementation detail. The 68000 just needs to be able to 1) establish a connection and 2) send and receive packets (possibly over a buffer). Could be done through a DSP or a FPGA or whatever. I just guess that something running software would be probably the cheapest option.
Yes, this is why I used the word processor instead of DSP.

To work out point 1: the connection is controlled using a control-block that the 68K and the Processor can see.

Are we talking about a general custom-MD cart here or the WiFi cart in particular just so we do not misunderstand each other.

In any case, the Processor residing on the custom-cart would be given jobs to carry out and when finished would alter the control-block.
The 68K would then read the control-block or it may be possible to generate an exception.
Sik wrote: On that note, did you ever think how programming would work from the 68000's viewpoint? (even if just a mockup idea)
Yes, as answered further up the Thread.
UMDK Fanboy

User avatar
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 » Thu Feb 04, 2016 12:34 pm

Sik wrote:You could probably solve the IPv6 issue by just letting the 68000 take care of it? Like, 68000 builds the packet, module just sends it over. I think the only real issue would be checksum calculation (possible but a waste of time as it needs to examine the whole packet, maybe this could be automated as a convenience).
That would be inadvisable: the 68K is not meant to be doing any extra work. Checksums in any case are a doddle for the custom-cart's Processor as we can assume pretty much any modern processor would me many orders greater in MIPS than the lowly 68K. A simple ARM uC would be laughing at the 68K. You would handle most of this in any case using Exceptions.
Sik wrote: I was thinking more about things like addresses and such. I program the MD in asm and would rather know how to use the hardware directly (especially if the provided library is not built with optimizations! yes I've seen such a thing in the past, it was awful)
When you say 'addresses' do you mean the memory-map?
UMDK Fanboy

User avatar
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 » Thu Feb 04, 2016 12:36 pm

doragasu wrote:I do not want the 68k to handle low level network stuff (like building packets for the transport layer and below). Let the 68k handle the game, and the CPU in the WiFi module handle communications! So IPv6 stuff should be done in the WiFi module. But right now, IPv6 is not supported by esp-open-sdk (the SDK I'm using to build the firmware for the WiFi module).
Exactly: there is no point in giving the 68K more work to do as this defeats the point in having a custom-cart with its extra processing power.
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.
UMDK Fanboy

User avatar
Sik
Very interested
Posts: 714
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: [WIP] Not a debug cart project!

Post by Sik » Thu Feb 04, 2016 3:43 pm

The 68000 is not that slow, its biggest problem is pumping out all that data in the first place (its memory accesses are awful and doing anything that would involve many accesses per byte is crazy, which is why the effort should be focused in optimizing that).
MintyTheCat wrote:Are we talking about a general custom-MD cart here or the WiFi cart in particular just so we do not misunderstand each other.
Just saying how I'd make it if it was up to me.
Sik is pronounced as "seek", not as "sick".

User avatar
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 » Thu Feb 04, 2016 4:36 pm

Sik wrote:The 68000 is not that slow, its biggest problem is pumping out all that data in the first place (its memory accesses are awful and doing anything that would involve many accesses per byte is crazy, which is why the effort should be focused in optimizing that).
MintyTheCat wrote:Are we talking about a general custom-MD cart here or the WiFi cart in particular just so we do not misunderstand each other.
Just saying how I'd make it if it was up to me.
These things are all relative, Sik, but the 68K cannot compete against even a modestly powerful RISC uC. It was the late 70s when the 68K appeared and we have witnessed improvements since that time. What has improved is pipe-lining now much more so on the RISC machines compared to the CISC machines. The best way to gauge this is to run various tests but essentially it boils down to MIPS vs. power consumption with the power consumption being related to the frequency that the processor is clocked at.

We had discussed mapping pages into the 68K's space for the custom-cart rather like how existing hardware such as UMDK and the Action-Replay function so there would not be much need to "pump out all that data", Sik.

If you look into parallel processing and such you will see how these types of processing problems are categorised:

https://en.wikipedia.org/wiki/Parallel_ ... s_taxonomy

Essentially, you want the custom-cart to handle the heavy actions. You can imagine a table being passed to the custom-cart, it calculating results and the 68K merely acting on the results returned.

I recall the programmer who wrote Tesla Punk asking me "how does the MD handle angles and such?". After I had stopped laughing at him I told him how the MD can only approximate angles and such using often tables.

In order to determine what would improve the MD's lot I first looked at what the SNES as a comparable piece of hardware had by way of extra hardware. But having graphical transforms, fixed-point maths, trigonometry and such and a set of frame-buffers all made good sense.

This, however, requires someone who can handle the hardware design though to make this happen. I have not designed any hardware since leaving University so I would not trust my decisions wrt hardware :D

It would be an excellent project someone who is not afraid of doing some good work though.

Edit: I have been trying to find some kind of comparison between 68K CISC and modern typical RISC processors but cannot much more than university course notes. This will have to do:

https://en.wikipedia.org/wiki/Instructions_per_second

Processor / System Dhrystone MIPS / MIPS D IPS / clock cycles per second D IPS / clock cycles per second / cores per die Year

Hitachi-Motorola 68HC000 3.5 MIPS at 20 MHz 0.175 0.175 1985
ARM Cortex-M0 45 MIPS at 50 MHz 0.9 0.9 2009

Given that the modern RISC uCs consume substantially less power there is also less need to drive them at high clock rates.
MIP for MIP it is substantially cheaper to run a RISC than the 68K as a CISC.

Essentially, the 68K was very good for its time but as more applications were found and insight came about it did not take too long for RISC to beat the old CISC machines hands down.

The interesting cross-over is to find something that would improve the MD's undertaking without adding to much to the BOM for a commercial release and as such we elected a modern RISC based uC as a CPLD and FPGA were too costly.

This of course will change in time as devices are improved. Already, it has been fairly common offer devices with both uC and DSP cores on the same device. There are now CPLD, uC devices available too - we live in interesting times :)
UMDK Fanboy

User avatar
Sik
Very interested
Posts: 714
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: [WIP] Not a debug cart project!

Post by Sik » Thu Feb 04, 2016 5:55 pm

Considering that when sending packets the 68000 still has to generate the data somehow? I'd say that yes, it still has to "pump it out" in some sense =P Also I wonder if you realize just how much data it could be passing back and forth, for starters there's a limit on RAM, and even though the buffer provided by the wi-fi module could be reused as an extension to RAM, I still wouldn't expect much data going through each packet.

Honestly the whole thing about comparing the 68000 to modern processors is stupid. Why not just use a platform with a modern CPU in the first place if you insist so much on it? =S There are way more complex tasks to handle, like the encryption so it can be transmitted to the router. That definitely would be too much for the 68000.
Sik is pronounced as "seek", not as "sick".

User avatar
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 » Thu Feb 04, 2016 8:37 pm

Sik wrote:Considering that when sending packets the 68000 still has to generate the data somehow? I'd say that yes, it still has to "pump it out" in some sense =P Also I wonder if you realize just how much data it could be passing back and forth, for starters there's a limit on RAM, and even though the buffer provided by the wi-fi module could be reused as an extension to RAM, I still wouldn't expect much data going through each packet.
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.

The addition of this hardware would entail that the 68K becomes more about consumption of data than processing of the data. I do not want to have to calculate a table of equations on the 68K side very often but if there was the custom hardware then we can ask it to do the work for us. Cheating for purists, I am a purist by the way, but if the SNES could do it then the MD can too - on a technical level.
Sik wrote: Honestly the whole thing about comparing the 68000 to modern processors is stupid. Why not just use a platform with a modern CPU in the first place if you insist so much on it? =S There are way more complex tasks to handle, like the encryption so it can be transmitted to the router. That definitely would be too much for the 68000.
I think that you misunderstand me, Sik. This is a rhetorical question about extending the MD's basic hardware capabilities and has nothing to do with developing on a modern platform :D

I shall ask you: was the 32X or the SNES using custom chips for largely DSP like tasks cheating in your book?
It depends on what you want to achieve I feel: the vane amongst us would discount something that is not pure MD - the demo crowd for example.
But the game developers who are more interested in offering something interesting for their gamers to play may well be more supportive.
We did discuss adding more sound generation to the custom-cart last time it was raised in addition to what I put above - to enhance the gaming experience. Generally, and me and Prophet36 feel the same about this is that it no longer is the MD when you bypass the VDP and the video output stage but sure, if someone wants to design a cart that has more math power, more sound channels and they do something interesting with it that is fine in my book. The demo people will write more optimised code and try to do the maximum in the smallest amount of memory so the two outlooks in my book are quite seperate but both valid.


And I am not "insisting on it", Sik - I am merely stating what is known about solving a given problem.

I feel that it is easy to write just in C or some other high-level language as NG:Dev do on their NeoGeo releases with most of the work being carried out by the FPGA/CPLD based device and the results being sent to the 68K on the NeoGeo.

However, in order to know how long a stick is you need to first measure it - which is why I write in Assembly on the MD and why I have not gone all out on using custom-hardware.
UMDK Fanboy

User avatar
Sik
Very interested
Posts: 714
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: [WIP] Not a debug cart project!

Post by Sik » Thu Feb 04, 2016 11:03 pm

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
Sik is pronounced as "seek", not as "sick".

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest