[WIP] Not a debug cart project!
-
- Very interested
- Posts: 89
- Joined: Mon Feb 24, 2014 6:04 pm
- Location: Kapuskasing, Ontario, Canada
- Contact:
Re: [WIP] Not a debug cart project!
MegaWifi!!!
What does db stand for? Well that's an excellent question...
http://www.db-electronics.ca
http://www.db-electronics.ca
Re: [WIP] Not a debug cart project!
First prototype
-
- Very interested
- Posts: 211
- Joined: Sat Apr 19, 2008 10:58 am
- Location: Frankfurt, Germany
- Contact:
Re: [WIP] Not a debug cart project!
Hah! WiFi on the MD, nice
What is this going to be used for?
What is this going to be used for?
-
- Very interested
- Posts: 746
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar
Re: [WIP] Not a debug cart project!
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.
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.
10 years passed...
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.
10 years passed...
Re: [WIP] Not a debug cart project!
@HardwareMan: Impressive! Maybe you should rescue that project!
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...
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...Oerg866 wrote:What is this going to be used for?
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...
Re: [WIP] Not a debug cart project!
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!
It's a shame the MD does not have a single interrupt pin in the cart slot!
-
- Very interested
- Posts: 211
- Joined: Sat Apr 19, 2008 10:58 am
- Location: Frankfurt, Germany
- Contact:
Re: [WIP] Not a debug cart project!
Seems quite interesting, even though I despise WiFi for gaming...
This, a thousand timesIt's a shame the MD does not have a single interrupt pin in the cart slot!
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: [WIP] Not a debug cart project!
EXT_Int is one option.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!
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
Re: [WIP] Not a debug cart project!
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".
Re: [WIP] Not a debug cart project!
Is this the interrupt available on the gamepad ports? I would like the device to be connected only to the cart slot.MintyTheCat wrote:EXT_Int is one option.
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".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.
@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.
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Re: [WIP] Not a debug cart project!
Yes, EXT-Int is found on the Controller ports. It is a level 2 IRQ so it is the lowest priority on the MD.doragasu wrote:Is this the interrupt available on the gamepad ports? I would like the device to be connected only to the cart slot.MintyTheCat wrote:EXT_Int is one option.
The EXT-Int signal is not available on the cart connector so you cannot use it in that 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.doragasu wrote: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".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.
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
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 bedoragasu 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.
[1] http://md.squee.co/VDP#.240A_-_Horizont ... pt_Counter
UMDK Fanboy
Re: [WIP] Not a debug cart project!
@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
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
-
- Very interested
- Posts: 2442
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Re: [WIP] Not a debug cart project!
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
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
Re: [WIP] Not a debug cart project!
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".