bryce@hoser.berkeley.edu (Bryce Nesbitt) (12/20/87)
[ Do you feel that "one-stop shopping" of technical notes and proclamations
would be worthwhile? Finding finding technical information from all the
scattered sources is a pain at best. This is an attempt to bring it all
together. Let me know how you like it]
********************************************************
*** AmigaLine, technical notes for Amiga programmers ***
*** ***
*** Intended as a direct, open channel to reach ***
*** anyone and everyone with an interest in ***
*** programming the Amiga. "Not sold in stores, ***
*** we only give them away". ***
*** ***
*** Currently unofficial, but I hope the Commodore ***
*** picks up on the idea. ***
*** ***
*** You are encouraged to anthologize and distribute ***
*** these notes anywhere and everywhere. ***
********************************************************
----------------------------------------------------------------------------
Technical Note #2
blitter software, minor change to low level blit routines
SUMMARY
$ 2/0 blitter software, minor change to low level blit routines
$ release
$ 4-Oct-87 Robert R. Burns / Commodore-Amiga, Inc.
$ text, blitter, graphics, BltBitMap(), BltTemplate(), speed
A change will be made to some of the low-level blit routines. Rather
that calulating the directions for each bitplane in turn, the calculation
will be done once.
----------------------------------------------------------------------------
Developer Folks:
I'm reviewing the grunt graphics.library blitting routines (i.e. BltBitMap
and BltTemplate) with an eye towards enhancing their speed as part of the
work I'm doing for Commodore to enhance the text code.
I'm considering making an assumption about how bit planes in BltBitMap are
organized that will allow me to reduce both calculation and hardware
register usage. Dale [Luck] and I agree that it's a reasonable assumption,
but I offer it to y'all for review so noone gets burned.
For background, remember that the source and destination of a blit are
related to one another in one of six ways. These six cases require
different blit directions and modulos (and in two of the cases, non-zero A
sources) to accomplish moving the source to the destination without
tromping on the source during the move.
Under 1.2 (<=V34), these cases were calculated for each bit plane
source/destination pair in the copy.
+----+ Thus, a BltBitMap that took a source
|s0 | +----+ that described two planes that were
| | |d0+----+ to be moved in different directions
| +----+ | |d1 | to the destination would be handled
+--|s1 | | | | correctly. (see visual aid)
| | +--| |
| | +----+ I conjecture that noone uses this
+----+ capability: that no uses of
BltBitMap distort a BitMap to do
an in-place copy in two different directions at once.
For 1.? (>V34), I propose to calculate the relationship between the source
and the destination once, and then cycle thru the bit planes. If you know
of a reason why I should not, please mail me a reply.
Bob Burns for Commodore-Amiga, Inc.
Kodiak Software
USENET: well!amiga!kodiak
BIX: kodiak
SEE ALSO
----------------------------------------------------------------------------
Technical Note #3
LoadWB, possible change for new versions of Kickstart
SUMMARY
$ 3/0 LoadWB, possible change for new versions of Kickstart
$ PRELIMINARY
$ 19-Dec-87 Nobody / Nothing
$ LoadWB, Workbench, ROM, copy-protection
There is not enough space in the ROMs for all the expansion that is
needed in new versions of Kickstart. 384 or 512K ROMS can be adapted to
all members of the Amiga family, but probably won't be at this time. There
is one module that can be easily moved from ROM to disk; Workbench.
Commodore-Amiga is seriously considering this step.
----------------------------------------------------------------------------
If Workbench is moved out of the ROMs, this will mean that the old
"LoadWB" command will be unable start Workbench. This is particularly
troublesome for bootable copy-protected products don't allow writing to
the master disk.
WHAT THE NEW LOADWB WOULD DO
The new LoadWB command would be distributed on the new Workbench disks.
It would be about 60K in length, and would contain the entire Workbench
tool. This LoadWB would probably also work in a V1.2 Kickstart
environment.
WHAT THE OLD LOADWB WOULD DO
The old LoadWB command is just a tiny stub that fires up the Workbench
tool in ROM. When this command is run under the new Kickstart there
will be no Workbench tool to fire up. What will probably happen is
Kickstart will post a requester that looks like this:
"Please insert a V1.X Workbench disk in any drive"
The new LoadWB would then be read in.
SOLUTIONS
* Make your disks writeable, so the new LoadWB can be copied over.
* Allow your users to boot up with some other Workbench, then open your
disk and double-click on the icon to start.
* Start your program directly from the Startup-Sequence and *then* have
a LoadWB. If the LoadWB fails, nothing much is lost.
SOLUTIONS FOR COPY-PROTECTED PROGRAMS
Obviously the ideal solution is for all bootable disks to be writeable.
Even if you insist on annoying users with copy-protection, you can
ensure that writing to the disk does no damage:
* Create a file on the disk called "copy protected sectors"
* Using a sector editor, link any sectors or tracks affected by the
protection into that file. Include in this list any sectors that
would be dangerous to write to.
* If your copy protection is on Track 81, ignore the above.
Don't worry that this will help pirates... they already have very easy
and effective ways of sniffing out the location of your protection
schemes. This information will be useless (or misleading, depending on
how many "Red-Herring" sectors you toss in :-).
The only beneficiaries of your caution will be your customers and your
reputation.
|\ /| . Ack! (NAK, SOH, EOT)
{o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (or try "cogsci")
(")
U "Your theory is crazy... but not crazy enought to be true." -Niels Bohr