tniASM 0.45 + ASCII 16k mapper?

Champion (352)

24-07-2021, 21:46

I've been working on my MSXdev entry that'll reuse my adventure game engine, but it uses multiple memory pages, one page per episode (of which there are three). So a bit of a hack rather than do it smartly already the first time.

Anyway, I looked at the Wiki page. I've been using the last freeware version of tniASM (v0.45) so far. I tried copypasting the sample code there for tniASM, and it complained of stuff like "end" and "B000h". I tried fixing those (drop the "end" command, replace B000h with $B000), but... BlueMSX worked as I hoped, Webmsx and Openmsx 0.15.0 (haven't looked if there are any updates) both show just the text from segment 1.

What would you suggest I do -- contact TNI about buying the 1.0 version (I've used the freeware one for three games and a bunch of prototypes by now, so it's about time I paid for the program), have the freeware version produce working megaroms by some fix I don't know, or start using a different assembler? All my changes to the model ASM code there were to replace the 8000h -format of hexadecimals with $8000 -type and drop the "end" from the end of the file.

I'm pretty sure the last option will mean I can't partake in MSXdev'21 since I have the content for half of the game not made and little of what is done, is polished. But given the high number of entries already in the contest, my game isn't really needed there.

(I suppose I could also download another assembler, try compiling the sample rom with that, and then do a bytewise comparison of the result files to find out what I'm doing wrong...)

Entrar ou registrar-se para comentar

Por Grauw

Ascended (10768)

24-07-2021, 22:26

Make sure to specify the mapper type to the emulator. The mapper type guessing algorithms are unreliable. This is probably the reason why it works in one emulator but not the other.

For openMSX this is specified on the command line like so:

openmsx -cart mygame.rom -romtype ASCII16

For WebMSX you specify this in the URL:

 http://webmsx.org/?ROM=http://example.com/mygame.rom&ROM_FORMAT=ASCII16

Por Uninteresting

Champion (352)

24-07-2021, 22:29

Thanks! That helped with at least Webmsx and the sample code. Now to fix my game ROM which had further issues, but things are looking up again.

Por syn

Prophet (2123)

24-07-2021, 23:48

Like most assemblers, tniASM v0.45 needs an 0 in front of an hex value if it starts with A~F, so 0B000h should work.
Upon request, I changed this and some other things in the example code for tniASM on that wiki page.

Being a tniASM v1.0 user, I dont recall encountering this myself, because hex without a 0 prefix like B000h works there.

Por AxelF

Champion (395)

25-07-2021, 00:15

An assember shouldn't dictate which method you should use to display hex numbers, that's just wrong.

Por Grauw

Ascended (10768)

25-07-2021, 00:43

@AxelF The requirement for hexadecimal number literals to start with a decimal numeral in H-suffix notation is standard syntax across assemblers for the Z80 and several other CPUs.

The reason the syntax requires the 0 prefix is because otherwise e.g. BACH would be ambiguous, it can be either a hexadecimal literal or a symbol. Whereas 0BACH is unambiguously a hexadecimal literal since symbol names can not start with a numeral.

Por santiontanon

Paragon (1805)

25-07-2021, 01:40

Even "B000h" is ambiguous, since things like "b1" can easily be used as labels, why not "b000h". So, indeed, it's not a fault of the assemblers, but a necessity for making the code unambiguous.

Por Ped7g

Expert (67)

25-07-2021, 08:17

(jumping on the opiniotating assemblers wagon) the "h" suffix syntax is just evil ... ... 0xb000 makes you C compatible, or lot of Z80 assemblers support $89ab or #89ab syntax for hexa. (I don't know what tniasm supports, I wouldn't be surprised if all of that)

back to OP "What would you suggest I do"
- supporting SW authors is always nice, so if you feel like the value is there, make the deal

"I suppose I could also download another assembler"
- as they all slightly differ in syntax (mostly of extra directives), switching between assemblers is not so trivial. Also if the example already contains "B000h" as hexa value, that's quite rare, can't recall any other assembler to parse that, so that's quite TNIasm specific.
- but if you are open to the "switch assembler" adventure, zoom128's fork of sjasmplus is actively maintained and improved by me, so you are welcome... (I don't see currently any reason why *you* should switch. Especially if you are not yet comfortable with assembly and platform, and you have examples or tutorials written for tniASM, switching makes no sense at all and would just cause more pain and issues. But if you ever feel so, or you run into actual technical reason - one big MSX project did switch just months before release, because main developer didn't have x86 computers at home any more, and running tniASM 0.45 through qemu in linux was too much hassle - there are many alternatives )

Por Uninteresting

Champion (352)

25-07-2021, 10:59

@Ped7g: "Download another assembler" option was just for the case of finding out what the problem with output binaries is, and under the assumption that the sample ASM codes on the Wiki page produced identical binaries, I wouldn't need to convert my game, just see what (hopefully minor) changes I need to do to create a working binary. And yes, making the shift to another assembler would've taken a long time.

My two cents on the hex coding... so long as I can control what the type is intended to be, I'm content. Although, I suppose 0xb000 is also the Python way, so maybe I should prefer that.

Por MsxKun

Paragon (1124)

25-07-2021, 11:52

Just use $B000. It works fine. I always used that way.