AtariWiki V3.1: Action Bugsheet

This page (revision-9) was last changed on 03-Feb-2023 15:21 by Gromit

This page was created on 27-Aug-2010 22:53 by Florian Dingler

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version	Date Modified	Size	Author	Changes ...
9	03-Feb-2023 15:21	31 KB	Gromit	to previous
8	17-May-2011 13:30	30 KB	Gromit	to previous \| to last
7	17-May-2011 12:34	30 KB	Gromit	to previous \| to last
6	28-Aug-2010 12:51	30 KB	Florian Dingler	to previous \| to last
5	28-Aug-2010 12:44	19 KB	Florian Dingler	to previous \| to last
4	28-Aug-2010 12:43	19 KB	Florian Dingler	to previous \| to last
3	27-Aug-2010 23:01	13 KB	Florian Dingler	to previous \| to last
2	27-Aug-2010 22:58	13 KB	Florian Dingler	to previous \| to last
1	27-Aug-2010 22:53	13 KB	Florian Dingler	to last

Page References

Incoming links	Outgoing links
Action Bugsheet Action	Action Bugsheet

Version management

Difference between version and

At line 1 changed one line

!!!ACTION! BUG SHEET #3 - part 1 to 6

!!!ACTION! BUG SHEET #3 - part 1

At line 3 removed one line

At line 5 changed one line

----

--------------------------------------------------------------------------

At line 7 removed 5 lines

[{TableOfContents }]

At line 16 changed one line

!!P1. TIPS ON TEMPS

!TIPS ON TEMPS

At line 142 changed one line

!!P2. BUGS IN THE ACTION! CARTRIDGES

!!BUGS IN THE ACTION! CARTRIDGES

At line 145 changed 3 lines

