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)