Functions Your Amiga Never Told You About
Compiled from Usenet by Andre Frech
Excerpts from Articles by Bob Page and Wayne Hamilton

In the recent 'maps' that appeared in mod.amiga.sources, I noticed
that there were some functions that are listed under the ##private
section.  They are listed below.

What are their functions?  Obviously, since they are private, they
should be considered non-public!  However, I think that there may
be times that they could be useful to have, with the understanding
that they may go away at any time .. would anyone in the know like
to share some light on the subject?

Note:  Replies are from Wayne Hamilton.

In that note Bob remarks:
[ A few days ago I asked what the undocumented functions do.  Here
is the first response, from Wayne Hamilton.  Not surprisingly,
the folks at Commodore and Amiga have been silent on this.  --Bob]

##base _GfxBase
GelsFuncE()
GelsFuncF()

Can't help you with these.

##base _DOSBase
GetPacket(wait)(D1)
QueuePacket(packet)(D1)

These are WEIRD, even for BCPL.  I have disassembled the dos.library
code, and the functions pointed at by these vectors don't seem to have anything
at all to do with packets.  One of them looks like a "clear memory" utility
(like, "bzero(ptr, count)".

##base _SysBase
##private

special functions:

Supervisor()
ExitIntr()
Schedule()
Reschedule()
Switch()
Dispatch()
Exception()

These aren't simple.  I'm still trying to figure them out, along
with the rest of the exec task handling stuff.

new functions:

RawIOInit()
RawMayGetChar()
RawPutChar(char)(d0)
RawDoFmt()(A0/A1/A2/A3)

I tried to use these for some debugging, but something went
wrong.  Likely it was my fault, tho.  RawIOInit() seems to initialize
the serial port for 9600 baud i/o;  RawMayGetChar() looks at the serial
port data register and returns -1 if there's no data there, and reads
and returns the byte there otherwise.  RawPutChar(c) sends 'c' out the
port.  It uses busy-waiting if the port is still busy from a previous
put.  It also seems to check for ^S coming in, but it looks funny.

	RawDoFmt(fmt,arglistptr,byteout,byteoutarg)
		char *fmt;
		char **arglistptr;
		void (*byteout)();
		long byteoutarg;

Ihe way i've got it figured, 'fmt' and 'arglistptr' work like the
corresponding args to unix's _doprnt().  'byteout' is called each
time there's a formatted byte ready for "output" (in d0), including
the NUL byte that terminates 'fmt' (handy!).  None of the formatting
routines reference register a3, so i assume it's either 1) a mistake
in the template, or 2) available for indirect communication between
your code that calls RawDoFmt() and your byteout().  Obvious example
would be a stream or buffer pointer.


So, What's New in the New AmigaBasic?
by Carolyn Scheppner, Commodore Technology (...!cbmvax!carolyn)

For the most part, AmigaBasic 1.2 is mostly bug fixes.  The only new
thing I know of is that the new version parses command line arguments.
This means that it is now possible to boot directly from the startup
sequence into a basic program.  The correct paths relative to the
current directory (initially df0:) must of course be specified.

Example:

If AmigaBasic is on the boot disk in a directory called "Basic" and
the basic program is on the boot disk in a directory called "Programs"

   Basic/AmigaBasic Programs/MyBasicProgram

should load AmigaBasic which should then load and run MyBasicProgram.

One thing to remember however.  When you start AmigaBasic (or any
executable program) from Workbench, the resulting process is CD'd
where you double-clicked.  CLI processes however are CD'd to the same
place as the CLI they were started from.  So if your AmigaBasic program
needs to read in any files (such as bmaps, graphics, etc) or writes
files with no path expecting them to go to certain directory, you
will probably need to add a CHDIR statement to your Basic program
to make sure IT is CD'd where you want.

Q: Anyone done any neat ways of sending data from one AmigaBasic
program to the next one?

