AmigaOS 3.2 NDK released

[bubbob42]

The new AmigaOS 3.2 Native Developer Kit can be found here:

https://www.hyperion-entertainment.c...=form&file=122

as a free download. It is an updated version compared to the one shipped on the AmigaOS 3.2 CD-ROM and contains Includes&Autodocs, full changelogs since 3.1 and more.

Developers plan to publish more information to provide assistance for installation and usage in combination with various compilers and assemblers. All contributions for any programming language are welcome!

[Edders]

Thank you for providing this, much appreciated!

[kamelito]

why did the NDK changed :

$dff020 DSKPTH Disk track buffer pointer (high 5 bits)
$dff022 DSKPTL Disk track buffer pointer (low 15 bits)


to dskpt I guess some source code won't assemble anymore right?

same for other 5bits/15bits registers (hi/low)

[Phantasm]

Originally Posted by kamelito

why did the NDK changed :

$dff020DSKPTHDisk track buffer pointer (high 5 bits)
$dff022DSKPTLDisk track buffer pointer (low 15 bits)


to dskpt I guess some source code won't assemble anymore right?

same for other 5bits/15bits registers (hi/low)

Can't think why you would ever need to access these separately

[Olaf Barthel]

Originally Posted by kamelito

why did the NDK changed :

$dff020 DSKPTH Disk track buffer pointer (high 5 bits)
$dff022 DSKPTL Disk track buffer pointer (low 15 bits)


to dskpt I guess some source code won't assemble anymore right?

same for other 5bits/15bits registers (hi/low)

Hm... scratching my head there: where did you find the file which contains these register definitions, including the documentation? This looks more like something from the hardware reference manual.

The NDK 3.2 R4 contents feature exactly three files which even reference the dskpt register, these being:

Include_H/hardware/custom.h:41:    APTR    dskpt;
Include_H/proto/alib.h:147:extern volatile APTR dskpt;
Include_I/hardware/custom.i:35:dskpt	    EQU   $020

And that's all she wrote. There is not even a single dff020 or dff022 reference either.

Truth be told, most of the NDK 3.2 material has been published before and we are merely standing on the shoulders of giants

The more detailed custom register properties are not what the header files are concerned with.

[kamelito]

@Olsen

http://coppershade.org/articles/Code...Register_List/

and

http://amiga-dev.wikidot.com/information:hardware

@Phantasm
True

[Steady]

As far as I can recall, the custom.i file only ever referred to the full register where there was H and L parts (i.e. dskpth followed by dskptl was referred to as the 32-bit dskpt). Any breakdown into the individual H & L parts was done by files external to the NDK.

Appendix I in the Hardware Reference Manual contained a more broken down version of the register address mapping but that is not directly part of the NDK. Here, in particular, you will find DSKPTH and DSKPTL.

https://archive.org/details/amiga-ha...e/373/mode/2up

[Olaf Barthel]

Originally Posted by kamelito

@Olsen

http://coppershade.org/articles/Code...Register_List/

and

http://amiga-dev.wikidot.com/information:hardware

Well, at least these are not part of the NDK 3.2 or any of the previous releases, going back to 1987/1988 and never have been

You really had me worried there for a minute. What's in the NDK 3.2 is really just the collection of tools and documentation for tinkering with the Amiga at the operating system level or slightly below that. Deeper layers of the machine certainly exist, but their scope is outside the NDK save for the header files which describe the custom chip & CIA registers.

[bebbo]

IMHO the amiga.lib misses some relocations:

... e.g. _CreatePort (in CreatePort.c-00001382.o) calls _NewList (NewList.asm-00001381.o) with a `bsr`

  5c:   486b 0014       pea 20(a3)
  60:   6100 0000       bsr.w 62 62 _NewList+0x62
  64:   584f            addq.w #4,sp

But there is no relocation for that. Right?

[LamboJay]

Am I not seeing it or is reaction.lib missing from the 3.2 SDK?

