claudeMar 11, 2022

#ProofOfConcept #WorkInProgress #uxn #varvara #uxncli #CLI #amiga #AmigaOS #m68k #MC68000

`uxncli` ported to AmigaOS (cross-compiled with #VBCC, only things needed changing were POSIX `dirent.h` + `unistd.h` -> AmigaOS `dos.library` calls in the file device). Should be compatible with WB1.3, but I only tested on WB2.04 in FS-UAE so far.

Not fully working yet - `uxncli.68000 hexes.rom < hexes.tal` prints out data, Ctrl-C when done to exit (with exit code 20 indicating failure to the shell), but `uxncli.68000 asma.rom hexes.tal hexes2.rom` returns success (return code 0 printed in AmigaShell), but there is no output `hexes2.rom` file anywhere. Same output text as on Linux, just no output file appears...

```
Loaded asma.rom
0x003e lines of source code.
0x00be bytes of heap used, 0xd22b bytes free.
```

Show threadclaudeMar 11, 2022

Oh, it seems the VBCC standard C library doesn't fully support `fopen(filename, "ab")` (open or create binary file for appending) - it only succeeds if the file already exists, so my workaround is to use dos.library calls to create it if it doesn't exist (theoretically racy with other processes on the system, but who really cares).

Now it works! Takes almost 10mins for `uxncli.68000 asma.rom projects/software/asma.tal asma2.rom` to finish in an "accurate" emulated A500+ in FS-UAE, but the output ROM is identical.

Show threadWilliam D. JonesMar 11, 2022

@mathr Almost 10 minutes?! :o

Wonder why...

Show threadcancelMar 12, 2022
@cr1901 @mathr @neauoire uxn is not a very efficient instruction set. but it could also be that the C compiler is outputting partially 32-bit code for 68k, which would be pretty slow. (I'm not sure, I have no experience with Amiga or C compilers on it. But it's just a guess.)
Show threadclaudeMar 12, 2022
@cancel @cr1901 @neauoire mixed 32bit code for 16bit operations was indeed a problem with earlier compiler versions (fixed in preview for next release) but I think it is mainly that the 7MHz CPU is slow by modern standards with the fastest instructions taking 4 cycles, more if memory is accessed.
Show threadcancelMar 13, 2022
@mathr @cr1901 @neauoire You could write a much faster one in 68k assembly. There's little chance that the C code produces anything good for the Uxn CPU core emulator on 68k.
Show threadclaudeMar 14, 2022

@cancel @cr1901 @neauoire

yeah! 68000 assembly version is ~4.5x faster than the C version!

https://code.mathr.co.uk/uxn-amiga/commitdiff/d09ab5ac6dcef13c04b29104162b6ddeb15432bf

One bug I forgot to mention in the docs, is that .System/wsp and .System/rsp device IO doesn't work, because during the uxn_eval inner loop they're stored in registers - flushing them to RAM before device access and restoring after should be possible, I just haven't done that yet...

code.mathr.co.uk - uxn-amiga/commitdiff

Show threadWilliam D. JonesMar 14, 2022
@mathr @cancel @neauoire Is VBCC an optimizing C compiler?
Show threadclaudeMar 14, 2022
@cr1901 @cancel @neauoire yes, it's pretty good and still getting better with each new release - has a non-commercial (plus presumably pay-for-commercial-use) license for platforms other than m68k amigaos though....
Show threadclaude
@cr1901 @cancel @neauoire #ProofOfConcept #WorkInProgress #uxn #varvara #uxnemu #GUI #amiga #AmigaOS #m68k #MC68000 neralie clock (if a clock is what it is? it's a bit cryptic!) working (but very slowly, and overlapping window decorations...).
Mar 14, 2022 at 9:20pmWeb
Show threadEd SApr 10, 2022

#uxn on #amiga? That's #retrocomputing !

(tagging for signal boost)

@mathr @cr1901 @cancel @neauoire