aros-development-team/aros

Main AROS repository for active development. Contains the main Operating System components and Build System.

AROS Git Repository

This is the main repository for active development of the AROS Operating System. The repository contains the main Operating System components, SDK and Build System.

Nightly Test Builds

• All builds are scheduled to run at 00:00 UTC.
• The builds are made using the scripts/azure-pipelines.yml file. Further details can be found in that file.
• GCC 6.5.0 builds are configured using default toolchain settings. Newer GCC builds may also use newer versions of binutils.
• The main AROS target and distfiles are built for each arch.
• The builds are downloadable via http://www.aros.org/nightly1.php .

BUILD Arch	Status
Toolchain	GNU				LLVM
	6.5.0	9.1.0	10.2.0	13.1.0	10.0
amiga-m68k		---	---	---	---
pc-i386		---	---	---	---
pc-x86_64	---	---		---	---
pc-x86_64-smp	---	---	---		---
raspi-armhf	---		---	---	---
sam440-ppc		---	---	---	---
linux-i386		---	---	---
linux-x86_64	---	---	---
linux-arm		---	---	---	---
linux-armhf		---	---	---	---
darwin-i386	---	---		---	---
darwin-x86_64	---	---		---	---
darwin-ppc		---	---	---	---
mingw32-i386	---	---		---	---
mingw32-x86_64	---	---		---	---

Contributing

Please see the CONTRIBUTING.md file for details on joining the GitHub organization, and guidelines on contributing to the AROS project.

License

This project is licensed under the APL License - see the LICENSE file for details

Acknowledgments

AROS contains parts built upon external components - see the ACKNOWLEDGEMENTS file for details

aros's Issues

validate the data is HUNK

AROS/tools/dtdesc/createdtdesc.c

Lines 607 to 612 in a41b99f

	// TODO: validate the data is HUNK
	}
	fclose(dtcdInput);
	}
	if (DTCDdata)

---

This issue was generated by todo based on a TODO comment in a41b99f. It's been assigned to @Kalamatee because they committed the code.

in cli <>NIL: is not silent. (thx amiga23)

The run command does always print the Process ID like "[CLI4]", also if called with <>NIL:

That causes the CLI to open during boot and may interfere with IPrefs changing the screenmode.

https://ae.amigalife.org/index.php?topic=443.msg3741;topicseen#msg3741

Moving Icons to other folder copies instead of move (thx amiga23)

If you move an icon to another folder on same disk, it is copied instead of moved.

https://ae.amigalife.org/index.php?topic=447.0

Camd midi class seems to be faulty, my experience with using it with amithlon

I’m trying to get bars and pipes running on amithlon using poseidon USB camd midi class. I have to use Alfred Faust Version 1.29 as it allows for camd. I tried using many different USB midi interfaces. Many of them only received midi in data but failed to send midi out data. Then I bought a ESI MIDIMATE EX usb midi interface and it was able to send midi data out. It’s not perfect, it doesn’t send midi data to some channels. Channel 1,2,3,7,13 do not function. The other channel’s send out note on and off but don’t send any program change data. So one is stuck with only the first voice which is piano 1. Drums on channel 10 work perfectly.

I think that the camd poseidon class is incorrectly programed. I’ve tried camd. Library version 37 and the open source version 40.5. It’s not the libraries so it has to be the camd midi class in poseidon. How can we get the class fixed? I would appreciate it very much.

I have a dell C640 laptop which worked out of the box with kernel 3. I also have amithlon running in virtualbox on a Linux host. The same problem with the camd midi class exists on both installations. Aros has a source code development site
https://github.com/aros-development-team/AROS/tree/master/rom/usb/classes/camdmidi

Which includes the camd midi class source data for both AROS and amiga native code.

Any suggestions on how to get this class repaired?

Regards
Warren

website three years out of date

Looking at https://www.aros.org/, the last news update is in October of 2016. This presents the impression that serious work on AROS has stopped and that the github commits are only minor maintenance.

Implement */

AROS/arch/m68k-all/processor/processor_init.c

Lines 46 to 51 in 1c9a76e

	info->CPUFrequency = 0; /* TODO: Implement */
	pcr = 0;
	if (SysBase->AttnFlags & (AFF_68060 | AFF_68080)) {
	pcr = Supervisor(ReadPCR);
	}

---

This issue was generated by todo based on a TODO comment in 1c9a76e. It's been assigned to @Kalamatee because they committed the code.

Screen title not aligned as menu (68k native video)

The text inside a screen title bar is placed slightly high. When the menu is opened, the menu title texts are better centered. If one has the same initial text in both, the effect is not so nice as the text moves down and up, it should probably look better if it stayed in the same position.

