June 2007
    Jul »

IC2005 Smart Shop

OSX PCE flash cart commandline utility v0.1

OSX PCE flash cart commandline utility v0.1

more info: OSX PCE flash cart commandline utility v0.1

Ok. Here's the very first 'beta' of the OSX PCE flash cart commandline utility. Download the sources and the precompiled binary for PowerPC OSX. Please read the readme.txt for instructions.




My OSX version is 10.4.6. You need to have libusb installed — get it from e.g. source forge. This program might be a bit buggy as I haven't done any extensive testing. However, it has so far worked for me (and that's what I care about). Some things are still a bit unclear because of the lack of proper documenation. Have fun.


Slim-e-loader v0.1 (c) 2005-2006 Jouni 'Mr.Spiv/Scoopex' Korhonen

What is Slim-e-loader?

        Slim-e-loader is a tool for OSX/Linux/BSD/… to flash PC-Engine
        ROM images using Neoflash SlimLoader IV and Neoflash PCE cart.
        Currently 64M PCE flash cart is supported.
        To find out program options type:
     slimeloader -h

        Sources are provided.

Terms of use:

        No warranty of any kind. Please, don't 'borrow' the source without
        giving the credit. If you enhance the program or fix bugs, please
        send them to me as well.

        The program, even slightly hacky, has been done poratbility in mind.
        The USB part uses libusb and everything in endianess clean.


        Below are a couple of examples how to use the Slim-e-loader.

        To flash a set of roms with menu type:
            slimeloader -m -p rom1.pce rom2.pce rom3.pce rom3.pce etc

        To flash a single rom (without menu) type:
            slimeloader -p rom1.pce

        To flash 3 roms with manu and also saving the rom image to disk:
            slimeloader -s output.pce -p -m rom1.pce rom2.pce rom3.pce

Version history:

        – v0.1 Initial version. Supports only flashing ROM images and
          uses Neoflash's multi-rom menu code.

Technical information:

        This tool is a result of minor reverse engineering. Basically
        the protocol has been taken from dumped USB traffic on Windows
        platform. Nothing special.
        There are known issues of checking possible headers on roms.
        Current implementation tries to strip away the 512 bytes dummy
        header that is present in some rom images. This functionality
        is applied only when multiple roms are flashed.

        The multi-rom menu is shamelessly taken from Neoflash and
        included into the Slim-e-loader.


        o Add ROM dumping
        o Own multi-rom menu
        o Bug fixes (I'm sure there are plenty)

Mambo Jambo:
        Have fun. Comments, bug reports etc:
        mouho@iki.fi or meet me at EfNet.
        Check my lousy development pages:
        /Jouni aka Mr.Spiv
        ..in memorian of StoneCracker 🙂


        o Wntrmute @ EfNet – for his help with the SlimLoader III reversing
          (and his nice Makefile 😉
        o Neoflash for their multi-rom menu and making this hardware.


Some information how roms need to be stored into PCE flash cart:

        Following information is based on trial and error. Assuming we
        have different sized PC-Engine roms like 2Mbits, 3Mbits, 4Mbits,
        8Mbits and 20Mbits. At least I have experience with previously
        listed rom sizes. When a rom is stored into the flash it needs to
        have be aligned to its 'natural' alignment. The following table
        shows the alignment:
         o 2Mbits -> start rom at address that is divisible by 0x40000
         o 3Mbits -> start rom at address that is divisible by 0x80000
         o 4Mbits -> start rom at address that is divisible by 0x80000
         o 8Mbits -> start rom at address that is divisible by 0x100000
         o 20Mbits -> start rom at address that is divisible by 0x100000

        That's the basic rule and appears to be working. Slim-e-loader
        has a sorting algorithm build in that tries to arrange roms as
        optimally as possible into the flash cart.

Some preliminary information how bank switching on the 64M flash cart:

        After the PC-Engine reboots the bank #0 of the cart gets mapped
        to 0xe000 -> 0xffff, where also the reset vector is located (0xfffe).
        This is standard PC-Engine boot stuff. The bank switching code itself
        needs to be run off RAM. Neoflash's menu v1.03 seems to run switching
        code from 0x800 (mapped to 0x0000).

        To switch bank do the following (64M cart):

         o write 0x57 to 0xfff0
         o write 0x75 to 0xfff0
         o write 0x63 to 0xfff0
         o write BANK_HI to 0xfff0

         o write 0x57 to 0xfff0
         o write 0x75 to 0xfff0
         o write 0x85 to 0xfff0
         o write BANK_LO to 0xfff0

         o write 0x57 to 0xfff0
         o write 0x75 to 0xfff0
         o write 0x36 to 0xfff0
         o write SZ to 0xfff0
         o write SZ to 0xfff0

        Jump to 0xfffe  (reset vector).

        BANK_HI is the high byte of the 16bits bank address. BANK_LO is the low
        byte of the bank address. One bank is size of 0x0400, which represents
        1Mbits. The Neoflash's menu v1.03 always rounds all roms to 2Mbits boundary i.e.
        the address is divisible by 0x0800.

        As an example Neoflash's menu v1.03 is located in the cart at address 0x0000
        and its size is 2Mbits. Then the next rom can start at 0x0800 (BANK_HI is 0x08,
        BANK_LO is 0x00).

        The SZ is 0x86 for 2Mbits rom, 0xc4 for 3Mbits rom, 0x84 for 4Mbits rom,
        0x80 for 8Mbits rom and 0x80 for 20Mbits rom. Why the SZ is like this I don't
        know for sure yet.

        Reading from 0xfff0 tells the cart size. If the read returns 0x00 then the cart
        is 64Mbits. If the read returns 0x01 then the cart is 128Mbits. Again, I don't
        have 128M cart to verify this..


Leave a Reply