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.

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 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).

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..