low level technical curiosity on Everdrives

Discussion in 'Everdrive General' started by exdeath, Jul 31, 2011.

  1. exdeath

    exdeath Rising Member

    Joined:
    Jul 11, 2011
    Messages:
    59
    Likes Received:
    0
    Not really specific to Everdrives, but I've always wondered how the mapping switch takes place when a backup unit goes from the OS to the game ROM and back.

    For those not certain what I'm talking about, what I mean is the part of the flash that the OS is on comes up in the "start" address space of the SNES on power on. This is how we see the Super Everdrive, Double Pro Fighter, etc menu right away. At some point, the currently executing OS is magically and instantaneously "replaced" when the ROM is remapped with the user selected game. If this hand over were not carefully controlled and timed, we would be executing the OS one second loading our game and programming the CPLD to remap the address space with the flashed game ROM, then suddenly executing random game cart code or data mid execution when the selected game is mapped to the bus in the same address where the OS ROM used to be.

    Two methods I see:

    1) OS places and then jumps to some code in the host device's RAM which does the final CPLD programming to map the ROM into current address space, then jumps to the reset vector of the newly mapped ROM. This works, but once the switch occurs, RAM is wiped out and you have no way to return to your OS. The CPLD somehow has to know on reset to change the mapping back again before the SNES takes the reset vector.

    2) The CPLD itself monitors the bus and decides what to map in whenever it detects software reset. So you could remap and program everything you needed without fear of your OS disappearing, and on the next reset vector the CPLD automatically does the address space swap. OS just "resets itself" when it's done, knowing that it's going to be a game there instead of itself.

    Above, 1) doesn't seem to be the case on the Everdrive, because you can hit reset and return to the Everdrive OS when it can't possibly be in RAM anymore after game code execution has wiped it. 2) makes the most logical sense?

    Care to share any info? What are the methods for detecting resets and controlling the address space changeover back and forth? My primary assumption is that the OS and a game ROM cannot be mapped at the same time, or the largest 32-48 mbit ROMs would not be possible.

    TLDR: wondering how the dynamic remapping of the physical address space occurs mid execution (of the OS), as when loading a game ROM into the same start location that the OS started in.

    Actually looking at getting back into SNES dev, though I am spoiled by GBA's flat linear no nonsense address space. No hirom, lorom, strange mirrors, or diff bus speeds or split bank complexities. But alas no SPC700 :(
     
    Last edited: Jul 31, 2011
  2. KRIKzz

    KRIKzz Well Known Member

    Joined:
    Apr 5, 2010
    Messages:
    1,672
    Likes Received:
    2
    main code of OS placed in OS ROM, but some routines which perform bank switch or flash memory R/W placed in RAM (0x200 - 0x1000 area). they are copied to ram by OS init routine.
    when you push the reset, reset wire at cart port goes LOW and CPLD detect this moment and perform bank switch. so after reset OS code again in start of address space and ready to run

    before game start OS perform memory configuration and then perform permanent lock for all custom registers, reset switch the only way to unlock them.
     
  3. exdeath

    exdeath Rising Member

    Joined:
    Jul 11, 2011
    Messages:
    59
    Likes Received:
    0
    Ah a reset line to the cart port makes things much easier. Pin 26?

    To load a game, a OS stub is put into SNES RAM, SNES RAM code programs the bank change then jumps to the regular reset vector of the new ROM bank to start the game (soft reset)? On hard reset, CPLD sees /RESET, looks at config choice to return to OS or not, if so, remap OS portion back to start, otherwise just leave the game portion mapped and do nothing and allow the game to reset.

    And Everdrive uses a 8 MB flash with 2 MB reserved for internal use (OS, reserve OS, config settings, etc), right?

    Cool stuff, I need to get into hardware. Just got my first Everdrive and I'm inspired. I need to get me one of these and start learning Verilog:

    http://cgi.ebay.com/Altera-MAXII-MA...661?pt=LH_DefaultDomain_0&hash=item2eb1699e55

    :p
     
  4. KRIKzz

    KRIKzz Well Known Member

    Joined:
    Apr 5, 2010
    Messages:
    1,672
    Likes Received:
    2
    i not remember reset pin number, but remember that it was pin near to vcc on face side.
    yep, ram code do all copy and bank switch work. in depends of configuration CPLD may switch banks by reset or leave all as is.
    right, 8 bm total and upper 1.5mb reserved for OS
    small MAX2 board not a best choice, atera DE1 or DE0 boards the best thing for education, but they cost bit more
     
  5. KRIKzz

    KRIKzz Well Known Member

    Joined:
    Apr 5, 2010
    Messages:
    1,672
    Likes Received:
    2
    here is must have thing for fpga developers who chosen Altera:
    DE0 or DE1
     
    Last edited: Jul 31, 2011
  6. exdeath

    exdeath Rising Member

    Joined:
    Jul 11, 2011
    Messages:
    59
    Likes Received:
    0
    I'll have to get one of those. Always wanted to learn how to make my own SDRAM controller :)
     
  7. bertobp

    bertobp Rising Member

    Joined:
    Jun 10, 2011
    Messages:
    67
    Likes Received:
    0
  8. KRIKzz

    KRIKzz Well Known Member

    Joined:
    Apr 5, 2010
    Messages:
    1,672
    Likes Received:
    2
    don't know. official DE0/DE1 boards have good documentation and samples, also a lot of homebrew shared projects in internet, but i guess that your board have few samples in best case, that's all. it not really important, but for me DE1 is a much more interesting thing
     
  9. exdeath

    exdeath Rising Member

    Joined:
    Jul 11, 2011
    Messages:
    59
    Likes Received:
    0
    CPLD registers mapped to ROM addresses to the SNES? SNES is never allowed to write to ROM space/flash, and no game would ever do that, so you access CPLD registers by detecting abnormal /WRITE to a ROM address?

    I think that's what my GBA Flash Advance cart does and you can access those functions to do custom bank switching in home brew apps.

    So even after game ROM from flash is mapped and the OS ROM disappears, you can still write to the CPLD registers hidden in ROM address space (pretend you are writing to the SNES cart ROM), until you set the final register that disables them permanently until reset. But the OS code in ram checks one final thing, if the ROM has Everdrive id in the header, it doesn't do the last write to disable registers.

    Right track?
     
    Last edited: Aug 1, 2011
  10. KRIKzz

    KRIKzz Well Known Member

    Joined:
    Apr 5, 2010
    Messages:
    1,672
    Likes Received:
    2
    super ed registers area begins from 0x3000, as far as i know this area used by dsp and super fx, but not by rom. and yes, if "EVDR" ID was detected, then registers will stay unlocked, so homebrew rom could use SD, USB and flash
     
  11. exdeath

    exdeath Rising Member

    Joined:
    Jul 11, 2011
    Messages:
    59
    Likes Received:
    0
    If SED is at 0x3000 and DSP is also, what happens when the OS accesses the registers (to lock them for example before transfering control to the ROM) after loading in a DSP ROM? How is it determined whether CLPD or DSP responds?
     
  12. KRIKzz

    KRIKzz Well Known Member

    Joined:
    Apr 5, 2010
    Messages:
    1,672
    Likes Received:
    2
    DSP also contrroled by CPLD, so cpld just dissable access to DSP. honestly i can't remember where exactly mapped dsp, i should look in my cpld sources, but i remember that dsp use different mappimg for hirom and lorom
     
  13. exdeath

    exdeath Rising Member

    Joined:
    Jul 11, 2011
    Messages:
    59
    Likes Received:
    0
    So the CPLDs in these type of devices are purely address mappers or multi option address bus decoders, and all data read/write, flashing, FAT access, etc is all done in host CPU code?

    So lets go through the whole process.

    Power on. CPLD default maps "hidden" OS portion of flash chip to start address in cart space, SNES OS code inits and runs.

    Select rom image, SNES CPU reads data from SD card via SPI_DAT reads FAT data, reads rom image header, determines type of rom image (lorom, hirom, SRAM, etc). Then goes to OS code in SNES RAM with the gathered info.

    Then SNES CPU programs CPLD ROM_BANK, SRAM_SIZE, and CFG registers to change visible flash from OS portion to user game portion depending on size of the selected rom image file and this remapped flash is R/W in the game cart area of SNES as if it were RAM.

    SNES CPU reads FAT game rom image data from SPI_DAT and simply writes it all out to the ROM cart area (which is now up to 6 MB of R/W flash).

    When flash is done, SNES CPU code in RAM backs up and loads SRAM contents to SD card. Then sets CFG bits to set cart rom addresses now to read only, and locks registers. Then performs a final jump to the loaded game rom's reset vector.


    :D
     
    Last edited: Aug 2, 2011
  14. KRIKzz

    KRIKzz Well Known Member

    Joined:
    Apr 5, 2010
    Messages:
    1,672
    Likes Received:
    2
    yep, cpld it is only memory mapper and spi controller, snes cpu is a main worker
     
  15. exdeath

    exdeath Rising Member

    Joined:
    Jul 11, 2011
    Messages:
    59
    Likes Received:
    0
    SPI_DAT is just a shift register that expects standard SPI commands? CPLD takes care of the shifting and clocking each bit to the SD socket? CPLD only clocks SD 8-16 bits at a time on each access to SPI_DAT?

    CPLD faster than SNES bus cycle to shift 8/16 bits in/out of SPI_DAT as fast as the SNES can consecutively read/write to 0x3000?

    Possible to use DMA from 0x3000 to flash area, with fixed source address? Bit rusty on SNES, GBA has much more flexible general purpose DMA and I somehow recall SNES DMA end points are hard wired.
     
    Last edited: Aug 2, 2011
  16. KRIKzz

    KRIKzz Well Known Member

    Joined:
    Apr 5, 2010
    Messages:
    1,672
    Likes Received:
    2
    boards v 1.5 has 25 mhz spi, so it works more fast than snes can read, but old boards have 5mhz spi and you should check if data ready. you can't use dma because flash no a ram. flash use complex flashing algorithm with various commands, also always need to wait for end of command execution
     
  17. exdeath

    exdeath Rising Member

    Joined:
    Jul 11, 2011
    Messages:
    59
    Likes Received:
    0
    Something like this for a lo rom?

    lda #$00
    pha
    pld ; data bank $00

    ; $00:8000 snes side = $000000 on flash or depends how CPLD maps if not from beginning of flash to beginning of SNES cart

    ; begin 3 cycle PROGRAM command
    lda #$AA
    sta $8AAA ; write AA to AAA on flash

    lda #$55
    sta $8555 ; write 55 to 555 on flash

    lda #$A0
    sta $8AAA ; write A0 to AAA on flash

    ; PROGRAM command complete, now send actual byte and address

    lda BYTE ; store byte at flash address $000000, appears in SNES cart
    sta $8000 ; as $00:8000 = BYTE

    busy:
    lda $8123 ;dummy read to any flash address to get status byte and check if done programming
     
    Last edited: Aug 2, 2011
  18. KRIKzz

    KRIKzz Well Known Member

    Joined:
    Apr 5, 2010
    Messages:
    1,672
    Likes Received:
    2
    yes, also always need to erase flash sector before write, because write operaion can't set bit to '1' state, only to '0' state. erase operation set all bits to '1'
     

Share This Page