|
Post by gameblabla on Jan 28, 2022 23:25:16 GMT
Hello, so i have a few questions (and begging ) regarding the KING chip and the different background formats. (aka HuC6272) One thing that puzzles me is regarding the so-called "Block mode". What is it actually ? I've seen mentions of a block attribute mode in the PC engine documentation but it doesn't seem that the AGE utility supports it. I've managed to figure out that the "normal" 8bpp mode is in fact linear. However, the bytes are swapped (it expects a big endian format), even though the CPU (V810) is little endian ! This does make it potentially annoying to work with.
I then took a look at the 16bpp color mode, as the file size was suspiciously the same as a raw 16bpp buffer. Turns out that this mode is little endian, unlike the 8bpp mode which is big endian.
I've posted my basic BMP to HUC 8/16bpp converter with my findings here :
I am still unsure however about the 24bpp mode and the block mode ones. Given that the 24bpp image is the same size as the 16bpp one, they must be using some kind of a YUV-encoded image. This is not JPEG either, as the file size for the 24bpp image is the same regardless of the content.
So far, we know that : - 8bpp is byte swapped (big endian) and linear. - 16bpp is not byte swapped (little endian) and also linear.
All color modes expect Y8U4V4 pixels, from what i gather. I'm still unsure about the 2/4bpp color modes and most importantly the 24bpp one... Any ideas ?
Another thing that i'm unsure about is the so-called 320 pixels wide mode that you can toggle. This would be very helpful for some potential ports but unfortunately when i tried to set it, it seems to do actually nothing. I recall a post from elmer saying that it does not actually improve the internal resolution...
|
|
|
Post by elmer on Jan 29, 2022 20:17:32 GMT
If you're going to continue having fun investigating this stuff, which I hope you are, then you should really read the SDK docs and not just rely on Alex's website (which is just a transcription of *some* of the docs). Here they are in .doc format instead of the unreadable-these-days .wri format of the originals, together with my lousy-google-translation of parts of the docs. BTW ... "block" is just another term for "character/tile".
|
|
|
Post by elmer on Jan 29, 2022 22:33:22 GMT
BTW, if you're going to keep on experimenting with graphics files, you may want to include them directly into your C program, rather than reading them in as files from CD. Turning a game-ready-graphics file, or any other kind of binary file, into an object file so that it can be linked into a C program is a slightly arcane piece of development lore that doesn't get documented nearly enough (IMHO). For example, if you wanted to include the file "blob.bin" in your C project ... ***********************************************
$ v810-objcopy -I binary -O elf32-v810 -B v810 blob.bin blob.o
***********************************************
$ v810-objdump -t blob.o
blob.o: file format elf32-v810
SYMBOL TABLE: 00000000 l d .data 00000000 .data 00000000 g .data 00000000 _binary_blob_bin_start 00000010 g .data 00000000 _binary_blob_bin_end 00000010 g *ABS* 00000000 _binary_blob_bin_size
***********************************************
#include <stdio.h>
extern unsigned char _binary_blob_bin_start; extern unsigned char _binary_blob_bin_end; extern unsigned char _binary_blob_bin_size;
int main() { unsigned char *pblob = &_binary_blob_bin_start; while(pblob < &_binary_blob_bin_end) { printf("%d: %02X\n", pblob - &_binary_blob_bin_start, *pblob); pblob++; } printf("size: %d\n", &_binary_blob_bin_size);
return 0; }
***********************************************
See these old webpages for more information ... balau82.wordpress.com/2012/02/19/linking-a-binary-blob-with-gcc/www.devever.net/~hl/incbin
|
|
|
Post by dshadoff on Mar 19, 2023 14:28:33 GMT
As a follow-up, the way stated above for inclusion of binaries works... but there may be an unstated weakness:
$ v810-objdump -t -x payload.o
payload.o: file format elf32-v810 payload.o architecture: v810, flags 0x00000010: HAS_SYMS start address 0x00000000 private flags = 0: v810 architecture
Sections: Idx Name Size VMA LMA File off Algn 0 .data 00007904 00000000 00000000 00000034 2**0 CONTENTS, ALLOC, LOAD, DATA SYMBOL TABLE: 00000000 l d .data 00000000 .data 00000000 g .data 00000000 _binary_payload_start 00007904 g .data 00000000 _binary_payload_end 00007904 g *ABS* 00000000 _binary_payload_size
As you can see, the alignment is "2**0", which means that it is not word-aligned, but rather byte-aligned.
In my test program, I found that the included data was placed at the start of the ".data" segment, so it was actually word-aligned (because the .data segment itself is word-aligned", but this may not always be the case. That is to say, the start of the .data segment is word-aligned, but within that segment, individual data items may be specified to have their own alignment, and the above example only makes it byte-aligned.
What may be required instead is the following:
v810-objcopy -I binary -O elf32-v810 -B v810 --rename-section .data=.data.blob1 payload payload.o
This will place the data into a segment named ".data.blob1", which - based on the link script in place - should treat it like another ".data"-like segment, with its own word-alignment. (Any ".data.*" segment should).
There are probably other ways to make this alignment happen using the assembler, but this way should work using just v810-objcopy and the linker.
|
|