# AMOS Professional

Allows you to write in [[:amiga:development:languages:amos_basic|AMOS Basic]]. My language of choice for years.

## With FS-UAE

Make sure [mouse_integration](https://fs-uae.net/docs/options/mouse-integration) is disabled in FS-UAE, otherwise the mouse will not move in AMOS Professional. You may have to edit the machine's config file in a text editor if you can't turn off `mouse_integration` via the UI.

## Manual

* https://www.ultimateamiga.co.uk/HostedProjects/AMOSFactory/AMOSProManual/3/301.html

Doesn't have search functionality unfortunately.

## Books

* https://amigasourcepres.gitlab.io/page/books/amos/

[[amiga:development_environments:basic:amos_professional:command_notes|AMOS Pro Command Notes]]

## Source Code

* [GitHub](https://github.com/AOZ-Studio/AMOS-Professional-Official)

The source is licensed under the MIT License now.

## Unofficial Releases

AMOS Pro 2.10 was assembled and released by bruceuncle. It fixes a number of issues.

* https://www.ultimateamiga.com/index.php?topic=9701.45

## Tools

* https://github.com/kyz/amostools/
  * Includes a bunch of extensions as well

## Setup

* Get the ADFs from TOSEC. They're already set up for registration.
  * Note that AMOS Pro is currently distributed under the MIT License, so this is perfectly fine.
* Keep disks 1-6 in your media pool or mount them individually as needed
  * You can't use the AmigaOS 3.2 auto ADF mount to do this, you'll need to mount the disks in the emulator config.
* When you pick a folder to install into, an AMOSPro folder will be made, so if you want it in, say, `SYS:Development/`, don't make another `AMOSPro` folder within.
* Also install the AMOS Compiler, whose disks are also in TOSEC.

### Bugs

Due to a combo of AMOS's use of signed long numbers and the `dos/Info()` function for retrieving disk free information, you can't install AMOS on a partition larger than 2GB.

## Extensions

Extensions are written in [[m68k:development:m68k_assembly_language|Motorola 68000 Assembly Language]]. You can have 26 of them. You can also call machine language code directly via Pcall and Insert Program.

* [[amiga:development_environments:basic:amos_professional:extension_development|Extension Development]] - My own notes from developing an extension.

### Existing extension lists

* http://aliensrcooluk.com/public/Amiga_AMOS_extlist.html
* https://www.exotica.org.uk/wiki/AMOS_extensions/AMOS-LIST
* https://www.ultimateamiga.com/index.php?topic=9066.0

Lots of extensions implement a lot of the same useful functionality, and since there can be only 26, you have to pick and choose.

## Variables

In some situations, variables are pass by reference.

* They definitely are for strings.

All integers are signed longs, so −2,147,483,648 to 2,147,483,647 are supported. You can't even type in a larger number, the first digit gets truncated from 2,147,483,648 in the editor.

If you're doing floating point math, convert as many of the values to floating point as possible before doing more complex calculations. AMOS will sometimes drop the fact that it's supposed to do FP math and will switch back to integer.

## Help Files

File format goes here.

## Prepping art for use

Ideal pipeline: Krita -> GIMP -> ArtPRO -> AMOS object banks

* Krita
  * Use a thick brush if you're working on a higher rez screen
* GIMP
  * Set grid to 1x1 px
  * Don't use single window mode, have a second view on the image to see the whole thing
  * Use Pencil, not brush tool
  * Use single pixel brush
  * Create a custom palette with destination colors
  * Loading an image
    * Load as RGB
    * Convert to indexed using palette, no interpolation
    * Resize to desired size
    * Clean up image
    * Save as indexed PNG

### Issues

#### PNG output image only uses 8 of 16 possible screen colors

Possible solutions:

* Always include all colors
  * Stick all 16 colors in the image somewhere
  * Convert to ILBM
  * Use DPaint to erase those bits
  * Resave as ILBM
* Import into AMOS

If I put all the colors into the indexed palette of the image in GIMP it "works", but it's super high friction. I need something that can:

* read the pixels of an indexed PNG file
* read what colors those pixels are
* read a palette definition
* swap around colors that match
* alert on colors that don't match
* add in missing colors
* create a new indexed PNG
  * or XPM file? https://en.wikipedia.org/wiki/X_PixMap These can be written as text.

## IFF Files

AMOS Pro adds an additional chunk called `AMSC`. This seems to store extra AMOS screen information for the active screen that's being saved:

```asm
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
; 					Sauve le AMSC
; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	Lib_Def	SaveAMSC
; - - - - - - - - - - - - -
	move.l	Buffer(a5),a1
	move.l	#"AMSC",(a1)+
	move.l	#7*2,(a1)+
	move.w	EcAWX(a2),(a1)+
	move.w	EcAWY(a2),(a1)+
	move.w	EcAWTX(a2),(a1)+
	move.w	EcAWTY(a2),(a1)+
	move.w	EcAVX(a2),(a1)+
	move.w	EcAVY(a2),(a1)+
	move.w	EcFlags(a2),d0
	and.w	#$8000,d0
	move.w	d0,(a1)+
	Rbra	L_SaveA1
```

When you enable compression with `Save Iff`, it's standard ByteRun1 encoding (tested on DPaint.js). If this is what's meant by the "standard Amos Professional compression system", then reading compressed AMOS Pro data elsewhere should be pretty straightforward.