[WIP] Not a debug cart project!

For hardware talk only (please avoid ROM dumper stuff)
doragasu
Very interested
Posts: 125
Joined: Tue Oct 09, 2012 8:15 am

[WIP] Not a debug cart project!

Post by doragasu » Mon Feb 01, 2016 2:59 pm

Image

db-electronics
Very interested
Posts: 89
Joined: Mon Feb 24, 2014 6:04 pm
Location: Kapuskasing, Ontario, Canada
Contact:

Re: [WIP] Not a debug cart project!

Post by db-electronics » Mon Feb 01, 2016 4:24 pm

MegaWifi!!!
What does db stand for? Well that's an excellent question...
http://www.db-electronics.ca

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

Re: [WIP] Not a debug cart project!

Post by doragasu » Tue Feb 02, 2016 7:30 am

Image
First prototype

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 » Tue Feb 02, 2016 2:10 pm

Hah! WiFi on the MD, nice :D

What is this going to be used for?

HardWareMan
Very interested
Posts: 727
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Re: [WIP] Not a debug cart project!

Post by HardWareMan » Tue Feb 02, 2016 5:57 pm

In the 200x I planned to connect HDD and VS1001 MP3 codec. Well, HDD was connected, codec don't. Later HDD was swapped to microSD.
Image
You can see here: link port with PC via LPT, HDD drive to save dumps and system cartridge. There was 128KB SRAM (expandable to 1MB) cartridge for load and run dumps. MD get power from HDD board.

Also you can notice DTACK module near Z80. It fire DTACK pulse if it don't appear after 8 VCLK pulses. ;)

Image
10 years passed...

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

Re: [WIP] Not a debug cart project!

Post by doragasu » Tue Feb 02, 2016 7:49 pm

@HardwareMan: Impressive! Maybe you should rescue that project!
Oerg866 wrote:What is this going to be used for?
There are some devs in 1985alternativo interested in making an online game, but as they are also busy with other things, it's not clear if it will ever materialize. Anyway, I would like to release everything as free hardware and software, just in case anyone is interested in developing for this thing. But I don't know when. I don't even know when it will be finished...

I havent yet tested all the hardware, but everything I tested works: I can flash and play games, and I can talk to the UART, send and receive data. Unfortunately I have a ton of software to write before I can test the WiFi chip. Right now I'm extending my programmer functionality to allow loading firmware on the WiFi module...

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

Re: [WIP] Not a debug cart project!

Post by doragasu » Tue Feb 02, 2016 7:55 pm

BTW: Now than I talk about software, I think the main challenge I'll face is maximizing throughput while ingame. The UART I'm using has tiny 16-byte TX and RX FIFOs, so if I want to avoid wasting too much time polling, I'll be limited to 16 bytes per frame, unless I use HBLANK interrupts or any other trick I can think of to check the UART at regular intervals. I'm open to suggestions in this regard.

It's a shame the MD does not have a single interrupt pin in the cart slot!

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 » Tue Feb 02, 2016 10:48 pm

Seems quite interesting, even though I despise WiFi for gaming...
It's a shame the MD does not have a single interrupt pin in the cart slot!
This, a thousand times :(

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 02, 2016 11:06 pm

doragasu wrote:BTW: Now than I talk about software, I think the main challenge I'll face is maximizing throughput while ingame. The UART I'm using has tiny 16-byte TX and RX FIFOs, so if I want to avoid wasting too much time polling, I'll be limited to 16 bytes per frame, unless I use HBLANK interrupts or any other trick I can think of to check the UART at regular intervals. I'm open to suggestions in this regard.

It's a shame the MD does not have a single interrupt pin in the cart slot!
EXT_Int is one option.

You can also optimise your data Tx by calculating the best time to transmit keyed off one of the H/V-Interrupts - which you can get on the Cart Slot. Think of it as a sort of PLL between the MD and your custom hardware.

What do you need software wise, you mentioned needing to write a tonne of sw first.
PM me if you need assistance.
UMDK Fanboy

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

Re: [WIP] Not a debug cart project!

Post by Sik » Tue Feb 02, 2016 11:55 pm

Honestly, for wi-fi the best option would be to.just have a coprocessor talk to the wi-fi hardware and then it talks to the 68000 by passing around blocks of memory. But I bet this would be expensive and would not work over the joystick ports, on the other hand performance would.be much better and would not require much polling (maybe once or twice a frame?)
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 8:01 am

MintyTheCat wrote:EXT_Int is one option.
Is this the interrupt available on the gamepad ports? I would like the device to be connected only to the cart slot.
MintyTheCat wrote:You can also optimise your data Tx by calculating the best time to transmit keyed off one of the H/V-Interrupts - which you can get on the Cart Slot. Think of it as a sort of PLL between the MD and your custom hardware.
Neat idea! I was thinking of using UART RTS/CTS handshaking for the WiFi module to transmit whenever it wants until filling the UART RX FIFO, without the need of a precise synchronization. But wiring the HSYNC/VSYNC signals to the module might be a good idea "just in case".

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

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 1:35 pm

doragasu wrote:
MintyTheCat wrote:EXT_Int is one option.
Is this the interrupt available on the gamepad ports? I would like the device to be connected only to the cart slot.
Yes, EXT-Int is found on the Controller ports. It is a level 2 IRQ so it is the lowest priority on the MD.
The EXT-Int signal is not available on the cart connector so you cannot use it in that case.
doragasu wrote:
MintyTheCat wrote:You can also optimise your data Tx by calculating the best time to transmit keyed off one of the H/V-Interrupts - which you can get on the Cart Slot. Think of it as a sort of PLL between the MD and your custom hardware.
Neat idea! I was thinking of using UART RTS/CTS handshaking for the WiFi module to transmit whenever it wants until filling the UART RX FIFO, without the need of a precise synchronization. But wiring the HSYNC/VSYNC signals to the module might be a good idea "just in case".
So, given that you want this to be cart slot only you cannot use the UART as it is without having a seperate connector to the controller port. To be honest, I would not consider the UART as it is very, very slow.
But synchronising your state-machine on the WiFi board's side is a better way to do things. You can be absolutely sure of the H/V-Sync signals however you shall need to configure the H-Sync Interrupt to what you expect it to be on the MD side [1].

Essentially, you buffer all the data to be written or read on the active V-Blank then you do your updates to the MD (reads and writes) on the inactive.
You have the full 68K Address and Data Buses on the cart connector. I would forget the UART :D
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 have discussed amongst ourselves creating an enhanced MD cart with themes such as which type of device: uC, DSP, CPLD, FPGA coming up and power margins being significant. No one to my knowledge has sat down and designed anything as yet that would keep things within an acceptable budget. I hope this changes in future so that the MD can tell the SNES which way things are meant to be :)

[1] http://md.squee.co/VDP#.240A_-_Horizont ... pt_Counter
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 » Wed Feb 03, 2016 5:00 pm

@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!

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

TmEE co.(TM)
Very interested
Posts: 2370
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: [WIP] Not a debug cart project!

Post by TmEE co.(TM) » Wed Feb 03, 2016 5:04 pm

Those TI DSPs are garbage, ADI ones are waaaaaaay better.
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

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

Re: [WIP] Not a debug cart project!

Post by Sik » Wed Feb 03, 2016 5:29 pm

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

Post Reply