I got my rom board working last week (had to desolder the rom and resolder in a zif socket). Thanks to Charles for helping me out with some things
There’s some special stuff instore for this rom board. The one I’ll make public is the 64meg mapper based on the Street Fighter 2. I call it the extend SF2 mapper
It’ll be a series of TTL logic until I can get someone to program a PAL or GAL for me. The other project is more advanced, but you’ll just have to wait and see what it is. (Charles is awesome)
Chris Covell got pucrunch working for hucard rom projects (and fixed a bug in my code too!). This is awesome. Any real hucard project needs a serious compression scheme for tiny ram footprint project and this totally fits the bill. Pucrunch works surprisingly good with only a 256 or 512 byte buffer.
If you don’t know, Ki the author of PC2E PC-Engine emulator that Ootake is based off of, is still active in the PCE community. He’s got some serious hardware projects in the works. One of them is totally disassembled PC-Engine with each chip setup as plugin boards. He’s able to single step the whole system or clock it really slow (yes, I’m jealous). Charles and I had talked about a new method for doing the interlaced display mode on the PCE. The current method involves switching between 263 scanlines and 262 scanlines every other frame. This works great for standard definition displays and some(most?) capture cards, but it’s not a legal interlaced signal. No HDTVs (CRT or not) handle the signal correctly. There’s speculation that the VCE that generates the composite frame work/output uses a separate timing mechanism for a frames length than a scanline counter - based on a few observations from tests. IIRC, changing the register that handles this immediately ends the currently scanline - anywhere in the scanline. Ki said he should be able to take a look as this behavior at a slower rate. I’m crossing my fingers.
On a side note, the Genesis interlace mode isn’t entirely NTSC legal either. It generates a lot of half lines during vblank, but if you add all the halfs up and with the full scanlines, you get 262.5 for NTSC (which is the correct number of scanlines for interlaced mode). The interesting thing is that if those half scanlines were full (except for the last one), it would generate a PAL frame :O Speculation is that some of the internal circuitry was reused to save costs. Pretty interesting. I need to test out how my HDTV handles that interlaced signal.
Sarcie (the author of mednafen), has written a software ADPCM decoder demo for PCE. Sounds great
It uses the 10bit PCM playback channel pair method for the decoded output.
There is more news, but I don’t have time to post anymore currently. Will do so in the next few days.
October 1st, 2008 | No reply
Xavier has a new Sonic demo for CD out on the PCE
Download here
Collect the gems/emeralds to complete the stage


September 13th, 2008 | No reply
Has it really been almost a whole year since Dragon Warrior project for PCECD? Man, time’s really flying along. I haven’t heard anything from Sliver X about Dragoon Omega remix or such. I’m gonna shoot him an email and see if he’s still interesting in that project for the PCE.
On a related note, Black Tiger made a cool replacement title screen for the PCE remix of DW and it looks great. I did some work to divide up the colors (94 colors!) for PCE format. Gonna have to section off some parts into the sprite area. It’s too bad I don’t have my app for the 8×1 tile method up and running. It would have been perfect for this.
Been thinking about PCE dev tools recently. Or more specifically game development tools. It’s one thing to build a large virtual tilemap with mappy or such, but what about more complex levels that require something more akin to a script? Nothing too fancy. Take an automatic scrolling shmup for instance. You have hardcoded logic/rules, then you have a simple script with timers/frame logic, and assets like sprites, tiles, and tilemap strips. This obviously isn’t anything new to the 16bit or even later 8bit gaming world of back then. I’ve seen that some homebrew projects include *some* of the logic and boundaries into the tilemap and probably sprites as dynamic structs to a level or something similar. Fine for smaller projects, but the idea doesn’t seem as clean to me. I like the idea of developing a whole level in a editor and being able to run it through a simulator. The whole thing; enemies, scrolling, effects, conditional logic, temporal logic, animations, etc. It’s probably safe to say that there’s nothing standard like this for some of the other console development communities, other than what’s been inhouse/private.
Sounds great and all, but then that means I would need to write my own editor. Fail. Ok, maybe not “fail” - but it doesn’t really thrill me to death about writing such an app from scratch. All of my PC coding has been for win32 C ‘console’ and SDL. I’m not big on PC coding and I usually don’t need any fancy GUI setups for my apps (yeah! “8 parameters at a time” console apps - GO!). My choices are A) learn how to code for a GUI based app or B) bypass that GUI crap and write my own internal GUI with brute force via SDL. ‘A’ isn’t so appealing with learning all the nuisances of new keywords, rules, interfaces, etc not to mention it would be in C++ or C# rather than C (although that’s minor). ‘B’ sounds like something I normally like to do - build something from the ground up. But it has the downside of time to develop just the GUI part.
I could bypass A and B and go straight to C, which is writing a few console apps and have a in game engine to build out some of the things I need. Basically a fancy in game editor with some support apps on the PC side. I really like the sound of option ‘C’, but I doubt anyone would use such tools. If my logic appears to be convoluted at times, that’s because it is
If I did option A or B *and* made the script flexible enough, I’m sure someone else might actually use it. If only I could find someone to write one for me… 
September 12th, 2008 | No reply
Version 0.90 is out. This release has audio 
September 7th, 2008 | 4 replies
“You can never trust Leonard.”
September 4th, 2008 | No reply
If you haven’t caught them, there are some updates to the two games (here).
I started work on the audio code. Square channel is outputting some recognizable sound in castlevania. I’ll probably have basic sound support for the triangle and noise channel some time this week. Not sure how or if I’m going to support DMC though. I’ve already setup the TIMER interrupt for audio envelopes/counter emulation, so it might not be too much overhead to emulate the DMC.
September 2nd, 2008 | No reply
…get back over to utopiasoft!!!
August 30th, 2008 | No reply
Another one. Yup - more time wasted hacking another NES game for PCE ;). It’s fairly far along but with only a few days of work into it. Looks like the backend code from Megaman is starting to paying off :). Download here


August 28th, 2008 | 4 replies
Yes, yes, yes. Megaman. This is a NES conversion project. How’s it work? By running the game code natively, but emulating the PPU and other hardware. While the PCE is fast, it’s not fast enough to poll the address locations for the PPU and APU read/writes. So…you replace sta $2001 with jsr $xxxx, etc. Simple. Sort of. Maybe not. Anyway you can read about updates here

August 19th, 2008 | 5 replies
Did some LFO testing this week. Seems there is some incorrect info in the psg docs and the patent as well. Read about it here. Will be doing some more tests tomorrow.
July 18th, 2008 | No reply