SpritesMind.Net

AFAIK, the 68k at the hardware level, cannot read a single byte: if you want to read a byte, it reads a full 16-bit word, but keeps only the relevant 8 bits (the upper or lower byte). But when writing to the cart, it can write bytes: we have LDSW line to write the lower part (at an odd address) and ...

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

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

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.

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

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

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

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

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

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

@HardwareMan: Impressive! Maybe you should rescue that project! 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 ever...

First prototype

It's just the weird name that made me suspect... Why is it called #TIME and not something like #CEX?

I have changed the program to write to 0xA130CE, and then read from the same address to a variable, and... mystery solved!: http://i.imgur.com/CXn2AfF.png I was wrongly assuming that when writing to even addresses, #LDSW was active, but it is #UDSW line the one that is lowered! In the upper capture ...