Archive for the NES2PCE Category

Email and file server is down

Posted in hacks, homebrew, NES2PCE, retro on October 17, 2015 by pcedev

My server account got suspended cause I didn’t pay the bill. Hopefully I can get it back online in the next few days.

I’ve been messing with PCE hardware this weekend. Also looking over what projects are due, what needs attention, and what is going to be put on the back burner (for time resource reasons).

That and just some gaming on the SGX+SCD. I was playing SMB (nes2pce) and realized I could optimized some of the nes2pce PPU emulation code. Anytime the cpu writes to vram, the internal emulation code has to do all these checks to make sure it’s transferring data to the right area (and how to interpret that data). I needed this because I found games could just load PPU tile, sprite, and tilemap stuffs all in one shot.

Of course this slows things down having to do all these checks. Sometimes it puts what would normally be the cpu in vblank time, into the start of active display. I figured one way to speed this up, is to have dedicated $2007 write functions. NES games tend to setup strings of data into a buffer to be updated during vblank (because game logic is processed during active display). This means it’s very rare that a string of data will cross a tile bank into a nametable area, etc. So for those areas of code, I could potentially use the faster and specific $2007 write functions.

Nes2pce code was never meant as general emulation for NES games to run on the PCE. It was to get the game up and running close as possible, to help the transition of replacing the original NES sprite and map routines into native PCE stuffs. Though none of the nes2pce stuffs I’ve released have these changes.

Ideally, the sprite and map routines should be hacked for direct PCE writes, by passing some of the PPU emulation. So the optimization I listed it kind of counter intuitive to the goal of nes2pce. But I just don’t have the time to alter each game for these kinds of changes. I used to have that kind of time, but I squandered it :/ Eventually, I will have that kind of time again – but will people really care about nes stuffs on PCE by then? One example is Dragon Warrior. It’s the first RPG I’ve ever played, so I have nostalgia for it. I’ve already hacked the map routines somewhat. The game is simple enough to keep modifying. But should I really put my time into it? This is the dilemma I’m faced with nes2pce.

Anyway, just thinking out loud.

Advertisements

Summer update

Posted in homebrew, Megaman, NES2PCE, translations on July 6, 2014 by pcedev

Lost my place (last minute notice, didn’t have a contract); everything got moved to storage or thrown away (tower is in storage). I’m also away/out of town for the summer, so things are slow and limited on the PCE side (this is the time of year I make my money). I have my laptop to do some dev stuff on, but no translations or megaman hacking stuffs. My classes started late August, so when things get settled down – I can started working on stuff again. I swear to whoever – life is never a dull moment for long.. ugh.

I want to keep my PCE coding skills sharp and in practice, so I’m gonna do a tiny little project with CC65 for PCE. A one level/simple game or something. Mostly to get a CC65 setup for PCE, etc.

Posted in hacks, Megaman, NES2PCE on February 23, 2014 by pcedev

I’ve been thinking about the map format for Megaman. I really don’t like the idea of 32×32 with a huge LUT to draw from. Not because it’s hard to write the decoder, quite the opposite. But more of because writing the encoder means writing a whole new app.

So that got me thinking. 8×8 is out of the question for all room data, but 16×16 is a good compromise. 16×16 with WORD entries (4bits for subpalette and 9bits for tile). The ’tile’ could simply just be the base number<<4 and each tile following tile is +1 (for whatever layout I want). Typical stuffs for meta tiles, but 16×16 format is small enough; only 512bytes per 256×256 pixel res room. It also makes use of existing tilemap tools. And, if I ~really~ need more precision than that, I can reserve anything between the 10th bit to indicate a look up value, rather than an actual straight block reference. That way, if I really need 8×8 with each subpalette reference for small specific parts of the room map, I’ll have it. Done and done.

Been busy this weekend though (I’m replacing the cylinder head of my 1993 4.0L 4×4 jeep. Old head cracked, so I bought a new one. I’m reassembling the engine, slowly). Gonna try to do some test runs on new BG stuff tonight though.

Posted in Megaman, NES2PCE, Uncategorized on February 20, 2014 by pcedev

