MintyTheCat wrote:The other thing that some how I had not gotten around to was that it would be really great if UMDK's Memory-Map could be put somewhere for reference
Good idea. Here goes:
SSF2 Banking
Each UMDK cart has 8 or 16 MiB of physical SDRAM. This is accessible contiguously by the host using the "loader" command's "-r" and "-w" options. The SDRAM can always be read and written, irrespective of whether the MD is executing or not. This 16MiB can be mapped into the MegaDrive's ("logical") address space using banking registers. The bare minimum to support
SSF2 is to implement the
bank-switching registers specified by SEGA, but UMDK extends those by splitting the 16MiB of physical SDRAM into 32 pages, 512KiB each, any of which can be mapped into any of the 512KiB logical ranges in the bottom 4MiB of the MegaDrive address-space (except the bottom 512KiB, which is hard-coded to SDRAM page 0), and into any of the 512KiB ranges in the 4MiB above that (except the 512KiB at 0x400000, which is hard-coded to SDRAM page 31, and is reserved for use by UMDK). The default on power-up is a 1:1 mapping of logical to physical addresses, except in the logical range 0x400000 - 0x47FFFF as I mentioned.
Rather than use new registers I have just reused the existing SSF2 registers, with bit 6 selecting whether to affect the first or the second 4MiB range. Here are some examples:
Ex 1: Map SDRAM page 31 at 0x080000 - 0x0FFFFF
Ex 2: Map SDRAM page 0 at 0x380000 - 0x3FFFFF
Ex 3: Map SDRAM page 1 at 0x480000 - 0x4FFFFF
Ex 4: Map SDRAM page 2 at 0x780000 - 0x7FFFFF
The first two examples are specified by SEGA; the latter two are UMDK's proprietary extensions. So you can map any of the 32 SDRAM 512KiB pages into any of the the seven SEGA-specified regions, and into any of the seven additional regions defined by UMDK:
Code: Select all
SSF2 REGISTERS
-------------------------------------------------------
| Register | D6=0 | D6=1 |
|-----------|---------------------|---------------------|
| 0xA130F3: | 0x080000 - 0x0FFFFF | 0x480000 - 0x4FFFFF |
| 0xA130F5: | 0x100000 - 0x17FFFF | 0x500000 - 0x57FFFF |
| 0xA130F7: | 0x180000 - 0x1FFFFF | 0x580000 - 0x5FFFFF |
| 0xA130F9: | 0x200000 - 0x27FFFF | 0x600000 - 0x67FFFF |
| 0xA130FB: | 0x280000 - 0x2FFFFF | 0x680000 - 0x6FFFFF |
| 0xA130FD: | 0x300000 - 0x37FFFF | 0x700000 - 0x77FFFF |
| 0xA130FF: | 0x380000 - 0x3FFFFF | 0x780000 - 0x7FFFFF |
-------------------------------------------------------
The 0x400000-0x47FFFF logical range is analogous to the 0x000000-0x07FFFF logical range, which SEGA specifies as fixed (not bankable). The difference is, whilst the 0x000000-0x07FFFF range is fixed to SDRAM bank 0, the 0x400000-0x47FFFF range is fixed to SDRAM bank 31, which I'm claiming for use by the UMDK monitor. That gives game developers 15½ MiB to play with, which is
hopefully enough!
SPI Controller
The SPI controller allows you to read and write to the flash and SD-card. There are three registers, SPIDATW=0xA13000, SPIDATB=0xA13002 and SPICON=0xA13004. The SPICON register looks like this:
Code: Select all
SPICON (0xA13004)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|15|14|13|12|11|10| 9| 8| 7| 6| 5| 4| 3| 2| 1| 0|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
\_________________________________/ | | | |
| | | | \ TURBO
RESERVED (MUST BE ZERO) | | |
| | \ SUPPRESS
| |
| \ FLASHCS
|
\ SDCS
The TURBO bit allows you to select the SPI clock rate (1=24MHz, 0=400kHz). The SUPPRESS bit is not used, and should be set to zero. Lastly, the FLASHCS bit selects the UMDK's 512KiB boot flash, and the SDCS bit selects the SD-card.
There are two data registers, one for word-access and another for byte access. See the example code from a couple of posts back for an example of reading the flash using SPIDATW and the flash chip's 0x03 "read bytes" command (see page 25 of the
M25P40 datasheet). Basically, word-writes to SPIDATW cause that word to be sent out on the SPI bus. Word-reads from SPIDATW read the last word received from the SPI bus. As a convenience, reads also trigger a clock-out of 0xFFFF, so you can read from flash in a tight loop (~3MiB/s in turbo mode). Note that there is no way to check whether the SPI hardware has finished sending/receiving a word; you have to insert NOPs if necessary to ensure you don't try to give the SPI controller more work to do whilst it's still busy. This is partly laziness, and partly for performance (i.e it allows a tight dbra-loop containing just one instruction [e.g
move.w SPIDATW(a0), (a1)+] to read data from flash). The problem with the SPIDATW register is it only supports word-wide accesses. That's what SPIDATB is for - it behaves in exactly the same way, but for individual bytes.
If you're accessing the SD-card you should probably look at the
low-level driver and the
FAT32 implementation in the menu program, rather than implementing your own code at the hardware-register level. I'm happy to write proper docs for these APIs if someone's actually interested.
Soft Reset
There's a register at 0xA13006 which is a little tricky. It allows the MegaDrive to do a hard reset from software. It's used in
the trap #0 handler of the menu program to allow the newly-loaded game to be started as if from power-on. You use it by writing the magic number 0xDEAD to 0xA13006.
Flash Boot Process
The first-stage bootloader lives in a
small ROM in the FPGA. Its sole purpose is to start the second-stage bootloader by reading 256 bytes from flash address 0x060000 into WRAM at address 0xFF0000, and jumping into it.
The
second-stage bootloader loads 1024 bytes of monitor code from flash starting at 0x060100 into SDRAM at 0x400000, then it loads the next 512 bytes from flash (making up the menu program's vectors and cart metadata) into SDRAM at 0x000000, then it loads next ~64KiB from flash (making up the actual code of the menu program) into SDRAM at 0x420200 and starts it running. The reason the menu program is loaded so high is because it needs to be able to load games without overwriting itself. The menu program itself uses the banked logical range 0x480000 - 0x4FFFFF to load the selected game ROM, but that range is free for use after loading is complete.
Monitor Program
The
monitor program is loaded by the flash-boot sequence at logical address 0x400000. It is the thing which actually implements the gdb bridge, by intercepting the 68000's single-step and illegal-instruction vectors. It uses the range 0x400400 - 0x410447 for maintaining the communication with gdb. So technically the range 0x410448 - 0x47FFFF is free, but I'm claiming it as UMDK-reserved, so writing to it will result in undefined behaviour.
I think that's everything. Let me know if it's unclear and I'll re-work it.
)
