search

z00m128 / sjasmplus

Command-line cross-compiler of assembly language for Z80 CPU.
http://z00m128.github.io/sjasmplus/
BSD 3-Clause "New" or "Revised" License
382 stars 54 forks source link

SAVETAP: codeblock of 166 bytes length starting at 0xFF59 saved to .tap #194

Closed denisiorus closed 2 years ago

denisiorus commented 2 years ago

Sjasmplus version:1.20.1. Codeblock of 166 bytes length starting at 0xFF59 saved to .tap (DEVCE is ZXSPECTRUM128, memory at 0xFF59 and above is not used). 166 bytes data seems to be charaster set...?

following directives helps to get rid of the bug:

ORG 0xFF59 ds 0xA6

denisiorus commented 2 years ago

Sorry, it seems to be UDG charasters. But, is it worth to include them to the tap?

ped7g commented 2 years ago

Nobody of active maintainers care too much about snapshot-like SAVETAP. As long as it loads correctly, it's good enough.

Inclusion of UDG is more like feature than bug (at least for some users).

Your work-around with memory clear by DS looks "good enough" to me to close this as resolved.

The recommended way to produce "release" tap file is to build it per each block, having full control over every byte, own BASIC loader, etc... (this part of SAVETAP is actively maintained, test covered, example covered and used by several contributors).

If you want yourself to improve the snapshot-like SAVETAP, you are welcome. The topic is slightly difficult as there are different needs for different type of users. Somebody learning Z80 assembly following some tutorials using lot of ROM functions may need the UDG chars and sysvars to be initialised even when loading snapshot produced by sjasmplus (there were people confused even by IM1 ROM handler being disabled in SAVESNA and by the keyboard reading producing tokens instead of charactes in the sysvar), some seasoned ZX coders asked for clear device memory to set up everything themselves.

I'm reluctant to dig deep into it, because a) it's easy to work-around current state like you did, b) changing default sjasmplus behaviour always breaks someone's old project, c) changing non-default behaviour (like adding new directive or option) is often ignored even by the users who wanted the change... ;) So this is "won't fix" situation for me, but feel free to argue if you think I'm completely wrong and should do something about it.

Thank you for the report.