This happens on a standard Amiga running native video at least, I have not examined other variants.

Stacksnoop nonsense output

Describe the bug
C:StackSnoop prints for each Task a negative stack size and then "needs more stack"

To Reproduce
Steps to reproduce the behavior:

1. open a Shell
2. enter "stacksnoop"
3. view the result

Expected behavior
A list of the used stack should be printed

Screenshots

Architecture

• linux (hosted)

not yet tested:

• Amiga (including UAE, Vampire cards)
• pc (native)
• Raspberry Pi
• mingw
• darwin
• other:

CPU

• x86_64

not yet tested:

• i386
• m68k
• arm
• ppc
• other:

Version
ABI WIP, current (2020-01-26)

Additional context
Add any other context about the problem here.

Wanderer prefs detailed settings do not save correctly on big endian systems.

including (tested on) m68k.
the problem must be in
https://github.com/aros-development-team/AROS/blob/master/workbench/prefs/wanderer/wpeditor.c
there is a number of macros responsible for this, among others SAVEVIEWSETTINGSTAG
as far as i know these settings should be asved in little endian for all platforms, so that the prefs files could be interchangeable.
so the numeric prefs should probably be endian converted for big endian platforms using aros det of macros like LONG2LE or something like that.

This shouldnt be done in the gfx driver!

AROS/arch/m68k-amiga/hidd/amigavideo/chipset.c

Lines 965 to 970 in 5d819c2

	/* TODO: This shouldnt be done in the gfx driver!
	* move to somewhere more appropriate */
	/* Reset audio registers to values that help emulation
	* if some program enables audio DMA without setting period
	* or length. Very high period emulation is very CPU intensive.

---

This issue was generated by todo based on a TODO comment in 5d819c2. It's been assigned to @Kalamatee because they committed the code.

Aros68K Distance Label From Image Icon with MagicWb Icon and ClassicWb Icon

Hi to all,
problem there is both Native Mode and Rtg Mode

AROS-20190926-amiga-m68k nightbuild

I try to use old 16 color MagicWb icon (but also classic wb icon), but the label of text are too distance from image icon ,such as the image in attached file.

I try to change setting into wanderer prefs, but the result non change.

Thanks a lot for help.

convert the hunk seglist data to LE values ...

AROS/workbench/libs/kms/openkeymap.c

Lines 130 to 135 in 0f20403

	// TODO: convert the hunk seglist data to LE values ...
	return NULL;
	#endif
	#endif
	}
	#endif

---

This issue was generated by todo based on a TODO comment in 0f20403. It's been assigned to @Kalamatee because they committed the code.

Not sure what to do here??

AROS/rom/usb/classes/camdmidi/camd/poseidonusb.c

Lines 128 to 133 in ea4b45f

	} while (sent < 100); // TODO: Not sure what to do here??
	Signal(port->ca_MsgPort->mp_SigTask, (1 << port->ca_MsgPort->mp_SigBit));
	AROS_USERFUNC_EXIT
	}

---

This issue was generated by todo based on a TODO comment in ea4b45f. It's been assigned to @Kalamatee because they committed the code.

pen palette per screen is not implemented.

when opening a new screen a new pallete/pens are set overwriting previous values, when switching back to previous screen, its palette is not restored, instead pens for the new screen are used.

perhaps we should just ask display driver about its current display mode? */

AROS/rom/intuition/inputhandler.c

