PC Engine specifics

Discussion of development of software for any "obsolete" computer or video game system.
turboxray
Posts: 75
Joined: Thu Oct 31, 2019 12:56 am

Re: PC Engine specifics

Post by turboxray » Thu Oct 31, 2019 1:04 am

ccovell wrote:Okay, I whipped up a quick test.

Hmm, sorry for the misinformation, then. It looks like the Y,A, and X registers are pushed to the stack as part of the Txx instructions. I don't know exactly why anymore, but as part of my programming, using a Txx instruction with like 6-7 bytes of data length screwed up the registers when transferring $2000 bytes or so didn't.

edit: maybe it was done when I transferred $FC00-$FFF5 in ROM to RAM mapped into $C000-$DFFF, before I had mapped in bank $F8 RAM into the $2000 range, or some other rare case.
I mean, if you use it to clear scratch ram then Y,A,X will get set to zero haha. I remember that "weird" bug years ago.

@za909

The audio 'pop' on the 6280 is from turning the channel on and off. Or more specifically, when there's a large volume change on the channel (which turning it off does). It doesn't matter if the channel is actively playing waveform buffer data or not. The 6280A in the SuperGrafx fixes this issue. You can get around the pop on the original 6280 because the pop is directly proportional to the direction of the volume change. So you can use two channels, and as you turn off one, turn on the other. The pops will cancel each other out (mostly, they're a few cpu cycles out of phase).

Mid-res doesn't need the 2 cycle clock setting. It's just an over conservative setting used early on by NEC. But high-res mode with 1 cycle setting definitely overclocks video memory (~94ns vs 120ns rated ram). Though I've never seen any artifacting from it (did a lot of demos in high res mode).

Pokun
Posts: 1447
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: PC Engine specifics

Post by Pokun » Thu Oct 31, 2019 5:47 pm

turboxray wrote: @za909

The audio 'pop' on the 6280 is from turning the channel on and off. Or more specifically, when there's a large volume change on the channel (which turning it off does). It doesn't matter if the channel is actively playing waveform buffer data or not. The 6280A in the SuperGrafx fixes this issue. You can get around the pop on the original 6280 because the pop is directly proportional to the direction of the volume change. So you can use two channels, and as you turn off one, turn on the other. The pops will cancel each other out (mostly, they're a few cpu cycles out of phase).
I heard there are two popping bugs with the non-revised CPU's PSG.
One is the mentioned volume change bug. I guess it happens anytime volume is changed on a channel whether it is caused by $0801 (master pan volume control), $0804 bits 0 to 4 (channel volume control), $0804 bit 7 (channel ON/OFF) or $0805 (channel pan volume control), and the bigger the volume change the louder the pop. As Tuboxray said, a volume-up-pop may be cancelled out by a volume-down-pop and vice versa. But I guess that is hard to do with notes with envelopes since the volume is changing all the time.
The other pop happens when writing to the wavetable memory in the middle of a note (because the new waveform is usually out of sync) like Chris Covell said. A good solution to this doesn't seems to exist.

The revised CPU supposedly has both pop bugs fixed and they're mostly inaudible there. The HuC6280A seems to be found in all SuperGrafx systems because it's part of its specs (as well as a revised VCE (HuC6260A) with unkown changes), but has also been found in CoreGrafx I and GT systems. Other models seems to seldom or never have it, including the CoreGrafx II, TurboGrafx and all the Duo models. The CoreGrafx I was released around the time the SuperGrafx was released and features the same colour design (black with blue logo) and is bundled with the same controller pad (PI-PD6) so I guess they used spare HuC6280A chips in it. I have seen videos of opening the CoreGrafx I and the unrevised HuC6280 CPU could be seen, so it's not a guarantee it has the revised CPU.

Mednafen emulates both CPU revisions, and apparently games made with the unrevised PSG's popping in mind may cause popping on the revised PSG instead (I have no idea what games), so one is not necessarily better than the other.
Mid-res doesn't need the 2 cycle clock setting. It's just an over conservative setting used early on by NEC. But high-res mode with 1 cycle setting definitely overclocks video memory (~94ns vs 120ns rated ram). Though I've never seen any artifacting from it (did a lot of demos in high res mode).
So in other words, you can always use the 1-dot width modes (write %0xxx0000 to MWR) when using 5.37 MHz or 7.16 MHz dot clocks, but if using the high-resolution 10.7 MHz dot clock mode you might need to set the access widths to something else?

turboxray
Posts: 75
Joined: Thu Oct 31, 2019 12:56 am

Re: PC Engine specifics

Post by turboxray » Fri Nov 01, 2019 8:57 am

Yeah. Best to use 2 dot access for 512 mode (10.7mhz), and you won't get sprite scanline dropout either.

Here's a chart made by elmer that shows how using a 2-dot access in mid-res mode can affect your sprites:
Screen Shot 2019-11-01 at 8.54.03 AM.png
The US localization of Rtype potentially has more flicker than the Japanese counter part. They tried to minimize the change in memory access by clipping the viewable window area because all sprite pixel data is fetched during hblank. There's talk of having TED patch the games at load time, back to full memory access.

Pokun
Posts: 1447
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: PC Engine specifics

Post by Pokun » Sat Nov 02, 2019 3:33 pm

Yeah thanks, I saw that, it's from one of the linked threads. I finally joined that forum since the PCEngineFX forum was apparently destroyed by spammers and the English PC Engine community was split in two.

OK so 2-dot mode for the hi-res mode it is. There are two access width settings though. VM (VRAM Access Width Mode) and SM (Sprite Access Width Mode). In that list I see that some games sets MWR to $x9 and some sets it to $xA (but they are mid-res games of course).

I find it peculiar that the hi-res mode and the NTSC artifact correction filter isn't mentioned in either the VCE development manual or the Develo assembly book as far as I can see. It almost sounds like Hudson didn't want them to be used, or that they were added in later. Both features do work on my Duo-R though, so it's probably not an addition for the revised VCE.

turboxray
Posts: 75
Joined: Thu Oct 31, 2019 12:56 am

Re: PC Engine specifics

Post by turboxray » Sat Nov 02, 2019 7:28 pm

Pokun wrote:Yeah thanks, I saw that, it's from one of the linked threads. I finally joined that forum since the PCEngineFX forum was apparently destroyed by spammers and the English PC Engine community was split in two.

OK so 2-dot mode for the hi-res mode it is. There are two access width settings though. VM (VRAM Access Width Mode) and SM (Sprite Access Width Mode). In that list I see that some games sets MWR to $x9 and some sets it to $xA (but they are mid-res games of course).

I find it peculiar that the hi-res mode and the NTSC artifact correction filter isn't mentioned in either the VCE development manual or the Develo assembly book as far as I can see. It almost sounds like Hudson didn't want them to be used, or that they were added in later. Both features do work on my Duo-R though, so it's probably not an addition for the revised VCE.
0x9 and 0xA are the same settings. Bit pattern 10 and 01 are the same on the BG, but are NOT on the sprite. Bit pattern 10 on sprites is same 4 planes read as dot clock 1, but takes twice as long. You'd need a screen res somewhere around 312px in mid-res mode to get all 16 sprite pixel data read. If you chose pattern 01, then sprites become 2bits per pixel, which all 16 read in the same time as dot clock 1, but the LSbit of the Y position of the sprite is used to select which set of bit planes to read from (0,1 or 2,3).

All those VDC regs (and VCE regs) are writable at anytime. A few are buffered and applied during new scanline, but you changes those attributes. I made a cheesy "transparency" demo on sprites and BG doing that.. forcing it to display 2bit mode for sprites in certain areas of the screen. Can do the same with background.

I'll have to dig through the Hu7 development manual, but I don't remember off the top of my head. I'm pretty sure the NTSC (262/263 alternating frame) bit was described. Most used it.

Pokun
Posts: 1447
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: PC Engine specifics

Post by Pokun » Sun Nov 03, 2019 1:31 pm

Ah! My bad, you are right. Both $xA and $x9 does the same thing. Only SM has two different types of 2-dot width modes. But I think it isn't the LSbit of the Y-coordinate but the LSbit of the PC (Pattern Code, AKA "name") of the sprite data that decides which set of pattern data to use. Otherwise sprites wouldn't be able to be displayed everywhere on the screen, while reducing PC just affects the Sprite Generator.

Anyway, I guess that if I use high-res mode I should set MWR to $xA/$x9 then. *taking notes*


Yeah it's a pretty cool thing that the CPU can access the video chip during the active display period, something not that common at the time. I guess some computers did that (Commodore 64?) but the PC Engine was also very fast for its time. I read it's fast because NEC designed it with CD-ROM technology in mind from the start (NEC was one of the pioneers of CDs), and it made it a very expensive system.
The only thing that I can see is sensitive is to change the VCE dot clock while accessing the VDC, probably because the VDC uses the same clock as the VCE.

Hmm it would be cool to make transparency for water or something in a game.



I haven't read the Hu7 docs yet since I haven't gotten into CDs yet, but at a glance, I can see that the CD BIOS manual has the same description for the EX_SCRMOD BIOS call that the Develo manual has. Only arguments for 5 MHz and 7 MHz are listed, which is why I thought it felt like Hudson didn't want developers to use the 10 MHz mode. I don't see anything about the artifact setting, but as you say most games do use that, and there is little reason not to use it unless you are taking advantage of NTSC artifacts somehow.

turboxray
Posts: 75
Joined: Thu Oct 31, 2019 12:56 am

Re: PC Engine specifics

Post by turboxray » Mon Nov 04, 2019 11:48 am

Pokun wrote:Ah! My bad, you are right. Both $xA and $x9 does the same thing. Only SM has two different types of 2-dot width modes. But I think it isn't the LSbit of the Y-coordinate but the LSbit of the PC (Pattern Code, AKA "name") of the sprite data that decides which set of pattern data to use. Otherwise sprites wouldn't be able to be displayed everywhere on the screen, while reducing PC just affects the Sprite Generator.

Anyway, I guess that if I use high-res mode I should set MWR to $xA/$x9 then. *taking notes*


Yeah it's a pretty cool thing that the CPU can access the video chip during the active display period, something not that common at the time. I guess some computers did that (Commodore 64?) but the PC Engine was also very fast for its time. I read it's fast because NEC designed it with CD-ROM technology in mind from the start (NEC was one of the pioneers of CDs), and it made it a very expensive system.
The only thing that I can see is sensitive is to change the VCE dot clock while accessing the VDC, probably because the VDC uses the same clock as the VCE.

Hmm it would be cool to make transparency for water or something in a game.



I haven't read the Hu7 docs yet since I haven't gotten into CDs yet, but at a glance, I can see that the CD BIOS manual has the same description for the EX_SCRMOD BIOS call that the Develo manual has. Only arguments for 5 MHz and 7 MHz are listed, which is why I thought it felt like Hudson didn't want developers to use the 10 MHz mode. I don't see anything about the artifact setting, but as you say most games do use that, and there is little reason not to use it unless you are taking advantage of NTSC artifacts somehow.
Ahh you're right. It's the pattern offset. Sorry, it was a freudian slip (I have a VDC setttings that shows every other sprite line, essentially halving the sprite height, where the LSbit of the Y selects which interleaved set of lines to show for said sprite).
The only thing that I can see is sensitive is to change the VCE dot clock while accessing the VDC, probably because the VDC uses the same clock as the VCE.
The VCE is given the 21mhz master clock. I suspect it runs faster than VDC. It just divides the master clock for the VDC. The VDC was designed to run with extern sync or uses its own. Basically, the VDC uses the h-sync and v-sync window to wait for the external sync to fire (and the width of these wait windows are changable per scanline), and if it doesn't get a sync signal by the time the wait window expires, then it simple moves onto the next phase (hblank, then active display). But at ANY point the VDC receives the sync signal from external source, it snaps back to the beginning of the corresponding sync signal process (i.e. hsync fires, it starts a new line immediately). Because the VDC does evaluation logic at different points in the hblank area, have the VCE interrupt the VDC causes those changes to remain in effect while it starts the process over. This is how I get it to skip every other line of a sprite; making an XX by 8 pixel mode (smaller objects now have less impact on sprite drop out).

There are some other tricks you can do. The VDC can be made to draw another frame with in 3 scanlines (for 5.37mhz mode), which will force the VDC to reload the entire sprite table. You can do water/sprite mirror effects like in Castlevania for Genesis (the mirror lake effect), by forcing this anywhere mid screen and have it load an alt set of sprites.

When accessing the VCE (any register) when the VDC is drawing the display, causes the VCE to no read from the VDC's pixel bus. Instead, you get a repeat of the last color (indirect pixel) sent by the VDC. You can use this to draw solid lines across the screen. Coupling the start and end of said line with two sprites, you can draw long lasers across the screen with only using two sprites! It requires using Txx instruction because that instruction always holds the bus. If you did something like a series of sta $4xx, only part of that instruction holds the bus.. so you get distortion like this: https://www.youtube.com/watch?v=-xU9uuRzLwo . I was trying to make a cool distortion effect. That's running on the real hardware (it's also using the "half sprite" there; those are link sprites shrunk vertically in half). The half height sprite trick can also be turned on and off anywhere in the screen, making for some interesting effects.

I have lots and lots of unique effects saved up for the PCE. One day I just need to make a demo game to show them off haha.

Post Reply