SjASMPlus от z00m

[Ped7g]

https://github.com/z00m128/sjasmplus...es/tag/v1.13.3

v1.13.3 changelog:
- bugfixes, new examples (check tests/lua_examples)
- UTF BOM are now detected, UTF8 BOM is silently skipped, UTF16/32 BOMs cause fatal error
- ZXSPECTRUMNEXT device is now initialized with whole memory zeroed (no more ZX48 sysvars)
- DEFL documented, "no forward reference" rule relaxed for EQU
- some error messages reworded to make them easier to comprehend

Documentation http://z00m128.github.io/sjasmplus/documentation.html (or in the package/cloned source).

P.S.
I managed to set up "coverage" measuring in the project, and connected it with web service coveralls.io:
https://coveralls.io/github/z00m128/sjasmplus

I'm already at 81% for base sjasm sources (excluding lua/tolua++ which are external projects), which I find "not bad", but in following days I will now use the coverage data to see which parts of sjasmplus lack testing, and add tests where appropriate (my guess is the optimal coverage for this project should be somewhere in 90-95% range).

That will probably lead to few more bugfixes and release of few more v1.13.x versions of z00m's sjasmplus...

But I think there will be no v1.14, but v2.0 after that, which will have some changes in default settings, so old sources (used with v1.13.x) may not compile and will require some small changes to "fix" them. (I already managed to break few things between 1.10.4 and 1.13.3, but those compatibility issues were due to desperate situations where it was very difficult to maintain old behaviour ... in v2.x I will break few more only due to "better style/syntax" reasons)

So if you have some nice archive of sjasmplus projects, please test with v1.13.3 if they still work correctly, and report any bugs (if 1.13.3 fails and they work in v1.07 - v1.10.4 or in the mkoloberdin branch, try to read through "what's new" list in docs to see if your problem is actually announced change, like MAP removal back in v1.11 or when it was, etc).

I will certainly try to support v1.13.x even after I will start working on v2.0, but only bugfixes and similar, no major rewrites or new features.

