ZX0 compressor using non-standard decompressors

بواسطة albs_br

Champion (468)

صورة 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.

Login أوregister لوضع تعليقاتك

بواسطة theNestruo

Champion (414)

صورة 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)

بواسطة aoineko

Paladin (899)

صورة aoineko

19-01-2023, 17:59

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

بواسطة albs_br

Champion (468)

صورة 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.

بواسطة albs_br

Champion (468)

صورة 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.

بواسطة santiontanon

Paragon (1770)

صورة 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.

بواسطة santiontanon

Paragon (1770)

صورة 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!