GDSDF7 schematics

Discussion in 'Rare and Obscure Gaming' started by kammedo, May 5, 2007.

  1. kammedo

    kammedo and the lost N64 Hardware Docs

    Joined:
    Sep 24, 2004
    Messages:
    2,138
    Likes Received:
    12
    GDSF7 schematics

    Any of those lying around here somewhere?
     
    Last edited: May 5, 2007
  2. Calpis

    Calpis Champion of the Forum

    Joined:
    Mar 13, 2004
    Messages:
    5,906
    Likes Received:
    21
    Even if there were schematics (I'm positive there aren't any online!), you can't get the ASIC anywhere but from a GDSF7 and you aren't going to build the ASIC which contains over 100 DFFs and a few thousand gates! It is also not easy to solder the SMD RAM required.

    If you want to make your own copier, you must really know what you're doing. I can give you some pointers but probably if you're capable of pulling any part of it off, you shouldn't need help. I would suggest making a copier with a small CPLD, 62256 SRAM, 2764 ROM, 4MiB SIMM and 8272 floppy controller, that's all you need. If you want, I can describe all of the logical components of a SNES (or any other system's) copier.
     
    Last edited: May 5, 2007
  3. MottZilla

    MottZilla Champion of the Forum

    Joined:
    Feb 1, 2006
    Messages:
    5,066
    Likes Received:
    102
    I'd love to hear it. ;)
     
  4. Calpis

    Calpis Champion of the Forum

    Joined:
    Mar 13, 2004
    Messages:
    5,906
    Likes Received:
    21
    Logical components:

    -Address decoding, this will decode the config register and floppy registers. It should partially decode SRAM (the rest is decoded via config register logic) since there are multiple configurations.

    -Config register(s), this maps the BIOS/SRAM/DRAM/cartridge into the address space. This is a decoded register feeding combinatorial logic. This will also define the DRAM's memory map if the unit does not simulate mirroring (open bus) via software. For a good SNES copier, this should also preform SRAM limiting. It would be a good idea to have a feature to unmap the copier registers too in order to dump any cart freely.

    -DRAM controller. This is a state machine which generally preforms a CBR refresh loop on all DRAM chips while the "ROM" is inactive. When active it preforms a read/write sequence using RAS, CAS and the DRAM multiplexer bit. The DRAM controller preforms multiple operations per ROM cycle making this the most complicated part of a copier.

    -DRAM multiplexer. DRAM is addressed in a square grid, to address the RAM's word you need to strobe your row and column in addition to asserting address bits as you would do with a ROM or SRAM. You thus need to assert half the bits, strobe, assert the other half and strobe again.

    -Copiers which store multiple games (GDSF, Supercom) use bankswitching. They have a special config register array which correlate to blocks of memory in the SNES memory map. The register's bits are put through a giant multiplexer then are output to DRAM address lines, when the particular memory area is active, the MUX switches to the section of ROM defined by the register. The BIOS must keep track of how a game's mapping works and where the game's blocks are stored in RAM so that it can reassemble them to a linear ROM.

    -Parallel ports are implemented with a input "register" (tristate chip) and output register, data arbitration is provided through software. Usually there's a hardware handshake consisting of a single flipflop.

    -DSP support is achieved by passing DSP areas to the external cartridge slot (or the socketted DSP on the mobo). In order for a LoROM DSP game to work with a HiROM external cartridge or vice versa, simple address translation has to be preformed.

    Soft components:

    -Accessing cart memory (ROM, SRAM) involves either comapping the cart with the BIOS/copier RAM concurrently or switching between the two using code in the console's RAM.

    -Game genie type cheats (Golden Finger) aren't applied in hardware, they're preformed before the game is loaded.

    -Real time save/slow motion add a portion of ROM to an obscure area of memory. The game's Vblank vector is hijacked to point to this routine where the controller is polled. If the hotkeys are triggered, the copier runs a routine to save/restore the consoles state to the best of it's abilities. DRAM has to be used to store the immense amount of data. The routine then hands control back to the game's real Vblank handler. This routine is also how RAM modifying codes (Action replay type) work, every Vblank they modify variables. Slow motion is realized through repetitive saves/restores. Because real time save can't backup/restore every vital component of the system (because you can't access all hardware aspects from software) and because even when it's not used but turned on, it steals CPU time, it's a very buggy feature. Copier RTS will never match an emulator's, it's impossible to without emulating the console itself.
     
    Last edited: May 8, 2007
sonicdude10
Draft saved Draft deleted
Insert every image as a...
  1.  0%

Share This Page