Working on changing the tilemap format, for the room/screens. Originally, the game uses a 32×32 meta tile format. IIRC, it’s one byte per 32×32 block. So that’s 64 bytes per 256×256 pixel screen. That’s pretty small. A 256×256 pixel screen with 8×8 tiles (and subpalette per tile) is 2048 bytes. Quite a bit bigger. Cutman’s level has 22 rooms. If I made each room unique, than that’s 45k just for that level. Not a big deal if this was strictly just a hucard/rom project, but that’s pushing it a bit for the CD project. I’ve already decided that I’m gonna break the levels into ‘loads’, and certain things can be loaded directly into vram from the CD track at the start of a level, but even then – I still need to keep the space requirements down.

I figured that I can build upon the 32×32 block system. I could double the map entry with a parallel map, so that each block is two bytes instead of 1 byte. That gives me 65,536 blocks; too much for a look up table. But I don’t need to use all the bits. I figured, with 16k, I can get about ~630 32×32 blocks in the decode table. That would decode the 32×32 block into 16 8×8 tiles. Each tile would be 9bit addressing (access up to 512 tiles in vram), and each tile would have access to its own unique subpalette. I’d bitpack everything to cram it into 16k table. I think the original game uses something like 64 32×32 blocks? This would be a big improvement, in just that alone. I could even use the unused bits for collision stuffs. For the backend PPU emulation, I’ll add a special ‘reg’ that the code reads from – to get the additional subpalette and MSbit. It’ll clear it after reading from it, too.

Posted in Megaman, NES2PCE on February 19, 2014 by pcedev

Power meter replacement design/code is finished. I’m pretty happy with the way it works. In regular weapon mode, the whole meter width is the health. In weapon mode, the meter is divided by half – one side for health and one side for weapon energy (well, one more pixel for health width than weapon energy). Next will be to do a version for the boss as well. I still need to make some ‘weapon’ icons for below/base of MM power meter, since I’m keeping Megaman blue regardless of the weapon picked. Though I might have a setting in the options to change this (retro look). It’s not that it’s more difficult, it’s just that I like the original megaman colors for the more modern looking sprite.

I also got rid of the score at the top, as well as the sprite ‘flicker’ routine. The routine is automatic, and cycles/staggers the sprite order depending on even/odd frames. This is primarily to reduce blank out (induce flicker) for the NES sprite line width problems. Since I’ve upgraded the sprites to new sizes and less of them, this isn’t an issue anymore. Plus, it’ll make sprite layers for parallax less of an issue to deal with (I want specific sprite priorities).

Posted in hacks, Megaman, NES2PCE with tags , , , , , , , , , on February 12, 2014 by pcedev

Show off new sprites for Cutman’s level:

Can’t really see much, but each sprite has its own subpalette. I think I reserved something like 10 per room, for enemies. Most sprites use all 15 colors, though it doesn’t really show. In comparison, MM Wily Wars uses 7/8 colors per enemy sprite. Fragmare’s working on tweaking the MM sprites.

So nothing fancy to show off, other than it’s up and working (room sprite/pal load routine).

Posted in Audio, hacks, Megaman, NES2PCE, retro with tags , , , , , , , , , , , , , , , , on February 8, 2014 by pcedev

More Megaman 1 stuff.

Maaaannnn. Talk about a pain. Principle and execution; two very different things. What should have been a very easy upgrade to the load room graphics hook/code, ended up being a nightmare. It broke a lot of stuff that I already had in place. So, some other stuff got changed/upgraded (mostly OAM->SAT conversion). But it’s done and working. Finally. All the enemy sprites for Cutman stage are up and running. All converted to native PCE format. I worked out how to handle the palettes for those enemies too. You know, you don’t realize how much 16 subpalettes just for sprites – is incredibly large for that era. It makes things sooo much easier, and the fact that I still have another set of 16 just for the BG graphics – this is gonna be easy. Wily Wars on the MD/Gen, uses 7+1 colors for sprites. That how the extend the 4 subpalettes to be more than 4. 8 colors for a sprite, isn’t so bad for Megaman style design. BUT WE ARE GOING THE FULL 15 COLORS PER SPRITE! Yeah, baby. I purposely added colors to the sprites, even if you can see them – lol. I wanna have a few screens in the game, surpass the 100+ color count mark.

Anyway, things are coming along. I’m working on the ‘start stage sprite’ load routine, which is different than the load-room-sprites (not sure why). I’ll have something to show off when that’s finished.