Convert Binary to MSX Basic | MSX Resource Center (Página 1/2)

Master (172)

26-04-2023, 06:24

Here is an idea: A MSX-BASIC binary file contains start, end and execution addresses. Allow the script to detect if the binary file starts with FEh (MSX-BASIC binary header). If it does, read the 3rd word after that. That's the entry point of the binary program. So you don't have to provide that value in the command line in this case.

Por coldbreeze

Master (141)

26-04-2023, 06:51

Pizzapower, I love your idea! Thank you very much!

Por Manuel

Ascended (19678)

26-04-2023, 10:47

Reminds me of Data Maker from https://www.msxcomputermagazine.nl/archief/msxdos-25/

Por coldbreeze

Master (141)

26-04-2023, 10:52

1988... That brings back some nice memories.

Por PingPong

Enlighted (4156)

26-04-2023, 13:11

If msx - basic store data integer values in a compact format ( i do not know ) and there is no virual limit to the amount or lenght of data statements, maybe than using string could be an advantage to use straight int values?

just to avoid convertion between hex values and int and string manipulation and give a speed up to loader....

or does msx . basic store data with integer values like this?
data 1,45,34,201 ......
how they are readed in by read statement(s) ?

Por coldbreeze

Master (141)

26-04-2023, 14:50

PingPong, we could be dealing with the memory footprint vs. performance situation. The int-based encoding of the binary (in the DATA section) would take twice as much memory. However, I would expect faster parsing subject to a performance test.

Por Manuel

Ascended (19678)

26-04-2023, 16:22

I would expect that the format used by coldbreeze here is the most compact. A string with hexvalues. But nothing stops you from encoding it in an even more compact format, at the price of understanding what it is, type-ability and decoding-speed.

Por cjs

Master (143)

27-04-2023, 06:19

PingPong wrote:

If msx - basic store data integer values in a compact format...

It does not. After the DATA statement there's no tokenisation: characters are just copied until the next unquoted colon or the end of the line. So if you're looking to optimise space, you want the shortest strings possible representing the numbers. (Which I guess if you're not doing your own decoding thiswould be decimal: "-32768" is the same length as "&hFFFF", but positive numbers will be all shorter in decimal form.)

I know this becuase I wrote an MS-BASIC detokenizer. That code may answer other questions about how MSX BASIC tokenisation works, though it may be easier just to ask. (The code is somewhat complex because it also deals with character set translation to Unicode: DATA 3 will come out as just that, but DATA "3" will map the character "3" to whatever you've chosen for that point in the VDP character set, rather than the standard MSX character set for your chosen region.)

Por PingPong

Enlighted (4156)

27-04-2023, 07:00

Manuel wrote:

I would expect that the format used by coldbreeze here is the most compact. A string with hexvalues. But nothing stops you from encoding it in an even more compact format, at the price of understanding what it is, type-ability and decoding-speed.

the problem here was about the string space that is not extremely big. So i've only observed if a solution using data statements could be better. But as someone noted, the data format is far than compact.
But, giving the explanation, i also expect that DATA with string do not impact to the basic string space, only to the memory used to store the "source code" so there should be no problem.

Por coldbreeze

Master (141)

27-04-2023, 07:53

VampierMSX mentioned that I could drop the opening quote in the DATA lines, however, that would break the compatibility with MBASIC for CP/M. :-(

I am not a big fan of duality, but I might have to introduce an MSX specific option to the command line. Sometimes, it is worth saving an extra byte for each and every line.