AsmOne doesn't like my accelerator...

[Photon]

It's AsmOne V1.02+, which works fine on my A500 with 68040 and all caches but copyback on (same as for most programs). The reason I use it is because it has a minimal memory footprint (ie. possible to use to code a full demo on A500 512/512k) and does what I want.

Now, I've tried it with the ACA630 and didn't notice anything wrong, mainly because I never ran the program I coded! I coded on it for days, but for certain reasons I had to run this particular program from the commandline and not from within AsmOne. Every single thing went well for days.

And now I tried to 'j' to my program. Guru #8000000b in 32-bit ram. Same thing if I try to run it by Amiga-D, then Amiga-R - switches to the debugger view then gurus before anything.

Tried a simple wait for mousebutton, then rts - same thing. Turned off all caches and 'fast' options in ACATune. Booted with an empty startup-sequence, AsmOne, assemble, run, guru.

Tried some options, close WB, uncheck Debug, etc etc. With 'nothing' on, it still gurus. Every other aspect of coding in AsmOne is perfect, but not running the code

Works perfectly in 68000 mode (accelerator switched off) on the same machine.


Does this ring a bell with someone, and how did you fix it?


Alternately, I could be persuaded to upgrade, but I don't trust the latest stable AsmPro, it has given me trouble on all my machines.

The known remaining bugs/flaws in Asm-One are:
- some in-code *-references, many sections etc can give guru on WO.
- whole commented lines in macros cause a visual line-offset when stepping in debugger (use * instead of ; to fix it)
- \@ gave hexcode in reverse also, not very usable for counting.
- ESCaping out of source doesn't clear the screen (in WinUAE only).
- breakpoint in debugger is removed when run to (not very nice for loops...)
- I've had problems adding multiple watches and then step on, on 68040 (could be cache, or other issues too).


Is there some check-program to list compatibility-things like where the VBR is (I don't mind setting it to 0 if it fixes it).

Is there a more compatible SetPatch than v43.6b? (No, that doesn't cause it, but another version might un-cause the error...? )

And if nothing works, which is the Asm-One version you trust most that has
- minimum (chipmem) footprint
- problem-free debugger
- *optional* req.library

I don't need the new syntax, nor (right now) support for > 68000-instructionsets.

[Leffmann]

I know 1.20 has both optional reqtools.library and an option to set its screen to 1 bitplane, and it runs fine on 030 though there's one or two small graphics bugs under Kick 2.0 and above.

I can't recall what 1.30 is like but I think it's installed on my Amiga at my brother's place and I can see how it runs on a Blizz 1230 tomorrow evening if you haven't got 1.30 yourself.

[Photon]

I'll try to hunt for them, maybe it would be a nice feature with a list of assemblers and their manuals for coders visiting this forum? (If there isn't already...)

Edit: Never mind, I already had 1.20, will try. Seems hard to find any other versions but the ones on aminet, 1.44b and 1.48.

Edit 2: Assembled & ran the demo perfectly at the first try Same chipmem-footprint as 1.02. Won't have more than about 150K fastmem workspace on A500 512/512k with kick 2.0, but I can use 1.02 on such a setup. So far it's looking great!

[Photon]

I can confirm that AsmOne 1.20 debugger fails on 68000 (move.l to odd address error) with the proper settings set including choosing Assembler/Processor/68000. Before reaching the first line of the source, ie. before starting the debug session.

I thought 680x0 included 68000... will look for other assemblers, or use versions >1.02+ on ACA630 only.

I can also confirm AsmOne 1.20 removes support for IF var<value and requires things like IFLT var-value instead.

[Photon]

I can also confirm that

ds.l (42/4)*256
ds.l (42>>2)*256

both give 10240 bytes space but for some reason cause AsmOne 1.20 to completely mess up your demo.

Same with the more correct

ds.l ((42/4)+1)*256
ds.l ((42>>2)+1)*256

and

ds.l (((42&-4)/4)+1)*256
ds.l (((42&-4)>>2)+1)*256

(just testing... don't doubt my sanity...)

This works fine:
ds.w 42/2*256

This wasted an hour for me. I wonder if it has something to do with a non-required but somehow assumed FPU...

There's no error or complaint, the buffer is completely and utterly unused so there's nothing in my code that depends on it. No explanation... watch out if division gives decimals, I will $%^ up your demo in a way that you can't debug.

Be happy if someone confirms this has been continued in later assemblers...

"You want the decimals?? YOU CAN'T HANDLE THE DECIMALS!!" (c) Jack Nicholson

[Harry]

You may try V1.48 from the TFA homepage. It works for almost all things i do (for the remainder you could try Barfly from Aminet).
http://www.theflamearrows.info/homepage.html
Edit: you may also take the very ASM-One-like AsmPro from Aminet.

[Photon]

I'm using earlier assembler versions for many reasons, one of them is backwards compatibility. Something that is often sacrificed in newer versions of any software.

Why not code Amiga with the latest whatever-assembler for 68xxx under Linux instead of some old $% assembler like AsmOne 1.48 on an old home computer? (Provocative thought, not an accusation of Amiga or AsmOne 1.48.)

I don't have time to list all the other reasons for selecting a specific version of an assembler.