Graphic conversion for any 256x192 into MSX1 graphics (Source code in Blitz Basic).

Paragon (1134)

31-03-2019, 18:27

Rogerup wrote:

LeandroCorreia wrote:

Just that, a raw dump first for the pattern and one for the 2 colors? No extra bytes before to specify the memory entry point?

Now you need the entry point AND a loader. Send me the file of 12288 bytes (2 x 6144) that I will create an Assembly loader for it and see how are the exact bytes you need at the beginning of your files, in order to see it directly with bload "image",r without lines of basic.

e-mail: rogerup at gmail . com

Or you can use just the VRAM format posted above, add this bytes to the beggining of the file:

FE 00 00 FF 37 00 00

And just use Bload file, S (if using disk, won't work on tape)

Btw... here..

SC2_NAM1 = 0x1800 # name table
SC2_NAM2 = 0x1900
SC2_NAM3 = 0x1a00

each 3 blocks are going to need initialized with values from 0 to 255. Total of 768 bytes.

Van LeandroCorreia

Paladin (963)

31-03-2019, 19:53

MsxKun wrote:

Or you can use just the VRAM format posted above, add this bytes to the beggining of the file:

FE 00 00 FF 37 00 00

And just use Bload file, S (if using disk, won't work on tape)

Btw... here..

SC2_NAM1 = 0x1800 # name table
SC2_NAM2 = 0x1900
SC2_NAM3 = 0x1a00

each 3 blocks are going to need initialized with values from 0 to 255. Total of 768 bytes.

What I'm doing so far:

1) Create a file with a header of 7 bytes (FE 00 00 FF 37 00 00)
2) Keep adding for each 8x8 pixels a byte with attributes of each octet.
3 After that, for each 8x8 pixels I add a byte with color attributes.

It's buggy, so my exit file is wrong. Slowing down BlueMSX I noticed that the pixel attributes are loaded just fine, but probably at the part of color attributes, the whole image gets messed up. Should I add any other byte header between steps 1 and 2? (please remember I'm a high level programmer, not used to Assembly and similar stuff).

Van LeandroCorreia

Paladin (963)

31-03-2019, 20:30

MsxKun wrote:

Edit: Maybe the differences could be cause Python floats are doubles in fact? They have more precision than C (and Blitzbasic?) floats. If that, is that good or bad?

It seems for me it's due another reason. It looks like you scaled down the original version I posted in here with a resampling algorithm such as bilinear or bicubic, and that made your source image a bit different from mine.

Van Rogerup

Resident (39)

31-03-2019, 21:36

@Leandro,

I create an algorithm to convert from RGB to Screen2 Format: msx_RGBtoScreen2

Note that to use BLOAD "file",S you need to save more things between pattern and color.

If you want to use BLOAD "file,R" you need another header.

I explained better at the page.

Van LeandroCorreia

Paladin (963)

31-03-2019, 22:01

Rogerup wrote:

Note that to use BLOAD "file",S you need to save more things between pattern and color.

And what should I include? A sequence of a certain number of 0 bytes would be enough?

Currently my code saves the 7 byte header, then 6144 bytes of pixel attributes, then a row of 2048 zero bytes and then finally the sequence of color bytes. Reducing the speed of BlueMSX, it's obvious that pixel attributes are loaded OK, but soon the screen gets corrupted when colors are (b)loaded(,s).

Van LeandroCorreia

Paladin (963)

31-03-2019, 22:21

Made it work! Many thanks, MSXKun and Roger Up!

https://ibb.co/wWXkhMn

Van ARTRAG

Enlighted (6976)

31-03-2019, 23:36

Van LeandroCorreia

Paladin (963)

31-03-2019, 23:45

Van MsxKun

Paragon (1134)

31-03-2019, 23:45

I scaled the image posted here, but used linear.
I could try with the original file, not the upscaled one here, but most probably I typed something wrong (nothing big or it would be more messy). Or the float thing

I think it's a good start, probably has room to improve it. And then... add more screen modes and custom palette support.
Mostly, what BMP2MSX does It's still a wonderful little program, but I'll be glad to have a native linux one.

Van LeandroCorreia

Paladin (963)

31-03-2019, 23:47