SymbOS ASM-Developer kit 1.0

Страница 2/2
1 |

By Prodatron

Paragon (1843)

Аватар пользователя Prodatron

03-11-2021, 23:53

Oh, I missed this discussion, but thanks to AxelStone I found it now.
@NYYRIKKI thanks for your great work, this is so useful and motivating. You pointed me to several things which were "buggy" in the documentations, and I had to update several stuff, this all was really helpful. I hope it's now more easy to develop for SymbOS using assembler language.

@Ped7g: If I understand it correctly you are one of or the programmer of sjAsmPlus? I got in touch with it when improving NYYRIKKIs Doom port for SymbOS, and so I recognized, that it's a very very powerful Z80 assembler and it's fantastic, that it supports relocation tables compatible with the SymbOS specific feature of the WinApe assembler. Iam thinking about switching completely to it, it's very cool.

Regarding relocation of labels, which are 256byte aligned, and addressed with the high byte only:

As an example we have:

ds -$ mod 256
tab: db 1,2,3,4,5
ld h,tab/256

The assembler should just add the address of "tab/256" MINUS 1 to the relocator table.

By Ped7g

Expert (67)

Аватар пользователя Ped7g

04-11-2021, 09:33

Prodatron:
yes, sort of. When ZX Next project was made public on kickstarter (first one), that's now like 3-4 years back? April 2017. Uff.. I decided to have some more fun with ZX programming (I was active at ZX Spectrum demo scene in ~1992-97).

So then I was looking for some assembler, ideally with Next extras included, and some other cz/sk ZX sceners asked me to review some sjasmplus patch, and from there it snowballed, while working on Next extensions, I have seen parts of the source and what has been seen can't be unseen... so I kept fixing the bugs... turned out at this point I have modified probably 20-30% of sjasmplus source, so I guess I could qualify as co-author now. Smile (but I did mostly bug fixes, haven't added many new features, so if you find sjasmplus powerful, it thanks to the vision of previous authors)

If you will try to switch, let me know in case you will run into some issue (just open github issue or delegate to Nyyrikki if you don't want to deal with github).

Thanks for confirming SymbOS does actually need only 256 byte aligned relocation data, so having special mode of `relocation_start` looking for the high-byte relocation data only would make sense (and also for NextZXOS drivers).

I will think about it... it's always more incentive to change something, when you know some people will actually use it.

Special 256B mode would allow then also stuff like `ld h,tab/256` (in sjasmplus you can write also `ld h,high tab` which I personally prefer).

Copying the relocation feature from WinApe took lot more time than I expected (was like 2 or 3 weeks of work, endless lists of TODO items... Smile ), but I found on github some sjasmplus project doing relocations manually, and tried as experiment to convert it, and IMO it saves ton of headache, the final difference was like this: https://github.com/paulossilva/gameinput/pull/3/files ... I'm too lazy to write those manual things... :D

By Prodatron

Paragon (1843)

Аватар пользователя Prodatron

04-11-2021, 16:10

Really good that you continue this project!

I wonder if it's difficult to add this in sjAsmPlus.

We would just need an option, so that sjAsmPlus adds an entry in the relocation table, when it finds commands like...
LD r,HIGH(LABEL)
In this case the address in the table would point one byte before the "HIGH(LABEL)" (so here directly to the command byte).

Example:
#1000 LD HL,label1
#1003 LD A,HIGH(label2) ;or "label2/256"
...
relocate_table
DW #1001
DW #1003

In this way it should work fine in SymbOS.
- If it's a word it points to the word directly (as usual)
- if it's a high byte (=word/256) it points one byte before the high byte.

Ops, these Difs on github look like a lot of headache.

By Ped7g

Expert (67)

Аватар пользователя Ped7g

04-11-2021, 16:30

Prodatron wrote:

I wonder if it's difficult to add this in sjAsmPlus.
...

That's what I did mean by "256 byte aligned mode" for relocation.
So you would do `relocate_start 256` and the relocation data would care only about high bytes. And the relocate_table with offset +1 or -1 to make it produce the values which SymbOS needs.

But that will make syntax a bit different from WinApe ... but more in sync with current sjasmplus, as currently only word relocation is done and documented. I don't know what's your workflow is and how painful it would be if there are these small incompatibilities, I think currently the sources needs changes going from WinApe any way, so few more specific changes are just bad, but not horrible.

By Prodatron

Paragon (1843)

Аватар пользователя Prodatron

04-11-2021, 16:39

Yes, it won't work in WinApe anyway, so that's not an issue.

In WinApe it is allowed to place Z80 mnemonics directly at the beginning of a line, which sjAsmPlus would handle as a lable IIRC. So some source codes have to be modified anyway.

And if you have this new feature for 256 byte aligned relocation, it wouldn't work in WinApe in any case, so that's fine.

By NYYRIKKI

Enlighted (6067)

Аватар пользователя NYYRIKKI

04-11-2021, 17:47

AxelStone wrote:

Thanks for your great SymbOS stuff NYYRIKKI. Are you planning to continue MSX or is it finished?

You make it almost sound like SymbOS programming is not MSX programming. Smile There has always been new things... in 1986, in 1996, in 2006, 2016 and definitely in 2021 as well, but I'm still here and keep up my MSX-hobby when ever I have time. Smile

If you meant to ask, will I now move to SymbOS and leave all traditional MSX-DOS & MSX-BASIC stuff behind then no... likely not. SymbOS is great for many things but if you ie. want to do tricks and beat up all out of the hardware, use pattern modes or so then although SymbOS does not prevent you from doing it, it also does not help you in any way either, so in this case more simple OS is likely better as a starting point... On the other hand if you want to do a program that would benefit from stuff like mouse driven GUI, FAT32 or multitasking, it would be pretty stupid to select anything else than SymbOS... So likely for me it is just matter of selecting correct OS for the task I want to do.

By gflorez

Resident (61)

Аватар пользователя gflorez

04-11-2021, 21:26

Open the stables and let the horses run free....

By gflorez

Resident (61)

Аватар пользователя gflorez

04-11-2021, 21:51

Ok, I mean... why limit ourselves?. There are a still a lot of amazing things to do on retro-computers(with "s"), not only MSX, or thanks to MSX.

Two examples:
----SymbOS started on CPC, then MSX, PCW and Enterprise.
----The Yamaha V9990 is no more a MSX-only hardware, it has been interfaced to CPC, Enterprise and soon PCW.

By Ped7g

Expert (67)

Аватар пользователя Ped7g

09-06-2022, 14:22

Prodatron wrote:

And if you have this new feature for 256 byte aligned relocation, it wouldn't work in WinApe in any case, so that's fine.

So, it landed on the master branch, and it will be released in v1.20.0 (that was last major thing planned for it, I will just address few minor things in TODO list and start preparing the release, maybe next week).

For WinAPE source like nslookup it means you have use `relocate_start high` and `relocate_table +1` to get the correct relocation data (pointing one byte ahead of the MSB)

(the fully converted example https://github.com/z00m128/sjasmplus/tree/master/examples/Sy... - with regular word relocation, but I tried to patch it to new "high" mode and it does produce the same binary)

This enables also source like:

 relocate_start high
label:
  ld a,high label  ; relocation data point at "ld" instruction
  ld hl,label ; relocation data point at LSB
  ld hl,high label ; relocation data point at "ld" instruction so the LSB is patched (! smart relocator :P )
  ld hl,low label ; no relocation data (value is fixed)
 relocate_table 1
 relocate_end
Страница 2/2
1 |