Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Archive » net.micro.apple » Bug fixes in Pascal 1.2 - (nf)
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Bug fixes in Pascal 1.2 - (nf) [message #72495] Sat, 25 May 2013 10:27
muller is currently offline  muller
Messages: 11
Registered: May 2013
Karma: 0
Junior Member
Message-ID: <1729@inmet.UUCP>
Date: Thu, 23-Aug-84 00:46:15 EDT
Article-I.D.: inmet.1729
Posted: Thu Aug 23 00:46:15 1984
Date-Received: Sat, 25-Aug-84 02:33:52 EDT
Lines: 139

#N:inmet:17900030:000:8149
inmet!muller    Aug 21 15:29:00 1984

**
Someone had asked about bug fixes in Apple Pascal 1.2...

 > From the Apple Pascal 1.2 Update Manual, Appendix A:
I. Compiler bugs
  1) Regular units using (*$R segname*) or (*$R unitname*) are now
     linked properly.
  2) if Compiler Resident option ($R) was used on intrinsic unit which had a
     data segment, the code was loaded first, so the datahad wrong addresses.
     Now the data is loaded first.
  3) Exit(procedurename) didn't work if the procedure was a regular unit with
     number > 127.  Now it works.
  4) Initializations in nested units were executed in reverse order.  Now the
     order is correct.
  5) If (*$R segname*) or (*$R unitname*) refered to a nonexistent segment or
     unit, no error message was given.  Now it is.
  6) If an intrinsic unit had the same segment number for code and data
     segments, the Compiler did not give an error message.  Now it does.
  7) The Compiler did not check for an empty data segment in an intrinsic unit.
     Now it does.
  8) Error message #350 (if an intrinsic unit needed a data segment but none
     was declared) was issued at the end of the initialization section.  Now
     it comes at the start of the implementation section.
  9) If a procedure was declared FORWARD but not defined, the error message
     did not stop compilation.  The error could therefore be overlooked unless
     the operator watched the screen closely (no codefile was created however).
     Now the compilation stops and the error message displayed.
 10) The Compiler could release heap symbol storage space too soon.  Not now.
 11) Negative long integers were treated incorrectly.  O.K. now.
 12) Compiler did not check for any constant string longer than 80.  Now it
     does.
 13) When a listing was turned of, the Compiler still issued a FormFeed when
     it saw a (*$P*).  Now it doesn't.
 14) Random errors could show up with identifiers that began with the letters
     H, J, K, Q, X, Y, or Z.  O.K. now.
 15) If several compiler options were issued in a single statement, the
     Compiler would ignore any that followed $S++.  Now it doesn't.
II. Assembler bugs
  1) .ALIGN was handled incorrectly.  O.K. now.
  2) If there were no symbols, the Assembler would print a garbage symbol
     table.  Now it doesn't.
  3) A fixup to a word that crossed buffer boundaries would destroy the byte
     following the end of the buffer.  Now it doesn't.
  4) The Assembler did not test for nested macros (illegal).  Now it does.
  5) An .ENDM without a corresponding .MACRO was not printed, and a wrong
     error ("undefined label") was issued.  O.K. now.
  6) The Assembler could overwrite SYSTEM.PASCAL if there were more than 10
     procedures.  Now it doesn't.
  7) .INTERP references were relocated incorrectly.  O.K. now.
  8) If an .INCLUDE statement had garbage after the filename, the file was
     not included.  Now it is after the error message is issued.
III. Linker bugs
  1) The Linker sometimes failed handle DEF's and REF's properly to see if
     the labels of two assembly routines matched.  Now it checks.
  2) Regular units could not use segments numbered 16...31.  Now they can.
IV. LIBRARY.CODE bug
  1) If a library file being built exceeded 200 blocks, the interface text
     sections were not copied into the file.  Now they are.
V. LIBMAP.CODE bug
  1) Interface text of units that started after block 200 in the library were
     not reported.  Now they are.