{{{

?$B000 [[RETURN]

}}}

?$B000 [[RETURN]

At line 149 removed one line

{{{

At line 151 changed 2 lines

}}}

At line 157 removed one line

At line 159 removed one line

At line 178 removed one line

At line 180 removed one line

At line 185 removed one line

At line 187 removed one line

At line 192 removed one line

At line 194 removed one line

At line 205 removed one line

At line 207 removed one line

At line 216 removed one line

At line 218 removed one line

At line 228 removed one line

At line 230 removed one line

At line 243 removed one line

At line 245 removed one line

At line 250 removed one line

At line 252 removed one line

At line 260 removed one line

At line 262 removed one line

At line 283 removed one line

At line 285 removed one line

At line 295 removed one line

At line 297 removed one line

At line 302 removed one line

At line 304 removed one line

At line 309 removed one line

At line 311 removed one line

At line 316 removed one line

At line 318 removed one line

At line 323 removed one line

At line 325 removed one line

At line 353 removed one line

At line 355 removed one line

At line 366 removed one line

At line 368 removed one line

At line 380 removed one line

At line 382 removed one line

At line 395 removed one line

At line 397 removed one line

At line 407 removed one line

At line 409 removed one line

At line 418 removed one line

At line 420 removed one line

At line 428 removed one line

At line 430 removed one line

At line 432 removed 415 lines

!!P3. BUGS IN THE ACTION! RUNTIME LIBRARY

We have found a few bugs in the original version(s) of the RunTime Library Disk. Fortunately, they are all easy to fix. (The RunTime library is independent of the cartridge, so bugs affect all versions.)

In the fixes given below, the portion to be changed (to implement the fix) is underlined. The rest of the line remains the same. To make the fixes, simply load the library file containing the affected PROCedure, edit, and save it back to disk.

!1. Hex numbers are printed incorrectly by PrintH and the %H parameter of PrintF.

Fix: Change second line of CCIO:

{{{

PROC CCIO=*()

[$A386$A0A$A0A$AA$A3A5$9D$342 ...

--- ---

}}}

!2. PrintBDE can cause a spurious compile time error.

Fix: Change first line of PrintBDE:

{{{

PROC PrintBDE =*(BYTE d,n)[$A0$0]

}}}

!3. A minor error exists in ChkErr.

Fix: Change second line of ChkErr:

{{{

PROC ChkErr=*(BYTE r,b,eC)

[$1610$88C0$8F0

$98$80C0$12F0 ...

---

}}}

!4. If your program redefines a

library procedure (e.g., one

which declares its own version of

PROC Graphics), it will compile

with no errors using the

cartridge only (because declared

procedures take precedence over

built-in ones). However, since

the RunTime library uses this

same precedence trick to include

its own definitions of library

procedures, your program will

generate Error 6 (doubly defined

name) if you do not delete the

appropriate PROCedure (or

FUNCtion) from the RunTime

library before INCLUDEing it.

Fix: Make a custom version of

the RunTime library on a COPY

(please, only on a copy) of your

RunTime disk which does not

contain the routines you wish to

replace.

5. On page 17 of the Reference Guide

for the Runtime Package, the

DEFINE for ROM will cause

incorrect code if you use local

variables.

Fix: Use the following form of

definition, instead:

{{{

DEFINE ROM = "BYTE ZZQQJUNK

-------------

SET $680 = $E^

SET $B5 = $5800

SET $E = $682^"

}}}

!!P4. PROBLEMS WITH Programmer's Aid Disk

We will list the problems (and solutions) regarding the Programmer's Aid Disk (PAD) here in reasonably compact form.

!1. BGET/BPUT PROBLEMS

The BGet and BPut routines in the IO.ACT file do not work properly under certain conditions. To fix this bug, replace the BGet and BPut routines with the following ACTION! code:

{{{

;********************************

;Burst (Block) I/O routines to do

;quick disk I/O, utilizing a call

;to CIO

;********************************

PROC CIO=$E456( BYTE areg, xreg )

;********************************

CARD FUNC Burst( BYTE chan, mode,

CARD addr, buflen )

TYPE IOCB=[BYTE id,num,cmd,stat

CARD badr,padr,blen

BYTE a1,a2,a3,

a4,a5,a6]

IOCB POINTER iptr

chan ==& $07

iptr = $340+(chan LSH 4)

iptr.cmd = mode

iptr.blen = buflen

iptr.badr = addr

CIO( 0, chan LSH 4 )

RETURN( iptr.blen )

;********************************

CARD FUNC BGet( BYTE chan,

CARD addr, len )

CARD temp

temp = Burst(chan,7,addr,len)

RETURN( temp )

;********************************

PROC BPut(BYTE chan,

CARD addr,len)

Burst( chan, 11, addr, len )

RETURN

}}}

!2. PRINTF

The PRINTF routine has a bug which was reported and fixed in the Spring, 1984 newsletter. In the file PRINTF.ACT, use the ACTION! editor to find

{{{

args ==+ s

}}}

and change it to

{{{

args ==+ 2

}}}

!3. PLAYER/MISSILE GRAPHICS

Because S: uses some memory just below the display list (undocumented), our method of finding the base address for Player/Missile Graphics needs a slight revision. Use the ACTION! editor with the file PMG.ACT to find

{{{

PM_BaseAdr=(HiMem-

PM_MemSize(mode))

&PM_AdrMask(mode)

}}}

and change it to

{{{

PM_BaseAdr=(HiMem-

PM_MemSize(mode)-$80)

&PM_AdrMask(mode)

}}}

!4. PMMove

If you use the PMMove procedure and specify a vertical movement of zero, the horizontal movement does not take place (it should). To fix this, change the lines in PMG.ACT which read

{{{

IF deltay=0 THEN

RETURN ; do nothing

}}}

to the following:

{{{

IF deltay=0 THEN

; do horizontal anyway

PMHpos(n)=x

RETURN

}}}

!5. PLAYER/MISSILE GRAPHICS

The documentation for PMG.ACT states that you may read the contents of PMHpos to find the horizontal position of a player or missile. This is simply not true. PMHpos is a set of write-only hardware registers. (Note that in the ToolKit we have added a shadow array and changed the name of the hardware registers, so this works correctly. If you wish, you could consider doing something similar on your PAD.)

!6. REAL NUMBER ROUTINES

There are two discrepancies in PROCedure names in the REAL.ACT library as compared to the REAL.DOC documentation, as follow:

||Name in .DOC||Name in .ACT

|StrR|RealToStr

|ValR|StrToReal

We suggest that you change the source code in REAL.ACT to reflect the names given in the documentation (rather than vice versa), since this makes the names appear compatibile with the library's other number-string conversion routines.

!7. REAL NUMBER ROUTINES

In that same area, the routine RealToStr (or should that be StrR?) needs to change the line which reads ptr=LBuff to the following:

{{{

ptr=InBuff

}}}

!8. ALLOC.ACT

The free list pointer may not be set up properly. Also, when freeing a block, right adjacency is not handled properly if left adjacency has already been found. Fix these problems as follows:

In the PROCedure Free, after the line reading:

{{{

last.size==+nBytes

}}}

insert the line:

{{{

target=last

}}}

Also, in the same procedure, change the line reading:

{{{

IF target+nBytes=current THEN

}}}

to read:

{{{

IF target+target.size

=current THEN

}}}

In the PROCedure AllocInit, replace the line reading:

{{{

FreeList.next=p

}}}

with the following lines:

{{{

FreeList=p

p==+4

FreeList.next=p

}}}

!!P5. TOOLKIT TROUBLES

It's hard to believe that a product as new as the ACTION! ToolKit can already have bug reports. Sigh. Anyway, there are already three versions of the ToolKit. Version 1 has 31 free sectors (when you list its directory). Version 2 has fewer free sectors and the second line of the file MUSIC.DEM reads ";Version 2". On version 3, the file ABS.ACT starts with the version number. This last convention will be followed in future versions. The comments here are organized by affected version(s).

!VERSION 1 ONLY

!1. I/O ROUTINES

The manual describes a routine called Format (in the IO.ACT library), but no such procedure exists on the disk. However, the routine is there--it's just called Init instead. You should change your disk to match your manual.

!2. MUSIC.DEM

The program called MUSIC.DEM will not work as is on older 400/800 machines. This is because it uses a call to Graphics(15), which is only available on XL machines. You may change the program to use Graphics(8) with no effect except that the true colors of mode 15 become artifact colors in mode 8 instead.

!VERSIONS 1 AND 2

!1. REAL ROUTINES

There are two discrepancies in PROCedure names in the REAL.ACT library as compared to the REAL.DOC documentation, as follow:

||Name in .DOC||Name in .ACT

|StrR|RealToStr

|ValR|StrToReal

!2. SORT ROUTINES

There are four discrepancies in PROCecure names in the SORT.ACT library as compared to the SORT.ACT documentation, as follows:

||Name in .DOC||Name in .ACT

|SortB|BSort

|SortC|CSort

|SortI|ISort

|SortS|SSort

Please change your disk file to agree with your manual.

!3. PRINTF

The PRINTF routine has a bug which was reported and fixed in the Sprint, 1984 newsletter. In the file PRINTF.ACT, use the ACTION! editor to find

{{{

args ==+ s

}}}

and change it to

{{{

args ==+ 2

}}}

!VERSIONS 1, 2, AND 3.

!1. ALLOC ROUTINES

The manual indicates that the procedure AllocInit requires that you pass it the address of the first free byte of memory (because Alloc "dispenses" memory from the first free byte through the top of memory, as correctly described in the manual). However, since you MUST follow the procedure described in the introduction to ALLOCATE.ACT (that is, you must declare in your program a CARD called EndProg and use the command

{{{

SET EndProg=*

}}}

after compiling), the parameter to AllocInit is not really needed and so has been eliminated. (AllocInit uses EndProg just as Alloc does.) If you pass a parameter to AllocInit, it will be ignored.

!2. WARP.DEM

No mention is made in the Toolkit manual that this file can only be run when compiled from disk (unless you are using DOS XL to gain extra memory). WARP.DEM is just too big for ACTION! to hold both the source and object in memory at one time.

!3. ALLOCATE.ACT

The free list pointer may not be set up properly. Also, when freeing a block, right adjacency is not handled properly if left adjacency has already been found. Fix these problems as follows:

In the PROCedure Free, after the line reading:

{{{

last.size==+nBytes

}}}

insert the line:

{{{

target=last

}}}

Also, in the same procedure, change the line reading:

{{{

IF target+nBytes=current THEN

}}}

to read:

{{{

IF target+target.size

=current THEN

}}}

In the PROCedure AllocInit, replace the line reading:

{{{

p=EndProg

}}}

with the following lines:

{{{

FreeList=EndProg

p=EndProg+4

}}}

!!P6. ACTION MANUAL ERRATA

First of all, you need to know which version of the manual you have. If Part III is the Language, then you have the first version of the manual. Otherwise, you have the second (newest) version. Unfortunately, both manuals contain content as well as typographical errors. We'll skip the typos and concentrate on the content errors, since typos don't impair your understanding of the language (although you may wonder where we learned to spell).

!VERSION 1 ERRATA:

PAGE ERROR

2 In the last paragraph, it says that the library is on the disk. This is not true. It's in your cartridge.

23 Under the description of <BACK-S>, the comparison with the Atari screen editor is exactly reversed. If you are in REPLACE mode, this key works as in the Atari editor.

26 Under <CTRL><SHIFT>T, it says you may not use lower-case characters as tags. This is untrue.

48 In the NOTE preceeding 4.3, you should add "The *, /, and MOD operators result in an implied INT type. For this reason, multiplication, division, and modulus of large CARD numbers does not always work properly."

49 Section 4.4 says that you may only have one special operator in a complex relational expression. This is untrue.

For example, the following is perfectly legal:

(x=7 AND y#10) OR z<100

82 Section 6.2.3 implies that you may not use a function as a procedure. This is not true. You may call a function as though it were a procedure, but the value returned from the function is ignored.

97 Section 8.1.1 states that you may either initialize a POINTER to an address or give it a value. Only the second is possible, and you should use this form:

BYTE POINTER x=<value>

Not this:

BYTE POINTER x=[[<value>]

99 In example #1 there are two PrintF statements which have "ptr" as one parameter. These should be "bptr", not "ptr".

101 In the last example of ARRAY declaration (BYTE ARRAY tests(5)...), the dimension is overruled by the initialization options, and so its dimension is only three. To fill only the first 3 of 5 elements, do the following:

BYTE ARRAY tests(5)=[[4 7 18 0 0]

104 In example #3 you see the program line "PrintE(b)". This should read "PrintE(barray)".

108 Section 8.3.1.2 states that you can initialize the fields of a record when you declare it. This is untrue; you may only initialize its address.

110 The program line "rec.level = InputB()" should read "rec.level = GetD(7)".

112 Same as previous error.

115 Same as previous error.

112 The program line "continue=InputB()" should read "continue=GetD(7)"

120 The program line "mode=InputB()" should read "mode=GetD(7)", and the program line "PrintE(name)" should read "PrintE(nameptr)".

115 Same as previous error.

122 The program line "incctr=chgclr" should read "incclr=chgclr".

142 Section 5.3 states that you should not use channel 7. ACTION! uses this channel to get characters from the keyboard, and you may use it to do this also. However, don't close this channel or alter its configuration in any way.

153 The example of declaring an ACTION! procedure at an address is wrong! If you do this, the internal pointer to the procedure will point to the specified address, but the code generated by the procedure will not be there. Instead, it will be in with your main code. Use procedure and function addressing ONLY to call machine language routines.

161 Where the table of contents lists the routines in section 2.3, it should read:

PrintBD NOT PrintDB

PrintCD NOT PrintDC

PrintID NOT PrintDI

162 Where the table of contents lists the routines in sections 6.7 and 6.8, it should read:

PeekC NOT CPeek

PokeC NOT CPoke

165 Error in section 2.3. See changes for pg. 161 and make similar corrections.

179 Section 6.4 states some information concerning the results of misusing the SCopy routine, detailing that the routine does string trucation, etc., to make the procedure work. This is not true. You must make sure that the strings are compatible in size.

181 Section 6.8 states that the parameters to Poke and PokeC consist only of an address. Instead, they consist of an address and a value, as follows:

Poke(<address>,<BYTE value>)

PokeC(<address>,<CARD value>)

182 Section 6.11. MoveBlock will move a maximum block of 256 bytes in versions 3.0 to 3.4 of ACTION! Versions 3.5 and up will move any number of bytes.

191 Some error numbers are wrong. The corrections are:

14 Out of Space

15 Missing DO

19 Missing OD

24 Illegal FOR statement

26 Nesting Too Deep

27 Illegal TYPE reference

28 Illegal RETURN

128 BREAK key abort

Also, error 62 is error 61, and 54 & 56 do not exist.

197 In the PrintF statement, %D should be changed to %U.

!VERSION 2 ERRATA:

PAGE ERROR

38 Section 2.7, paragraph 3. The last sentence states that you can RUN compiled ACTION! programs from disk. This is untrue. The RUN command will only compile and run ACTION! source files. Use DOS to run compiled object files.

39 The last RUN example (RUN PrintE()) will not work, since RUN expects a file name. Use the "Xecute" command instead.

63 In the TECHNICAL NOTE preceeding section 4.3, "*" should be changed to "*, /, or MOD".

126 The last assignment on the page makes newrecord point to the current record in the array, not the end of the array.

132 The program line "mode=InputB()" should be changed to "mode=GetD(7)".

138 The program line "IF sub(1)=str(ctr)" should read "IF sub(1)=str(ctrl)".

163 The PutDE procedure requires only a channel as a parameter, and does not put out both a character and a <RETURN>. Rather, it puts out a <RETURN> only.

172 In graphics mode 0 and all text windows, color 1 is the character luminance, color 2 is the background color, and color 3 is unused.

174 In section 5.6, references to the "lower right corner" should instead be "lower left corner".

180 Section 6.1.2 states some information concerning the results of misusing the SCopy routine, detailing that the routine does string truncating, etc. This is not true. You must make sure that the strings are compatible in size.

182 Section 6.11. MoveBlock will move a maximum block of 256 bytes in versions 3.0 to 3.4 of ACTION! Versions 3.5 and up will move any number of bytes.

!ACTION OBJECT CODE RELOCATION PROGRAM

The program SIMPLREL.ACT on this BBS may be used to cause an ACTION! program to load and run at a different address than that address at which it was compiled. The same program will also work for assembly language object files, providing you also follow the given instructions.

The program takes two object files as input and produces a third file which will load and run at a desired address. The relocating program prompts the user for the two input files, which must have been compiled one page (256 bytes) apart. It then prompts for an output file name (the relocated file), the page number of the starting address of the first file, and the page number of the desired destination address. Both page numbers must be decimal values. For example, specifying 32 as the destination page will cause the output file to load at address 32*256 ($2000), not $3200. See part V, "The ACTION! Compiler", chapter 2, page 144, for information on compiling programs to a specified address (Used to compile the two object files one page apart).

In order to use the relocating program, download SIMPLEREL.ACT and read the instructions therein.

This page (revision-9) was last changed on 03-Feb-2023 15:21 by Gromit Top

Articles

FAQ

Index