учись пользоваться отладчиком в эмуляторах, тогда и вопросов меньше будетЦитата:
Сообщение от YuronN
Вид для печати
учись пользоваться отладчиком в эмуляторах, тогда и вопросов меньше будетЦитата:
Сообщение от YuronN
+1. Извиняюсь за неточность. Просто я только с таким и работаю, про версии без плюса и забыл уже за давностью. Ну, главное, разобрались. Я только на понял чем с итоге sjasmplus не устраивает. К нему ещё и unreal с поддержкой меток можно прикрутить так что в дебаге будете ходить по своим меткам.Цитата:
Сообщение от Shadow Maker
Ну там вон сообщали, что какая-то системная переменная в снапшоте неправильно инициализирована и у автора топика не работало. Ему сказали фикс, теперь его вроде бы всё устраивает.Цитата:
Сообщение от SoftLight
just few quick comments to the whole thread:Цитата:
Сообщение от SoftLight
the first post mentions also #CSpect emulator and ZX Spectrum Next. In zoom's branch of sjasmplus you can export map file for CSpect emulator directly with `CSPECTMAP` ( http://z00m128.github.io/sjasmplus/d...l#po_cspectmap ) directive since v1.13.1
About `SAVESNA` in sjasmplus vs pure binaries: sjasmplus has both. It was extra work for sjasmplus contributors, but *you* can safely ignore `SAVESNA` in *your* projects and use only raw binary output. :) (there, problem solved)
About SNA vs original problem: you will meet more surprises with the SNA, it's really invasive format replacing all memory (of classic ZX48 and ZX128 models), giving the ROM fake artificial state. If this fake state is not what you need, then fix the state.
But technically that's not a fail of the assembler, or the SNA file, you had system variables in a state when the ROM keyboard routine was scanning key "P" not as small letter "p", but as BASIC keyword "PRINT", which is just another mode of the ROM keyboard routine... but it fails in your test. When you did load the TAP, the BASIC was still in the letter-input mode after writing `LOAD ""`, so the keyboard routine was reading "p", not PRINT.
Overall I'm always a bit puzzled by these tutorials, which prefer ROM calls for reading keyboard or printing text, as the HW on ZX is very simple, and it takes only few hours to learn how to read keyboard, and maybe couple of days to print your own character and string, directly into video RAM. And the ROM routines are good for BASIC, but not for games. Where's the fun in calling the ROM... :)
Can you describe, please, what is the difference between HEXA_16BIT_ADDRESS and HEXA_LONG_ADDRESS in labels list from CSPECTMAP directive?Цитата:
Сообщение от Ped7g
It is convenient in some cases. Of course, we should set the needed state of system variables before this. Generated SNA file can't provide all possible needed states.Цитата:
Сообщение от Ped7g
The 16bit address is within Z80 address range, where the label was mapped when defined in assembler (if it's not memory address, but just some large value, it will be simply truncated to 16 bits)).Цитата:
Сообщение от weiv
The long address is address in the 1.75MiB SRAM space of ZX Spectrum Next (8kiB pages 0, 1, 2, 3, ..., 223) = "flat addressing".
The default memory mapping of Next after boot into NextZXOS is [255, 255, 10, 11, 4, 5, 0, 1] (255=ROM), or in terms of 16kiB banks [ROM, Bank 5, Bank 2, Bank 0] ... so when you define label "xyz" at ORG $4001 (without changing pages), it is in 8kiB page 10, offset 1 = long address 0x14001. The #CSpect emulator understand this address formatting and will display in debugger the label "xyz" when you map page 10 into memory (and hide the label, when page is not mapped). (the format is defined by #CSpect developer, so I'm not sure what it does when you map page 10 to different region, and I don't care too much, as it's closed source, so I can't help with anything - but I can fix sjasmplus export if somebody will find some bug in it)
Ped7g, thanks. Seems like it's not much useful for 48/128kb Spectrum models. The Unreal's labels files generated by LABELSLIST directive is much more useful because of page info of labels.
While I can agree with your general sentiment (Unreal is probably better), I don't understand the second part of your comment.Цитата:
Сообщение от weiv
The page offset is 13 bits ($0000..$1FFF), so if you cut the bottom 13 bits of the "long address", you have the page number (8 bits in case of Next) of label.
0x14001-> offset $0001, page $0A
I.e. it's the same information as unreal export, just different formatting (unreal export does the offset mask already in export, so the exported offset is 14 bit (zx128 banks) only and it shows bank number separately, but it's the same information in the end on the bit level). Maybe the formatting is less human-friendly...
Ped7g, thanks again, I got it at last. I did not see the page info from map file by sight, but i got it with calculator)