PC-FX homebrew development.

[nodtveidt]

In order to get this sprite to display on the PCE, I would normally give it pattern values in offsets of 0x40. Here, it's a pattern value offset of 2. That does not make a whole lot of sense to me.

Code: [Select]

eris_sup_spr_set(0);
eris_sup_spr_create(0, 0, 0, 0);
eris_sup_spr_set(1);
eris_sup_spr_create(16,0,2,0);
eris_sup_spr_set(2);
eris_sup_spr_create(0,16,4,0);
eris_sup_spr_set(3);
eris_sup_spr_create(16,16,6,0);
but anyway...

Code: [Select]

_eris_sup_spr_ctrl:
mov lp, r17
setup_addr r20, r19, r18, 3
mov r6, r16
mov r7, r15

mov r19, r6
mov r18, r7
jal _eris_low_sup_set_vram_write

mov r19, r6
mov r18, r7
jal _eris_low_sup_set_vram_read

mov r19, r6
jal _eris_low_sup_vram_read
mov r10, r7

and r16, r7
or r15, r7
mov r19, r6
jal _eris_low_sup_vram_write

mov r17, lp
jmp [lp]
I am not sure how similar this is to the original C code I wrote, as this is nineteen flavors of Greek to me, but in theory, the only purpose of the function is to modify the high byte of the fourth word of the SATB entry.

[nodtveidt]

OK so I did some more testing... it seems that the fourth argument of eris_sup_spr_create() affects the entire fourth word. So, I set it to 0x1180 to set a size of 32x32 with a priority of 1 and a palette of 0, then got rid of the code for the other three sprites. It worked. So, I changed it to 0x1080 to reduce it to 16x32. It worked. So, it looks like it's affecting the entire word. I can work with that for now. I can only surmise from this that eris_sup_spr_ctrl() is doing the same thing.

[elmer]

In order to get this sprite to display on the PCE, I would normally give it pattern values in offsets of 0x40. Here, it's a pattern value offset of 2. That does not make a whole lot of sense to me.

I've not looked at the documentation ... is he perhaps using an "index" instead of an "byte-offset"?

Code: [Select]

_eris_sup_spr_ctrl:
mov lp, r17
setup_addr r20, r19, r18, 3
mov r6, r16
mov r7, r15

mov r19, r6
mov r18, r7
jal _eris_low_sup_set_vram_write

mov r19, r6
mov r18, r7
jal _eris_low_sup_set_vram_read

mov r19, r6
jal _eris_low_sup_vram_read
mov r10, r7

and r16, r7
or r15, r7
mov r19, r6
jal _eris_low_sup_vram_write

mov r17, lp
jmp [lp]

It makes sense when you know that the 1st 4 parameters to a C function are passed in registers r6,r7,r8,r9, and that the return value is passed back in r10.

"lp" is just the function's return-address (unlike the 6502, it doesn't go on the stack). So he's saving it temporarily in r17 so that it doesn't get trashed by the subroutine calls (the "jal" jump-and-link instructions).

He's using r15-r20 as temporary registers (there are 32 registers).

So, that code ...
[ul][li]calculates a VRAM address[/li][li]sets that address in the VDC's MARR (READ) and MAWR (WRITE) registers[/li][li]reads the 16-bit word at that VRAM address[/li][li]ANDs it with the the contents of r6 (the original 1st parameter)[/li][li]ORs it with the the contents of r7 (the original 2nd parameter)[/li][li]writes the 16-bit word back into the VRAM address[/li][/ul]
Basically, simple stuff, but done in a really slow-and-horrible way.

BTW ... Alex's function has a bug in it. He shouldn't be using r20 without saving it on the stack.

The ABI defines it as a "callee-saved" function-preserved register, and not a "caller-saved" function-workspace register.

P.S. I'm going to "guess" that this is the kind of technical stuff that makes most people's head ache! 

[nodtveidt]

Aye... the way spr_ctrl normally works is you set a mask and then set new parameters. For example:

Code: [Select]

spr_ctrl(SIZE_MAS|FLIP_MAS, SZ_32x32|NO_FLIP);
or

Code: [Select]

spr_ctrl(FLIP_MAS, FLIP_X);
so only the bits you want to change are affected.

[nodtveidt]

Okay so this is all starting to come together... all the differences in paradigms are starting to lose relevance. Practice always makes perfect, I guess.



Two 32x64 sprites glued together on the first 6270. What I did was write a test program in assembly that does nothing more than import a sprite file, then wrote a utility that will extract the converted data from it and put it into a neat little text file. I can then copy the text out of the text file and paste it into my program, where I have a large array that holds all the sprite data. It's not the most elegant solution but for now it works.

[elmer]

That's great to see on the screen! 

[nodtveidt]

I could not find a random number generator in liberis and since stdlib is disabled, I figured I would just add one manually. I implemented the basic xorshift RNG, and gave it static seeds (until I implement a "Push Run Button" part to seed it). The stars fly by from right to left and respawn at random X and Y values when they reach the left side of the screen. The right half of the asteroid on the screen is white because I was testing the eris_sup_spr_pal() function... it works.

