SpritesMind.Net

Is the 0xB00000-0xBFFFFF range known to be used by anything? I can't find anything in my notes about usage in this area, and nothing comes to mind....

Nemesis wrote:I'm ordering the parts for this today, gonna build one ASAP.

That's great! Provided you can assure me you have the right tools and experience for soldering the 0.5mm-pitch FPGA, I'd be willing to sell you some blank PCBs at cost. The PCB runs were USD 75.60 for ten FPGA boards and USD 36.75 for ten bridge boards, so that comes in at USD 11.24 per cart, plus postage from the UK, which will be an extra few dollars to Australia (sorry about denominating everything in USD but that's how the electronics world seems to work and I don't much like swimming against the current!).

Nemesis wrote:I'm also interested in making some tweaks to get this unit compatible with a MegaCD attached....and assert DTACK yourself.

I have not tried DTACK generation, but one of the FPGA I/Os is connected (via a transistor to avoid a 5V appearing on the FPGA pin) to DTACK, but I currently don't populate it, just relying on the automatic DTACK generation in the 0x400000-0x7FFFFF range.

The monitor code itself is currently 426 bytes, but that could be crunched a bit by using movem.l instead of move.l to save the registers. And it needs an extra 18 longwords to store the 68000 state, but it also uses 64KiB of the 0x400000-0x7FFFFF range for the message-exchange with the host (e.g to allow the host to read the MD's onboard RAM). So you need to find a suitable hole that is 65KiB or so in size. If none are available you could reduce the maximum size of the message payload below 64KiB and just split requests up on the host side.

The 0x400000-0x7FFFFF region is also banked in the same way as the 0x000000-0x3FFFFF range is, using the SSF2 registers. Basically the SDRAM is split into 32 pages of 512KiB, with 0x000000-0x07FFFF locked to page 0 (as spec'd by Sega) and 0x400000-0x47FFFF locked to page 31, but any page can be mapped into any other slot using D6 to choose between mapping in the lower 4MiB range or the upper 4MiB range: Also, the menu program uses part of the 0x40000-0x7FFFFF range to load data into the lower 4MiB range (on my MD2 the write strobes don't trigger properly in the lower 4MiB so I load games off SD card into SDRAM mapped a page at a time into 0x480000-0x4FFFFF).

The SPI interface and hardware reset trigger also use four 16-bit registers at 0xA1300x.

Nemesis wrote:I'm very interested in this hardware, and I'm more than happy to contribute some enhancements. One thing I really want is a fast and easy way to stream data back from the Mega Drive to the PC over the USB link, driven by the 68000 processor, IE, by writing to some target addresses. Is there currently any way to do this kind of thing? What I'd really love is a DMA mode where the kit itself can take ownership of the bus and do DMA from ram for example, and transfer to the PC. A lot more work, but it would give the best performance. Still, just the ability to stream data back over a USB link would be awesome.

Well, my SDRAM controller is dual-ported (that's how the monitor works - it waits for the host to send it a message by writing the message payload into SDRAM and then writing to a semaphore to trigger the "send"). So you already have DMA, effectively. The problem is you're limited to about 3MiB/s that way because of the way the interleaving is done. An alternative would be to provide a way to guarantee that the 68000 will leave the SDRAM alone whilst the host has exclusive access, and then you'll get about 10MiB/s. One way to achieve that is by making a hardware register in the FPGA either serve the opcode for "bra.s -2" or "rts". That way you can just do "jsr 0xA13xxx" to both trigger the DMA and be sure that control returns to you precisely when the DMA is complete. I used that trick in an early prototype whose memory wasn't fast enough to dual-port. I can explain it further (with ugly code) if you're interested.

The USB link itself will go up to 42MiB/s without breaking sweat, but you have to be able to produce data fast enough, which is tricky on a 7MHz 68000!

Nemesis wrote:Looking at the videos he's posted, I can see he needs a space in memory large enough to store the monitor program for the 68K debugger, so that's not going to fit in the 0xA130XX region. I think picking a gap between a repeat of the VDP interface is the best bet. There are large gaps at 0xC10000, 0xC90000, 0xD10000, and 0xD90000. You've got 0x6FFFF continuous bytes per block, times 4 blocks. A bit less convenient than the 0x800000-0x9FFFFF range, but almost as big. It's large enough for bankswitching to be not too painful too.

Oh, I see. Gaps in the CD address range may also be the best way to handle it.

Personally, I'd put a slight more hardware toward the problem like this:

Have it at 0x200000 like the sram, and have it enable/disable like the sram. Then have a tiny fragment of code at 0xA130xx that turns on the bank and jumps to it.
7 words of a fixed value for the bank switch and jmp, and one for the bank select control. Easy.

The region used by the monitor has to be mapped in all the time, (a) because it's the target of several exception vectors, and (b) it's shared memory and is used for message-passing between the host & MD.

hi there,

For any more question, be free to open a new topic on the dedicated UMDK section.
It'll make it easier for other people to look for/share information.

Thanks

KanedaFr wrote:hi there,

For any more question, be free to open a new topic on the dedicated UMDK section.
It'll make it easier for other people to look for/share information.

Thanks

Yes, I feel that UMDK needs its own Section entirely. I also want the Community to support it as Prophet has given the MD Community something highly useful and his work must not be disregarded.

Chilly Willy wrote:Oh, I see. Gaps in the CD address range may also be the best way to handle it.

AFAIK there are no gaps in CD address range, it's mirrored all over the place as upper address lines are simply not connected to expansion port..

I think he meant gaps in the 0x800000-0xFFFFFF range.

It would be nice if you could take over the work ram area. You have two megs of space there, and only need to present 64KB for compatibility. You could keep 1M (- 64K) of ram for code and data, 512K of flash, and 512K for hardware.

Yeah, if only...

Chilly Willy wrote:It would be nice if you could take over the work ram area. You have two megs of space there, and only need to present 64KB for compatibility. You could keep 1M (- 64K) of ram for code and data, 512K of flash, and 512K for hardware.

Pity but internal 64K takes all of this 2 regions: $E and $F. And you can't use them without hardware modding the console.

HardWareMan wrote:

Chilly Willy wrote:It would be nice if you could take over the work ram area. You have two megs of space there, and only need to present 64KB for compatibility. You could keep 1M (- 64K) of ram for code and data, 512K of flash, and 512K for hardware.

Pity but internal 64K takes all of this 2 regions: $E and $F. And you can't use them without hardware modding the console.

Yeah, but that would make a better debug setup - mod the console to insert the hardware there and sell as a debug console. The extra ram would make it easier to debug games as well. The developer version of most consoles usually has twice the ram of the consumer models just for debug purposes. A cart is good, but a dedicated debug console is best, if more expensive.

Why would extra RAM make debugging easier?

Actually, that question could do with further elaboration. I can see how extra RAM would be useful in a traditional development environment, where the only way of tracing what's going on is to write log information and metrics to some extra RAM and then read it back later for analysis. But if you have full source-level debugging and 20ns-accurate arbitrary-length nonintrusive bus-tracing, why does having extra RAM help?