VI. SEEK/PUT bugs
  1) Dynamically extending a diskfile, by SEEKing past the last block and then
     PUTting, could overwrite the next file, if the next file started right
     after the previous one.  Now, if there is not enough space to PUT the 
     record, the PUT will get an IORESULT of 8, "no room".
  2) SEEKing a record number to expand a file, when there was room in the last
     block, resulted in a record being written after the former last record.
     Now the file expansion is tried first, and an IORESULT of 8 is issued
     if necessary.
  3) Seek went to the wrong place whenever it wanted a position between the 
     current EOF and the EOF at the time of the last RESET.  Now the correct
     block is used for the buffer and the pointer is positioned correctly.
  4) A SEEK to a large record number in a file with a large record size could
     take too much time.  This has been substantially reduced.
VII. I/O bugs
  1) If a driver was attached to a unit number 4...12, UNITREADs and UNITWRITEs
     would work okay, but file input or output by volume name might not.  Now
     it will.
  2) Floppy disk routines disabled interrupts, and left them that way.  Now
     they are re-enabled after disk routines are done.
  3) A WRITE of a null string did not set IORESULT properly if it was non-
     zero before.  Now it does.
  4) RESET or REWRITE on a DOS volume did not return an IORESULT error.  Now it
     gives a value of 10, i.e. "file not found".
VIII. Turtlegraphics bugs
  1) Parameter YSKIP in procedure DRAWBLOCK did not work.  Now it does.
  2) DRAWBLOCK did not work correctly if part extended outside the viewport.
     Now it does.
IX. Miscellaneous run-time bugs
  1) If (*$NR*) option refered to a unit that had an assembly procedure in
     its interface, and that procedure was called from outside the unit, the
     segment's memory was not released when the procedure terminated, thus 
     occupying memory unnecessarily.  If repeated calls were made to the
     procedure, memory could fill up with copies of that procedure's code.
     This memory is released properly now.
  2) Repeated Control-A's during compilation or disk i/o's could crash the
     system or causde bad disk writes.  Not now.
  3) If "ignore external terminal" flag was set with RTSETMODE, any card in
     slot 3 was initialized, even though it was not used.  Now it isn't.
  4) A random character could be written in the last position of a real number
     if the field was wide.  Not now.
  5) An error in a long integer computation caused the interpreter to go into
     a loop.  Now an error message is issued.
  6) There was no check for stack-overflow when intrinsic-unit data segments
     were loaded onto the stack.  Now there is.

Pascal 1.2 offers several enhancements to take advantage of the features of
the Apple //e.  It also has an enlarged error message set, an improved 
FORMATTER program, additional block volume units, a new operating system
swapping option, a "same volume name as executing program" prefix for
file names, and a new REMSTATUS procedure to poll I/O on slot 2.  Finally, 
it offers a "128k" system for machines with extra memory; this is obtained 
by replacing SYSTEM.APPLE and SYSTEM.PASCAL with new versions provided.  This 
space is used to hold p-code.  (Actually, the "language card" space in the 
aux.mem. is "reserved for future use" so it isn't really a full 128k ram 
system.)  There appears to be nothing lost by using this system at all times 
(this is what Apple says, too); there is no apparant increase in either 
running or compile time.  The 128k system allows some enhancements in library
file usage and it allows more segments, though they generally have to be from 
intrinsic units.

 > From the Addendum to the 1.2 manual, it appears that the bug which held up
distribution was that if the 80 character wide screen was used with the
editor, and a character was written into the last column in line 24, it could
damage the file.  Apple's solution was to recommend changing the MISCINFO file
to use only 79 columns on the screen.  The value apparantly could not be 
changed in the MISCINFO file for a //e, so they provided another MISCINFO file 
for the //e which uses 79 columns.  The obvious problem with this approach is
that some application programs might really want to use 80 columns, e.g. a
terminal emulator (?).  The solution seems to be to use the 80 col. MISCINFO
file on a startup disk intended for that program's execution, but to use the
79 col. MISCINFO file for any program development.

All in all, 1.2 seems to be a very nice package, and a real improvement over
1.1.   Have fun....          Jim Muller
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: apple keyboard hack
Next Topic: Need help to port sumacc to SUN
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 21:56:51 EDT 2024

Total time taken to generate the page: 0.02633 seconds