ANSI control-code (?) bug in "all" AsmOne versions under Kick 2.0+
 

Did some testing with latest stable WinUAE, default A500 kick 1.3 Quickstart config.

All works as it should under kick 1.3, but in Kick 2.0 and 3.1 there is a bug. When you've pressed Esc to edit some code, then press Esc to go to the command line, the Asm-One screen is not updated correctly. Instead of putting the cursor at the bottom, below the status bar, it ends up at the top displaying ;1H after the commandline caret, and not clearing the screen (you still see code written all over the screen).

Tested at 1 fps to see if it types a character before the ;1H code which is then overwritten by the caret character, but it was impossible to see.

I've seen the bug in all Asm-One versions, and all it takes to fix it is to load kick 1.3. It works with kick 2.0+ on a real A500, A600, and A1200, of course, or I wouldn't report it :)

I'm using for example "Kickstart v2.04 rev 37.175 (1991)(Commodore)(A500+).rom".

Also tried with and without setting Full ECS+Chipset extra A500+ for this rom.

Tested with and without startup-sequence (ie. with and without relevant setpatch, if that could influence it).

Never seen this and I use asmone very regularly in emulation.

btw, it can't have anything to do with ansi codes, emulation does not know nothing about console.device or ansi codes.

Well, it's been this way in WinUAE for years. At first I thought it was the Asm-One version, but I've tried 5 versions and it's exactly the same. Even my oldest original 1.01 is this way. It's definitely related to kickstart version and nothing else.

First step is to reproduce the bug, can you see the bug with kick 2.0+ using some other Asm-One version?

Create bootable disk image that only contains require file(s), make sure the problem still happens, attach the disk image.

You are quite correct, file copied to a floppy without s-seq does not give the bug.

Same file when booted from harddisk-directory without s-seq does.

Attached the bootfloppy used, both versions work fine when run from floppy. You seem to have found it already, I can only think of some code from boot to cli window or some ENV: thing. I will try mocking up a harddisk-directory with only those 2 files and go from there.

Edit: OK, tested and it appeared again when I copied the S: directory to the new harddisk-directory. I renamed startup-sequence to zstartup-sequence, no change. Will report back, just thought you wanted the info asap. :)

Edit 2: Removing S:Asm-One.pref fixed it! How the same Asm-One binary handles it differently on a real Amiga is a good question.

Copied the suspect Asm-One.pref file to CF card. Result: works fine in real Amiga, Asmone 1.02+ and 1.20, in WinUAE it works fine in 1.20 but not 1.02+. All tests are without s-seq.

Attached binary+pref file, if you want to find out difference in execution on Amiga vs. WinUAE. "No" combo of settings [in a recreated pref file] fixed it, as soon as a .pref file exists, you get this artifact. [Same thing worked in 1.20 so problem is only in this version] I suspect it either reads the file differently, or memory allocation is slightly different in WinUAE vs. Amiga (or patched to make software more compatible and it didn't work out for this one - except with kick 1.3). Because it alloc/deallocs each time you toggle editor/console, IIRC.