Computing desk
< November 11	<< Oct \| November \| Dec >>	Current desk >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

November 12

Text-only Amiga emulator?

After trying out FS-UAE on my Fedora Linux system, which worked quite nicely, I got to thinking. Even though when the Amiga was originally released in the middle 1980s, it was revolutionary in its graphics and sound capabilities, not all Amiga programs need them. As a specific case, C compilers on the Amiga have no need of the computer's graphics and sound capabilities. (I mean the compilers themselves don't, the programs they produce as compiled output may well do.)

So it seems to me that firing up a fully emulated Amiga just to compile C code on it is overkill. Would it be technically possible to have an emulator that has an emulated Motorola 680x0 CPU and the Amiga operating system ROM running, maps the Amiga's file system to the host computer's like FS-UAE does, but instead of implementing a full Amiga GUI only interacts with the user through standard stdio? That way it could run in a Linux terminal and be faster, more efficient and less error-prone to use. The emulator could just skip all system calls or direct chip instructions that use graphics or sound.

Is this kind of thing possible? And if it is, does something like it exist and has anyone else thought about it? JIP | Talk 20:09, 12 November 2020 (UTC)[reply]

I have no memory of an Amiga having text-only mode. It booted straight into graphics. The console was a graphical window with text drawn in it. So, this isn't emulating AmigaOS at all. It is a DOS that mimics AmigaOS dos commands. 97.82.165.112 (talk) 18:28, 17 November 2020 (UTC)[reply]

You misunderstood my question. I am looking for an Amiga emulator that doesn't use the Amiga user interface at all. Instead, it would emulate Amiga programs that only need stdio for an interface by mapping the stdio directly to the host system's stdio, so it could be used as a console application. JIP | Talk 19:25, 17 November 2020 (UTC)[reply]

Distinguish between AJAX call errors?

I ran to a rather interesting scenario at work. I was testing a page that had a standard HTML form and an AJAX call. The AJAX call is in this kind of form:

$.post("/MyController/MyAction", { myParameter: "My value" }).done(function (data) { doSomething(); }.fail(function () { reportError(); });

What happened in my test was that I submitted the form before the AJAX call had finished, which resulted in reportError(); firing before the form had been submitted and the resulting action had been processed.

What I think this was caused by is that submitting a standard HTML form makes a full page reload, which causes any pending AJAX call to abort. What I am asking here is if it's somehow possible in AJAX to distinguish between this and some other kind of error in the AJAX request. Is this possible? JIP | Talk 21:28, 12 November 2020 (UTC)[reply]

If I understand the JQuery Ajax documentation correctly, the error handler function is of type "Function( jqXHR jqXHR, String textStatus, String errorThrown )". This indicates that it will be provided three values, the second and third of which may contain the details you need. I suggest you capture and examine these values under the submit scenario you described and a couple of other intentionally introduced error conditions. -- Tom N talk/contrib 02:52, 13 November 2020 (UTC)[reply]

If the Ajax post needs to complete then maybe disable the form submit button by default and re-enable it in the done() handler. Perhaps better would be to convert the form submit to Ajax so that all actions stay within the page. — GhostInTheMachine ^{talk to me} 09:52, 13 November 2020 (UTC)[reply]

In other words, for the onsubmit function, don't bubble up the submit event to the default form handler. Even if you submit to #, it will often reload the page, killing all running scripts. 97.82.165.112 (talk) 13:33, 13 November 2020 (UTC)[reply]