Topics

[Localizations, Games, Apps, Docs / Space Harrier floor effect]

Obviously it's missing the checker board floor from the arcade version (which the MD "version" also has). Can the PCE do it?

 I would say yes, and with less vram memory than what was required on the MD. How? Simple compression. While the PCE lacks tile flipping (horizontal in this case), the PCE does have an advantage; planar tiles. The checkered floor is essentially 1bit graphics with a h-interrupt changing one color to produce the movement effect. On the PCE, you can store four sets of 1bit tiles in a single tile and use four sub palettes to display each one as its own graphics (you won't see the other overlaid tiles). And with the PCE having 16 background palettes, this is no sweat.

 So now begs the question.. who's going to hack this into the game? Haha. I don't have time ( serious C programming class this semester is going to dominate my time. It's the last "elimination" class for the major). I nominate elmer 

[PCE/TG-16|CD/SGX Discussion / SNES Dracula X]

Ok. I'm in the process of ripping some graphics from the SNES version, and I watched a longplay of it to see what I wanted from the game. I noticed something that I missed before; outside the flashy "town" on fire, the SNES version is really lacking in multi-layered parallax for most of its of levels. And some areas, the PCE could do it with sprites (Konami already did that approach on the PCE Rondo version).

 What I hear often around the net, is that the SNES graphics are superior to the PCE version. That the PCE version looks closer to 8bit than 16bit. I'm talking about the levels, not the enemies or bosses. The consensus is that the PCE couldn't handle the SNES version graphics, which is why they look different. Do you think the SNES level graphics are superior? Do you think the PCE could handle them?

[PCE/TG-16|CD/SGX Discussion / Modding my Hori Fighting Commander PC]

Someone donated some money to my pcedev site, so I found this a good time to pick up a 6 button controller for PCE. Of all these years, I've never owned one..

 It looks awesome, but one thing would have topped it off - a switch to map run or select to button 3. So I'm planning on modding one of the other turbo switches to function as this; toggles run, select, or off (regular button 3). Of course, the devil will be in the details (need to see how this would work when the control is in 2B mode).

 Anyone tried anything like this before for the Hori fighting pad? Anyone interested in doing this to theirs if I get it to work?

[PCE/TG-16|CD/SGX Discussion / Kaizou Chounin Shubibinman 3]

 After the credits roll, there's a series of pics and something about "winds". What are they referencing?

@34:30 <- skip to the end to see what I'm talking about.

[Localizations, Games, Apps, Docs / Binary Trees in PCEAS]

How do you guys handle trees in rom? Do you just build the tree with external tools as a data block, and just incbin into PCEAS? With root node being first in the block, and all pointers to child nodes as relative offsets? Or do you use an external program that outputs labels, DBs, etc for PCEAS to directly use?

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

I was digging through my PCM code from over the summer, and looked at an unfinished project; 15.3khz @ four 8bit PCM channels using just 2 hardware channels, for a total of 8 channels.

 It has no frequency scaling or "mod" type sample-based synth, just regular sample playback. I had problems mixing in the last channel of the 4. So yesterday, I fixed it and it's all working. There's software volume for each mixed channel too. I use the video scanline interrupt to playback a buffer of mixed samples to a paired channel 10bit output. I added up all the numbers, and it's 47% cpu resource to do this. Probably not attractive enough number for some projects, but it's a working example of a proof of concept.

 So I started modifying it for 7khz output (no video interrupt required). I'm looking at ~24% cpu resource for the same thing, but at 7khz. So 8channels on PCE, 4 are PCM at 8bit res. I think someone was interested in this (touko maybe?). I dunno, but considering Air Zonk eats up that same amount for its music engine with just one channel - I thought that was pretty good. It's possible to mix more software channels in, but it doesn't seem worth it. I mean, what are you going to do with something like 8 PCM channel anyway???

 I might be able to drop the resource down a couple of percentage points on the 7khz 4 channel  version with some optimization. I'll have to see what I can do.

Update:
 Here's my batch of 7khz sample scaling vs 14khz sample scaling demo roms. On the real system, the 14khz performs better than on emulators thanks to the analog filtering. It's still not a difference, or as much as I expected, going with double the frequency. But there is more 'punch' to some of the samples. Or at least on my stereo system. http://www.pcedev.net/HuPCMDriver/7khz_and_14khz.zip <- try them out on the real system (not emulator).

[Localizations, Games, Apps, Docs / C++17 for 6502]

So, this video popped up: https://youtu.be/zBkNBP00wJE.
He writes C++17 code to write a C64 game. The point of the video was showing how advance code could be written with zero overhead, and used a limited processor environment like the 6502 to demonstrate this. To get 6502 instruction output, he just translates the x86 (set to 386 IIRC) to 65x. But the overall idea is kind of interesting.

[Localizations, Games, Apps, Docs / Making some of my pce dev tools public]

Since I'm taking another Java level course, I figure I might as well get in some practice. I've never really worked with gui frameworks before (all my stuff was hand build internal gui code). Jframe seems decent and I've learned to write some interfacing code for it.

 But here's my question; does it matter of the program is a JAR file or windows EXE file? I can wrap the JAR into an EXE launcher, but you'll still need to install Java SDK to run it.

 Also, anyone familiar with Jframe, or another gui framework for Java that they recommend?

[Localizations, Games, Apps, Docs / The new fork of HuC]

https://github.com/uli/huc

 So is anyone interested in using this?

On a side note:
 I downloaded the source and tried to compile it under gcc using code:blocks, but it errors out on fmemopen() reference. I looked it up, and according to gnu it's part of stdio.h (gnu.org/software/libc/manual/html_node/String-Streams.html). But when I look at stdio.h from mingw include folder, fmemopen (as well as open_memstream) is not declared in the file. Why would mingw exclude this in stdio?

Update:
Commenting the fmemopen reference...

Code Select Expand

/*if (!data)
data = fmemopen(data_buf, DATABUFSIZE, "w");
if (!rodata)
rodata = fmemopen(rodata_buf, DATABUFSIZE, "w");
    */
And it compiles without problems. Just need to figure out how to re-implement fmemopen in mingw.

[Localizations, Games, Apps, Docs / 32bit operations in HuC]

While there doesn't seem to be a 32bit type for HuC, there does seem to be some internal functions for handling 32bit operations via pointers.

 Here's a list of library functions (some may not appear in the library reference help file):

Code Select Expand

/* default pragma's */
static char *pragma_init[] = {
/* far pointer support funcs */
"fastcall farpeekb(farptr _fbank:_fptr)",
"fastcall farpeekw(farptr _fbank:_fptr)",
"fastcall farmemget(word bx, farptr _fbank:_fptr, word acc)",
/* asm-lib wrappers */
"fastcall load_palette(byte al, farptr bl:si, byte cl)",
"fastcall load_bat(word di, farptr bl:si, byte cl, byte ch)",
"fastcall load_vram(word di, farptr bl:si, word cx)",
"fastcall load_vram2(word di, word si, byte bl, word cx)",
"fastcall snd_trkreg(byte al, farptr bl:si)",
/* text funcs */
"fastcall cls(word dx)",
"fastcall set_xres(word ax)",
"fastcall set_xres(word ax, byte cl)",
"fastcall set_font_color(byte al, byte acc)",
"fastcall load_font(farptr bl:si, byte cl)",
"fastcall load_font(farptr bl:si, byte cl, word di)",
"fastcall load_default_font(byte dl)",
"fastcall load_default_font(byte dl, word di)",
"fastcall put_digit(byte, word)",
"fastcall put_digit(byte, byte, byte)",
"fastcall put_char(byte, word)",
"fastcall put_char(byte, byte, byte)",
"fastcall put_raw(word, word)",
"fastcall put_raw(word, byte, byte)",
"fastcall put_number(word, byte, word)",
"fastcall put_number(word, byte, byte, byte)",
"fastcall put_hex(word, byte, word)",
"fastcall put_hex(word, byte, byte, byte)",
"fastcall put_string(word, word)",
"fastcall put_string(word, byte, byte)",
/* gfx lib funcs */
"fastcall gfx_plot(word bx, word cx, word acc)",
"fastcall gfx_point(word bx, word cx)",
"fastcall gfx_line(word bx, word cx, word si, word bp, word acc)",

"fastcall vram_addr(byte al, byte acc)",
"fastcall spr_ctrl(byte al, byte acc)",
"fastcall get_color(word color_reg)",
"fastcall set_color(word color_reg, word color_data) nop",
"fastcall set_color_rgb(word color_reg, byte al, byte ah, byte acc)",
"fastcall fade_color(word ax, byte acc)",
"fastcall fade_color(word color_reg, word ax, byte acc)",
/* map lib funcs */
"fastcall scan_map_table(word si, word ax, word cx)",
"fastcall load_map(byte al, byte ah, word, word, byte dl, byte dh)",
"fastcall set_map_data(word acc)",
"fastcall set_map_data(farptr bl:si, word ax, word acc)",
"fastcall set_map_data(farptr bl:si, word ax, word dx, byte acc)",
"fastcall set_tile_data(word di)",
"fastcall set_tile_data(farptr bl:si, word cx, farptr al:dx)",
"fastcall put_tile(word dx, word acc)",
"fastcall put_tile(word dx, byte al, byte acc)",
"fastcall map_get_tile(byte dl, byte acc)",
"fastcall map_put_tile(byte dl, byte dh, byte acc)",
/* misc funcs */
"fastcall get_joy_events(byte acc)",
"fastcall get_joy_events(byte al, byte acc)",
"fastcall set_joy_callback(byte dl, byte al, byte ah, farptr bl:si)",
"fastcall poke(word bx, word acc)",
"fastcall pokew(word bx, word acc)",
"fastcall srand32(word dx, word cx)",
/* 32-bit math funcs */
"fastcall mov32(word di, dword acc:ax|bx)",
"fastcall add32(word di, dword acc:ax|bx)",
"fastcall sub32(word di, dword acc:ax|bx)",
"fastcall mul32(word bp, dword acc:ax|bx)",
"fastcall div32(word bp, dword acc:ax|bx)",
"fastcall cmp32(word di, dword acc:ax|bx)",
"fastcall com32(word di)",
/* bcd math funcs */
"fastcall bcd_init(word bx, word acc)",
"fastcall bcd_set(word bx, word acc)",
"fastcall bcd_mov(word bx, word acc)",
"fastcall bcd_add(word di, word acc)",
/* bram funcs */
"fastcall bm_rawwrite(word bx, word acc)",
"fastcall bm_read(word di, word bx, word bp, word acc)",
"fastcall bm_write(word di, word bx, word bp, word acc)",
"fastcall bm_create(word bx, word acc)",
"fastcall bm_getptr(word bp, word acc)",
/* string funcs */
"fastcall strcpy(word di, word si)",
"fastcall strncpy(word di, word si, word acc)",
"fastcall strcat(word di, word si)",
"fastcall strncat(word di, word si, word acc)",
"fastcall strcmp(word di, word si)",
"fastcall strncmp(word di, word si, word acc)",
"fastcall memcpy(word di, word si, word acc)",
"fastcall memcmp(word di, word si, word acc)",
/* CDROM funcs */
"fastcall cd_trkinfo(word ax, word cx, word dx, word bp)",
"fastcall cd_playtrk(word bx, word cx, word acc)",
"fastcall cd_playmsf(byte al, byte ah, byte bl, byte cl, byte ch, byte dl, word acc)",
"fastcall cd_loadvram(word di, word si, word bx, word acc)",
"fastcall cd_loaddata(word di, word si, farptr bl:bp, word acc)",
/* ADPCM funcs */
"fastcall ad_trans(word di, word si, byte al, word bx)",
"fastcall ad_read(word cx, byte dh, word bx, word ax)",
"fastcall ad_write(word cx, byte dh, word bx, word ax)",
"fastcall ad_play(word bx, word ax, byte dh, byte dl)",
NULL
 And specifically these ones:

Code Select Expand

/* 32-bit math funcs */
"fastcall mov32(word di, dword acc:ax|bx)",
"fastcall add32(word di, dword acc:ax|bx)",
"fastcall sub32(word di, dword acc:ax|bx)",
"fastcall mul32(word bp, dword acc:ax|bx)",
"fastcall div32(word bp, dword acc:ax|bx)",
"fastcall cmp32(word di, dword acc:ax|bx)",
"fastcall com32(word di)",

And the comments to the libs are:

Code Select Expand

mov32(void *dst [di], void *src)
add32(void *dst [di], void *src) /* ax|bx */
sub32(void *dst [di], void *src)
mul32(void *dst [bp], void *src)
div32(void *dst [di], void *src)
cmp32(void *dst [di], void *src)
com32(void *dst)
The following code worked fine:
   

Code Select Expand

int _LSB0,_MSB0,_LSB1,_MSB1;
int* PTR_0;
int* PTR_1;
.
.
.
.

_LSB0=65535;
_MSB0=0;
_LSB1=65535;
_MSB1=0;
PTR_0 = &_LSB0;
PTR_1 = &_LSB1;
add32(PTR_0, PTR_1);
add32(&_LSB0, 99999);


 The code generation is decent, and doesn't use far pointers like most HuC stuff does. So it should be decently quick.

 Note: Not that it's probably needed, but you can't nest these inside an expression or use as an argument because there is no return type. Even if there was such a return type, HuC couldn't even handle it (it doesn't handle larger than 16bit expressions).

 Also something else to note as interesting; the source is a 32bit pointer but if a local pointer is used, it will just store 0's in the upper 16bits. I mean, it's not like it's using a far pointer or anything (at least from the macro that gets used in the source), but this presents a problem if you try to use the direct reference for the source (&_LSB1) - because it can't be resolved into a dword pointer for some reason (HuC thing).

[PCE/TG-16|CD/SGX Discussion / Shooters: Hu vs CD]

Ok, this needs to be discussed:

I found this supposedly complete list:
https://archives.tg-16.com/complete_list_of_tg16_pce_shooters.htm
of PCe shooters, and there's a good deal more of them in Hucard format than CD. True a few epic games, such as Lords/Gate of Thunder, Star Parodier, hell even Cho Aniki as well as others, are only available on CDROM, and a few of the Hueys might be garbage, or barely fit in the SHMUP genre if at all, but there seems to be a lot to love available on Hucard, SHMUP or otherwise, and Hudson did continue to release games on Hucard for as long as the Duo was in production, both in Japan and US.

Ok, Top tier CD vs top tier Hucard scooters, then 2nd tier, 3rd tier, etc.

My list...

-Top tier CD shmups in no particular order:

Gate of Thunder
Lords Of Thunder
Cotton
Spriggan
Spriggan Mark 2
Gradius 2
Sapphire
Macross 2036
Sylphia
Star Parodia
Kiaiden 00
Rayxanber III
Nexzr
Forgotten Worlds
Super Raiden
Super Darius II (I like this one, but it barely makes the top tier list)


-Top tier Hucard shmups in no particular order:
Blazing Lazers
Super Star Soldier
Final Soldier
Soldier Blade
Parodius
TwinBee
AeroBlasters
Air Zonk
Magical Chase
R-Type


NOTE: The link in that quote isn't the full list of shooters, and there are about 6 titles that don't belong on that list. Shmups.com has a better list (hu list and CD list)

[Localizations, Games, Apps, Docs / Turbo Everdrive 2.4]

Hey elmer, or anyone else familiar with TED 2.4 (MooZ ?), can you run by the ram mode for me again?

 Can SF2 be run in all ram mode? Is all 4megabytes of ram accessible in some other mapper mode?

 The reason I ask, and this came up in another thread, is that it would be cool to convert a few stages of PCE CD games to run on hucard. Ram mode would definitely allow for that. Gate of Thunder and Force Gear are the two that I had in mind.

[Off-Topic / Java stuffs]

So I got to write Java code for the first time, today. The class I'm taking is Java oriented. So far it's pretty easy to pick up, but we haven't done too much yet. Having experience with C makes picking up other languages' syntax fairly easy (well, the related ones anyway). Java's a little word-y, but that doesn't bother me.

 In the spring, they're replacing all their Java related classes with Python. I though that weird. I'm little bit glad that I'm not coding with python (I can always do that on my own, if need be).

 What are your guys thoughts on Java? Using the Eclipse IDE with it, is kinda nice.

[Localizations, Games, Apps, Docs / CD functions without the system card]

I know some people have duplicated or written their own CD access code for the units, outside of using the system card, but most of them are probably lost over the ages.

 Notably, Charles MacDonald had a ADPCM source lib that could be used for hucard projects (enchanced hucards).

 I'm really interested in something like this. A game that's on the hucard, but is meant for the CD system (you supply the CD to for the audio, etc).

 Anyone else experiment in do this? Or interested in this?

[PCE/TG-16|CD/SGX Discussion / Popful Mail versions?]

So I decided to play the game on mednafen the other day. There were some graphic glitches on the sprites during the cinemas, but the game played fine. That is, until I encountered a cinema that couldn't be skipped and would stall out (black screen with the internal code waiting for something).
 I did some research and mednafen has no issues with this since build 9.0 (I'm using 9.8..something or other).

 So I ripped the bram data from the emulator save state, updated my SCD unit BRAM with it, burned the game, and continued to play it on that. Same thing happened. I decided to try it without the arcade card, and it played fine.

 So either my arcade card is defective (as well as the mednafen even though it claims to run the game fine), or the game I have is bad dump (I sold off almost all my PCE/CD games a few years ago, so I don't own the original anymore). Usually a bad dump would be bad regardless of using a ACD or SCD card. Last I checked, and used, my Arcade Card worked just fine.

 I wished I have ripped my games before selling them with turborip, so I'd know of it I had a good copy or not. But that's neither here nor there. So, anyone else run into this issue? I've played up to the very last level without problems using SCD (built in card).

Note: The image/dump itself is labeled: HECD4011

[Localizations, Games, Apps, Docs / Dragon Warrior for PCE]

Ok, so I promised I'd get this out (it's 99% done). I just need to fix a few things. It used original (and old) nes emulation code from back in 2007, and nothing as advanced as the other stuff after MM1. I tried to revamp it with the new code, but something went entirely wrong and I don't have time to figure out why. Instead, I'm just going to patch up two minor bugs.

 That said, I'm adding an intro to the game. Something simple with some sliding pics, new title screen, etc. This is where I can use some help. I need a new logo for "nes2pce" or "nes2nec". I haven't decided which one, something with some style; about 192pix wide. Anyone interested? I'm writing the bram code too, so I need some brave souls to test this out.

 Some back story as to why I never released this: some members here and I were working on redoing the graphics and sound for this game. Things got delayed, and none of the upgraded work was finished.

 If it wasn't for Bernie bugging me to finish this, I probably would have just written this project off. I've got two weeks of no school starting Tuesday (I have summer classes), so I'll be crunching to get this done (as well as some Megaman tweaks with bram suppport). I'll post videos of the intro WIP; provide feedback if you can. 

 If someone can find me a complete remix soundtrack, then I might reconsider adding CD playback support.

[PCE/TG-16|CD/SGX Discussion / New PCE chiptunes thread]

This is for new chiptunes people are making.

Here's the first link:

And another:

[Localizations, Games, Apps, Docs / BRAM Library]

I know there are some existing libs out there for BRAM support (HuC), but I've written a set of my own. I'm just cleaning everything up and reducing the code/data/bss/zp footprint. This is mostly for Hucard projects, but it should be compatible with any CD project as well.

 I tried to offer a little more support than what the syscard bios funcs provided. I know mednafen had an option to allow up to 8k of BRAM. So I added compatibility for that, as well as upgrading the BRAM header to 8k size. BRAM doesn't mirror, so it should work in theory. IIRC, Ryphecha said one game didn't like it (but only one). I know people have been talking about making BRAM boosters for their systems, so would work with that - if that ever comes to pass (larger than 8k).
 
 I going to do some tests over the next couple of days and then I'll release the lib. I would definitely appreciate feedback on it (suggested support, interfacing, etc).




Edit: (old)
Ok, I was wondering if anyone out there with some experience with bram interfacing could help out?

 I have Dragon Warrior for the PCE that I promised to release for Bernie, but I don't want to release it without BRAM support. I have very-very little time, so I'm seeing if anyone else could help out with the explanation of how to interface with it (the save file interfacing)? I also remember someone (Ccovell?) saying that HuC had a bug in one of its support functions.

 Anyone interested in helping out?

[Localizations, Games, Apps, Docs / Game design with regards to resolution]

I've been thinking about this over the past year. Well, more than a year, but definitely this past year. Old consoles, especially small home computers, have really been pushed to their limits as of the past 7 or so years. Demos are all nice and such, but I'm talking about stuff that works in game (even if it is limiting to the game engine). I bring this up, because the approach is more of thinking outside the box - non traditional approach to the system.

 Some people just want to make games. Some people just want to push the system as far as they can. I'm interested in doing both.

 So I was thinking, what would be a non-traditional approach to game design on the PCE, in relation to hardware? Parallax has always been the achilles heel for the PCE. I personally think this stigma would be so much as it is, if devs had taken the time in presentation. As in, you don't need parallax everything. But if you sprinkle enough of it across a game, even if useless but fancy in specific parts, it distances that feeling of lack of parallax or depth. But that's more about polish presentation in game design than what I want to talk about here.

 So how can we get parallax on the PCE? The two practical methods are hsync scrolls (think AirZonk) or dynamic tiles (think Gradius 2 @ second level). Sometimes sprites are used to help out (Rondo is filled with examples; the ghost ship areas are excellent examples). A rarely used method is tile/cell scrolling (think Ys 3). But is there another way?

 I propose that there is; Sprites. We all know, or most of us, that the PC-Engine only has 1 background layer. So with that in mind, and the PCE is fast at fetching sprite pixel data in hblank, then why didn't the developers extended the PCE's sprite per scanline pixel count? If the PCE was capable of 32 sprite cells per scanline, there wouldn't be a need for a second BG layer. I could make some examples that would run in an emulator; the parallax layering would be quite nice. It's a little more work on the cpu, but it's cheaper. But the PCE can't. So how does this help us?

 The problem is that the sprite pixel count per scanline is exactly 1:1 to the PCE low res. Can we change this? The answer is yes. The VDC is very powerful in its frame defining attributes. You can clip the screen, on both ends, horizontally in 8pixel increments. For instance, I could setup the screen to only show 240 pixels. I've now changed the SPL (sprite pixel line limit) ration from 1:1 to 1:0.9375.

 This in itself is significant, because I can actually scroll an un-interruptable stream of sprites from edge to edge. On a 256px wide screen, at any given point scrolling a solid horizontal stream of sprites would be either 16 or 17 sprites per scanline. As soon as you hit 17 sprites, which is going to happen ~99% of the time, the overflow limit kicks in and one of those sprite cells will drop out. That breaks the illusion. But with a 240px wide window, the requirements will be 15 or 16, and since 16 fits within the SPL (16x16=256px) - the illusion is maintained. You can visualize this as a block wall that a sprite can't appear in front of.

 But what if we take this even further? What if did 224px wide screen? Or even lower.. 208px screen? Now keep in mind the resolution of the pixel itself isn't changing, so the pixels aren't getting any fatter - it's just clipping the display. So at this point, you're probably thinking that's not going to look so hot. Black borders on the side of the screen usually aren't desirable, right? I counter that thought with.. maybe. If you saw the PCE doing some really extraordinary things, with that clipped window, you might change you mind.

 So far, this is all talk. Why not look at an example:
/Y's%20III%20-%20Wanderers%20From%20Y's%20(U)-0000.png

 Recognize that game? (You better!) Yeah, the scrolling is kinda choppy, but there are a lot of fans of this port (myself included). While the scrolling might be choppy (it's 15fps on average), the gamelogic itself is not. Which actually makes the game playable, even if a bit awkward as first. That why people/gamers tend to get used to the scrolling.
 
 Anyway, that's not the point of the example pic. Look again. See those black borders on either side of the screen? Let's put some numbers to this screen shot. First, from the edge to edge horizontally of that gold border, it's 288 pixels wide. The actually playable area, inside that window, is 256 pixels wide.

 This game runs at a higher res than the standard PCE used resolution. So those numbers don't really mean anything because they aren't in low res form. So let's change that. Mid res is ~7.159mhz and low res is ~5.369mhz. So mid res is 4/3 more pixel area (horizontally) than low res mode. So the first number: 288 / (4/3) = 216. And the second number: 256 / (4/3) = 192.

 So if the game ran in low res mode, with the correct window aspect ratio, the edge to edge horizontal gold-ish/trim border would be 216 pixels wide. The playable window inside it would be 192 pixels wide. The idea of that much clipping sounds horrible, or at least unpleasant/undesirable, and yet when you play the game.. it isn't really that noticeable. To top it off, the vertical height of the playable window in that game.. is 128 pixels!

 Bringing this back into prospective, I made the suggestion of 208px wide screen (viewable area). That's only 8 pixels shorter than the border with, and 8 pixels larger than the active playable window. 208/16 = 13 cells to fill edge to edge, and +1 for scrolling so 14 cells needed for edge to edge streaming/scrolling. I just want to clarify here, when I talk about edge to edge streaming - I'm talking about a solid horizontal stripe of sprites going across the screen without interruption. This is worse case scenario, because not all of a BG layer made of sprites would be solid runs of sprite pixels or cell segments.

 The idea to create large sections of a scrollable fake BG layer with sprites. This layer could be the background, or the this layer could be the foreground.
 I think a Sonic type design would a good example of a foreground method, simply because the far background in sonic is edge to edge (think of the green hill zone, the lake and the mountains).
Here's a pic:
/sonic_example.png

 I enlarged the viewable area to get a sense of the foreground design, but the yellow tinted block is a 208x160 window.

 Let's switch to a more zoomed in view with 16x16 cell definition:
/sonic_example2.png

 Each square is 16x16 pixels in the above pic. Assuming a game like Sonic, the main character isn't going to go behind that wall, so if the camera is focused on the main character being in the middle of the screen, that wall doesn't present a problem. But notice cell segment just below the top grass line and the wall to the right of it. Together, of the camera scrolled over more, would make a solid edge to edge row of sprites. This won't be a problem because we've allowed up to 14 cells per width for this very issue. With sprites being the foreground layer, though, we're optimizing for that open area above the grass line. There are a lot more open areas in the green hill zone of Sonic 2.

 What about the grass that appears on front of Sonic's feet? That constitutes sprite overlapping, increasing that cell limit for whatever scanlines affected by it. If the main character was 32x32 sprite cell, and the edge to edge scenario only takes up 14 cells max, then we're exactly at the 256px sprite scanline limit.

 Are you going to run out of SAT entries doing this? At a 208x160 viewable window, it's 7x5 entries if the ENTIRE screen was filled with 32x32 sprites. That's 35 sprite entries of the 64. So I think we're in a pretty safe zone. If even that max was pushed to 48 entries, for whatever reason, that still leaves 16 entries open for the character and enemies. More than enough for considering sprite objects can be quite large. Do the sprites for the pseudo layer have to be 32x32 in size? No. I would do a 32x32 tilemap system, with a meta tile lookup table that would be capable of displaying any size and combination of multiple sprites inside that definition (including fine pixel offsets).   

 In this Sonic type example, the foreground would be all sprites and the background would be the real BG layer. Well, hsync scrolls are easy to do on the PCE, so all the nice background parallax/linescrolling is easily replicated on the PCE. The Chemical Zone in Sonic 2 would be even easier to do on the PCE than Green Hill zone.

I personally think this would be an impressive sight to see. Combine this with the PCE's color capabilities and we've got a win IMO.


 Now to take this one step further; what if the game ran at 30fps instead of 60fps, but added even more complex layering scenery/capability? Stuff like complex dynamic tiles (larger areas), and realtime masking/ORing pixel data over sprites to do more complex fake sprite layer (ease the limitation of solid areas and add more possible enemies). I mean, there are games on the PCE that run 30fps (like Tenchi o Kurau).

 It's note just parallax layering that's an issue on PCE, it's also more shallow depth issues that plague the system. As in if the BG layer is the foreground - it's rare that anything shows in front of sprites/enemies/main character simple because the PCE lacks the per tile priority for this. Using the TRB instructions, which both ANDs and copies sprite data from vram to vram, a game engine could easily be setup have complex layering depth on a per pixel basis of objects in relation to the BG layer. Think of light posts, signs, grass, etc - appearing in front of a sprite object without the need to use sprite masks, which wastes SPL bandwidth. 

 There are many options, configurations, and combinations one could use, in relation to this, but the idea is to think outside the standard design approach on the PCE.

The question to the PCE gamer is: would 60fps game with a clipped window be an issue? Would 30fps be an issue?  Or 30fps and a clipped window? Where would you draw the line when it comes to squeezing out the most of the PCE graphical capabilities?



PS: I'll edit for any grammar mistakes later. This is all off the cuff.

[PCE/TG-16|CD/SGX Discussion / PCE games with mouse support]

The other thread about analog controllers got me thinking: What pce games do think would benefit from optional mouse support?

 I think Operation Wolf would be one of them.
 Playing Forgotten Worlds would be interesting: mouse for movement and gamepad (direction part?) for the pod movement. I mean, imagine the main character being controlled like a mouse pointer (and all the acceleration that goes along with it). It'd probably make the game too easy.

[PCE/TG-16|CD/SGX Discussion / 720p output]

So this is pretty cool...
http://d.hatena.ne.jp/na6ko/20151117/p1

[Localizations, Games, Apps, Docs / This is interesting.. (cc65)]

https://github.com/cc65/cc65/commit/b2657ecef5c0db061587c4f98e94b7500c74a93f

[Localizations, Games, Apps, Docs / Some audio stuffs]

I posted here: https://pcedev.wordpress.com/2015/10/31/pcm-player/

tl;dr

On the topic of audio, have you guys ever heard the PCE stream 55khz 5bit PCM using the channel's waveform memory as a buffer? Check it out: pcedev .net/6280a/sgx_dump.wav That was recorded from my SuperGrafx.

So, basically I know what I can do on the SGX or more specifically the 6280a, but I wanted to get some recordings from PCE owners (6280), if possible. I'll post a few demos. I'm looking for recordings like the one above and what console it was recorded from.

[Localizations, Games, Apps, Docs / hyakushiki's Phantasy Star port/thing for PCE.]

Seems like he's still working on it http://www.hyakushiki.net/consoles.htm
The latest update is this year. Has anyone played through any of these builds?

[PCE/TG-16|CD/SGX Discussion / Gate of Thunder debug stage?]

 The Ys IV thread reminded me of this: Gate of Thunder has a hidden stage in the data track. I looked at the differences between the JP and US versions, and it appears to have some changes to the data structure just like the other stages (i.e. looks like it was recompiled and not just left over data track junk). I was never able to figure out how to access it without manually block copying assets over from it to half build a level (I did this visually with an image editor.. yes, it worked) - but that resulted in some level with just a boss fight (reused boss).

 Anyone up for poking around in GoT to figure out what this is?

[Localizations, Games, Apps, Docs / Hacking tools]

Mednafen is a great tool, but the more the better. Bizhawk offers trace logging, but there's something I've been using lately that can be specifically tailored per game or feature; LUA scripting. Bizhawk supports this as well. It's fairly powerful; it can overlay text and video directly over the emulator as well as log to a console window. You can read, write, and call functions on memory access (execution, read, write, etc). It's fairly powerful. With bizhawk, you can run multiple lua scripts, manually pause and resume, etc.

[Off-Topic / Anyone else ride?]

Or used to ride?

I don't have a car, so this is my daily commuter; Zx6r 636.

I just finished repainting the bike..






This was the old color scheme:

 It's a 2004.. old by nowadays standards, but it feels like a completely new bike. Pretty much took me two weeks total to disassemble, patch and sand, paint, and reassemble. It's the first time I've ever shot automotive paint and automotive clear coat (the curved surfaces are tricky). I also did a -1 front sprocket to get a little more pep (I don't need the 170mph top speed of this bike, so the trade off was worth it). I still need a GP muffler (hate the one that's on there).


 Ride? Used to ride? Post pics!

[Localizations, Games, Apps, Docs / Ninja Ryukenden/Gaiden]

I just finally got my own place, and pulled the PCE stuffs out of storage (yay!). So to warm up to PCE stuffs, in which I hadn't done for quite some time, I decided to look at Ninja Gaiden for the PCE (my son was playing the NES one over the weekend).

 Specifically, how to turn off the fake scrolling. That part was easy; just change one opcode from a BEQ to a BRA (@ $8153... I forget the bank number). But the problem lies with the maps. Except for the first level, all the maps have black tiles where the faux BG layer is supposed to be (after first map draw). The maps don't appear to be uncompressed (they are 16x16 metatiles, horizontal row format, and 13 meta tiles tall). I was able to easy find one, but removing the rom header and loading the rom into photoshop as a RAW 8bit grayscale image (64 pixels wide) and visually identifying some of the maps (not all maps can be identified this was single they might have different tile widths). But I hadn't figured out the pointer table to the maps for extraction.

 I'm not sure if I'm gonna continue with this for now, but I did want to at least post what I had found. If you're a hacker and interested, have at it!

[Localizations, Games, Apps, Docs / Game dev related]

I just saw this site: http://gamasutra.com/blogs/ItayKeren/20150511/243083/Scroll_Back_The_Theory_and_Practice_of_Cameras_in_SideScrollers.php
It's got a lot of animated gifs, so it takes a while to fully load up.
It basically discusses different types of "cameras" for 2D games. You wouldn't think there is a camera in a 2D game, like with 3D games, but indeed there are. They show some popular games, too.

[PCE/TG-16|CD/SGX Discussion / Some new PC-Engine chiptunes]

Was there already a thread for this kind of thing?
Anyway...

Check out the person's channel for more vids. They use Deflemask which is a tracker with PCE sound emulation. You can export the files for the real system, but if I recall they're VGM style format.

[PCE/TG-16|CD/SGX Discussion / Dracula-x unused graphics]

I had this a while ago, and was currently moving stuff around.. so I figured I should share it:

This appears to be an unused enemy/monster in the game.

pcedev.net/drac-x/drac-x-1.png

Here's a look when applied to a random enemy palette:



 This wasn't just some random stuff left in the ISO (like a lot of games), but this is actually contained in the game itself. And of all things, it's loaded in vram on stage1-1. As far as I know, this isn't used in game. Unless there's a hidden area where it's used?

[Localizations, Games, Apps, Docs / Xanadu I/II and other SCD translations]

Is it possible this can be made into a sticky?




Sub-topic: What this, and other translations need, is an sys 3.0 card with expanded ram:

Also, does anyone have circuit files they are willing to share? Or even better, willing to make or modify one for two 512k rom/ram chips (1megabyte)? That one guy in France made a few boards, but they only have one chip on them. If this translation (and others) are gonna get finished, we need a card that can hold a rom (for SCD 3.0 bios) and a 256k ram chip (preferably 512k). If anyone is willing to help out, that would be great. Again, these are for SCD translations. Yes, you would need this card to play them. But it's a simple card with no mapper and two memory chips (the layout of the one made in France would work fine). I can start the projects in emulation, but at some point I'll need to test on the real hardware.

[Localizations, Games, Apps, Docs / Graphic, Sound & Coding Tips/Tricks/FX/Etc. Tools for Development]

Can we get a sticky for graphic, sound, and coding tips/tricks/effects/etc?

 Since the TED info isn't stickied, here are the relative links for it:
pcengine-fx.com/forums/index.php?topic=21121.0
pcengine-fx.com/forums/index.php?topic=20120.0


TOOLS

 https://tasvideos.org/Bizhawk.html Bizhawk PCE emulator with LUA script support. Perfect for debugging your games, or hacking existing games. Check out the sample LUA script for Neutopia. It shows collision boxes and HP points for them.

[Localizations, Games, Apps, Docs / Looking for some help on a little PCE homebrew game]

Here's the link.
http://pcedev.wordpress.com/2014/08/21/game-2014/

 Also, trying to get in contact with runinruder. If anyone talks with him outside the forums, can you have him PM me?

 Edit: A video...

[Localizations, Games, Apps, Docs / Sprite editors]

What do you guys use?

 I need something that will do more than just basic sprite assembly. Something that will allow setting the animation speed, and output sprite animate tables (with these attributes). The tables are a must. I'm sick of making them by hand, and changing them after modifying an animation sequence or number of meta-sprites, etc.

[Localizations, Games, Apps, Docs / Mappy]

Curious how many of you pce homebrew peeps use Mappy?

[Localizations, Games, Apps, Docs / CC65 for PCE/SGX]

I talked with Chilly Willy about this, a number of months back, and CC65 has some pretty nifty features (he's interested in doing C for SGX). Not that I use HuC much (if at all), but I'm ditching it in favor of CC package. I don't have much free time, but I post whatever setups/libs I can - if anyone is interested in taking this route.

[Buy/Sell/Trade / Japanese gamecube stuff]

PC-Genjin CIB - $30 shipped (US price for shipped). (SOLD to the man in the red shirt)

Waverace Bluestorm - $10 shipped (US). $5 if purchased with PC-Genjin.

 I also have a Japanese Gamecube; purple, no controllers, ad adapter. $20+shipping (not sure what shipping is going to be, but I figure around $15).

[Buy/Sell/Trade / Saturn games for sale]

 I'll update the post as I get pics in.

.............................................
US titles:
.............................................

US Bomberman (SOLD): Excellent condition. The manual is near mint, except this strange warping (no wear, tear, creases, dog ears, etc). I think it's from it just sitting in the case, lying on its back. Comes with two other paper articles (whatever came with it new). The lower case is excellent condition. The door is pretty good with just mainly just micro scuffing. The CD is very good condition, would be excellent condition if it wasn't for some slight micro scuffing. I bought this game new, and played it a few times. Pics: http://www.pcedev.net/for_sale/us_bomberman/
$65+shipping (if US lower 48 states, then $70 total shipped)

Astal(CiB) (SOLD): Manual: Has some warping, but other than the warping  - excellent condition (no wear/tear/creases/erc). Lid and lower case have quite a bit of scuffing, but still clear (not cloudy). CD is looks great (no scuffs or micro scuffing), but has a few very light circular scratches on the bottom side. $14+shipping.

Albert Odyssey(CiB)(SOLD): CD: very good condition (about 3 micro scuffs). Manual: excellent condition, except for the warping thing - there's no wear, tear, creases, etc. Lid: pretty good condition (decent amount of micro scuff, but it's clear and no cracks). Lower case: good condition, but has some thicker scuffing (not scratchs, more like permanent harsh rub markers) and decent amount of micro scuffing too - no cracks. The case also has this weird warping anomaly (which astal and one other us saturn game has), on the black inside part. Looks like a factory defect. It's not too noticeable, but one of the pics zooms in on it and you can clearly see it. Else, it's not really noticeable to the naked eye. I'm thinking... $63+shipping.

Darius Gaiden(CiB) - removed.

.............................................
JP titles:
.............................................

Strikers 1945 (SOLD): Manual: very good condition; no creases, tears, or wear marks - but it does have slight warping on the back side. Lid: lot of micro scuffing, but it's decently clear. Lower case: same as lid, micro scuffing but clear. CD: Near mint except for two tiny smudge marks. They are both on the outer edge (music track or null data). They aren't line scratch, or grooves. They looks like.. smudges. About 1/16 long, both of them and about 1.5 mm wide. It was like that when I got the game, and hadn't experienced any skipping or not loading. Because of the two smudge marks on the CD, I'm asking $13+shipping.

Cotton 2(SOLD): This one has one of those slightly larger than normal CD cased. It's hard to tell (about a few mm's thicker). Manual: good condition. CD: good condition. Lid: good condition. Lower case: OK condition, but has a strange circle crack (something indented it) about 3/4 inch long. $30+shipping

Twin Bee deluxe pack(SOLD): Lid/cover - Ok condition (lesser amount of micro scuffs. Two hair line cracks; hard to see-ish. No broken tabs). Lower case: good condition (a couple of scuffs. micro scuffing too). Manual; near excellent condition. CD: near mint condition. $13+shipping

Gokujou Parodius Da! Deluxe Pack(SOLD). Lid/cover has a broken tab (needs to be replaced). Lower case is pretty good condition (micro scuffing). Manual: excellent condition/almost mint. CD: mint.  $10+shipping

[Buy/Sell/Trade / PC-Engine stuff for sale]

I'll update the list as I go through my stuff.


For sale:
White PCE CD unit SOLD (just the CD unit, not the interface). I took apart my interface unit, to see what was inside of it.. but I lost some parts and can't put it back together. So I have this CD unit I can't use. I haven't used it in a few years, but it worked last time I used it. It does ~not~ like CD-Rs, I know that much. I played and beat Dragon's Slayer on it, last time I used it. I'll post pics later.

 Street Fighter 2: Case, manuals, other stuff that comes with it. No hucard (unless you want it). I took it apart because I was curious to see what it looked like underneath the bump. Now it doesn't work right. So.. yeah. $5+shipping

Ys IV: Case, manual, CD. Post pics later. No map (did it come with a map?), no spin card. $25+shipping.

Macross 2036: Ugh.. I don't want to sell this..




.............................................
Books
.............................................

PC-Engine Fan: 1993, January. (pics http://www.pcedev.net/for_sale/books_mags/)

Dragon Slayer 2 guide book. I wish I had time to scan and translate this. It's got a LOT of maps of the dungeons. ( pics: http://www.pcedev.net/for_sale/books_mags/)

1994 PC Engine catalog??? (pics: http://www.pcedev.net/for_sale/books_mags/  the blue and gold book).

 Make an offer on one or all the books. Shipping will be flat rate USPS, and your choice of package size (aka price; envelope, box, etc).

[Buy/Sell/Trade / PS Vita for sale (original model) and some games (Ys IV too).... (SOLD)]

Update: Now with pics: http://www.pcedev.net/for_sale/vita/

PS Vita (SOLD) (with the original awesome OLED screen), AC adapter, carrying case...err it's got a replacement plan from Gamestop on it still (I think that's transferable). 8gig memory card.

 Games:
All-stars Battle Royal
Dragon's Crown
Ys Memories of Celceta
Asphalt Injection
Soul Sacrifice
(all games with cases)
HotShots Golf

[Buy/Sell/Trade / Turbo Express for sale.. some other TG16 stuffs too]

I'll add more as I go through my stuffs. PC-Engine stuffs will be posted in the PCE sales thread. Had a job lined up, that fell through. So, selling off stuffs to pay bills - blah blah, yadda yadda.



TG Express (SOLD):  Works, but I haven't used it in couple of years. Need to get some batteries and test it out. No batteries yet, but here are some pics and a description: www.pcedev.net/for_sale/express/ . Over all condition is pretty good. A few minor dings on the volume side, and one scratch right below the select button (on the bottom edge/lip). The screen glass is in great condition (no scuffs or scratches), but there is a single tiny pit in the lower area. About the size of a 0.005 pen point (if you draw/ink). The camera won't pick it up, so I can't show it. There's no AC adapter or any other cables. The battery cover is intact. No bend springs or clips. The on/off green switch at the top, has a small cross groove in it (you can see it in the pics). The face/front of the unit is in excellent condition; no scratches or scuffing. The silk mark lettering is excellent with no fading. Still need a video of the unit playing games. $70+ shipping, assuming everything else checks out.


CD system card 2.0: Pretty good condition. loose. $8+shipping. Pics on inquiry.


Games:
Soldier Blade(SOLD): Box, plastic, manual, sleeve, and hucard. It's a little beat up. Pics: www.pcedev.net/for_sale/soldierblade/
make offer (~might~ put this on the evil bay. Sorry guys - paying bills is high priority)

Neutopia 2(SOLD): Box, plastic, manual, sleeve, and hucard. This one is pretty beat up. Pics: http://www.pcedev.net/for_sale/n2/
make offer (offer pending).


SideArms(SOLD): I have just the cardboard box for Sidearms. It's in ok condition. $8? Post pics later


Dragon Slayer (SOLD); complete with case, manual, map, and CD. Manual has water damage (son split his drink when he was playing the game) and has quite a bit of wear. The map has a quite a bit of wear as well, and starting to come apart at the two middle seams. The CD is in good condition; mostly micro scuffs (playable; I've beaten the game many times over the years from this CD). Case is so so; lots of micro scratches. Will post pics later.
Probably $45+shipping.


Loose hucards:
 
Jackie Chan(SOLD): Excellent condition. No case or manual. $30? I'll post pics later

Jackie Chan(SOLD) #2: worn condition. Really worn... just the hucard. $7+shipping

Bonk's Revenge(SOLD): worn, but mostly lots of micro scuffs (and one scratch through the title of the card). Back side is really scuffed up and stained/dirty. Manual is ok - mostly creases. No case. $7+shipping

Super Star Solder(SOLD): ~really~ worn condition. Works though. $8+shipping

Dungeon Explorer(SOLD): Average condition? Mostly a lot of micro scuffs. Manual too (canadian version) - good condition. No case. $8+shipping

Alien Crush(SOLD): Hucard, great condition. Manual; pretty good condition. Lower case: decent, but the tab is broken that holds the hucard. Door: crappy with scuffs/worn, but no cracks. Hucard sleeve: err good? $7+shipping

Cyber Core(SOLD): Hucard, great condition. Manual; pretty good condition. Lower case: good condition, no broken tabs. Door: average with scuffs/worn, but no cracks. No hucard sleeve. $11+shipping

Psychosis(SOLD): Hucard in good condition. Manual; crease down the middle and some ripples. Lower case: hucard tab isn't broken, label is ok, some glue residue inside the hucard area (???). Door is cracked, but still together. Sleeve: Tinted..that's the best explanation I can give. $12+shipping.

 

Systems:
TG16 with Booster (not booster plus) (SOLD). Pretty good condition. No AC adapter or gamepad. http://www.pcedev.net/for_sale/tg16/
$38+shipping.

I'll update with more stuffs later (still more stuffs)

[PCE/TG-16|CD/SGX Discussion / Two models of the white PC Engine?]

I noticed that there are two models, or pics of them floating around the net. Is this common knowledge? And if so, which one is the original/release one? You can tell by looking at the controller port on the front. One is just round, while the other has a flat edge on the top:

[Localizations, Games, Apps, Docs / Palette fade routine]

I figured I'd post this. I've written a few in the past, but I needed something more efficient and faster. Plus, I like the fade 'in' part much better than my older method.

Code Select Expand

;....................................................................
;
FadePal:
   
    lda <D3
    asl a
    asl a
    asl a
    sta <D4
    asl a
    asl a
    asl a
    sta <D5
    cla
    rol a
    sta <D5+1
   
   
   
_int_Fade0:
    clx
.loop
    lda PalBlock,x
    and #$07
    sec
    sbc <D3
    bpl .BlueOVF 
    cla
.BlueOVF 
    sta WorkBlock,x
    lda PalBlock,x
    and #$38
    sec
    sbc <D4
    bpl .RedOVF
    cla
.RedOVF
    ora WorkBlock,x
    sta WorkBlock,x
    lda PalBlock,x
    and #$c0
    sec
    sbc <D5
    tay
    lda PalBlock+1,x
    and #$01            ;needed because reading pal data from VCE leaves garbage in the top unused bits
    sbc <D5+1
    bpl .GreenOVF
    cla
    cly
.GreenOVF
    sta WorkBlock+1,x
    tya
    ora WorkBlock,x
    sta WorkBlock,x
    inx
    inx
    bne .loop
   
   
_int_Fade1:   
.loop
    lda PalBlock+256,x
    and #$07
    sec
    sbc <D3
    bpl .BlueOVF 
    cla
.BlueOVF 
    sta WorkBlock+256,x
    lda PalBlock+256,x
    and #$38
    sec
    sbc <D4
    bpl .RedOVF
    cla
.RedOVF
    ora WorkBlock+256,x
    sta WorkBlock+256,x
    lda PalBlock+256,x
    and #$c0
    sec
    sbc <D5
    tay
    lda PalBlock+256+1,x
    and #$01
    sbc <D5+1
    bpl .GreenOVF
    cla
    cly
.GreenOVF
    sta WorkBlock+256+1,x
    tya
    ora WorkBlock+256,x
    sta WorkBlock+256,x
    inx
    inx
    bne .loop
   
  rts
 
;endsub

 The call argument is D3, and two blocks of memory are whatever you define in local ram. D3 is a value from 00 to 07. It's modified for D4 and D5, so they can subtract those specific R/G elements without shifting them. I use two blocks of memory; both are 512 bytes long. Because I need to fade the existing BG palette, which might be made up of dynamic subpalettes at any point in time - I read all of CRAM from the VCE into "PalBlock" segment of ram. "WorkBlock" is the temporary palette buffer that the changes are saved to, to be uploaded to the VCE CRAM.

Here's the code to read CRAM into the block/array(local ram).

Code Select Expand

;....................................................................
;
UpdateWorkPal:
    stz $402
    stz $403
    tia WorkBlock,$404,$200
  rts
;endsub

 Not many docs mention that you can actually read from VCE CRAM, but you can. IIRC, though, there's no guarantee that the upper unused bits will be cleared. Normally not a problem, especially if you upload with those bits set, but when altering the color value as such as the above code - make sure you AND/mask off those bits. The above fade routine does that, so no worries.

 Reading and writing to the VCE (any of the VCE regs) will stall the VCE and show distortion on active display. It's best to call the VCE CRAM read routine from vblank to avoid this. You only need to call it once; one and done (the VCE CRAM read routine).

 The above routines only fade/adjust the BG 256 colors. You'd have to modify it for sprite 256 colors. If you want to fade to black or fade up from black, you'll need another routine that modifies D3 and calls the FadePal routine each time.

[Localizations, Games, Apps, Docs / Jackal nes2pce]

I'll need some play testers.. pretty soon. 2 players simultaneous testing too (get your TAPs ready).

Download:
wayback://nes2pce/Jackal_beta_031_.zip

[Localizations, Games, Apps, Docs / Hardware tips and tricks]

I have a decent amount of tricks for the PCE, some known - some not.

 I figure'd maybe I should share some with the community.

 Here's one for transparency effect on the PCE. Pretty easy. It's similar to what the Sonic games do on the Genesis. They flash interleaving sprites to had the garbage pixels on that scanline, when they update color ram. The PCE also gets garbage pixels, but they are in the form of short stretched pixel lines going across the screen. There's a way to hide this transition.

 The method works as such:

Say you have a water transition line. For the sake of setup, let's say that water below the line is going to be a blue hue-ish color/transparency. The first thing you do, is make sprite color #0 a nice blue color, relative to this under water scheme. Next, you reserve a single row in the tilemap with solid color tiles. These tiles are to make a solid line, and the same color as you did for sprite color #0. Now, for the transition line - you do an hsync interrupt, reposition the tilemap to that solid color area, then disable sprites. That'll make sure that nothing but this line will show.

 Now comes the tricky part. There are two ways to update CRAM (vce); one is to use TIA to block copy the new colors. This will delay interrupts of the TIMER interrupt, if you're playing samples. I doubt a delay this short will even be audible, but if you're that picky - you can use the alternate method. You reserve a chunk of ram, and setup a string of code that LDA #$nn, STA port. With an RTS at the end. It's slightly slower (14 cycles to copy a WORD vs 12 cycles of TIA). Ok, so it's not actually that tricky ;)

 You can easily fit ~64 color updates (4 subpalettes for sprites) in this time. Right at the end, you re-enable sprites and reposition the tilemap. All of this needs to be done fairly quickly, so do all of your calculations before hand.

 What you don't need to do, is update ~any~ colors in the BG subpalettes. The PCE has plenty of those and you can easily make duplicates with the alternate coloring for them. You also don't need two tilemaps either. You just need a redundant copy of the tile row (of the tilemap) that the transition line is on - with the alter water color. Just ~that~ row. Everything below that should have already been changed from the previous vblank call in preparation for this, if needed (i.e. your water line moves up and down on the screen).

 The reason why sprite color #0 needs to be the same color as the BG transition line, is that updating color ram (VCE) stretches pixels. Since they are all the same color, you can't see this pixel stretching and all you see the solid color line. The border outside of the BG area (including left/right sides), is filled with sprite color #0. You don't need to update this every frame, unless you're doing color cycling on the transparency (going through hues). And you don't need to do this during hsync; doing so during the previous vblank is good enough. That saves one less color to update for the sprite palette anyway, during the active screen update. I hope that makes sense. Sure, you only have 4 sprite subpalettes for this design (for the main character and any enemies that transition this line). Of course, any objects or enemies that remain above or below this line - don't need to fall into this 4 subpalette group; they can remain fixed in their subpalette. This trick uses two scanlines total. So two solid lines appear as the transition.


Possibly make this a sticky?

[Localizations, Games, Apps, Docs / Street Fighter 2 Arcade card project]

Update: I'm looking for tracer, CDL, and logging support for any PCE emulator that supports the SF2 mapper. The video/sound emulation doesn't even need to be that accurate. FCEUX is open source and could be used as an example (it's what makes hacking NES stuff, and disassembling - pretty awesome). I know of no PCE that supports these features. Mednafen has simple logging, but nothing close to this.

 If you can code in C/C++, but no PCE related stuffs/code, take a look at to see if you can help out in this department (for an open source emulator). Or maybe get some emulator authors to support this. This would help out tremendously.


I'm curious if there was any desire (any real desire, not just 'yeah, that'd be cool') to hack and reconfigure SF2 to the arcade card. What do you guys think?

 If enough knowledge was researched and recorded, the game could be hacked in many ways. Including adding in additional characters, new moves, etc. As stuff gets known/understood, it can evolve into a pseudo source code project as well (similar to the Sonic decode projects, and some for NES as well). The idea works like this; you include binary parts of the original game to be assemble along side new source code. You eventually work your way towards full source code - but that's not entire needed or required. I use this method for a lot of my hacking (Dracula X would be a good example). Stuff can be relocated without actually fully understanding how it works. Just the basics are need. Most games are divided down into subroutines anyway. It's possible to hack or completely replace them, as long as you know what the input parameters are and what the output is supposed to be. It is actually that simple.

 The problem lies with time. While I have the skill, I don't exactly have a lot of free time on my hands. I have other stuff that I'd like to do (both related to pce and coding, and not related). I swear that it seems like that I'm the only person that does any sort of in-depth hacking for PCE. Especially outside of translation hacking. The only thing that comes to memory, is Ccovell's Rtype hack project for the Supergrafx (not sure how far that went). And recently, cabbage's SF2 translation hack.

 Would anyone be interested in working on this as a public community effort (mostly talking about coders/hackers)? Do fighting games on the PCE actually have that big of a fan base? Once it's hacked/reverse engineered to a certain level, it wouldn't even have to be SF2 specific anymore. It could be ~something~ more along the lines of OpenBOR or Mugen (though that makes me cringe a little). The arcade card CD platform would allow for quite a bit of flexibility for graphics and animation. Even SGX support could be added (that would be fairly easy).

 I already have quite a bit of info about the game structure. And it didn't take that long to get that info, either. I have decent experience with writing hooks and relocating code for hacks (needed for hucard and CD translations). But I am not interested in doing something like this alone. It'd be more something along the lines that I could help with; jumping in and out of the project.

 Let me know your opinions. Be brutally honest. If you like the idea, but not the targeted game - don't be afraid to say so. While I'm looking for coder/hacker opinions, anyone's opinion is welcome. The reason I bring this up, is that it's pretty doable. And I have a bit invested in this. I want to see Fragmare's upgraded backgrounds added to the game. But if that's all the comes of this, then so be it. This would be a project that blurs the line between homebrew and hacking (much like the Sonic recompile hacks).


 PS: If you choose the last option, I have no LSD to give you. You're on your own there.

[Localizations, Games, Apps, Docs / Some mods]

Before people get there panties in a bunch (either excited or dismissive), this is just for fun. I've written quite a few different resample drivers for the PCE over the years (they all have different advantages). 7khz, 7.86khz, 15.7khz, 40khz-224khz, etc (I think etc, or maybe that's all of them). Some did the resampling inside the interrupt routine, others did it in sequence to a buffer for the driver to play. Blah-blah-blah.

 Anyway, my MOD pattern/fx decoder was never finished. I had a convertor to take MOD/XMs and convert them, but... well, nevermind that. So this is David Michael's mod player. It's not finished either, but a decent amount of FX are supported. Quite simple, but while the code works - it's far from optimized. It did the resampling inside the interrupt routine, converted the sample on the fly inside the routine, etc. Blah, blah, yadda-yadda. I always wondered why DM's player sounded so harsh, until I looked at it and found out that ... jitter from a not fast enough interrupt routine. Made high frequencies sound like crap. So, with a little help - here's DM's mod player with a few mods, without the jitter. Doesn't sound too bad. I was supposed to keep this hush-hush, but it's been like... over 5 years now..... come on! (GOB reference)

(has two different songs in the video)

Personally, I like the PCE sound. Going with (re)samplers like this, you loose that. Still, PCE sound lacks a few things IMO. A fatter bottom end and some instruments with more pronounced timbre other than just detuning two channels and using vibrato. I think the marriage of the two would probably yield some decent PCE-fied tunes. Anyway, this is just one of those - hey, check this out. Kind of thing. Some instruments in the video/mods sounds decent, while others not so much. Non of these samples are preprocessed. They're straight 7khz resampled on the fly. This is roughly what later gen GBA games did (7-8khz to a single 9bit stereo dac with a resampler routine.)

[Localizations, Games, Apps, Docs / HUC - huc_misc.asm file check]

Can you guys check your huc_misc.asm file, under the lib2_farmemget.3: label?

Does it read as this?

Code Select Expand

lib2_farmemget.3:

__stw <_cx
 lda <__fbank
 tam #3

 I downloaded a few packages from huc's site and they all have the same error in the lib file.

[Localizations, Games, Apps, Docs / 68k and HuC6280 comparison]

These two processor architectures are so polarizingly different, not to mention the 'bitness' aspect as they are defined (32bit,16bit, and 8bit). This is a discussion for a more detailed look between both CPU's, in relation to the MD and PCE, beyond general assumptions and popular/common beliefs. This is not a system vs system compare. If the cpu's offer an advantage to the supported/specific hardware, than that's valid. Talk and examples of similar CPUs that share either of the two's architecture is also valid. And while game examples are valid, I'd rather it not be the primary source of comparison. Maybe more to reiterate a point or such. The primary discussion should focus more on code related examples, if possible.

 So, 68000 vs huc6280.


Please, no trolling. And if the trolls do come a knocking, please don't feed them. Best to ignore them.