IncIFF, IncIFFP and CS, AUTO

[gljubojevic]

Great extenstion, thank you for excelent work!

I was wandering would it be possible to improve AsmONE compatibility by adding support for:

• IncIFFP - Include raw iff image
• IncIFFP - Include iff image palete
• AUTO\CS - create sinus table in defined block

You allready have IFF view included and I was wandering if it would be posssible to preprocess source by including IFF data before vasm. Same goes for AUTO\CS but it looks it is bit more complex since it would require to replace bkl inside source with sine generated before vasm.

This would improve AsmONE source compatibility...

For IFF operations I'm prepared to create TypeScript lib for easier integration if this is something that would help.

[geijer]

I think that this is what the Makefile support is perfect for. Call conversion tools in your Makefile to prepare the data.

[prb28]

Thanks!

For the Sinus, you should try this: https://github.com/prb28/vscode-amiga-assembly/wiki/DataGenerator. Tell me if something is missing.

For the IFF, maybe as said @geijer a mix between a makefile or a pre-build task should be more flexible. You have a pre-build to convert/extract your image, with all kind of languages or existing tools. And and INCBIN instruction in you asm source. What do you think about this solution ?

Even if I prefer this first solution, this does not enable the direct build for a ASMOne source. And yes, it can be considered, is there other ASMOne particularities?

There are still some tools that should be added to convert/process images: RAW <-> IFF <-> PNG with palette extraction and RAW/MEMORY image visualization, but that's 'some' other work to do.

[gljubojevic]

Hi,

I see how modifying source on the fly can be issue and brake build process, however I do have few sources written in AsmOne so entire proposition idea is to be able to compile old source without modification in new environment.

I'll give try DataGenerator for sinus tables, I'll let you know :)

Here is AsmONE guide for reference: ASM-One_V1.4x_Guides.zip

Hopefully http://www.theflamearrows.info/documents/asmone.html will not hold it against me :)

AsmONE supports two directive types

• "Directives" during assembling like IncIFF that loads IFF file from disk and adds it to binary vasm supports as far as i can see all except amiga specific inciff and inciffp.

• "Direct Line Command(s)" After assembling like CS (create sinus) usually triggered by AUTO command

Any "Direct Line Command" can be invoked by AUTO command and this makes it complicated because there are many commands e.g. RB (read binary) etc...

However it is ideal to be implemented as post build task of some kind provided that is possible to modify binary after build process and that there are symbol offsets available of assembled binary.

Let's say that I write JS post build task that taks:

• Source
• Symbol positions from vasm (if that is possible)
• Output binary I think it could be possible to cover most if not all direct commands and AUTO directives, I'll try to see what vasm will say about source that includes all that directives.

Please don't take this discussion wrong way I'm simply trying to see what would be possible to implement and how could I help to do it, because I don't have any experience in developing vscode plugins.

[prb28]

Please don't take this discussion wrong way

Not at all! I really thank you for proposing help, that I accept, but I'm just trying to figure the best way to achieve a good compatibility with ASM-One source. And if it should be part of the extension or an external script/tool.

The idea of an optional ASM-One post task look great. Some cautions must be added because it may create some problems with the debugging -> line info must correspond to binary offsets! I retrieve the symbols in the binary file after vasm/vlink build:

• https://github.com/prb28/vscode-amiga-assembly/blob/a620f844bcade4c270f287386a61bd1fc6b52566/src/amigaHunkParser.ts#L159 And yes, all this info can be sent with the sources and the output binary to your typescript class.

But other solutions are possible: you can add some kind of converter that would generate a makefile with vasm build and other script commands. That can be added to a command of the extension like 'convert from ASM-One'. This solution may generate a more maintainable code that can be used in other compilers or in a mix with C code. What do you think about this solution?

Some other questions (I'm a noob in asm-one):

• What transformations do a IncIFF to the image? (other than a basic INCBIN)
• What are the classical use of AUTO/DLC in the sources? (copy files? insert binaries?, etc?)

[gljubojevic]

I have forked example workspace in order to try adding post build script for Asm-ONE compatibility, I'll let you know how it goes depending on time I have to work on it.

What transformations do a IncIFF to the image? (other than a basic INCBIN) Main feature is that decompresses IFF body during inclusuon so you can directly use it to show or blit. IncIFFP extracts only palette as words also to use it directly.

It is a nice fieature of Asm-One it helps you to avoid IFF->RAW conversion and INCBIN inclusuion, it is easier to modify images and save some time on RAW conversion.

What are the classical use of AUTO/DLC in the sources? (copy files? insert binaries?, etc?) It is really interesting feature, besides creating sin tables i have used it for:

• Calculating bootblock floppy checksum and writing bootblock to floppy
• Writing demo parts to floppy after assemble and compression because it has nice write memory to tracks features. When you think of it, it is exactly like post build task runner with Asm-ONE commands I really don't know how others used it, but it is form of automation that allows you to do interessting stuff e.g you can assemble source start init routine to pre generate tables and than write that binary to disk.

It is hardly likely that is possible to implement all use cases how ever small subset is nice to have for compatibility with existing sources.

[prb28]

Great!

Thank you for these answers.

Tell me if you need some help. If you do the code in TypeScript, I can add it as an optional command integrated in the build.

[gljubojevic]

Hi, just submitted pull request for AsmONE Auto CS (create sinus) https://github.com/prb28/vscode-amiga-assembly/pull/71

Hope you will like it :)

[prb28]

I've added an option to enable it, by default it is disabled because it may hide some compile errors. We will set it to enabled by default when it is ready.

[gljubojevic]

Ok, still not finished with test coverage but it can always be default disabled we can add warning to enable it when Auto is found in source.

Also while writing tests found an issue with assemble...

When you have section in code e.g.

	section "data_fast", Data_F

	AUTO	CS\SinTab_BF\0\180\180\127\0\B1\yy
SinTab_BF:
	blk.b	180,0

	AUTO	CS\SinTab_WF\0\180\180\32767\0\W1\yy
SinTab_WF:
	blk.w	180,0

	AUTO	CS\SinTab_LF\0\180\180\2147483647\0\L1\yy
SinTab_LF:
	blk.l	180,0

and everything in that section is blk or dc initialised with 0 (zeros) vasm creates bss hunk (need to check this) in order to keep executable smaller, but in effect Auto CS in that section overwrites file and destroys hunk information so executable is not working any more.

To fix this I need to either

• add warning that Auto CS can't be executed
• or use some additional vasm option to prevent creating bss hunk (if there is something like this).

Other options is to modify source where CS is created to be blk.w 100,$ff instead of blk.w 100,0 but this kind of breaks seamless compatibility I was trying to achieve.

[prb28]

I’ll try to do a release this weekend. After that your asmone feature will be enabled by default in 0.18 release.

For your problem it remembers me this thread : http://eab.abime.net/showthread.php?t=95742 If you add ‘-Z’ to vlink options that may solve it.

[prb28]

@gljubojevic do you have some progress on this feature to add in the 0.18 release ?

[gljubojevic]

Sorry no, I can't find enough time lately to finish it, please release without it, I don't want to hold releases. Hopefully my schedule will clear in two weeks so I can resume working on this feature.

[prb28]

There no hurry, I keep it in standby. Thanks