Lines 1373 to 1378 in 454a5a4

	TODO: perhaps we should just ask display driver about its current display mode? */
	scr = FindFirstScreen(GetPrivIBase(IntuitionBase)->ActiveMonitor, IntuitionBase);
	if (scr)
	{
	DWidth = scr->ViewPort.ColorMap->cm_vpe->DisplayClip.MaxX - scr->ViewPort.ColorMap->cm_vpe->DisplayClip.MinX + 1;
	DHeight = scr->ViewPort.ColorMap->cm_vpe->DisplayClip.MaxY - scr->ViewPort.ColorMap->cm_vpe->DisplayClip.MinY + 1;

---

This issue was generated by todo based on a TODO comment in 454a5a4. It's been assigned to @Kalamatee because they committed the code.

Missing DOS and PosixC 64bit File IO functions

AROS does support 64-bit IO at the device level, but there are no usable functions to access large files.

SysInfo gives a wrong 'Horiz KHz' and 'Vert Hz' values with AROS ROM

submitted by ShK

tested on WinUAE with stock A1200+4MB settings
and nightly AROS floppy http://www.aros.org/nightly1.php
with SysInfo floppy https://sysinfo.d0.se/

elf2hunk generates wrong relocation info

AROS tool, elf2hunk, generates wrong relocation in case of R_68_PC32. The partial relocation done in this tool seems to be correct, but the relocation is copied into RELOC32 which is absolutely wrong.

Correct behaviour is to copy the R_68_PC32 into RELRELOC32, or to eliminate R_68_PC32 completely if both relocation and symbol are in the very same hunk.

Map pixel color

AROS/workbench/classes/datatypes/animation/animationclass.c

Lines 662 to 667 in 9f206e3

	// TODO: Map pixel color
	outline[x] = 0;
	}
	else
	{
	outline[x * 4] = 0;

---

This issue was generated by todo based on a TODO comment in 9f206e3. It's been assigned to @Kalamatee because they committed the code.

Amiga command key glyph in menu looks awful (native video Amiga)

Load a menu with some Amiga command key definitions, the inverted slanted 'A' that should be there does not look anything near that, see attached photo from a screen using native video.

Missing German translations

arch/all-pc/acpitool/catalogs
rom/security/catalogs
rom/usb/trident/catalogs
workbench/libs/identify/catalogs
workbench/tools/InstallAROS/catalogs

Document new utility.library functions

Fill the autodoccs.

iostream hangs on m68k (thx bsek)

the following code doesnt output anything and doesnt complete on m68k. it is tested working on x86_64.

#include <iostream>
​
int main(int argc, char** argv) {
std::cout << "test" << std::endl;
return 0;
}

IMPLEMENT */

AROS/arch/m68k-all/processor/getcpuinfo.c

Lines 106 to 111 in 4194bac

	*((ULONG *)passedTag->ti_Data) = 0; /* TODO: IMPLEMENT */
	break;
	case(GCIT_FrontsideSpeed):
	*((UQUAD *)passedTag->ti_Data) = processor->BusFrequency;
	break;
	case(GCIT_Vendor):

---

This issue was generated by todo based on a TODO comment in 4194bac. It's been assigned to @Kalamatee because they committed the code.

Debugging with GDB doesn't work on X86-64 hosted

Run AROS as shown in the debugging manual:
gdb boot/linux/AROSBootstrap

Run Developer/Debug/Test/exec/crashtest

It segfaults but findaddr doesn't work:
Thread 2.1 "AROSBootstrap" received signal SIGSEGV, Segmentation fault.
[Wechseln zu Thread 0x7ffff7fd7740 (LWP 26165)]
0x000000004111d6d4 in ?? ()
(gdb) bt
# 0 0x000000004111d6d4 in ?? ()
# 1 0x0000000041116890 in ?? ()
# 2 0x0000000000000000 in ?? ()
(gdb) findaddr 0x000000004111d6d4
(gdb) findaddr 0x0000000041116890

Corrupt native video in NTSC

Running on NTSC machines often makes AROS end up with a corrupt screen like this:

In FS-UAE, set up an A3000, tick the NTSC checkbox, install AROS ROMs and boot from a standard Commodore 3.1 floppy image, like the Installer or Workbench. The above screenshot is from such setup.

It can also be reproduced on hardware using an A3000, which has a jumper for PAL/NTSC. With the jumper set to NTSC, a similar screen effect is often seen. If changed to PAL, it works as expected (no strange video).

BLANK SCREEN */

AROS/arch/m68k-amiga/hidd/amigavideo/amigavideo_compositorclass.c

Lines 91 to 96 in 3b333e5

	/* TODO: BLANK SCREEN */
	UNLOCK_COMPOSITOR
	return;
	}
	vpdata = msg->data;

---

This issue was generated by todo based on a TODO comment in 3b333e5. It's been assigned to @Kalamatee because they committed the code.

Some draw actions extremely slow on Amiga native chipset

I have so far seen three cases when this happens.

1. The cat eyes no boot media screen is drawn very slow.

2. Horizontal scroll in the 'more' text viewer tool. A file with long lines are truncated, try to use the horizontal scroller and it is terribly slow.

3. Using the C= Installer tool to open a file that does not exist, i.e. Installer foo, which puts up a rectangle with an error over the window, after a while. Once up, click Proceed and watch it go away slowly, pixel line after pixel line.

linux-i386 shows fallback mouse pointer

Changing in prefs. helps only temporarily

Amithlon camd midi usb class for the the poseidon software

actions called on the host are done under the AROS task's stack

On hosted, AROS uses signals to alter the host processes hardware context, so that the currently running AROS tasks stack/PC, etc, is used.