What I am doing here is porting my old Asteroid Challenge demo to the PC-FX. A great deal of the code is directly portable, though any code that references graphics needs to be updated. The core logic and collision routines are 100% portable without changes from its PCE original. This is why I like C so much.

EDIT: Moved further along... have added the asteroid generator.

[esteban]

Awesome.

[nodtveidt]

As was with the PCE version, the sprites of the high score and the player shots create massive amounts of flicker due to the very large asteroids... but now I can move both of those to the second 6270 to eliminate the flicker. Woohoo

[nodtveidt]

The game works.



It currently lacks asteroid-to-player collision because it runs too fast, and I have not yet added any sound aside from the CD audio music... but it's working and playable.

[nodtveidt]

The pad code does not work on real hardware. I don't know why. It will register a value and then immediately go back to 0... and will toggle just like that as you hold down *anything*.

EDIT: I came up with a hack that works... I read the pad more than once and use the highest value as the result. That gets the job done. I have no idea what's wrong but hey, at least I figured out a workaround.

[elmer]

The game works.

Excellent! 

But OTOH, that means that you're going to beat me to having a working PC-FX game. 

The pad code does not work on real hardware. I don't know why. It will register a value and then immediately go back to 0... and will toggle just like that as you hold down *anything*.

That's another one of those things to look for in the SDK docs.

The PC-FX's joypads are hardware-serial-read rather than parallel-read, and IIRC the hardware allows for a multi-tap.

So the liberis function that you're calling may not be resetting the "read" back to the "initial" state for the pad ... or something ... or I may be totally wrong.

While you're "on-the-line" ... can I ask if you've seen anything in the PC-FX BIOS or libraries that uses the R2 and R5 registers?

AFAIK, they're not used except temporarily-during-startup, and I'd like to use them for the Frame Pointer and the Thread Local variables pointer.

No, but I haven't really dug into the BIOS and official dev libraries that much.

It doesn't look like anything in Hudson's compiler or BIOS is using R2 or R5, much to my surprise and happiness.

It does look like the BIOS "fsys" library is using $54 (or maybe $58) bytes of GP-relative storage from -32768[GP] to -32684[GP], but I think that I can take care of that in GCC's linker script so that we can still use those library functions.

My "stack-handling" problem is about 90% fixed ... it's something that I broke when doing the incredibly-ugly update from GCC 4.5.4 to GCC 4.7.4. 

[nodtveidt]

Excellent! 

But OTOH, that means that you're going to beat me to having a working PC-FX game. 

Sowwie... but on the plus side... that means that we're really super close to having a completely useful toolchain, right?

That's another one of those things to look for in the SDK docs.

The PC-FX's joypads are hardware-serial-read rather than parallel-read, and IIRC the hardware allows for a multi-tap.

So the liberis function that you're calling may not be resetting the "read" back to the "initial" state for the pad ... or something ... or I may be totally wrong.

I am not sure what the problem is myself and I have not tried doing it through just regular port reads (I assume liberis already does this though), but I worked around it by reading the port multiple times and using the highest value.

In other fun stuff, I tried implementing a track loop function... but it froze up the system. The SCSI-2 docs are HORRIBLE to comprehend... I was barely able to get CD audio playing at all, and even then, I can only send a single play command because successive commands lock the whole machine up. I am assuming it has something to do with the flag that tells the device to return a result immediately when a command is sent, but I have NO idea how to even get return values from the drive, nor am I able to figure out how to set ANY of the code pages to configure ANYTHING. I realize I'm not a coder but ffs, this shit's written for robots hocked up on Chesto berries.

[nodtveidt]

More fun trial-and-error... I used AGE to convert a 256 color BMP to a 256 color KING bitmap, then wrote a custom utility to strip off the 256 byte header, and used yet another tool I have that converts any file into a word array, plus my palette conversion utility that converts a JASC-PAL to a YUV palette array... bottom line, through a lot of experimentation and a lack of proper documentation, I got a nifty 256 color image to display on KING BG0.



Here's the code for it... this requires no external resources, as it's entirely array-based. I used bg7up.c as the initial template for this program, and made changes where needed.

http://www.frozenutopia.com/pcfx/bgking.c

I tried to paste the code into this msg but it exceeded the character limit for a post, so I just uploaded the source instead.

[elmer]

Sowwie... but on the plus side... that means that we're really super close to having a completely useful toolchain, right?

I am not sure what the problem is myself and I have not tried doing it through just regular port reads (I assume liberis already does this though), but I worked around it by reading the port multiple times and using the highest value.

I think that your 2nd comment answers your 1st question.

We're definitely on the "path" to having a completely useful toolchain, and it's nice that you're getting some pretty stuff on the screen, but ...

From my POV, we've got a "broken" compiler, and a "broken" library, with minimal functionality.

It's a good, maybe-even-a-great, start ... but it's just a "start". There's one heck of a long way to go to have a "completely useful toolchain".

Now, I've got the patience to keep-on-plugging-away it, but progress with GCC is slow-and-very-very-painful.