added INLINE data printout

[kollokollo]

The INLINE data in my gfa files where lost/ not convertet. So I added a INLINE data printout. The Data is convertet to comments with the HEX-Dump. I know that this can be very large data portions (max 32kBytes). Maybe it can still improved by introducing a commandline flag to gfalist which switches this feature on ad off. Also a INLINE data dump to file could be useful, but for my purpose the HEXDUMP was fine.

[mmuman]

I don't know GFA enough, is there an INLINE keyword that takes them as input just like DATA in the 8bit BASIC variants? In which case it should be output with the same formating. The goal of the tool is to reproduce a source file that can be parsed again and give an identical tokenized file.

[mmuman]

Do you have a sample file around?

[kollokollo]

This is not possible, because .GFA files can store chuncks of user defined binary data, which are loaded within the editor into an INLINE statement. The data is stored in GFA files, but not in LST files (the data is lost in case you convert it). My approach was, to at least convert that data into comments in the LST file, so it can im principle be (manually or so) restored. Sorry, I do not know the 8 Bit variants. INLINE is different from DATA.

[kollokollo]

Here is an example:

' ## INLINE: src=0x96ea3f4 bot=0x96ea4f4 ' $0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ' $0010: 7f ff ff fc 00 00 00 00 ff ff ff fe 7f ff ff fc ' $0020: ff ff ff fe 40 00 00 04 ff ff ff ff 55 55 55 56 ' $0030: ff ff ff ff 40 00 00 06 ff ff ff ff 7f ff ff fe ' $0040: ff ff ff ff 40 00 00 06 ff ff ff ff 40 00 01 06 ' $0050: ff ff ff ff 40 00 02 86 ff ff ff ff 40 00 02 86 ' $0060: ff ff ff ff 40 08 01 86 ff ff ff ff 40 0c 00 46 ' $0070: ff ff ff ff 40 0e 00 06 ff ff ff ff 40 0f 00 06 ' $0080: ff ff ff ff 40 0f 80 06 ff ff ff ff 40 0f c0 06 ' $0090: ff ff ff ff 40 0f e0 06 ff ff ff ff 40 0f f0 06 ' $00a0: ff ff ff ff 40 0f 80 06 ff ff ff ff 40 0d 80 06 ' $00b0: ff ff ff ff 40 08 c0 06 ff ff ff ff 40 00 c0 06 ' $00c0: ff ff ff ff 40 00 60 06 ff ff ff ff 40 00 60 06 ' $00d0: ff ff ff ff 40 00 00 06 ff ff ff ff 40 00 00 06 ' $00e0: ff ff ff ff 7f ff ff fe 7f ff ff ff 1f ff ff fe ' $00f0: 1f ff ff fe 00 00 00 00 00 00 00 00 00 00 00 00 ' 256 Bytes. INLINE spp%,256 ... The statement INLINE spp%,256 holds data for a sprite....

[kollokollo]

Without the INLINE data itseld the following code would be unusable and also later it would be inpossible to recreate the GFA file even with the original GFABASIC. This is the output of gfalist without my patch:

DEFFILL ,2,4 PBOX 0,0,640,400 r$=MKI$(&H1FE)+MKI$(&H101)+MKI$(&H0) INLINE s%,930 INLINE sp%,21760 INLINE spp%,256 FOR t&=0 TO 31 {spp%+t&_4_2}={sp%+t&_4+32_4} {spp%+t&_4_2+4}={sp%+t&*4} NEXT t& ssp%=GEMDOS(32,L:0) tab%=C:s%(0) ~GEMDOS(32,L:ssp%) ....and so on

[mmuman]

On old BASIC dialects for 8bit computers, we had a DATA statement that was similar, although the values were explicitly passed, and you had to iterate through it a bit like reading a file to read from it and POKE it to some other place.

In the case of INLINE then yes we need to dump it "out of bands" in comments indeed.

[kollokollo]

Sample file: SPRITE.GFA

Something went really wrong, and we can’t process that file. Try again. (seems github doe not accept .GFA files) What can I do?

[mmuman]

You can zip it: https://help.github.com/articles/file-attachments-on-issues-and-pull-requests/

[kollokollo]

SPRITE.GFA Unfortunately, we don’t support that file type. Try again with a PNG, GIF, JPG, DOCX, PPTX, XLSX, TXT, PDF, or ZIP.

SPRITE.GFA.gz Unfortunately, we don’t support that file type. Try again with a PNG, GIF, JPG, DOCX, PPTX, XLSX, TXT, PDF, or ZIP.

sample.zip (containing only SPRITE.GFA) Something went really wrong, and we can’t process that file. Try again.

[kollokollo]

[Uploading SAMPLE.ZIP…]()

[kollokollo]

...looks like now github has crashed...

[mmuman]

Looks like they check the zip contents for known formats... Last attempts just links to this pull-request.

What you can do is add a tests/ folder with that file inside, and commit it, and push that to your repo to update the pull-request. Someone might want to later make sure the output is stable with tests anyway.

[kollokollo]

OK, but let me first find a better and smaller example...

[mmuman]

Oh, someone just told me GBE generates inline files separately as pointername.inl when creating the LST file. So we might indeed want to add an option to do that. However in the case of a filter for git diff, we still want to keep that to the standard output, else git diff will not notice the inline changed.

[kollokollo]

I have added a sample gfa program with inline data. Do I need to do the pull request again?

[mmuman]

No it's fine, the commit has been added to it. As long as you do it on the same branch it works (here the master branch, which is the default).

[kollokollo]

Ok, fine. Thanks for talking me through. BTW: gfalist is now also used in X11-Basic for Android. That was the reason why I looked at my (outdated) fork of gfalist from 2001 (I think I got it from Peter Backes...) and tried to make the changes survive in the current version of gfalist. regards Markus

[mmuman]

Good to know! ;-)