The plans for v2.0 so far (may change easily):
- n-pass
- syntax tuned to be a bit more strict (similar to `--syntax=abf` in v1.13.3, but also with "keywords", so labels like "hl" will be not possible any more.
- DEFINE substitution even more formalized and documented, with the algorithm adjusted
- operators precedence changed to C++ precedence
- more operators and better support for "large" memory devices like 4MiB soviet machines or ZX Next
- some details here and there to make sjasmplus behave more similarly to common tools like gcc/clang (so various text editors supporting gcc/clang will probably work for sjasmplus reasonably well)

As the amount of changes is considerable, and will need probably months of effort, the v2.x may just as well never happen (because I often get distracted by other projects), so take the list and plans described above more like a "dream", not a "promise".

I still believe the sjasmplus v1.13.x is now very mature and solid tool, and can be used for Speccy SW development for another decade or two, even if we would release only few more bugfixes and nothing else.

Thank you for all the support so far, and keep the feedback coming, bugs reported, etc, it's very important part of the project, and you helped a lot already. Thank you all.

[Advertiser]

[Demige]

Can you add support of defining big text blocks in source?
Something like

LabelTXT DEFTXT 
sometext
another text
blablabla
ENDDEFTXT

[Ped7g]

Can you add support of defining big text blocks in source?

Hmm... it's possible, but it will very likely have the limits of sjasmplus parser, i.e. max 2048 chars per line... Actually not, if I would add it, I would have to avoid regular read-buffered-line, because it does some very limited parsing to correctly read multi-line comment blocks and strings in quotes/apostrophes, and that's not something to be done in the big-text block, so I would definitely have to write second "read-input" code to avoid regular, and then it can be without those limits of regular parser.

Ok, so it's possible, and I will add it to my TODO.txt.

But I find it very low priority, because I don't see much point in it.

Are you aware that you can write your big-text in other file, like "scroller2.txt", and do in ASM source simple:

LabelTXT:      INCBIN "scroller2.txt"

I find this workaround very reasonable, often maybe even better than having the text data directly in the ASM source (and I don't need to write whole new input-stream-reader ).

Let me know if you disagree or INCBIN solution doesn't fit your purpose, and let me know what is problematic (if you want the "big-text" feature to get higher priority).

With my current information about the issue, I will very likely keep it on the bottom of TODO list, so it may never happen or very lately.

[Demige]

In my project I have much text data (text dialogs). They not very big at once (may be 200b-3K for block), but their count big enough. And for each I need label to print text to screen. If I will use incbin, this would need for 500+ files to include.

I could wrote fulltext parser to get labels from text, but then I would have to solve problem where to store this labels and how to name them.

[Reobne]

Demige, а что если попробовать на LUA написать аналог INCBIN. Назвать его INCTEXT. Пусть он работает так же как INCBIN, но строки текста заканчивающиеся особым знаком превращал в метки.
Тогда подсунув ему такой текст в файле Messages.txt:

Label1>>
Supertext 
Message1>>
Game over!

Вызвав INCTEXT "Messages.txt",">>"
Он создаст две метки для двух текстов.

[Ped7g]

In my project I have much text data (text dialogs). They not very big at once (may be 200b-3K for block), but their count big enough. And for each I need label to print text to screen. If I will use incbin, this would need for 500+ files to include.

I could wrote fulltext parser to get labels from text, but then I would have to solve problem where to store this labels and how to name them.

I see, ok, this is the kind of stuff which makes big-text seem more important than I expected.

Some notes about possible workarounds with current sjasmplus version:

You can process data in device memory (reading them with { address } operator), but you can't easily build dynamic labels name from that, and values from memory can be read only in pass3, so the INCBIN+MACRO+DEFINE path would be very difficult to create some workaround, and it would probably not work well = unless I'm overlooking something, this is wrong approach.

Lua can add symbols (labels) (build dynamically, from file content for example) and can add bytes to the output (at least according to docs, I don't have these covered in tests, so you may find new bugs if you will try these, reporting them with example.asm will help me a lot). And there's probably a way in Lua to open text file and parse it, so you can implement your own INCTEXT as Reobne suggested, seems like good idea and should very likely work well (unless you run into some bug in sjasmplus). If you will go this route, and run into some problems, let me know, so we can fix it all.

Finally is the classic DB way *that* bad for these things?

Dialog1:
  db "Hi", 13, 13
  db "Some text.", 13
  db "Next line.",0
  ; to get zero terminated text with ZX enter=13 newlines

Depending on your workflow and where the devtime is mostly spent, having external .txt file processed by lua may even bring some productivity boost and may make it easier for non-programmer people to contribute to your project, so the Lua workaround sounds to me quite good, maybe even better than native support for big-text blocks from sjasmplus, but it's more initial work to get that setup working.

(would be also nice example of lua usage, if you want to share it afterwards , I can add it to the project tests/luaexamples)

[Reobne]

Кажется получилось!

Вот пример. Он компилируется! Для проверки - просмотр в дебагере.

IncText_test.asm

		DEVICE 	ZXSPECTRUM128
		
		LUA PASS1
		function inc_text(file_name,label_attr,line_terminator)
			if line_terminator==nil then
				l_t=13
			else
				l_t=line_terminator
			end
			for line in io.lines(file_name) do 
				if string.sub(line,1+string.len(line)-string.len(label_attr))==label_attr then
					--print          (string.sub(line,1,string.len(line)-string.len(label_attr)),sj.current_address)
					sj.parse_line(string.sub(line,1,string.len(line)-string.len(label_attr)))
				else
					for i = 1,string.len(line) do
						sj.add_byte(string.byte(line,i))
					end
					sj.add_byte(l_t)
				end
			end
		end
		ENDLUA
		
		;----------------------------------------------------------------------

		ORG	#8000
START		
		LD HL,TT1
		LD DE,TT2
		LD IX,TT3
MainLoop
		JP	MainLoop
		
		LUA ALLPASS
			inc_text("test.txt",">>")
		ENDLUA

		SAVESNA "textovik.sna",START	;в папку unreal после компиляции сохранится снапшот для запуска в эмуляторе, содержащий программу, описанную сверху

Образец текста.
test.txt

TT1>>
Hello!!
Ready?
3
2
1
Go!
TT2>>
SOS!!!
TT3>>
GAME OVER
PRESS ANY KEY
Final>>
	LD A,123>>
	RLCA>>
	JP Final>>
	BYTE "SEVER",0,"BURAN",0>>

Как видите, можно добавлять через текст не только метки.

Это моя первая "программа" на LUA, так что я готов к любой критике как стиля так и содержания.

[NEO SPECTRUMAN]

device
zxspectrum128\256\512\1024

slot 0
page 0
вообще работает?

slot 3
page 5
error: [PAGE] Page number must be in range 0..3
о_О

slot 1
page 5
error: [PAGE] Page number must be in range 0..3


как вообще сохранить sna
с нужной включенной в slot 3 страницей?

[Shiny]

а шо, у какого-то были такие девайсы?

[NEO SPECTRUMAN]

а шо, у какого-то были такие девайсы?

а шо другие sjasm-ы так ругаются?

для особо непонятливых

ZXSPECTRUM256

Same as russian clone Scorption 256. Has 16 RAM pages (0-15) with size 4000h.
ZXSPECTRUM512

Same as russian clones ATM Turbo 512 and Pentagon 512. Has 32 RAM pages (0-31) with size 4000h.
ZXSPECTRUM1024

Same as russian clones ATM Turbo 2 and Pentagon 1024 SL. Has 64 RAM pages (0-63) with size 4000h.

- - - Добавлено - - -

а шо, у какого-то были такие девайсы?

а еще есть пентевы с 256 страниц в любое окно...
которых нет в комплиторах....