Archive for the hacks 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.

VDC secret registers

Posted in hacks, homebrew on August 14, 2014 by pcedev

If you’ve coded for the PCE, especially in assembly and directly accessed the video hardware, you should have noticed that there’s a gap in the register list. Regs $03 and $04 are skipped. A couple of years back, with some discovery by tests Charles Macdonald had done, I eventually figured out that the key to using these registers – is to set the VRAM READ pointer. Depending on the bits set in the WORD buffer of that register, reading from $03 (IIRC, one the regs), enables or disables certain things of the VDC. It has minimal application outside of a few demo effects (mostly distortion type). But recently, it got me thinking. What I never tested… was if I could get the VDC to re-read any of the X/Y/CR/etc regs from the buffer – via these regs. Would be kinda neat for horizontal split screen scrolling and such, if possible. Just a note for when I get my console hardware back up and running.

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 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.

Posted in hacks, Megaman, NES2PCE, retro on February 4, 2014 by pcedev

No title to the post. Megaman stuffs…

Anyway, I got all the sprites for Cutman’s stage done. That is to say, all the new sprite sheets are in order. Hacking the room loading routine is next. I’ve already traced through it more times than I care to admit. I might be pretty fluent in 65x, but that doesn’t reading/understanding someone else’ code is easy.

The game makes it easy though. The game breaks down a sprite/palette load for a given room, over about 40 frames. That slow pan up or down, left or right, it’s updating vram sprites (which is why all sprites except megaman/score/powermeter are turned off). The game divides a level into 16k banks. There’s a variable for ‘currentlevel’; the game grabs this, maps it, uses the ‘current room’ as an index, and reads from a table (this table is in every level and in the same spot, just different values corresponding to the level), then maps in the tile bank and transfers to vram. All my hook needs to do, is get ‘currentlevel’ and ‘currentroom’, and the rest is just loading my own graphics to vram.

That part is fairly easy. The problem I’m running into now, is that there’s no room left in the ’emulation’ bank. There is where all the apu/ppu/mapper emulation code is. Since this is a fixed bank, this is also where my hack code and tables are. As of yesterday, I had to move all the enemy sprite sheets (object information, not the cell data) to another bank. Even with that, I’m left with 500bytes free in that 8k bank. So now I’m tasked with creating a second ‘library’ bank for code, and move non essential code to there (APU reg write code, PPU reg write code). I’m taking a note from the NES games, and duplicating the TIMER and VDC/NMI code into the second lib bank at the same place. That way when I swap in the far bank, the interrupt code still behaves as normal.

Eventually, I’ll won’t be needing the APU and PPU emulation code anymore. Actually, I soon plan to convert the sound FX in the game to a different format. Something along the lines of VGM format. That is to say, the sound FX will be streaming port writes at 1/60 tick (anything higher seems wasteful). It takes up very little room, compresses easily (and light on cpu resource), and allows me to make new sound FX outside of any music/sound engine design (and I don’t have to worry about a new PCE sound engine having legacy support too). Though OAM emulation will probably be the first to go. Once all the sprites have been converted over, I won’t need NES OAM (SAT) emulation anymore. That’ll free up a little bit of cpu resource. The tilemap code will probably be one of the last to go, leaving the game completely native PCE in execution (albeit limited to game logic).

But back to the ‘currentlevel’ and ‘currentgame’ variables. Knowing these two, I can create new stages. I just need to hook the bank changing routine for the higher level #’s. I want to add in two more Robot Master levels. Not MM: Powered Up levels, but something unique to this PCE version. That also means two new items or weapons. I figured I’ll probably make them ‘item-ish’ rather than weapons, as that would be harder to balance the game with new weapons. Or maybe new ‘moves’, like slide and charge power shot (you won’t need to ‘equip’ them). I do want to make a weapon/function that’s equivalent to ‘enery tanks’ in later MM games. I figured something along the lines of; convert weapon energy to health. And depending on the difficulty of the game setting, will be the ratio of transfer from energy to health.


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

The replacement hook for new sprites is working great, but the game loads new palettes and enemy sprites – per room load (small breaks in the level). Took me a bit, but I figured it out and how to hook it. This is important, because my hook needs to load the alt sprite graphics and palettes for ‘rooms’. Things are coming along nicely for the sprite upgrades. Much faster than I had originally thought.

I can also use this hook, to identify when a new room is loaded, and thus call my special foreground/background effects hook based on this. Since I’m reducing sprites to large than 8×8 cell segments, I’ll have more SAT room for these ‘effects’. And since the sprites are not made of less segments, I’ll have a much-much better sprite-pixel-scanline setup for this as well. Annnddd, the new graphics actually take up less vram than the emulated NES ones – so more vram for said ‘effect’ sprites.