SjASMPlus от z00m

[NEO SPECTRUMAN]

И более гибкие как раз мейкфайлы и скрипты снаружи, которые можно править как и когда тебе хочется, а не ждать, когда что-то внедрят в гибкий ассемблер.

мейки умеют плавающую запятую?
там логарифмы, степеня?

[Ped7g]

https://github.com/ped7g/ZXSpectrumN...acked.i.asm#L3

There was some ongoing discussion about packing 5bit 0..31 values (aka "strings" with limited charset) to bitstream, and how long the decoding routine has to be.
From the initial 22B by Busy we went down to 19B (thanks to Baze and Zilog), and I collected it all into my "code snippets" project (it's targetting ZX Next, but the particular 5b-decoding is classic Z80 only).

There's also sjasmplus macro to encode regular string literals... I'm so glad I did add WHILE in v1.18.0 ... it's becoming really handy (I could used `DUP inputdata_size` in this case too, but WHILE reads better to me, to understand what is happening).

Have fun. (I have some suspicion this is "old news" for you, but consider there are many newcomers trying to learn Z80 programming, the snippets are targetting those, as examples of small routines)

[SfS]

мейки умеют плавающую запятую?
там логарифмы, степеня?

Да. Всё что угодно через любое ПО.

[Bedazzle]

мейки умеют плавающую запятую?
там логарифмы, степеня?

Насколько помню, мы начинали с объединения нескольких бинарников в один.
Где здесь нужна степень или логарифм?

А если мы говорим просто о скриптах, то любой современный язык это умеет.
И да, он будет более гибкий, чем асм.

[NEO SPECTRUMAN]

Насколько помню, мы начинали с объединения нескольких бинарников в один.
Где здесь нужна степень или логарифм?

там где заявили, что компилятор ничего не должен делать

[Bedazzle]

там где заявили, что компилятор ничего не должен делать

Объединять три готовых бинарных куска в целое?
Да, хорошо зарекомендовавшая себя практика - делать это снаружи ассемблера.

[Advertiser]

[Ped7g]

there are several different approaches possible.

One MSX project I have seen sources of does this:
using `--longptr` option to have 24bit address space and `output -> outend` to produce binary 2MB file in one go (assembling machine code sequentially, emitting the file byte by byte). Then the mapping looks like `ld a,address>>14 ; bank num from long address` and `ld hl,address&$3FFF` to have offset into it (+ adjust to particular target area in memory) ... or something like that, I hope I remember it correctly.

I would personally go the virtual DEVICE route, making the virtual mapping match my runtime mapping, and using 16b labels (with page info):

  DEVICE ZXSPECTRUMNEXT  ; Next has 8ki pages
  MMU 0 n, 26, $0000 ; map page 26 into $0000..$1FFF , org $0000, enable auto-wrap
spriteData1: incbin "spr1.bin" ; spriteData1 == $0000, $$spriteData1 == 26 (page num)
spriteData2: incbin "spr2.bin"
  ...

  ORG $8000
  ; runtime mapping of data2 into $0000..$3FFF area (in case it does cross 8ki boundary while incbin)
  nextreg $50,$$spriteData2   ; maps $0000..$1FFF to page of spriteData2 symbol
  nextreg $51,$$spriteData2+1 ; maps $2000..$3FFF to page+1 (to cover for 8ki cross)
  ld hl,spriteData2           ; some 0000-1FFF offset to the beginning of the data

prepare full 1/2 MB memory state, and then SAVENEX to the "NEX" file which works with this pattern well.

For multi-load one can prepare each block in virtual memory, SAVEBIN/SAVEDEV it, then ORG back at the beginning and start over with second part...
All of these DEVICE "SAVE" directives are saving *current* state - local to their position in code, so you can produce different binary blocks from the same virtual memory area in one assembling - contrary to OUTPUT way, where you are emitting stream of bytes, making it quite tricky to "go back" (it's possible by opening the OUTPUT for rewrite, and then FPOS to position where you want to overwrite data - possible, but cumbersome a bit)).

The script few messages back to merge several bin blocks together into one big file using OUTPUT + INCBIN should definitely work (if small parts are less than 64kiB, then you will not even cross $10000 boundary, so no warning, but even with larger files it should work.. or you can avoid warning by some other trick, like INCBIN into MMU wrap-around page while also having OUTPUT active, or by using separate asm file without code, just to build the final big ROM, being assembled with --longptr switch).

....

But it also depends what you need at runtime, and how you plan to address those data... The example in this answer is slightly Next-specific for NEX file output, where I know the loader ".nexload" did already load all banks into memory, and I can just switch banks and data are there. Although I believe the principle does apply also to regular zx128 (but loader is up to you).

- - - Updated - - -

If you are just asking the basic "can sjasmplus produce 1MB ROM files?", then the answer is simple yes.

It should not only be possible, but it should feel like well supported, by multiple possible approaches. If you hit some issue with that, surely report it.

If you have issue to choose initial approach, then describe better what you are trying to do, and add some examples what you expect while writing runtime code, and what is the form of input data you want to assemble together.

- - - Updated - - -

а можно сделать дописывание файла при помощи SAVEBIN?

Thinking about it second time, while answering the stuff above... you can also use DEVICE with large-enough memory, INCBIN everything into memory into continuous memory block, and SAVEDEV to big file. (I forgot to mention SAVEDEV before)

[Shadow Maker]

@Ped7g just wanted to thank you for your continuing support of this assembler I believe you've spent hundreds of hours of your free time on it. Some people here were somewhat harsh, but you were always nice and sympathetic. Thank you! And keep up the good work

[NEO SPECTRUMAN]

SAVEBIN "part1.bin",$0000,$2000

а savebin происходит только во время pass 3 ?

[Ped7g]

а savebin происходит только во время pass 3 ?

Yes, it's saving bytes from DEVICE memory, which is not used in first passes during assembling, so it's completely zeroed in pass 1/2, and there's nothing to save.

The machine code production happens in third pass (also for OUTPUT/OUTEND/SAVETAP/... all the others).
(production = writing it... the machine code is "dry-simulated" in first 2 passes, ie. the assembler calculates how many bytes the instruction takes, to adjust labels, but then it throws away the opcode)