CHAIN can call in and run another program while preserving all variables.
Or you might want to write out a RAM: or disk file which the other program
could read.  If you want to implement BSAVE/BLOAD type of stuff, see my
AmigaBasic ILBM programs on Extras 1.2 for an example of the kind of
BSAVE/BLOAD that can be implemented with AmigaDOS system calls.
(Better than BSAVE/BLOAD because you can save many different areas of
memory in one file, and can load portions of one file back into various
memory addresses.)


The Unofficial 1.2 Buglist
by Bryce Nesbitt (...!ucbvax!COGSCI.BERKELEY.EDU!bryce)

Amiga BUGLIST. Each bug/condition has been verified as repeatable
in V1.2 (Release or Gamma1), and is not related to any hardware problems.

-- Trackdisk --

Sticking a disk in a drive, then changing your mind and pulling the disk
back out can severely confuse trackdisk.  It will continue to step and
notice disk insertion, however DOS will never find out about a disk placed
in that drive until a re-boot.  Timing is critical, but repeatable; insert
a new disk in, wait for the light to come on and the first 'grind' as the
head steps to block 880.  Pull the disk out before it gets there; If you
get a 'disk corrupt' requester you waited too long.  Repeat, varying
timing until the CLI 'info' command locks up when getting the
status of the 'dead' drive.  This can also happen if your finger slips
on the button while removing a disk, and that, in fact, is how I noticed
this bug.

-- ED --

Type "fish".  Press and hold the "-" key until the message "Line Too Long"
comes up.  Now type <CTRL><]> (control-bracket). 'Poof',the line disappears.
Now cursor up to the "h" in "fish" and hold the "-" key until the "Line
Too Long" message comes up.  Save to disk with <ESC>,<X> (escape then "x")
Ed has now crashed.

-- DOS --

Calling Delay(0), or WaitForChar(blah, 0) (any DOS call which takes
a timeout and setting that timeout to 0) intermittently crashes
the Amiga.  ( Test program: for(;;) Delay(0); ).

DOS devices such as RAM: or PIPE: that are meant to have a single
invocation/filehandle for multiple users have a problem.
If two programs attempt to reference the same DOS device simultaneously,
and DOS must load it from disk, the window is sufficiently large to cause
separate invocations of the driver (instead of just one) for each program
causing all sorts of problems.

[Mini editorial:]  The DOS driver must set a field when it starts up to
cause DOS not to make separate invocations.  Rightly, this should be a
bit or field in the Mountlist.

[suggestion]  BCPL programs link weird, and a exec() function should be
provided that will allow alternate CLI programs to function without major
structure fondling, compromises or kludges.  The current DOS execute()
does not qualify.  !!Requested by several programmers!!

[suggestion]  Error #200,'internal error'
                    #201,'newer operating system required'

[suggestion]  Rather than have empty drives 'click' every 3 seconds simply
reset the DISKCHANGE* latch by stepping outward repeatedly.  The optical
stop is there, it reduces noise, wear on the mechanism and the sample
rate can be upped without driving people batty.

[suggestion]  Preference item to enable/disable a requester warning when
a file is about to be overwritten.  Must be software setable so programs
with such protection already installed will not cause the user to be asked
twice.

-- Exec/Intuition --

Disk insertion should NOT <RETRY> a 'software error - task held' requester.

Alerts display the text message in the system font, NOT a hard coded ROM
font.  If the default system font has been changed to a RAM based font and
if becomes trashed, the alert will be unreadable.  Not a bug, but a
survivability concern.

The Alt-Amiga combinations are not accepted when alerts want a mouse button
press.

-- Intuition --

I have a tool that opens a window on the Workbench screen.  It works
perfectly.  I wished to speed up text writes to this window so I set the
rp_Mask field to $1, this too worked fine; that is until I depth arranged
the window and it started dropping bitplanes all over the place.  $FE,$FD
provided the same results.  I was shocked, one would think that Intuition
would have it's own idea about rp_Mask.  My tool now does things the old
way, monochrome text written into two bitplanes when the second plane is
already at a known state.  AHHHHH!!!!!!
For monochrome text the proper approach should be to clear/set all planes
of the text area, and write the text into only one of them.  Common sense.

