External Memory Map (Accessed with MOVX)

Status Codes

• Working - A reasonable number of tests have been done and this feature appears to be working properly.
• Looking Good... - Working in initial tests, but not enough tests have been done to know if it really works well.
• Untested - It's implemented and ought to work, but no tests have been done yet to see if it's actually working
• Unimplemented - Some piece of hardware is still missing to allow this feature to work... but since it's on this list, at least some of the hardware is in place.
• Missing - None of the hardware exists yet. These appear on a list at the bottom, because their functionality is not yet well defined enough to be added to the register list.

^* Data Type: "16 bit INT" types are also stored as "little endian", where the LSB is stored at the first location and MSB are the second. "Flag" types are special locations that cause an action when written. They do not have data associated with them, so any byte may be written (whatever's in the accumulator at the moment?).

Missing Stuff

• Tri-state all the IDE interface pins when the PC power sense pin is pulled low. There needs to be a way for the firmware to know this has happened.
• Interrupt mask. Right now there's no way to mask the individual interrupt sources. The current firmware (0.5.0) does polling by reading IRQ_IDENT and ignores the interrupt pin.

TODO: add memory map for code space.... explain bank swap, normal code goes in bank 0, how to properly call to and return from code in bank 1, how to get code to download to the correct bank, and possibly other issues I missed in this list.

TODO: explain how the DMA works. General process: do setup for that source has data, make sure pages are properly mapped, set up DMA parms, write to go flag, when interrupt happens it's done, clear interrupt with ack flag. All DMA channels are separate and can be used concurrently (sending data to MP3 decoder while also transfering sectors from the drive). DRAM is still accessible during DMA transfers, and it's ok to remap pages that aren't involved in the transfer.

IDE Port, 16 Bit Access

Accessing 16 bit data from the IDE port is tricky. Usually you would read IDE_DATA (0xFF60) first to get the LSB. Reading this register causes all 16 bits to be read into the FPGA's 16-bit buffer for the IDE port, so the upper 8 bits may be read using the IDE_DATA_BUF_MSB (0xFF43) register.

The tricky part is that any 16 bit access to or from the IDE drive or the DRAM will reuse the buffer and overwrite its contents. So, if you have code like this:

    xdata unsigned char my_lsb, my_msb;
    my_lsb = read_fpga_reg(0xFF60);
    my_msb = read_fpga_reg(0xFF43);

    data unsigned char my_lsb, my_msb;
    my_lsb = read_fpga_reg(0xFF60);
    my_msb = read_fpga_reg(0xFF43);

    data unsigned char my_lsb, my_msb;
    EA = 0;
    my_lsb = read_fpga_reg(0xFF60);
    my_msb = read_fpga_reg(0xFF43);
    EA = 1;

I don't currently have a reasonable way to work around the DMA access... so this is a pretty serious limitation which will need to be addressed in the hardware to enable you to make use of 16 bit PIO access to the IDE interface.

One thing that might make you life a bit easier is using some C syntax to directly access the registers, instead of having to call assembly language helper functions. You can declare the FPGA registers like this:

    volatile xdata unsigned char at 0xFF60 reg_ide_data;
    volatile xdata unsigned char at 0xFF43 reg_ide_buf_msb;

Flash ROM (Code) Memory Allocation