ZX0 compressor using non-standard decompressors

By albs_br

Champion (499)

albs_br さんの画像

19-01-2023, 16:52

I decided to start a new thread to not got too far off topic on the other (https://www.msx.org/forum/msx-talk/development/pletter-or-ot...).

The issue here is that the ZX0 standard decoder works just fine, but the other 3 won't.

It has been said that they use self modifying code, from where I concluded that the code needs to be on RAM.

So I made a LDIR to copy from ROM to RAM and it don't work:

https://github.com/albs-br/msx-tests/blob/master/zx0_compres...

It makes sense, as the original code uses some JP and calls which relies on absolute addresses and it will return to the code on ROM...

So, I wonder, how is possible to make it work? Is it possible to INCLUDE code on RAM, so the assembler calculates the address on RAM (above 0xC000)?

I'm using TNI Asm.

ログイン/登録して投稿

By theNestruo

Champion (430)

theNestruo さんの画像

19-01-2023, 17:10

To create code that will be moved to a different location, take a look at PHASE/DEPHASE directives (section 2.5.10 PHASE/DEPHASE in the tniASM manual)

By aoineko

Paragon (1144)

aoineko さんの画像

19-01-2023, 17:59

With tniASM, can't you just specify where the code starts with a directive like org 0xC000?

By albs_br

Champion (499)

albs_br さんの画像

19-01-2023, 18:14

theNestruo wrote:

To create code that will be moved to a different location, take a look at PHASE/DEPHASE directives (section 2.5.10 PHASE/DEPHASE in the tniASM manual)

Thanks, it worked perfectly.

By albs_br

Champion (499)

albs_br さんの画像

19-01-2023, 18:15

aoineko wrote:

With tniASM, can't you just specify where the code starts with a directive like org 0xC000?

I tried, but includes don't work inside RAM blocks. Apperently only rb and rw work on RAM.

By santiontanon

Paragon (1833)

santiontanon さんの画像

19-01-2023, 22:41

Some assemblers differentiate "logical address" from "physical address". In these assemblers (like Glass, for example), an "org" statement only changes the logical address, but not the place where the data that follows will be in the final binary. So, if you have "org #0000 ; db 1; org #1000; db 0", Glass will just generate a binary with 2 bytes, a 1 and a 0. Other assemblers, like tniasm, do not have such distinction, and "logical address == physical address". So, if you do "org #0000 ; db 1; org #1000; db 0", it will generate a 4097 byte binary (since it has to put a "1" in the first position, and a "0" in the position 4096). So, they need special commands, like "dephase", where inside of a "dephase" block, you can have a different "logical address". asMSX is the same as tinasm in this way.

I honestly think that the way tniasm / asMSX handle this is cumbersome and leads to confusion. Assemblers that have separate logical from physical address, like Glass, make much more sense, and are much more flexible in this respect.

By santiontanon

Paragon (1833)

santiontanon さんの画像

21-01-2023, 03:54

And ops, I think I spoke too quickly. tniasm would not have the behavior I describe above. Other assemblers that have the phase/dephase keywords do behave as I explain above, but tniasm is not one of them. Apologies for the confusion!