Place a window in the center of the screen and start a window resize.  Hit
Left Amiga-N or M.  Continue the resize PAST the top left corner of the
window.

When the system is nearly out of memory menus can still be pulled down,
but the actual graphics will not be drawn.

[mini-editorial:]  Why not calculate and reserve the proper maximum amount
of memory needed at the time a new strip is submitted to Intuition.  One
memory pool will serve all menus, since only one menu and one sub can be
pulled at a time.

Intuition should skip ahead to the latest mouse position report after pulling
down a menu, rather than responding to each in turn.

-- Workbench Bugs --

Type 'LoadWB' after hanging around in the CLI for a while.  Workbench
will ask for each know volume in turn.  <CANCEL> will not convince the
Workbench to give up asking for a disk that may be long gone, lost,
formatted, copied over or even relabeled.  Either the <CANCEL> option
should not be selectable, or it should cause WB to ignore that disk/lock
until it shows up on it's own accord.

Dropping a dragged icon at EXACTLY the right time, into the space where
a new disk icon is ABOUT to appear will cause that icon to 'stick' to the
pointer even after the button is released.  Moving the pointer to the title
bar and clicking crashes the machine. V1.0,V1.1 & V1.2 repeatable.

Vigorous resizing of WB windows will trash the 'Gas gauge.'

Corrupt .info files can crash the Workbench tool.  Sample 'killericon.info'
available on request.

If Workbench is not already doing it, these steps should be taken:

1> RENAME instead of COPY if the source and destination locks refer to the
same volume.

2> When updating the '.info' file, if no substantive changes are needed
update the datestamp with a seek, rather than with a new file.

3> When 'snapshoting' a '.info' file seek to the position variables and
modify them in place, rather than creating a new file.

-- V1.2 RAM: bugs --

Create an empty file.  Delete it.  The block count will be incorrect.
[COPY * TO FISH , <CTRL><\> , DELETE FISH , repeat , INFO]
Block counts such as -3 are easy to create.

Related:  If the first copy that sets up the RAM: fails due to lack
of memory the block count will be similarly screwed.

Rename allows duplicate file names.  [create files 'fish' & 'frog' rename
one to match the name of the other]

-- Font editor --

Select 'OPEN' from the menu.  While the editor is reading in the
font names, move the 'ZOOM' gadget.  Crash.

DOS related requesters belonging to the font editor appear in the
Workbench screen, not the font editor screen.  Set the pr_WindowPtr in
the DOS process structure.

-- EMACS Bugs --

In EMACS, select SAVE AS with mouse.  Save a long file to floppy.
While it is grinding away, select SAVE AS again and type another filename.
EMACS does not like this, and will become upset.

The justify function (^X^J) is broken.  Crashes always.

The 'ENTER' key does not function properly when inputing on the bottom line.

-- StripA (From Toolkit, strips extra symbol hunks from executables --

Files often do not work after the treatment.  Example; the notepad.

-- User interface --

The input device/Intuition does not track pointer movement during such
operations such as window resize.  This 'feels' sloppy.  Some hyper-high
priority task should keep the pointer visuals intact, even if Intuition is
stomping on the input.device task.

In cases where <RETRY> or <CANCEL> on a requester is NOT a valid operation,
the gadget should not be present, or selectable.  Example:  <RETRY> on most
'task held' requesters.

<CANCEL> should <CANCEL>.  Period.  None of this asking twice stuff.

'Desk' accessory menu to help combat clutter on the Workbench screen.  Direct
support for moving windows from one compatible screen to another.

-- Documentation --

The examples in Intuition manual encourage limiting window growth to 640*200.
PAL, interlace & morerows freaks hate this. The manuals should encourage
no limits if none are required.

Many, many people miss setting the NOCAREREFRESH flag in their SMART_REFRESH
windows, thus causing extra refreshes forever after a window resize.

                                            Timothy Rue (AAi member)