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.

Download here

Collect the gems/emeralds to complete the stage

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…

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.