Ramsections within libraries

[hang-on]

I'm looking into using wla-dx to build myself a reusable library of subroutines like these: http://maben.homeip.net/static/s100/zilog/z80/Z80%20Assembly%20Language%20Subroutines%201983%20-%20Leventhal.pdf

Sometimes a subroutine needs some variables in ram, but wla-dx wont let me have ramsections in my library. I'm fully aware that this is not a bug in wla-dx, and that I can structure my library as an .inc file and just include it to have ramsections. Anyway, consider this as a feature request.

Thanks for wla-dx btw., it is great for SMS development! :)

[vhelin]

Well to add support for .RAMSECTIONs in library files, we'd need a mechanism to put them into .BANK/.SLOTs when the library files get linked. Perhaps the best way to do this is to add configuration system for that into WLALINK/WLALINK's linkfile?

Any ideas guys?

[nicklausw]

Are you sure it would be too much trouble to have an .enum for these variables, and reserve that enum's area in the program?

[vhelin]

The .enum would still need to be placed somewhere (.bank/.slot)... I don't like the idea of a fixed place for libraries' RAM variables. Also, if possible, it might be a great idea to have libraries that contain multiple .RAMSECTIONs - or will this just make things needlessly complicated?

[vhelin]

IMO libraries really should have support for .RAMSECTIONs, but how to implement them in a simple but generic way?

[hang-on]

I think it would be great to have multiple ramsections in a library. That way, if a subroutine needs variables, a ramsection with the variables can be placed next to the subroutine code. Such a ramsection should ideally only be linked if the section containing the corresponding subroutine is not discarded.

/Anders.

Den 18. jan. 2016 kl. 22.27 skrev Ville Helin notifications@github.com:

The .enum would still need to be placed somewhere (.bank/.slot)... I don't like the idea of a fixed place for libraries' RAM variables. Also, if possible, it might be a great idea to have libraries that contain multiple .RAMSECTIONs - or will this just make things needlessly complicated?

— Reply to this email directly or view it on GitHub.

[nicklausw]

Recently I've been considering porting my gameboy project to wla-dx (not entirely sure), and my project uses various libraries that require RAM.

I've got multiple things I want to do with libraries. 1) This is completely a me thing (not going to push it on anyone else), but I want to write a tool named wlalib or something like that which is designed entirely around placing objects into libraries. IMO there's no point in a library if only one file with a bunch of others .included in can be in it. Part of what makes me want this tool is because the best fork of rgbds (bentley's) has no library support anymore.

It would be called like this: wlalib [library file] [object file(s) to add]

If I do this, I'd also prefer to remove library functionality from wla-xxxx, maybe still having the command line option available for backwards compatibility, even though in the end it just makes an object file. EDIT: I think it'd actually be better to keep library functionality, because wlalib wouldn't have to say "There's various directives here! Bad!" EDIT: Now I'm wondering why I ever thought library functionality could be removed, because object files as libraries make no sense.

2) As for the actual issue here and not my dreams, I'm thinking that in the linkfile, you could say something like bank 0 slot 4 ram bank 0 slot 0 bla.l.

[Kroc]

I'm running into this limitation too; I want to be able to build multiple versions of the same code, but with different memory layouts. The best way to do this would to have different link files define the desired banks/slots for library code. A straight-forward example is the sound driver which needs to reserve some RAM for itself.

A solution to this is to have the linker script define the BANK/SLOTs for each section/ramsection name. A library may ultimately need to push different pieces of code to different banks, for example code & data blocks. The library code would just name sections & ramsections:

.SECTION "sound_driver"
    ...
.ENDS
.SECTION "sound_data"
    ...
.ENDS

.RAMSECTION "sound_ram"
    ...
.ENDS

And the linker script would define which banks & slots to use for those names:

sound.lib:
"sound_driver" BANK 3 SLOT 1
"sound_data BANK 4 SLOT 2
"sound_ram" SLOT 3

[vhelin]

sound.lib:
"sound_driver" BANK 3 SLOT 1
"sound_data BANK 4 SLOT 2
"sound_ram" SLOT 3

This sounds like a nice solution. I'll look around and think some more about this, perhaps I can do something about this issue in the near future?

[vhelin]

How is this solution? .RAMSECTIONs now work in libraries, but when they are used, one must give them BANKs and SLOTs in the linkfile. Is the documentation ok?

[Kroc]

Just compiling now, I'll need some time to test but I'm looking forward to this! I would strongly suggest not using spaces in the RAMSECTION names because it appears as if these are meaningful; I initially thought that there was some kind of structure required there and it was confusing.

[Kroc]

~Appears to work, but~ I get the following when assembling the sound-driver to a library:

- assemble "sound.asm"
INTERNAL_PASS_1: A section must be open before any code/data can be accepted.

This is the source file in question: https://github.com/Kroc/Sonic1-Z80-ASM/blob/redo/src/sound.asm Is defining structs allowed in libraries?

[vhelin]

On Wed, Feb 27, 2019 at 11:03 AM Kroc Camen notifications@github.com wrote:

Appears to work, but I get the following when assembling the sound-driver to a library:

• assemble "sound.asm" INTERNAL_PASS_1: A section must be open before any code/data can be accepted.

Was it so that everything in library files must be inside sections?

This is the source file in question: https://github.com/Kroc/Sonic1-Z80-ASM/blob/redo/src/sound.asm Is defining structs allowed in libraries?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/vhelin/wla-dx/issues/80#issuecomment-467781213, or mute the thread https://github.com/notifications/unsubscribe-auth/AGHtUmEbK5fjwrfst_ZbhGGdfOSYbb2Iks5vRkn9gaJpZM4HHM6- .

[Kroc]

Sorry, your question doesn't quite make sense to me; if you look at the linked file, there's one ramsection, one code section and a struct, all inter-dependant on one-another. Are Structs allowed in libraries -- and if not, how am I to solve the circular dependency?

[vhelin]

On Wed, Feb 27, 2019 at 1:29 PM Kroc Camen notifications@github.com wrote:

Sorry, your question doesn't quite make sense to me; if you look at the linked file, there's one ramsection, one code section and a struct, all inter-dependant on one-another. Are Structs allowed in libraries -- and if not, how am I to solve the circular dependency?

Structs should work just fine in libraries. In fact I copy pasted your sound.asm to a local file, and the latest WLA compiled it just fine as a library:

$ ./binaries/wla-z80.exe -v -l sound.o sound.asm Pass 1... Directive checks... Internal pass 1... Internal pass 2... Section "sound_RAM" size 261. Section "sound_driver" size 16383.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/vhelin/wla-dx/issues/80#issuecomment-467827356, or mute the thread https://github.com/notifications/unsubscribe-auth/AGHtUuXmYIPXKD2CR_822xSbClDEH8ekks5vRmwWgaJpZM4HHM6- .

[Kroc]

OK, will re-compile and try again, thanks!

[Kroc]

The fault is that -i cannot be used with library building!

[vhelin]

The fault is that -i cannot be used with library building!

Hmm, I'll give it a look.

[vhelin]

Yeah, the sanity checker in pass_3.c broke when compiling a library with -i. -i outputted line numbers before a section was open, and line numbers weren't handled in the sanity checker loop and it thought that perhaps assembly code was given outside a section... Fixed.