MSX Screen 5 format

ページ 1/3
| 2 | 3

By zonk47

Supporter (11)

zonk47 さんの画像

13-03-2016, 02:37

Translating Dark Sider. Trying to read the graphics... they are BLOAD'ed to the screen from several different files. It seems this BLOAD format is markedly different from QBASIC's. Can anyone explain how it works in Screen 5? (I need details... just mentioning the 7 header bytes and then saying "go see the VDP manual" really isn't helpful).

ログイン/登録して投稿

By zonk47

Supporter (11)

zonk47 さんの画像

13-03-2016, 06:53

Please tell me I'm not gonna have to disassemble MSX-BASIC to figure this out >_<

By NYYRIKKI

Enlighted (6011)

NYYRIKKI さんの画像

13-03-2016, 08:24

Well... that description should be almost enough, but ok, I open it up a bit more:

Header is like this:

	db #fe 	;ID byte
	dw {VRAM begin address}
	dW {VRAM end address}
	dw {not used when loading to VRAM}

What goes to where depends of how you have set up the VDP... (See BASIC commands VDP, BASE, SCREEN and SET PAGE) When you boot your computer the default addresses in SCREEN 5 are:

  0000-69FF   Bitmap
  7400-75FF   Sprite colours
  7600-767F   Sprite attribute table
  7680-769F   Palette (MSX-BASIC feature. Stored actually inside VDP)
  7800-7FFF   Sprite character patterns

The most interesting part is probably the bitmap... In screen 5 the screen is filled from left to right and up to down. Each nibble represents one color out of the 16-color palette. This means that the whole screen size in bytes is 128 * 212. Please note that in screen 5 you can use second parameter (0-3) of SET PAGE command to add (#8000) offset to BLOAD, VPOKE etc commands... This way you can access whole 128KB (#00000-#1FFFF) although BLOAD header and command parameters use only 16-bit addresses.

By zonk47

Supporter (11)

zonk47 さんの画像

13-03-2016, 09:16

Thing is, this file is not full screen. It's 7508 bytes. Game was apparently written in 1986... inspired by Dragon Quest... got a feeling someone wrote it right after finishing DQ. One of the most ambitious -- and impressive -- interpreted BASIC games ever written. Nothing like it until DarknessEthereal's "Lianne in... the Dark Crown" in 1997 (although this game is actually more impressive than that! Full screen smooth scrolling (if not full screen... it's as big a window as Gameboy anyway).

I looked at the file format for Copy in your wiki. it specifies a 2 word header for the width and height. However, these would be larger than the screen size in the case of (MSX-BASIC) mode 5 (mode 4 from the VDP's standpoint). No idea what is going on... but MSX-BASIC apparently likes it right out the box because a simple "BLOAD "dstitle.pic", S is all the program uses to load it.

I've tried viewing it with MSXview. No dice.

Also I think this game is either unfinished, or the dump is incomplete. There are several references to files in the code that are not in the archive. Although several of these are created as aspects of the save system, "dsending.bas" is not. Does anyone have a fuller dump of the game? (I got my dump from planetemu.net)

Please note I'm not trying to edit this within an MSX or an emulator... trying to create a converter between this format and others.

By NYYRIKKI

Enlighted (6011)

NYYRIKKI さんの画像

13-03-2016, 09:37

PC programs like MSXview might not like if the extension is wrong or the picture is not full screen... Maybe you should try to save it as full screen picture? ... Something like:

10 screen 5
20 bload"dstitle.pic",s
30 bsave"dstitle.sc5",0,&h769f,s

By zonk47

Supporter (11)

zonk47 さんの画像

13-03-2016, 10:12

Interestingly, that didn't work.

Here's the title sequence:

1000 'OPENING1ƒ
1010 SET PAGE, 1: BLOAD "DSTITLE.PIC", S: CMD SAVE 0, &H1FFF, 0: CMD OPEN 0
1020 SET PAGE, 0: COPY (0, 104) - (172, 117), 1 TO (12, 155)
1030 COPY (0, 118) - (204, 137), 1 TO (32, 180)
1040 GOSUB 51330: GOSUB 51400
1050 Y = 0
1060 COPY (0, 0) - (203, Y), 1 TO (28, 104 - Y)
1070 FOR A = 0 TO 25 - Y \ 4: NEXT: IF STRIG(0) OR STRIG(1) THEN COPY(0, 0) - (203, 103), 1 TO(28, 1): RETURN
1080 Y = Y + 1: IF Y < 104 THEN 1060
1090 RETURN

I'm betting "CMD OPEN" is a decompression routine, and the graphics are compressed. Well, thanks anyway.

By anonymous

incognito ergo sum (116)

anonymous さんの画像

13-03-2016, 11:23

Yes, I guess the image is compressed too. The disk has a DSCMD.BIN that is loaded to #C800, so the depack code should be there.

Disassembling the OPEN or SAVE commands in that file should give you a clue about the format.

By zonk47

Supporter (11)

zonk47 さんの画像

13-03-2016, 12:06

I realize I don't have to know the format... I only need to pop your BSAVE line in after the CMD OPEN.

By anonymous

incognito ergo sum (116)

anonymous さんの画像

13-03-2016, 12:33

It depends on what do you want to do. If you only want to see the image, you don't need to know the format. If you want to modify it and save it back in the same format, you need to know how the compression works. Unless the packer is also included in that bin.

By ARTRAG

Enlighted (6914)

ARTRAG さんの画像

13-03-2016, 13:25

But you can skip compression and load your version of the picture

By zonk47

Supporter (11)

zonk47 さんの画像

13-03-2016, 13:34

The plot thickens... I can detokenize all the BAS files except ds.bas. Not only does this file not detokenize, but its tokenization seems to derail all efforts to run non-tokenized code alongside it... I keep getting this "Direct statement in file" error. Is it using some sorta defeat technique to prevent modification?

ページ 1/3
| 2 | 3