Canonical Bug List ABasic bugs: ABasiC Animate command----- Give up on this. The 1st page of the errata, referring to page R-96 "Note that the animate command might not be currently be implemented." C-A had hoped to get this in and working before the V1.0 release but it just didn't happen. It is, in fact not implemented. Your Amiga Basic upgrade DOES do animation. The "_" at the end some of the lines is put there by ABasiC when you press the down-arrow key at that point. This will cause a LF/CR/TAB-7 to start the next line indented to right under the beginning of the last excluding the line number. SPECIAL NOTE: There is apparently a bug in ABasiC in regard to the color used for the cursor and OUTLINEs. In the above example, register 3 is only used for these functions if the number of bit planes (in the SCREEN command) is 2. What is apparently happening is that the cursor/outline color is the "highest different color". Thus: # of bitplanes C/O Register ============== ============ 1 1 2 3 3 7 4 15 5 31 ( Remember the registers are numbered 0-31 ) SPEECH Contrary to what the ABasiC manual says, to get that rise at the end of a sentence that makes it a question, LEAVE OFF ALL PUNCTUATION. The question mark seems to act like a period. FILE ACCESS Conrary to the manual, LOF(n) returns the number of BYTES in the file REGARDLESS of whether the file is opened as sequential or random access. Divide by the record length to get the number of records. RGET will generate an end-of-file error upon reading the last block of the file. Use code similar to below to process that last block: 1010 ON ERROR GOTO 9010:_ RGET #1, BLK% 1020 ON ERROR GOTO 0 ' Disable ON ERROR . . Process the block as you would any other . It will be padded with blanks 8999 END_ 9010 RESUME NEXT ' Returns to 1020 Bugs in ROM Manual From Gary Girzon, Tue Oct 15 As probably noted earlier, the ROM Kernel manual has a 'few' bugs. Most of them are flagrant C errors in type casting and pointers. The one that has got me has to do with the type APTR. If I recall correctly, typedef APTR *STRPTR typedef unsigned char *STRPTR thus APTR -> STRPTR --> unsigned char, so APTR is an address location which holds another pointer to an array of chars. However, the ROM manual constantly insists in using APTR to point to a data buffer ( Actually, the Intuition manual does the same for defining things like menu text. I am sorry I cannot remember the exact pages). If you do that, the compiler will complain. Has anyone gotten the multi tasking example to run? It has the same probelem in assigning stack pointers using APTR type. My program, even when type cast and corrected, dies after the 'littletask' is launched. I am very tired of guru's. Also, is the console IoRequest structure documented anywhere? The ROM manual says "more on this latter...". I wish there was an example for console and serial IO (although that sort of works) similar to the one for audio. From Perry S. Kivolowitz The Intuition manual (v1.0) states that ACTIVEWINDOW and INACTIVEWINDOW are NewWindow flags. They are actually IDCMP flags. If you ``or'' in ACTIVEWINDOW, you get messages through the IDCMP whenever your window becomes the active window (message->Class == ACTIVEWINDOW). Similarly so for INACTIVEWINDOW. Look at intuition/intuition.h for more information. I was using these messages in IntuiScope, an intuition utility I am writing. I wanted to back track out of a menu selection if the IntuiScope window became deselected. /* text of Lattice 3.02 bugs, AmigaDOS 1.0 bugs, 1.1 improvements */ Subject: Lattice C V3.03 Date: 30 Oct 85 00:59:31 GMT From: Bob Page Here are the problems with Lattice C V3.02 that are fixed in C V3.03: 1. When objects whose size was not a power of two was subscripted with a short index, long multiplication was performed. Now the multiply is performed in-line with the MUL instruction. 2. Indirect references with offsets greater than 32K did not work correctly. 3. There were miscellaneous problems with short and character expressions where the operands were not being extended or masked correctly. 4. Technically invalid declarations were being accepted by the compiler (e.g., int a(space)b(space)c; instead of int a,b,c;). 5. Expressions like ((a !=0) != 0) were not evaluated properly. 6. When character pointers were converted to other types of pointers the value was forced to an even value to cause alignment on word boundaries. This has been removed; Caveat Emptor. 7. Casting an enum to an integral type generated an error message. 8. Initialization of arrays of structures required full use of brackets. 9. Enum declarations caused the compiler to fail on the Amiga, usually dragging the system down with it. Feel free to repost this to BIX, the fridge, and anywhere else you'd like. From bobp@amiga.UUCP (Robert S. Pariseau) Thu Nov 7 03:46:21 1985 Path: gumby!uwvax!seismo!cmcl2!philabs!prls!amdimage!amdcad!amd !pesnta!greipa!decwrl!pyramid!amiga!bobp From: bobp@amiga.UUCP (Robert S. Pariseau) Date: 7 Nov 85 09:46:21 GMT Reply-To: bobp@snake.UUCP (Robert S. Pariseau) Organization: Commodore-Amiga Inc., 983 University Ave #D, Los Gatos CA 95030 No Curt, you've read that backwards. The V1.0 manual says that OpenLibrary() will work if the library it finds has a version number equal to or greater than the one you requested. That manual also says (in the Libraries chapter), that as of this writing, the requested version number should be 0. For various compatability reasons, we had to disable the version checking in OpenLibrary() and OpenDevice() for V1.0. This was due to the pre-release software having version numbers like 29 (sigh). We currently plan to re-install the version checking for V1.1. We will maintain compatability by using library version numbers like 101 (for 1.1 yes?). In addition, the version checker will treat any requested version number of 100 or less as if you requested version 0. Thus old code asking for version 0 will continue to work and even older code asking for version 29 will continue to work. Any code dependent upon the new features in a V1.1 library should ask for version 101. This gives you a clean way to back out if the user tries to run your new program under a V1.0 Kickstart or with the V1.0 libraries and devices found on the Workbench disk. From: rodb@tektronix.UUCP (Rod Belshee ) Date: 25 Oct 85 20:23:02 GMT Organization: Tektronix, Beaverton OR I previously posted a FLAME about the documentation. After speaking with AMIGA support I have calmed down a bit. It seems that there is a discrepancy between the First half and the Last half of the manual. In particular the interface definition of the MakeVPort(&v,&vp,&ri,&ri) calls in the front and the MakeVPort(a0,a1) assembler interface definition in the back. TRUST THE ASSEMBLER INTERFACE DISCRIPTION. Amiga is redoing the ROM Kernal Manual and it should be out soon. For those of you who care, the following changes have to be made to the program found on page 8-29. 1. change include include 2. delete inlcude 3. change BitMap *b BitMap b 4. delete OFF_DISPLAY 5. delete ON_DISPLAY 6. delete call to Panic() 7. change "graphics" to "graphics.library" 8. add.******* vp.RastInfo = &ri; before MakeVPort call 9. delete last 2 parameters in the call to MakeVPort(); I forgot to ask but I don't think the call to Debug should be there either. If anybody else gets' info please take a minute to post it thanks. Curt Jutzi tektronix!gpp1!golem!jutz tektronix!rodb