Using sas/c 6.5.8, I was able to compile the example apps using the lib from 3.5 sdk. They work but I'm seeing bugs and wondering if it's because of the older .lib

[Olaf Barthel]

Originally Posted by bebbo

IMHO the amiga.lib misses some relocations:

... e.g. _CreatePort (in CreatePort.c-00001382.o) calls _NewList (NewList.asm-00001381.o) with a `bsr`

  5c:   486b 0014       pea 20(a3)
  60:   6100 0000       bsr.w 62 62 _NewList+0x62
  64:   584f            addq.w #4,sp

But there is no relocation for that. Right?

The NewList() is part of amiga.lib, has been since the exec.library API was frozen. Apparently, the exec list node macros in "exec/lists.i" were not adapted for use as 'C' macros and just NewList() made the cut, winding up as an amiga.lib function.

I reckon the problem here is that amiga.lib making a PC-relative call to NewList() is unsuitable for the program in question because of it size, or linker implementation constraints.

The original "vintage" amiga.lib was always built using the Green Hills 'C' compiler, which always used 32 bit adressing when referencing external code or data. Here's how the 1992 vintage CreatePort.c looks like:

Amiga Object File Loader V1.00
68000 Instruction Set

EXTERNAL DEFINITIONS

_DeletePort 0088-00    _CreatePort 0000-00

SECTION 00 "" 000000CC BYTES
       | 0000  48E7 3C20                      MOVEM.L     D2-D5/A2,-(A7)
       | 0004  262F 0018                      MOVE.L      0018(A7),D3
       | 0008  142F 001F                      MOVE.B      001F(A7),D2
       | 000C  7AFF                           MOVEQ       #FF,D5
       | 000E  2F05                           MOVE.L      D5,-(A7)
       | 0010  4EB9  0000 0000-XX             JSR         _AllocSignal
       | 0016  2800                           MOVE.L      D0,D4
       | 0018  588F                           ADDQ.L      #4,A7
       | 001A  6F64                           BLE.B       0080
       | 001C  2F3C 0001 0001                 MOVE.L      #00010001,-(A7)
       | 0022  4878 0022                      PEA         0022
       | 0026  4EB9  0000 0000-XX             JSR         _AllocMem
       | 002C  2440                           MOVEA.L     D0,A2
       | 002E  2A0A                           MOVE.L      A2,D5
       | 0030  508F                           ADDQ.L      #8,A7
       | 0032  6742                           BEQ.B       0076
       | 0034  2543 000A                      MOVE.L      D3,000A(A2)
       | 0038  1542 0009                      MOVE.B      D2,0009(A2)
       | 003C  157C 0004 0008                 MOVE.B      #04,0008(A2)
       | 0042  422A 000E                      CLR.B       000E(A2)
       | 0046  1544 000F                      MOVE.B      D4,000F(A2)
       | 004A  42A7                           CLR.L       -(A7)
       | 004C  4EB9  0000 0000-XX             JSR         _FindTask
       | 0052  2540 0010                      MOVE.L      D0,0010(A2)
       | 0056  4A83                           TST.L       D3
       | 0058  588F                           ADDQ.L      #4,A7
       | 005A  670A                           BEQ.B       0066
       | 005C  2F0A                           MOVE.L      A2,-(A7)
       | 005E  4EB9  0000 0000-XX             JSR         _AddPort
       | 0064  600A                           BRA.B       0070
       | 0066  486A 0014                      PEA         0014(A2)
       | 006A  4EB9  0000 0000-XX             JSR         _NewList
       | 0070  588F                           ADDQ.L      #4,A7
       | 0072  200A                           MOVE.L      A2,D0
       | 0074  600C                           BRA.B       0082
       | 0076  2F04                           MOVE.L      D4,-(A7)
       | 0078  4EB9  0000 0000-XX             JSR         _FreeSignal
       | 007E  588F                           ADDQ.L      #4,A7
       | 0080  7000                           MOVEQ       #00,D0
       | 0082  4CDF 043C                      MOVEM.L     (A7)+,D2-D5/A2
       | 0086  4E75                           RTS
       | 0088  2F0A                           MOVE.L      A2,-(A7)
       | 008A  246F 0008                      MOVEA.L     0008(A7),A2
       | 008E  4AAA 000A                      TST.L       000A(A2)
       | 0092  670A                           BEQ.B       009E
       | 0094  2F0A                           MOVE.L      A2,-(A7)
       | 0096  4EB9  0000 0000-XX             JSR         _RemPort
       | 009C  588F                           ADDQ.L      #4,A7
       | 009E  157C 00FF 0008                 MOVE.B      #FF,0008(A2)
       | 00A4  70FF                           MOVEQ       #FF,D0
       | 00A6  2540 0014                      MOVE.L      D0,0014(A2)
       | 00AA  7000                           MOVEQ       #00,D0
       | 00AC  102A 000F                      MOVE.B      000F(A2),D0
       | 00B0  2F00                           MOVE.L      D0,-(A7)
       | 00B2  4EB9  0000 0000-XX             JSR         _FreeSignal
       | 00B8  4878 0022                      PEA         0022
       | 00BC  2F0A                           MOVE.L      A2,-(A7)
       | 00BE  4EB9  0000 0000-XX             JSR         _FreeMem
       | 00C4  4FEF 000C                      LEA         000C(A7),A7
       | 00C8  245F                           MOVEA.L     (A7)+,A2
       | 00CA  4E75                           RTS

