Archive for August, 2014


Posted in homebrew with tags on August 20, 2014 by pcedev

Object-to-object collision is working. So all enemies move around the map, obey map collision, player obeys map collision, enemies coming in contact with player bounding box detected.

It’s almost a real game engine. Right now, the player and enemies move on a 16×16 pixel grid movement. When you press a direction, the player moves for 16 pixels in that direction. It’s quick. It doesn’t sound quite right for an action game, but Arkista’s Ring got away with it so I figured I could as well – for a mini game.

But I’m rethinking that approach. I might change it to 8×8 or 2×2. Something smaller than 16×16. I’ll have to change the map collision routines for the player, but that’s not hard. Object/Object collision works on a pixel basis, so that has no effect on the map/player movement.

Next is to add projectiles (and protruding weapons/swords/etc), to the object handing queue.


Posted in homebrew on August 17, 2014 by pcedev

Heh. I got the first iteration of ‘wanderer’ AI up and running. More like spastic/bug AI. But it’s cool to see it up and running (along with collision map detection). I need to add some bias into it; if at a far end screen/threshold, add a bias to towards the opposite end – so it doesn’t stay in one particular area.

I’ve been looking at the first Neutopia game enemy’s AI and I have a few ideas. Gonna need to look at a few more games as well.

I think I’ll get object to object collision working first, so the enemy can damage the player (and vice versa) – before I get too far into the enemy AI thing.


Posted in homebrew on August 17, 2014 by pcedev

Writing the AI (and the map collision detection for it) 😀

It’s challenging, but really fun. It’s not like simple side scrollers (walk back and fourth enemies), or scripted enemies in shmups. I never really thought about how to do AI for overhead maze/zelda/etc style designs.

Hopefully should have the NPC/enemies running around by the end of this week (they’re are on the map, have slots, etc – just no AI to control them). Well, at least one type of AI up and running for this week. I’m gonna have to make quite a few different ones for different enemy types.

Posted in homebrew on August 17, 2014 by pcedev

SXY/SAX/SAY aren’t the best instructions in the world. One 65x comparison doc in general, said they were a waste of opcode. While I agree that there could have been better opcodes added/upgraded to the 6280 from the W65C02S, they are not without their uses (albeit limited). I’ve used them on occasion; not so much as to save a cycle or three (I do that too), but as a convenient method of keeping code cut down/readable. Not unlike the BBR/BBS instructions.

Posted in homebrew on August 15, 2014 by pcedev


Hahahaha. It gets right to the point. I needed a quick title screen, because I need the human interface to ‘seed’ my random number generator routines. They also get reseeded on screen transitions (just in case).

But anyway… my spritesheet to SATB entry.. is amazingly slow ;_; 728 cycles per single entry (SATB entry)! Sure, I’m using macros and very unoptimized code, but still. I have a way to speed it up. Gonna try something I hadn’t thought of before.

Far calls

Posted in homebrew on August 14, 2014 by pcedev

I filled up my first lib bank (the first non-fixed mapped library bank). I had a far call setup from main/fixed to far lib stuffs, but now that I’m on my second lib bank I needed to figured out a way how to handle call far routines from lib bank 1 and vice versa.

The problem wasn’t so much a problem, until I needed the functionality of nesting far calls. I.e. call in banks, between banks, as if they were some linear mapped large bank. I’ve limited the far code to 8k, with 32k for data, and top 8k for fixed bank stuffs. The macro I have setup, helps keep the code clean – but otherwise it just stores bank:word -> A:X:Y and then JSRs to a fixed bank function. The fixed function basically pushed the return bank# and address onto the real stack. So, I can basically nest up to ~51 far calls. The overhead isn’t that bad:


sta FarJSR+2
tma #$02

lda FarJSR+2
tam #$02
stx FarJSR+0
sty FarJSR+1

jsr .CallFar

tam #$02

jmp [FarJSR]


Of course, routines inside a lib bank don’t need far calls (I’ll probably add testing logic in the macro, so it’ll automatically detect and use a near call or a far call. All on the Assembler program side; no cpu code used). So things are arranged optimally. For this game, a 16K far code page + 24k data page layout would probably be better. But for now, I’ll stick with the 8k far code page. Meh, I’ll probably end up changing it later on. So it goes..

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.