The problem is drivers, or any other code that calls functions on the host OS, do not switch out the AROS tasks stack when performing the operations and so call code written for the host operating system still with the running AROS tasks stack used. Since the host does not know how to work with our stack, undesirable things can occur.

HostGL is a prime example. Depending on the GL driver the host is actually using, either unpredictable behavior occurs or memory gets trashed in AROS due to functions using more stack than AROS provides.

"Dir" on a file in RAM: crashes

Describe the bug
Doing "Dir" on a file on the RAM disk causes a segfault.

To Reproduce
Steps to reproduce the behavior:

1. Open a Shell.
2. Do e.g. "cd ram:env"
3. Do e.g. "dir hdaudio.config"

(gdb) bt
#0 0x0000000044244449 in GetRealObject (object=0x411d6150)
at /home/mazze/projects/aros-src/rom/filesys/ram/./filesystem.c:1409
#1 0x0000000044240e44 in CmdExamineAll (handler=0x412ade80, lock=0x412aaca0,
buffer=0x41e0b500 "", size=4096, type=6, control=0x41db1f80)
at /home/mazze/projects/aros-src/rom/filesys/ram/./commands.c:1421
#2 0x000000004423ea9d in RAMMain (SysBase=0x41002820)
at /home/mazze/projects/aros-src/rom/filesys/ram/./handler.c:262
#3 0x000000004423db01 in ram_Handler (argptr=0x0, argsize=0,
SysBase=0x41002820)
at /home/mazze/projects/aros-linux-x86_64-dbg/bin/linux-x86_64/gen/rom/filesys/ram/ram/ram_start.c:84
#4 0x000000004410fa01 in CallEntry (argptr=0x0, argsize=0, entry=0x411546dc,
me=0x411da9b0) at /home/mazze/projects/aros-src/rom/dos/./exit.c:129
#5 0x000000004410b519 in DosEntry ()
at /home/mazze/projects/aros-src/rom/dos/./createnewproc.c:752
#6 0x000000004400cb60 in ?? ()
#7 0x0000000000000000 in ?? ()
(gdb) frame 0
#0 0x0000000044244449 in GetRealObject (object=0x411d6150)
at /home/mazze/projects/aros-src/rom/filesys/ram/./filesystem.c:1409
1409 while((pred = node->mln_Pred) != NULL)
(gdb) p node
$19 = (struct MinNode *) 0x20

Expected behavior
Should either list the file or print an error message.

Screenshots
If applicable, add screenshots to help explain your problem.

Architecture

• linux (hosted)

not yet tested:

• Amiga (including UAE, Vampire cards)
• pc (native)
• Raspberry Pi
• mingw
• darwin
• other:

CPU

• x86_64
• i386

not yet tested:

• m68k
• arm
• ppc
• other:

Version
Provide the GID ID from AboutAROS (call menu Wanderer>AROS>About)

Additional context
Add any other context about the problem here.

Startnotify doesn't work on EMU:

Describe the bug
Paolone complaint that C:WaitNotify isn't working on EMU: drive
https://ae.amigalife.org/index.php?topic=468.0

To Reproduce
Steps to reproduce the behavior:

1. Compile waitnotify.c from
   http://archives.aros-exec.org/index.php?function=showfile&file=utility/shell/waitnotify.i386-aros.zip'
2. Run in a Shell: waitnotify emu:x
3. Error message "WaitNotify: StartNotify() failed for emu:x

Expected behavior
Command should wait till emu:x is changed

Screenshots
If applicable, add screenshots to help explain your problem.

Architecture

• linux (hosted)

CPU

• i386
• x86_64

Additional context
It works on RAM:

Behavior of " RUN >NIL: " on CLI

Describe the bug
When using >NIL: on CLI with RUN, it does not return back to CLI and prints an extra line [CLI 2] when all output should go into NIL.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'AROS Early Startup Control'
2. Click on 'Boot With No Startup-Sequence'
3. Type in CLI 'run >NIL: date'
4. Compare the behavior to Amiga OS 3.1

Expected behavior
RUN >NIL: date should come back to the CLI and all output should go into NIL.

Screenshots

Architecture

• WinUAE 4.3.0

CPU

• Amiga 4000 "Quickstart".

Version
GID ID: b234335

Additional context

Prevent Input Prefs. from opening *.dbg files

check the lowest supported mode..

AROS/arch/m68k-amiga/hidd/amigavideo/amigavideo_compositorclass.c

