bincon.exe removes 2048 bytes from the beginning of 0WINCEOS.BIN and discards those bytes. It does not fill the last 2048 with zeros, it copies the previous 2048 bytes and duplicates it at the end of the file.
Just taking a step backing and thinking about some things here for a moment. Why do we do this with bincon?
Kalisto's release of Midway's Vol. 1 was the earliest time I see someone running WinCE code, on 7/25/2000. This was using Utopia bootCD, and the 0WINCEOS.BIN was renamed 1ST_READ.BIN and they cut the first 2048 bytes and repeated the last 2048:
Today we bring you the first working Windows CE game for your DC. This works with the current boot loader and once again shows you what is possible with the current boot loader. Have fun with the first WinCE game and remember who did it first.
They also did Sega Rally 2 without CDDA on 7/27 and Nightmare Creatures 2 with CDDA on 7/28, Armada on 7/29, etc.
Meanwhile bincon was written by dopefish so that 0WINCEOS.BIN could be loaded by the Utopia Boot CD, released on 7/28, clearly he copied Kalisto's work:
usage: bincon <0WINCEOS.BIN file> <new 1ST_READ.BIN to create>
example: bincon 0WINCEOS.BIN 1ST_READ.BIN
It does what it says it does. It allows you to run DC WinCE apps withUtopia's Boot Disc v1.1.
[...]
Thanks to:
-Utopia for the boot disc; we wouldn't be here without them.
-Kalisto for cracking the first WinCE games; I couldn't have written this without that.
Kalisto did the first selfboot pirate with Katana-developed Virtua Fighter 3tb next month on 8/19/2000 and a month later on 9/19/2000 Echelon released the selfboot toolkit, designed to allow people to make non-selfboot pirate releases into selfboots. It says WinCE binaries won't need to be binhacked and mentions nothing about bincon. This makes sense because clearly Utopia bootCD pirate versions already had their binaries "bincon'ed"
So it sounds to me like:
1. The Dreamcast loads binaries differently depending on if they're Katana or WinCE games, and the Utopia only wrote their loader to load binaries Katana-style
2. Instead of writing a WinCE type loader, Kalisto modified the binary so that it would load like a Katana binary
3. When converting these Kalisto releases to selfboot with the selfboot toolkit, Echelon realized WinCE bins worked if you kept the Katana binary format and made sure it was set to Katana in the IP.BIN meta info
4. Everyone has just taken for granted that we can do bincon+Echelon IP.BIN+check Katana in IP.BIN to load WinCE binaries, thus no one ever bothered to do a disc with WinCE OS selected and WinCE IP.BIN (esp. since it needs assembly hacking to unlock the drive)?
Does anyone know what the difference is between loading with Katana OS vs. WinCE OS set in IP.BIN?
Perhaps this is causing an incorrect/unexpected memory state?