учись пользоваться отладчиком в эмуляторах, тогда и вопросов меньше будетСообщение от YuronN
учись пользоваться отладчиком в эмуляторах, тогда и вопросов меньше будет
+1. Извиняюсь за неточность. Просто я только с таким и работаю, про версии без плюса и забыл уже за давностью. Ну, главное, разобрались. Я только на понял чем с итоге sjasmplus не устраивает. К нему ещё и unreal с поддержкой меток можно прикрутить так что в дебаге будете ходить по своим меткам.
Ну там вон сообщали, что какая-то системная переменная в снапшоте неправильно инициализирована и у автора топика не работало. Ему сказали фикс, теперь его вроде бы всё устраивает.
Свирепый агрессивно-депрессивный мордовец!
Не уверен - не напрягай!
Не сдавайся. Дыши?
Virtual TR-DOS
just few quick comments to the whole thread:
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...
YuronN(09.01.2020)
Can you describe, please, what is the difference between HEXA_16BIT_ADDRESS and HEXA_LONG_ADDRESS in labels list from CSPECTMAP directive?
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.
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)).
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)
Spectramine(09.01.2020)
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
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.
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; 09.01.2020 в 09:47. Причина: forgot the +8 bits in the offsets
Spectramine(09.01.2020)
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)
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