Lines 164 to 169 in 200937d

	visdwidth = 320; // TODO: check the lowest supported mode..
	visdheight = 200;
	if (msg->data)
	{
	IPTR tags[] = {aHidd_BitMap_Visible, TRUE, TAG_DONE};

---

This issue was generated by todo based on a TODO comment in 200937d. It's been assigned to @Kalamatee because they committed the code.

Sourceforge Bug Tracker

Many entries are still valid:
https://sourceforge.net/p/aros/bugs/

muimaster.library needs to be localized

report failure reason? */

AROS/rom/dos/runcommand.c

Lines 104 to 109 in 8abda1c

	/* TODO: report failure reason? */
	me->pr_Result2 = ;
	#endif
	return -1;
	}
	#endif

---

This issue was generated by todo based on a TODO comment in 8abda1c. It's been assigned to @Kalamatee because they committed the code.

locale.prefs and icontrol.prefs incompatible with the genuine amiga counterparts.

running the genuine amiga installation (wb3.9) from aros kickstart these both files seem not to be correctly interpreted. system hangs.

expose the azure-pipeline builds...

AROS/README.md

Lines 8 to 13 in cfe585f

	* Builds are currently not downloadable (TODO), and only done to check if the targets compile.
	* Builds are configured to use gcc 9.1.0
	* The main AROS target and distfiles are built for each arch.
	* Builds are made using the azure-pipelines.yml file found in the azure-pipelines branch. Further details can be found in that file.
	| BUILD Arch | Status |

---

This issue was generated by todo based on a TODO comment in cfe585f. It's been assigned to @Kalamatee because they committed the code.

AROS_ALMOST_COMPATIBLE

Check if AROS_ALMOST_COMPATIBLE is needed

convert the hunk seglist data to 64bit-LE values ...

AROS/workbench/libs/kms/openkeymap.c

Lines 126 to 131 in 0f20403

	// TODO: convert the hunk seglist data to 64bit-LE values ...
	return NULL;
	#else
	#if !AROS_BIG_ENDIAN
	// TODO: convert the hunk seglist data to LE values ...
	return NULL;

---

This issue was generated by todo based on a TODO comment in 0f20403. It's been assigned to @Kalamatee because they committed the code.

Incomplete localisation

Applications/Modules which aren't fully localized:
SysExplorer
HDtooBox

*/

AROS/workbench/libs/datatypes/class.c

Lines 828 to 833 in 242f948

	; /* TODO */
	}
	break;
	/* GM_LAYOUT and DTM_PROCLAYOUT have the same semantics; DTM_PROCLAYOUT

---

This issue was generated by todo based on a TODO comment in 242f948. It's been assigned to @Kalamatee because they committed the code.

trying to boot from fat file system instead of amiga one. (thx gunnar)

a disk with both AMIGA Filesystem and FAT filesystem will on AMIGA OS boot the AMIGA FS
but AROS will focus on FAT partitions as long as a PC Partition table is on the disk

Proposed fix: if RDB is present on disk then it should have priority over PC partition table in regards of selecting the boot drive.

the first ULONG should contain the DIB header size

AROS/workbench/classes/datatypes/bmp/bmpclass.c

Lines 299 to 303 in 42ca8fe

	//TODO: the first ULONG should contain the DIB header size
	#if (1)
	/* load BitmapInfoHeader from file, make sure, there are at least 40 bytes in buffer */
	if ( (BMPhandle->filebufbytes -= 40) < 0 && !LoadBMP_FillBuf(BMPhandle, 40) )
	{

---

This issue was generated by todo based on a TODO comment in 42ca8fe. It's been assigned to @Kalamatee because they committed the code.

Non-US keyboards don't work on X86_64 hosted

Something is wrong with X11 keyboard handling.

For French and German (and likely other) keyboards some keys aren't working (e.g. German umlauts äüö).

See
https://ae.amigalife.org/index.php?PHPSESSID=f4rb7d5i2loevlim905gh7o2g3&topic=430.msg3869#new

CAPS lock only change case every second time

On a real Amiga there is a CAPS lock key with a LED that indicates if CAPS is enabled or not.

Pressing this key results in that the LED toggles, but AROS only seem to listen to every second time, which means you have to press it twice to have effect, and then the LED light gets out of sync with actual behaviour.

This can be observed in the shell, but also in text entry fields in the GUI.

broken rendering and behaviour of zune prefs (generally zune guis) on (planar) low resolutions

such as

• zuneprefs nlisttree, nlistviews and texteditor dont save font settings and indent width
• sliders get sticky to pointer
• some (external) classes are being displayed two times in the list (texteditor, betterstring, nlisttree)
  that on pal hires nolace 640x256 m68k

probably it is a number of issues related to limited display size, zune is trying to cope with.