PC-Engine General questions

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: PC-Engine General questions

Post by Pokun »

I see, I'm kind of glad if that is the case as I want to get a SuperGrafx one day and that way I would have both CPU versions for testing and comparing with.

CoreGrafx I uses the same color scheme as SuperGrafx, maybe it was produced around the same time, and that's why spare A-chips was used in it?
I have seen videos of CoreGrafx I being opened and clearly showing it without the revised CPU so they are not 100% sure to have one.

I've also seen videos of an opened GT with the revised CPU so that's also more or less confirmed. It's not something mentioned a lot, but I've seen it mentioned on the Japanese internet.

Oh I see, I suppose it's an effect of NEC improving the general PCB design of the Duo-RX or something. Not all consoles gets better with later revisions (Nintendo, Sega, Sony...). It's too bad that the RX tends to be more expensive than Duo-R, or else I would have gotten an RX instead, despite it supposedly coming with the worst pad.
User avatar
za909
Posts: 249
Joined: Fri Jan 24, 2014 9:05 am
Location: Mijn hart woont al in Nederland

Re: PC-Engine General questions

Post by za909 »

turboxray wrote: Wed Apr 20, 2022 8:41 am
za909 wrote: Thu Apr 14, 2022 7:37 am As a fun teaser for what I have in store, here's a test of my code using the Timer interrupt to reset the wave phase on a channel playing a pitch bending sine wave. This creates a hard sync effect similar to what's possible on a SID chip. I'm fairly certain nobody has done this sort of thing on the PCE hardware. The best part is that this costs very little CPU effort and the lower you go with the Timer frequency, the less CPU time you need. One iteration takes 62 cycles and allows itself to be interrupted by a VDC interrupt so code that affects the display is always prioritized.
Nice! Love seeing stuff like this. There's actually quite a bit of hidden gem stuff you can do with PCE audio that no ones really trying to do. Problem is though, is that it requires people writing their own sound driver. Here's my old blog entry for some TIRQ sync related stuff (trying out new ideas and approaches): https://pcedev.wordpress.com/2010/07/18 ... -modeling/

But yeah, hard sync is pretty easy to do with TIRQ. Just out of curiosity, what method are you using to reset the waveform pointer without turning the channel on/off (i.e. avoiding the 'pop' on non-A revision chips)?

I did a bunch of tests with LFO and eventually came to the conclusion that it was "mostly" a waste of a channel. Maybe it has some value for CD games, where chip generated SFX have more channels to play with. But for chip music, if you can incorporate "macros" into your sound engine - then anything has value. I remember like 10 years ago someone in the FM community ("mad" or something like that) use PC interrupt timer and macros to create some incredible OPL3 instruments. After chatting with him, he was the one that inspired me to look into abusing all sorts of tricks on the PCE for creating new sounds. And there's actually quite a bit of stuff no one has done yet haha. If you'e interested, I can share what I have found. The more people trying this stuff out, the better! :beer:

Do you know about the waveform corruption method that the Fire Pro Wrestling games use? It's also super light weight (uses 60hz ticks instead of TIRQ). It's sooo under utilized that it's criminally overlooked hahah.
I'd be happy to join in with the things I've tried and possibly never thought about before. I was super-fascinated by Bloody Wolf changing waveforms mid-note. Of course it stutters but there is basically no pop sound. My method is to use a STZ to the sound register, then a TIN instruction followed by an STA to the sound register (with A pre-loaded) to re-enable the channel and RTS. This code is a subroutine that resides in RAM so that there is as little time possible spent with the channel turned off and so that I can re-write the source address for TIN to any waveform I want to upload. I haven't tested this on the console yet but in an emulator it works fine. It stutters of course but the pop can be hidden pretty well by the rest of the sound.

I don't plan on creating drawn out wave changing instruments like that. My engine is capable of looping any macro type but there isn't much point in looping wave sequences. I only really want to put a few attack / pluck waveforms in there for things like a piano, the pickup sound on an electric guitar, "faux FM" instruments and so on.

As for the LFO, I only want to incorporate it into the music for non-tonal percussive sounds or to try and make some more dynamic bass / ambience sounds. I have settled for only using channels 6 and 3 for SFX so that I can disrupt the parts of the music that I care about the least (echo, harmony, etc.) while still having access to one of the noise-capable channels for SFX.

the Timer IRQ is where you can go buck wild and do anything you want. I've done the aforementioned hard sync (it was quite buzzy on console though...) and I've written a 16-bit LFSR to generate high-fidelity noise as opposed to the 1-bit static that's available on channels 5 & 6. I still need to test my sample repitching method to see if there's any aliasing noise that comes about when I'm advancing the sample pointer by a non-integer value (I have a "float" phase-accumulator-like implementation to slow or speed up samples but it only works with uncompressed samples right now).
There's probably tons more, like generating multiple virtual square channels on one channel, etc.
User avatar
za909
Posts: 249
Joined: Fri Jan 24, 2014 9:05 am
Location: Mijn hart woont al in Nederland

Re: PC-Engine General questions

Post by za909 »

I am once again trying to "hack" the system and go against its design philosophy of only allowing you to use a lowest sprite size of 16x16. My mind just can't break away from the NES-style 8x8 tile philosophy so I tried to figure out a way to essentially store both BG and SP graphics in the BG format and to dynamically upload the tiles to VRAM used for sprites according to the format expected by the VDC. So I analyzed the bitplane data format for SP and BG graphics and created these tables to help myself with a visualization of "what goes where" during a runtime conversion:
Screenshot 2022-05-10 151912.png
With a "sub-sprite" system I can avoid wasting as much ROM space when I want to display smaller objects (can't do anything about wasted VRAM space sadly) and I can save some space with 8x8 tile reuse. I can also easily convert any BG graphic into sprites if I need to for things like moving blocks.

Unfortunately the VDC VRAM auto-increment modes do not help with making this upload process cleaner, and the required 16-bit writes can only be circumvented with dummy writes from what I can tell? So I'm not sure that if I wanted to upload JUST the top left 8x8 part of the sprite (Marked "A" in my image) would I have to do dummy writes to the high byte for my low byte writes to go through, or do the low bytes get written immediately? I can vaguely remember that the VDC data port (from the CPU) only gets latched by the VDC when the high byte is written. If that is so I can start with the low bytes and do dummy high writes, then only do high writes when I want to upload the top and bottom right "tiles". Can anyone please confirm this? Massive thanks!
Post Reply