AsmPro 1.19

[StingRay]

Originally Posted by kamelito

I have a source code that display « ** Include jam » every time
I assemble the source while on version 1.19a it does this once then works.
Dunno exactly why this message is displayed though.

Use the ZI (zap includes) command, this should fix the problem.

[FlynnTheAvatar]

ASMPro-1.20a works on E-UAE without any crashes. Thank you for fixing the issue!

Really strange that different environments (WinUAE, native, Vampire, E-UAE) behaved differently...

[kamelito]

@Stingray I used the zi command but it didn’t fixed the problem at least I learned about that command. Thanks.

[a/b]

Is that reproducible? Technically, it happens when the assembler is in pass2 and some include file is not found in cache (normally, everything is read and cached in pass1).
So, it should never happen, unless you are deliberately messing with conditionals (e.g. IF1, IF2), however it does happen regardless for some reason. And this is not only in 1.20, but also 1.18, asm-one 1.48 etc. It's very very rare but I can say it has happened to me, say... once or twice a year. That kind of rare (but I typically don't mess around much with includes). And I don't remember a case when ZI didn't resolve the problem.
The point being, I'm not even sure how to reproduce this. I did some... simple tests but they all either worked or never worked, as expected (because IF1/2 is absolute, it does what it should).

Does that happen with system includes, or your stuff only? If consistently reproducible, how complex is it, would it be possible to make a copy and throw out the code you are not comfortable sharing, and only leave the includes and relevant conditionals (IFDEF and similar, e.g. if you are using them as guards for once-only including) and send it + includes over to me? If that's a possibility, you might as well check if pruned source assembles properly or it's still a problem.

[kamelito]

It is 100% reproducible as I said on previous version or AsmOne it is occurring at the first assemble but in 1.20 in all of them.
Maybe something is buggy in the includes
It is not the officials includes but LVO.i and custom.i
I’ll check if repro in the non modified version.

[kamelito]

a/b
You can repro just using the 2 lines below, custom.i can contain anything or can be any file I guess. Same with the value of INCDIR, it could be any path.
INCLUDE “ram:custom.i”
INCDIR “ram:”
This give include jam every time. Under AsmOne or older version of AsmPro the message include jam only happens at the 1st assemble.

[a/b]

Thanks, figured it out. The problem is actually in the original code and consequently in 1.19. 1.20 exposes the problem with (un)related change (#15: incdir is reset at the start, intention was to prevent using the wrong path in case you switch sources), but doesn't provide a solution for the jam problem.
In 1.18/1.19 the file is actually cached *twice*, as ram:custom.i and RAM:ram:custom.i, because cache logic simply marges 2 paths together without checking whether or not they are absolute or relative. The jam problem occurs in run1 pass2 because now the incdir is non-empty (was set at the end of pass1) and the merged path is different. In run2 you start with a non-empty incdir and now the file is cached again as RAM:ram:custom.i and pass2 happily finds that one. The original ram:custom.i is still cached but never referenced again.
I'll upload a new version once I'm done fixing this...

[kamelito]

Thanks

[a/b]

Forgot to mention, a simple workaround for you for now is to set the incdir at the start of your code to what it is at the end.
I could do a lazy fix by simply reseting the incdir path at the start of each pass instead of only once at the start of assembly, but this still leaves the jam problem and double caching unaddressed and I want to get rid of that, now that I understand what's going on.

[kamelito]

No hurry I agree that it should be fixed properly.

[a/b]

v1.20b uploaded to aminet. Thanks to all who contributed with bugreports over the last few days.

[kamelito]

Thanks

[Photon]

Flynn bringing the crazy combos! And Pistorms and Vampires with no spec.

Please do not change code to make AsmPro work on HW with no spec. You can if you want, but because of the lack of spec first please look to legit accelerators including new ones like TF etc. If you accommodate HW with no spec it may affect these. You choose what you want to support, and if you support no spec I don't support you.

I know the work involved. Devs know which Assembler doesn't crash. Users have a much easier time to tell devs what to do. "Doesn't work". See this post in that light.

AsmPro has for decades had these 3 issues.
1. Initialization and allocation of added memory.
2. Debugging handover.
3. Rolling text buffer handling at start/end of source.

If you appreciate that feedback more then please have a look at those. Cheers.

[8bitbubsy]

There's one thing that annoys me. Scrolling of the AsmPro console is incredibly slow for me (does it use the blitter?), even on a 68060. Bigger projects with a lot of include files will output a lot of text and scroll the console quite a bit, and I have to wait several seconds for it to complete before I write to binary. Is there any way I can get this to be faster?

Otherwise, I love AsmPro and all the new versions. Good job!

[a/b]

It's using gfxlib->ScrollRaster() for RTG compatibility. If there's a better way, let me know.
Editor can still use the old cpu copypasta routines (editor prefs, custom scroll), apparently that was a problem for everyone and so it was left in.
For the cmdline mode, I could put it back in, but I don't think it would be sufficiently faster. I think something like (optionally) scrolling up 8 lines at a time instead of only 1.
I'll see what I can do...

[8bitbubsy]

It's a luxury problem, really. Not a big deal, but just a small thing I wish could be improved somehow so that the workflow would be even faster (when making small changes, assembling, testing, rinse repeat...). And by console I mean the console inside AsmPro when you start it.

[a/b]

v1.20c is in the zone (I won't upload it to aminet just yet) so grab it from there if you want it...
There is a new Multiscroll option in the asm preferences (just above the cpu selector), if enabled it will scroll the screen up by 8 lines instead of 1 during assembly.

[8bitbubsy]

Thanks!

EDIT: Just gave it a try, and it really did fix my problem. Thank you!

[Photon]

Today I fixed a nagging bug in AsmTwo that to my knowledge (and checking AsmOne 1.20 and AsmPro 1.17) is not fixed in any AsmOne/Pro version.

I'm still finding time to finish the todo-list for a finished AsmTwo (so I can customize it to my own taste, which will also take time). a/b, you have a DM with the fix so ppl won't have to wait until then.

[hitchhikr]

Where is the source code of the *latest* version of AsmPro ?