SECTION 01 " " 00000000 BYTES

In the mean time I have modified the build options for amiga.lib to emulate the Green Hills 'C' compiler behaviour: 32 bit references for code and data only.

I do wonder why amiga.lib is still being used, though. libnix, clib2, etc. should have their own versions of these functions. Nobody should need to link against amiga.lib. The majority of the code found in amiga.lib are stubs for calling Amiga library and device functions via stack-based parameter passing. If you really do not need these, you ought to link against small.lib, which is shorter because it omits the stubs.

[Olaf Barthel]

Originally Posted by LamboJay

Am I not seeing it or is reaction.lib missing from the 3.2 SDK?

Using sas/c 6.5.8, I was able to compile the example apps using the lib from 3.5 sdk. They work but I'm seeing bugs and wondering if it's because of the older .lib

Yes this is very likely. We reconstructed reaction.lib from bits and pieces but were unsure whether our "Battenberg cake" recipe is sufficiently complete. We do plan to ship it with the next NDK update.

[LamboJay]

Thanks Olaf

[bebbo]

in the header Include_H/workbench/workbench.h:88

    STRPTR *		do_ToolTypes;

should rather be

    CONST_STRPTR *		do_ToolTypes;

to match

UBYTE *FindToolType( CONST_STRPTR *toolTypeArray, CONST_STRPTR typeName );

[Olaf Barthel]

Originally Posted by bebbo

in the header Include_H/workbench/workbench.h:88

    STRPTR *		do_ToolTypes;

should rather be

    CONST_STRPTR *		do_ToolTypes;

to match

UBYTE *FindToolType( CONST_STRPTR *toolTypeArray, CONST_STRPTR typeName );

Yesterday evening I finally got around to changing the DiskObject structure as you suggested, followed by rebuilding the entire operating system from scratch. This produced a handful of warnings but no build-breaking errors. The warnings are sensible and not of the cryptic kind, as far as our build compiler is concerned

I'd say this change makes good sense in context and would be good to go into the NDK 3.2R4 change set. Thank you

[jabbadude]

Originally Posted by Olaf Barthel

I do wonder why amiga.lib is still being used, though. libnix, clib2, etc. should have their own versions of these functions. Nobody should need to link against amiga.lib. The majority of the code found in amiga.lib are stubs for calling Amiga library and device functions via stack-based parameter passing. If you really do not need these, you ought to link against small.lib, which is shorter because it omits the stubs.

I'm trying to figure out how to have Scoptions (sas/c 6.58) choose small.lib rather than amiga.lib. Or do people simply rename small.lib to amiga.lib?