Messages

[Console Repair/Mod Center / Re: FM Towns 20F LED Problem]

Do you have a picture of the circuit board where the LEDs are connected? That would help to diagnose this problem.

[Console Repair/Mod Center / Need something checked on PC-FX mobo]

If somebody has the time and inclination, I need to get something checked inside the PC-FX.

On one of the two PCBs is a NEC uPD78C14 chip, near the center. It is a 64-pin rectangular QFP. Here's a link to the chip pin assignment:


https://imgur.com/Q2u8Kue

Going counter-clockwise from the pin 1 indicator, I need to know how pins 21 (MODE1) and 23 (MODE0) are connected. One is probably connected to a nearby resistor or resistor array which may in turn be connected to +5V or ground. The other pin is probably directly connected to +5V or ground.

Also if you could let me know what all of the lines of text on the 78C14 chip are in their entirety that would help a lot.
Thanks!

[Off-Topic / Re: It's crazy-ass project time once again...]

It doesn't do -12V though?

[Localizations, Games, Apps, Docs / Re: MSR is finished!]

Being timidly polite through a long string of nonsense isn't "all getting along"- it's just being timidly polite.  Speaking your mind isn't "causing drama"- it's just speaking your mind.  You suckling noobs and frail older cats here really gotta start manning up.  The vaginas here trying to pass themselves off as actual people have turned into a punchless punch-line ran long and dying.  No one's abusing anyone's mom- no one's threatening anyone.  There is no "drama".

Go fuck yourself. I don't need a forum troll giving me the definition of drama.

PCEngineHell is bitching, complaining, and brown-nosing like mad and he didn't even pre-order the game. He has absolutely no stake in this yet is carrying on like he was greatly wronged and needs to tell everyone just how terribly he was shamed and screwed by an April Fool's joke, of all things. That's drama. He's being a dick.

[Localizations, Games, Apps, Docs / Re: MSR is finished!]

Blah, let's just all get along and enjoy life. No drama.

[Localizations, Games, Apps, Docs / Re: MSR is finished!]

Very cool! Thanks for sharing this game with the rest of the world.

Sorry to hear about the disc pressing issues. But MSR plays fine on a CD-R on my Turbo Duo at least, so I'm quite happy.

I'm only about 15 minutes in, but I've got to say it was definitely worth the wait! Kudos to everyone involved.

[Localizations, Games, Apps, Docs / Re: Question about Download 2 special effects]

One is the level where you see scrolling columns through holes in the background.

This one looks quite nice, doesn't it?

When you do a VRAM animation that isn't square, there is some overhead of having extra tiles for the non-square areas where you mask out the animated part and insert the stationary part. It takes a fair amount of processing time and is seldom done.

But when you look at the video in 480p you can see they cheated. The circular part is all horizontal lines, nothing is really moving. It's not like they had to take their animation data, and then cut out a circular part and insert in the arch around it. So that part is "free". (assuming the video isn't omitting fine detail I can't see)

For the pillars they repeat vertically, so they don't need to animate those parts and just re-use the same smaller set of dynamic tiles. Plus the pillars appear every 'n' pixels apart, so they repeate the animated data horizontally as well as vertically. This means they just move a small part (consisting of a single pillar section and some green space to the right of it) to make all the pillars move.

The exceptions are the top and bottoms of the pillars which is just the same technique using different graphics. The "notch" where the foreground overlaps the background halfway up the pillar is the only time they have to composite anything with the animation data, but it's just a solid color (black) and the pattern is rectangular so they only have to cut out some bitplane data. You could almost do it as a palette technique given the lower color count and no modification of the animation data would be needed.

This is a good example of how to have dynamic tiles bordered by non-square shapes without going to all the trouble that it looks like.

when you move up and down they seem to adjust in height. The way it slows down when the screen fills up makes me think it's a little CPU intensive because good collision detection routines, on their own

Yeah this one is weird. Most games have very smooth vertical scrolling for that kind of effect, but it seems weird here. Throw in the slowdown and I almost wonder if it is a dynamic tile effect for the vertical movement (not the horizontal). All the tiles repeat so they'd just have to update VRAM for a vertical 'slice' of the background. Doing it this way would definitely lead to slowdown.

But either way they still didn't quite do it right. If you used pure scrolling they could have had smoother movement, and if it was a VRAM effect it could have been less choppy. Other games have done this better IMO, and given the other cool things in Download 2 I'm surprised this did not come off as effectively.

[Localizations, Games, Apps, Docs / Re: Question about Download 2 special effects]

Almost all these effects are done just by shoving data into VRAM as fast as possible, such as using a TIA instruction to transfer data from ROM (or RAM for CD games) to VRAM. The PCE can move a lot of data so a brute force approach like this is sufficient most of the time.

In terms of programming there are a lot of optimizations you can do. The big one is storing pre-scrolled copies of the graphics so you aren't wasting time doing costly rotations on the bitplane data every frame. You only need eight copies of your tileset which isn't too bad (or more, but it depends on how far your image can scroll before repeating).

When I developed the "canyon demo" with Fragmare, I had to push a lot of data around at 60 FPS. Some of the techniques that helped included:

- Storing pre-scrolled copies of data in VRAM (not ROM/RAM), and using VRAM to VRAM DMA (faster than CPU transfer) to copy the scrolled data to a 'work buffer', which was the set of tiles that was actually displayed on the screen. It wastes some VRAM but is incredibly fast, and that's important for games where your VBlank cycles are precious.

- Making the copies twice as tall so I could start a copy and have it 'wrap' without having to break it into two smaller copy operations. This was for vertical scrolling but the same concept applies horizontally. There are wait states from accessing the VDC and VCE, so accessing them as infrequently as possible really helps (another reason to use DMA over CPU transfers too)

- Similarly, arranging BAT tile numbers so data could be loaded sequentially in long bunches instead of having to do many small transfers.

- Switching to 512-pixel mode during VBlank, which runs the VDC twice as fast as 256-pixel mode and doubles the VRAM to VRAM DMA transfer rate.

- Packing graphics data into 2 bits so one set of tiles could store two different images, in half the space. This made a tremendous amount of time savings and was really instrumental to doing full-screen column scrolling. You can do similar things with four 1-bit tiles in a single 4-bit tile. When you have a good artist (I did!) the color limitations are not a big deal and the end result still looks vivid and has that 16-bit feel.

On this subject, I think the one game that is a tad exceptional is Ninja Gaiden which has terrible choppy crappy parallax scrolling, but it does it by updating the BAT frequently and not VRAM which is unique. Kind of the wrong way to go about it.. but it's sort of charming in its own weird way. So you can update the BAT, or the tile data in VRAM.

For the Bonk transparency demo I even used dynamic tiles for sprites, instead of the background. So these techniques can be applied in a lot of ways. But in the end it's always just transferring data to VRAM as fast as possible. Download 2 looks pretty cool BTW, I hadn't seen it before. Nice use of the hardware.

[Localizations, Games, Apps, Docs / Re: URC Demo (PCE CD racing game)]

Back to racing games, how feasible would it be to have a FMV-type track loaded into Arcade Card RAM and streamed to the display in real time? (or at 30 or 15 fps)

Assume the player car moves within the playfield and doesn't change the camera position. Maybe the track area could be slightly wider than the screen to permit horizontal panning for some false sense of camera movement.

The track movie sequences could be broken down into segments like tunnels, turns, straight parts, etc. and a course is defined by a list of which segments come in which order. Space permitting, you could branch off into other paths so a course could have multiple ways to drive through it.

Also assume we are making some assumptions like low color count or chunky (2x2) pixels to help pack things into RAM better, with sprites used for the cars. The game would have to clip enemy cars against the FMV background, but some 1-bit bitmasks could be included per frame for that (or just do really crappy coarse clipping and update the bitmask less)

FMV games aren't fun, but the Arcade Card has enough storage to do it with a higher frame rate than a straight CD streaming approach I think.

[Localizations, Games, Apps, Docs / Re: PCE projects]

Same bug seems to be appears in fade_in fade_out effects, same kind of technic (palette changing) ..

Oh! I think I know what you mean.

When you change the palette during the active display period (e.g. outside of VBlank or HBlank) the VCE has flickering output for the duration of the CPU write to $0404 or $0405. This looks like horizontal lines of solid color on the screen.

To fix it, you just need to make sure you always update the palette within VBlank or HBlank. In the Bonk demo, the raster interrupt code takes too long before it writes the new colors, and that causes the flicker you are seeing.

For your palette fade-in/out problem, maybe you can do this:

1. Ensure the fade routine is running during VBlank. Maybe it should be the first thing you do in your VBlank handler instead of later. Often VBlank routines run too long, and the code at the end is actually running at the 'top' of the screen in the active display area.

2. Rewrite the code to make it faster in case it is taking too long.

It can be helpful to keep a copy of the palette in work RAM so that during fades, you don't have to read the palette data from the VCE, modify it, and write it back. Also you may be able to get away with only fading some palettes or palette entries instead of all of them.

It's a really easy mistake to make, because I developed the Bonk demo in an emulator I totally forgot. ;D
For your palette fade, are you using HuC functions or your own?

[Localizations, Games, Apps, Docs / Re: PCE projects]

Excellent, but have you some glishes due to color changing on every scanline on true hardware ????

Uh oh! Thanks for the bug report. I will try to get it fixed up and release an update with sources included.

[Localizations, Games, Apps, Docs / Re: It's MML time.]

Granted, it's not going to be high fidelity. It's going to be a long search for the right frequency combinations. And I'm sure there are a million other things that *could* go wrong. But in the sample run I did (really quickly thrown together, mind you) using about 40 waveforms, I got a recognizeable representation of the original sound.
Maybe I'll try a voice sample next... Anyway, it's just one of those strange things that kinda popped into my head while I was doing something with squirrel. I wondered how fast the psg-player could swap waveforms, and one thing led to another.

Well that's all that matters - if it sounds decent, I'd say you solved the problem!

[Localizations, Games, Apps, Docs / PCE projects]

Here's some recent stuff I did:

http://cgfm2.emuviews.com/temp/bonk.pce

This shows how to do "true" transparency on the PCE using the "Jackie Chan" sprite priority trick. The transparent stars are sprites and while I didn't add any movement to the program, they can be freely positioned anywhere on the screen and the transparency effect will continue to work.

The trick works like this: The background image is a blue-tinted Bonk made of tiles, and the foreground is a normal colored Bonk made out of high priority sprites. The stars are low priority but placed first in the sprite list, ahead of the Bonk foreground sprites. This means that when the stars overlap Bonk, the Bonk sprites aren't shown and the blue-tinted background image is forced to the front. That's how the transparency on Bonk works.

The background is a gradient done by changing the color every scanline. The graphics data for the low priority star sprites is also a gradient and the colors for each line are changed as the sprites move vertically (though they don't move in this program).

The only catch there is that the sprites are 32x32, but only have 15 colors. So lines 0-14 are palette #0, lines 15-30 are palette #1, line 31 is palette #2, etc. You need 2 or 3 palettes per star shown, so there is an upper limit.

In terms of CPU power the only work you do during VBlank is to load a new animation frame for the rotating star, and update 31 sprite colors, per star, so the star gradient order matches the background gradient order. If the vertical position doesn't change you can skip the palette update.

Note: If using YAME crank up the CPU speed to make the gradient visible. Or if you want to see the effect without the gradient, use the lower CPU speeds.

Special thanks to Fragmare for converting and color-correcting the Bonk image!

http://cgfm2.emuviews.com/temp/SloMoCompoEntry.zip

Designed to make your ears and eyes bleed, just an April Fools joke. But sources are included! ;D
Sit close to the TV and turn the sound up before you turn on your PC Engine!

[Localizations, Games, Apps, Docs / Re: It's MML time.]

(for those who are interested in wierd things, here's a pet project that's one the back burner for now:
Take a voice sample, real short. Convert it to 5-bits, and build a sequence of wave forms from it. Then, create a drum that just plays those waves, in order. Make an MML that plays that drum, and let me know how it turns out....)

This is a super cool idea, I think the problem people have had in the past when it comes to implementing this concept is the timing.

For example, assume channel 1 has 32 bytes of a sample loaded, and channel 2 has 32 bytes of a sample loaded. Both channels have their various settings made (panning, frequency, etc.) so all that has to happen next is a key-on.

1. Select channel 1. Write $9F to $0804. Channel 1 starts playing
2. Select channel 2. Wait for Channel 1 to stop (!). Write $9F to $0804 at that exact instant. Channel 2 picks up where channel 1 left off.

So the tricky part is knowing when to turn on channel #2 at precisely the right moment so the sample playback continues uninterrupted. And you'd also have to key-off channel #1 before it repeats the sample.

Because there is no synching mechanism to wave playback, it depends on having cycle accurate delays from the key-on of one channel to the key-on of another. The timer interrupt would introduce jitter due to the interrupt latency, so that's kinda out of the question. So it seems like the CPU would get tied up waiting during playback.

The other issue is that it isn't clear if the waveform index stays reset until key-on, or if it cycles continuously even when the channel is off - you'd never hear the difference, I think. I don't believe this behavior has been proven true or false, so it's all up in the air.

I think these complexities are why the PSG has DDA mode to make samples easy. Definitely not crapping on your idea though, it's a good one. Because others have kicked it around in the past I wanted to point out where people have gotten stuck. Maybe these limitations can be beaten!

Completely unrelated:

Perhaps somebody (not Aetherbyte, you guys have done enough!) could make a little tutorial about how to use the BIOS PSG library in general, and then give an example about doing that with the MML output from Squirrel. That way people who are approaching this from a game-programming POV would have an idea of how to have (say) multiple songs in a project and how to play one, stop one, etc. It's all very basic but just what the newbies need to enable their inner maestro.

The develo docs are perfectly good, but sort of dense for people unfamiliar with them. If nobody steps up to the plate I might do this from an assembly perspective. Partially because I want to get the hang of adding music to my own projects, and it would be nice to help others out.