
==========
amiga.com/software #888, from peabody, 661 chars, Mon Nov  6 02:35:23 1989
Comment to 887. Comment(s). More refs to 887.
----------
It's interesting that Music-X loses more bytes than serial.device does.
If anything I would have expected the opposite.

Perhaps we should start the chant now... Super Paula!  Super Paula!
(or some other way to add a 3 byte FIFO for serial receiver)

There's bound to be some system overhead for interrupts.  The CIA
processing for example has 4 or 5 vectors for each interrupt (I think)
so some polling has to go on in this handler.  Also CIAB has a higher
priority that RBF which can cause grief.  (why oh why didn't they
leave us with a low prioirty CIA to play with?).  For what it
worth, have you tried polling the serial hardware during your CIA handler?
Rf:
==========
amiga.com/software #889, from langeveld, 474 chars, Mon Nov  6 02:57:56 1989
Comment to 888. Comment(s). More refs to 888.
----------
	The hardware manual says that the serial device at higher baud
rates it is no longer possible to handle the overhead of interupts. "The
receiving end will have to be in a tight read loop".
	Do you think it might be possible to change the serial.device such
that at 19.2k and higher it no longer uses interrupts? I have no idea
what I'm talking about, but I think that even the implied busy-wait
would be okay, assuming task-switching could still occur normally...

	Willy.
Rf:
==========
amiga.com/software #892, from talin, 161 chars, Mon Nov  6 05:44:28 1989
Comment to 889. Comment(s).
----------
   What I have is an interrupt that goes into a tight read loop if another
byte is pending; that helped slightly. When no bytes pending, then leave
int handler.
Rf:
==========
amiga.com/software #897, from checkpoint, 190 chars, Mon Nov  6 22:49:32 1989
Comment to 892.
----------
You might consider sticking around for a few more tries, in a CPU loop,
even when there are no bytes pending. Say 30 or so, or maybe for one
scan line's worth (look for 2 changes in VPOSR).
Rf:
==========
amiga.com/software #891, from talin, 364 chars, Mon Nov  6 05:42:35 1989
Comment to 888. Comment(s). More refs to 888.
----------
   No, I haven't tried polling the serial handler during CIA, but that's
so ugly, and I can only think of two approaches, both won't work...
   1. Handle the byte inside the CIA. Hideous locking problems, because
my buffer pointers might be in RBF registers during CIA interrupt.
   2. Cause an RBF inside the CIA. No help -- by that time, RBF is already
pending.
Rf:
==========
amiga.com/software #895, from peabody, 179 chars, Mon Nov  6 21:50:51 1989
Comment to 891.
----------
You could always bump the SR interrupt level bits down to enable lower
level interrupts while processing the CIA.  Not terribly polite, or safe,
but it might be interesting hack.
Rf:
==========
amiga.com/software #896, from checkpoint, 196 chars, Mon Nov  6 22:47:33 1989
Comment to 888. Comment(s).
----------
"Super Paula! Super Paula!"
   16 byte serial FIFO
   Parity checking in hardware
   DIsk controller to support 1.44 (1.6!) Meg floppies
   Avail 1Q 1990

(No, it's just me, wishing out loud. :-)
Rf:
==========
amiga.com/software #900, from checkpoint, 46 chars, Mon Nov  6 23:24:11 1989
Comment to 896. More refs to 896.
----------
(Oh, how could I forget) 12 and 16 bit audio!
Rf:
==========
amiga.com/software #904, from sirnetics, 96 chars, Tue Nov  7 02:45:35 1989
Comment to 896.
----------
Our serial board has 16 byte FIFOs....	Now if I can just get it to
market....  ::sigh::

-Jeff
Rf:
==========
amiga.com/software #890, from asdg, 222 chars, Mon Nov	6 03:52:16 1989
Comment to 887. Comment(s).
----------
Well, you should have no trouble using your interrupt-driven approach if you
disable all other interrupts. :-)
Try this, David -- Disable the VERTB interrupt and see if you still get
overruns. I'll bet you don't.

- Aaron
Rf:
==========
amiga.com/software #893, from talin, 172 chars, Mon Nov  6 05:46:20 1989
Comment to 890. Comment(s).
----------
    I'll try the VERTB thing. In fact, I'll also try installing various
VERTB handlers that end the chain at various priorities.
    (And thanks for your support.... :-) )
Rf:
==========
amiga.com/software #894, from langeveld, 250 chars, Mon Nov  6 14:54:28 1989
Comment to 893. Comment(s). More refs to 893.
----------
	Is there any way to change the priorities of interrupts? Like, could
the serial interrupt be made to have higher priority than everything else?
(maybe it would give some funky displays if it were higher than bitmap
DMA, but what he heck.).

	Willy.
Rf:
==========
amiga.com/software #899, from asdg, 466 chars, Mon Nov	6 23:17:07 1989
Comment to 894.
----------
No way to adjust the interrupt priorities. That's hardware.
The serial receive interrupt already has a pretty high priority. It's
second only to the INT6 external (expansion slot) interrupt, and one of the
two CIA (8520) chips.

The real problem here is that Disable() will still lock out the interrupt,
and it's still done far too much in normal system operation. Some of the
lower priority interrupts also Disable(), notably VERTB, thus causing
problems.

- Aaron
Rf:
==========
amiga.com/software #898, from asdg, 138 chars, Mon Nov	6 23:12:35 1989
Comment to 893. Comment(s).
----------
Also, what are you using a CIA interrupt for, and which level? I assume it's
the level 6 CIA, since you're having such problems.

- Aaron
Rf:
==========
amiga.com/software #901, from talin, 562 chars, Tue Nov  7 00:41:47 1989
Comment to 898. Comment(s).
----------
   Well, the only way to accurate timing with the Amiga is with the CIA,
and under the rules the only CIA available is the level 6 one. Sorry,
VBLANK is simply inadequate for professional timing applications. I've
studied the market somewhat, and it looks like you have to get 5 ms or
better resolution if you want to be taken seriously. Unfortunately, VBL
is 16 ms, way to big. (I know one guy who claims he can hear 3 ms differences,
though I certainly can't -- Though it also depends heavily on the rythmic
context which the differences are taking place in).
Rf:
==========
amiga.com/software #903, from talin, 297 chars, Tue Nov  7 00:48:25 1989
Comment to 901. Comment(s).
----------
   Also, I noticed today (only tried it once, though) that I seem to
get less errors under 1.4 than 1.3. (for a 25K MIDI Sysex dump, I
got 15 as opposed to 30 -- of course, when my CIA interrupt is actually
doing real work, (I.e. calling Cause() instead of jumping over it),
I get ca. 145 errors.
Rf:
==========
amiga.com/software #905, from asdg, 432 chars, Wed Nov	8 20:48:58 1989
Comment to 903. Comment(s).
----------
How many CIA interrupts/sec are you making? Also, that Cause() could
possibly create more trouble than Signal() would. Maybe not.

Is there any way you can do your timing by polling a counter? It sounds
like you're just overloading the system with interrupts, and perhaps not
getting out of your CIA server fast enough. Heck, the CIA system overhead
is pretty massive; that's probably causing missed characters on its own.

- Aaron
Rf:
==========
amiga.com/software #906, from talin, 541 chars, Thu Nov  9 03:35:30 1989
Comment to 905.
----------
    Well, with 16 CIA interrupt per video frame, it's pretty lousy,
with 4 per frame it's about twice as good, and with CIA turned off,
it's significantly better but still nowhere near error-free.
    Ken suggested that everytime I get an error, I should look on
the stack to see who got interrupted, and store that address in a
table. When I look at the table, if one address appears a lot of times,
and the few instructions before that address are an Enable(), then
I will have caught the culprit red-handed. (That's Ken as in kenjordan).
Rf:
No further comments #887. Reading next unread.
==========
amiga.com/software #902, from talin, 440 chars, Tue Nov  7 00:45:09 1989
----------
TITLE: Also, could someone please answer my earlier question about
SetICR()?? On page 97 of Guru's Guide there is a SetICR() call in the
CIA interrupt server. However, mine doesn't have that call, and still
runs like clockwork. My assumption is that the CIA server master is doing
a SetICR internally already, and to have one in the interrupt server
itself is redundant. Can anybody tell me different? And if so, what would
the effects be?
No more unread
Hit <RETURN> for next
Rf:


Checking for conference activity.
Joining amiga.com/software 53 new messages.
Rf:
==========
amiga.com/software #907, from rjesup, 48 chars, Tue Nov 14 00:40:19 1989
Comment to 906. Comment(s).
----------
Good Trick!  Have you tried it yet???

	Randell
Rf:cur to la
==========
amiga.com/software #908, from talin, 219 chars, Tue Nov 14 01:55:33 1989
Comment to 907. More refs to 907.
----------
   Huh? I'm confused...
   I DID try it, and I posted a long message right here all about it,
except now that I look, there's no message! Must have done something wrong.
(Ack -- no wonder there were no replies....!!!!)

==========
amiga.com/software #909, from talin, 2712 chars, Tue Nov 14 01:57:23 1989
Comment(s).
----------
TITLE: ]More on Serial Overruns....
Here's the results of a little test I did, and the results are
very interesting.

Base Assumption: The reason the RBF interrupt is getting overruns is because
it is not getting serviced in time, due to the fact that interrupts are being
disabled by some other program. When interrupts are re-enabled, an RBF
interrupt will immediately occur. This will cause the address of the
instruction imediately after the enable to be placed on the system stack.

Procedure: I wrote an RBF routine which would:

    1. Get the serial data from SERDATR.
    2. Check the overrun bit.
    3. If the overrun bit was set, look on the stack to find the
	return address. Note it is neccessary to skip over the registers
	saved on the stack by the system master interrupt handler.
	Then record this address in a buffer.
    4. Call my normal Music-X RBF handler.
    5. Check to see if there is another byte in SERDATR.
    6. If so, then go back to step 2.
    7. Return from interrupt handler.

System: I ran this on a stock A1000 with Kickstart 1.3, 512 chip + 512K fast,
 with no special software installed. I ran the above program, and sent about
 400K of MIDI data to the A1000 using a standard MIDI interface (Mimetics).

Results: I have boiled down the results to the following table. There were 256
entries in the table, sorted by frequency.

Address:    Number of times occured:

00fe92d2    99
00fc44a0    64
00fe02d0    23
00fc0f42    17
00fc1f72    17
00fe940a    15
00fe941e    11
00fc5a78    6
00fe02e2    2
00215812    1
0021de0e    1
00fc0eba    1
00fc4ab8    1
00fc5a58    1
00fc5a6c    1
00fc7a9a    1
00fc7bb4    1
00fc7bee    1
00fc7c08    1
00fc7c3c    1
00fc7cac    1
00fe5f6e    1

    - Note that all but two of the occurances were in the ROMs.
    - Note that one entry, fe92d2, occured more than one-third of the
	time. The actual code for that address looks like this:

	    fe92c2	       subq.b  #1,126(a0)     ; <-- check IDNestCnt
	    fe92c6	       bge.s   fe92d0	      ; <-- skip if nested
	    fe92c8	       move.w  #-4000,dff09a  ; <-- enable()
	    fe92d0	       movea.l (a7)+,a3
	    fe92d2	       rts		      ; <-- entry in table

At this point, I can't go too much further. I have no intention of
dissembling the ROMs to find out what these particular Disables() are for
and how to work around them. Ione would like to inform me what exactly
these routines are doing, perhaps we can come up with a solution.

Could someone please respond ASAP. I'm under pressure to deliver the final
version of Music-X Jr, and it's basically waiting on this issue.

==========
amiga.com/software #910, from talin, 339 chars, Tue Nov 14 01:59:03 1989
Comment to 907. Comment(s).
----------
   The previous message was the one I THOUGHT I had posted. Anyway, I
hope you guys can figure it out.
   Also, I'm pretty sure that one of those addresses is for the actual
library vector Enable(). I'll have to modify my routine to look further
back on the stack in that particular case to see which program was
calling the exec library.

==========
amiga.com/software #911, from jmccormick, 644 chars, Tue Nov 14 02:04:25 1989
Comment to 910. Comment(s).
----------
You could SetFunction() Enable()/Disable() on the fly...(ack, no, please
I was only *kidding*!!! 8-)
In my limited research, it appeared that anything over 19,200 baud was
in dangecausing serial overruns.  At 100Kbaud, just moving the
mouse around is enough to cause the buffer to start falling behind, and
it never seems to make up for lost time.  I can easily imagine that
even at 31Kbaud, you could start falling behind in a multitasking
intensive environment.	Short of using a Twin-X board or writing your
software like a "take over the machine" game, I don't see how you
can win this battle quickly.

    Thoughtfully,
       Justin

==========
amiga.com/software #912, from talin, 295 chars, Tue Nov 14 02:07:30 1989
Comment to 911. Comment(s).
----------
   SetFunctioning Enable() & Disable() wouldn't helway -- Have you
ever looked at the assembly language definitions of enable/disable in the
include files? It's a macro. Nothing to setfunction. Sure, C programs call
the exec library which can be setfunctioned, but no assembly programs do.

==========
amiga.com/software #913, from afinkel, 227 chars, Tue Nov 14 13:38:02 1989
Comment to 909. Comment(s).
----------
It's in the timer.  I'm not sure of a workaround.  Does it
help that its fixed in 1.4 ?

The number of disables is dependent on the number of timer
requests outstanding.

Maybe someone else can think of a workaround...

		andy

==========
amiga.com/software #914, from gary_samad, 169 chars, Tue Nov 14 16:54:12 1989
Comment to 912. Comment(s).
----------
What?  Is this true?  So much for VM.  It seems to me that Enable() and
Disable() are two functions that would perform differently in a more
complicated world...

	Gary

==========
amiga.com/software #915, from afinkel, 144 chars, Tue Nov 14 20:13:38 1989
Comment to 914. Comment(s).
----------
It makes it more difficult certainly; not impossible.  It's those
assembly programmers again, doing anything that shaves off 2 cycles.

			andy

==========
amiga.com/software #916, from peabody, 129 chars, Wed Nov 15 03:34:17 1989
Comment to 913. Comment(s). More refs to 913.
----------
Gee... if I get a version of Music-X that uses CIAB, I'll be happy
to try it out under 1.4 in our studio (we have a 1000 there).

==========
amiga.com/software #917, from gary_samad, 15 chars, Wed Nov 15 13:12:07 1989
Comment to 915. Comment(s). More refs to 915.
----------
Jab, jab!  :-)

==========
amiga.com/software #918, from afinkel, 59 chars, Wed Nov 15 21:30:40 1989
Comment to 917. Comment(s).
----------
If I keep it up, maybe they'll stop doing it!  :-)

		andy

==========
amiga.com/software #919, from whowe, 101 chars, Thu Nov 16 00:52:10 1989
Comment to 918. Comment(s). Moreto 918.
----------
Where did the macros for Forbid/Disable come from in the first place?
     [poke, poke]
   <* Wes *>

==========
amiga.com/software #920, from talin, 64 chars, Thu Nov 16 01:40:42 1989
Comment to 916.
----------
   If you have Music-X 1.03, you have a version that uses CIAB.

==========
amiga.com/software #921, from talin, 57 chars, Thu Nov 16 01:41:24 1989
Comment to 919. Comment(s). More refs to 919.
----------
   Actually, Forbid() is not a macro. Only Disable() is.

==========
amiga.com/software #922, from cheath, 103 chars, Thu Nov 16 03:04:27 1989
Comment to 915.
----------
Gee, but if you didn't want asm programmer susing inline Enable/Disable,
why's it provided as a macro?

==========
amiga.com/software #923, from cheath, 40 chars, Thu Nov 16 03:05:18 1989
Comment to 921.
----------
Forbid() is macroable; Permit() is not.

==========
amiga.com/software #924, from afinkel, 52 chars, Thu Nov 16 19:02:46 1989
Comment to 919.
----------
Those assembler people are everywhere!	:-)

		andy

==========
amiga.com/software #925, from rjesup, 814 chars, Wed Nov 22 00:00:10 1989
Comment to 913. Comment(s).
----------
An amplification of Andy's comment: the _length_ of the disables is proportional
to the number of requests outstanding.	Usually, each floppy unit has one, and
various other things have requests active at times.  Note that this only
applies to the MicroHertz timer.  In fact, I think it's doing multiplies and
divides in the interrupt handler.

Best I can say is use fewer disk drives, have a faster processor (even an '010
might help here because of faster mult/div), etc.  If you wanted to do a _lot_
of work, you could write a more efficient version of timer.device, or some
such.  Sorry.

BTW, I suspect Bryce would be quite interested in this tool of yours for 1.4
system tuning to make sure we've nailed as many of these as possible (timer has
been hit already, but there are others on that list).

	Randell

==========
amiga.com/software #926, from talin, 558 chars, Wed Nov 22 06:28:21 1989
Comment to 925. Comment(s).
----------
  Well, I'll be glad to set up the tool for you, although right now it's
buried inside of Music-X. (That's fine - I can give you a special version
of Music-X which saved the enable address in an internal table -- to
find the address of the table, you get a debugger and look at execbase,
find the RBF code vector, trace through a couple of instructions...
I know it's not simple, but it was hacked together in about 1/2 an hour.
Of course, it would help if you guys had a MIDI instrument lying around
that could pump a bunch of data into the serial port...)

==========
amiga.com/software #927, from peabody, 72 chars, Wed Nov 22 06:45:41 1989
Comment to 926. Comment(s).
----------
Just another amiga running Music-X would suffice for a MIDI instrument.

==========
amiga.com/software #928, from talin, 271 chars, Wed Nov 22 06:52:56 1989
Comment to 927. Comment(s).
----------
   Yes, you could use Music-X as a serial source, but that would not
be as rigid a test. 1) You want to send the data as fast and as evenly
as possible, and 2) It's not as easy to set up Music-X to dump library
data as it is to hit the "data transfer" button on a synth.

==========
amiga.com/software #929, from rjesup, 97 chars, Wed Nov 22 17:45:51 1989
Comment to 928. More refs to 928.
----------
I think we have a few Midi intruments around here (Kevin Klop has some in his
office).

	Randell

==========
amiga.com/software #930, from peabody, 84 chars, Thu Nov 23 14:20:04 1989
Comment to 928.
----------
I was thinking perhaps of just looping a dense sequence (like full of
Pitch bends).

==========
amiga.com/software #931, from hazy, 369 chars, Tue Nov 28 02:26:25 1989
Comment to 918. Comment(s).
----------
They're obviously confused.  There's no reason for them to try
and shave a cycle or two like this.  If it doesn't run fast
enough, you obviously need faster hardware.  Once you get the
faster hardware, you make your problem more complex, such that
you need yet-again faster hardware.  This way, I look really
important at Commodore and keep getting big raises...
-Dave

==========
amiga.com/software #932, from whowe, 370 chars, Tue Nov 28 03:07:33 1989
Comment to 931. Comment(s).
----------
No, Dave, you have it backwards. First someone makes soemthing that runs
faster/better on the existing hardwareby shaving cycles, then everyone else
wants fast/better hardware to catch up without shaving cycles.
   I don't lose sleep over a few cycles on a lot of routines, but inside loops
I try to scrape away everything except the bare metal when I can.
   <* Wes :)

==========
amiga.com/software #933, from cheath, 171 chars, Tue Nov 28 03:12:46 1989
Comment to 932.
----------
Besides, it should be quite a challenge to do a multi-processor Disable()
in hardware when you notice that bit getting yanked.  That oughta be worth
a raise or two, Dave.

==========
amiga.com/software #934, from cheath, 123 chars, Thu Dec  7 17:16:51 1989
Comment(s).
----------
TITLE: GADGETID
Is there any reason in the system software why more than one gadget could
not use the same GADGETID value?

==========
amiga.com/software #935, from cheath, 369 chars, Thu Dec  7 17:19:05 1989
Comment(s).
----------
TITLE: Inheritance
There are lots of times/places where it would be nice if things like
keystrokes could be inherited, for instance when starting an application
to inherit any buffered key events from the initial console; when opening
new windows, to have the new window get unprocessed key events.  I don't
have any Great Ideas as to how this might be done, though...

==========
amiga.com/software #from mikeberro, 183 chars, Thu Dec	7 17:30:39 1989
Comment to 935.
----------
  I;ve thought about that too.	It wouldn't be difficult to do, but I don't know
a good way to make it friendly; i.e. optional.	In a lot of cases I don't
want it to happen.  ---Mike

==========
amiga.com/software #937, from jgerlachjr, 73 chars, Thu Dec  7 19:14:59 1989
Comment to 934. Comment(s).
----------
I think all Intuition's standard window gadgets use ID of zero... -JDGJr

==========
amiga.com/software #938, from jmackraz, 146 chars, Wed Dec 27 15:12:06 1989
Comment to 937.
----------
You can use the GadgetID field for whatever you want, with
*your* gadgets, but do not make assumptions about this field for
system gadgets.
	jimm

==========
amiga.com/software #939, from nicotra, 139 chars, Wed Dec 27 20:38:37 1989
Comment(s).
----------
TITLE: System Gadgets
Is there a system freindly way to create your own depth and close gadgets
and still have them managed by Intuition?


==========
amiga.com/software #940, from vertex, 120 chars, Wed Dec 27 22:18:56 1989
Comment to 939. Comment(s). More refs to 939.
----------
Just create normal gadgets, but set the gadget type field to those for
the standard system gadgets. Works like a charm.

==========
amiga.com/software #941, from talin, 1313 chars, Thu Dec 28 05:18:01 1989
Comment(s).
----------
TITLE: Questions about Views...
    I need to know a little more detail about the mechanism of ViewPorts
and their associated copperlists. For example, suppose I have a swatch
of code that looks like this:

    (assume there are several viewports already being displayed)

    (Now I change offsets, bitplanes, or add / remove ViewPorts)
    MakeVPort() (for each vport I changed)
    MrgCop()
    LoadView(), etc.

    Now, I assume that the makevport, mrgcop, etc. de-allocates the
old copper lists and creates new ones. But the harware DMA register
in the copper is still pointing to the old copper list. And LoadView
doesn't take effect until the next VBLANK. So unless you guys are doing
something tricky, like double-buffered copper lists, it means that
for part of a frame the copper would be riunning through unallocated
memory. Now, I know it's not doing this, but I can't find anything
in the View, ViewPort or GfxBase that looks like a double-buffered
copper list.
    I need this because I want to do some particular manipulations
with views (such as changing the number of bitplanes, resolution,
etc.) during different phases of a game, without disturbing other
viewports that may be visible. The current documentation I have doesn't
go into enough depth to let me know what's possible in this area.

==========
amiga.com/software #942, from vertex, 48 chars, Thu Dec 28 08:54:23 1989
Comment to 941. Comment(s).
----------
Perhaps LoadView is the one freeing the memory?

==========
amiga.com/software #943, from peabody, 93 chars, Thu Dec 28 20:52:46 1989
Comment to 940. Comment(s).
----------
Just remember to remove your custom depth, etc, gadgets before
closing the window.  or poof!

==========
amiga.com/software #944, from talin, 265 chars, Fri Dec 29 02:59:10 1989
Comment to 942. Comment(s).
----------
I thought that LoadView might be doing it, or rather the part of loadview
that occurs during vblank that reloads the copper pointers -- except
that you can't allocate and free memory in an interrupt. And there is
no "GfxBase" task for a vblank interrupt to signal.

==========
amiga.com/software #945, from jmackraz, 201 chars, Fri Dec 29 16:41:29 1989
Comment to 943. Comment(s).
----------
Actually, you should set the bits which say that it's a draggadget, and
so on, but not the SYSGADGET bit, which means that it's my
gadget.

Removing them before closing is a nice safety measure.
	jimm

==========
amiga.com/software #946, from jmackraz, 358 chars, Fri Dec 29 16:45:47 1989
Comment to 944.
----------
Intuition double-buffers the copper lists, actually, create new,
toss old, which is not always the nicest thing to do to a memory pool.

I think MrgCop *would* free the old, if you don't detach them first (
(null out the old cops in the view).  After MRgCop and LoadView,
there is a WaitTOF(), then the old copper lists are freed using
FreeCprList().

	jimm

==========
amiga.com/software #947, from peabody, 95 chars, Fri Dec 29 17:51:45 1989
Comment to 945. Comment(s).
----------
So that SYSGADGET bit isn't part of the function detection?  I'll have to
write that one down.

==========
amiga.com/software #948, from ewhac, 91 chars, Sat Dec 30 03:48:43 1989
Comment to 947. More refs to 947.
----------
	Yeah, if SYSGADGET is set, Intuition tries to FreeMem() it.  (Or
something.)

					Schwab

==========
amiga.com/software #949, from jmackraz, 158 chars, Wed Jan  3 20:40:16 1990
Comment to 947.
----------
It seems that current V1.4 gets confused over the need for SYSGADGET,
but I'll fix that: SYSGADGET isn't necessary for the function of a
system gadget.
	jimm

==========
amiga.com/software #950, from perry, 48 chars, Thu Jan	4 09:15:19 1990
Comment to 939. Comment(s).
----------
How about making your own screen depth gadgets?

==========
amiga.com/software #951, from vertex, 163 chars, Thu Jan  4 14:20:16 1990
Comment(s).
----------
TITLE: FreeMem()
Is it allowable to free a memory block obtained from AllocMem() using two
seperate calls to FreeMem()? I know it works, but will it keep working?

==========
amiga.com/software #952, from peabody, 203 chars, Fri Jan  5 03:16:05 1990
Comment to 950.
----------
I've done my own screen depth and drag gadgets.  It's sort of magic, and
I might be persuaded to upload my code somewhere (especially for those
on the inside to look at for potentially dangerous stuff).

==========
amiga.com/software #953, from jbiggs, 181 chars, Sat Jan  6 01:57:33 1990
----------
TITLE: A590/2091
Is there a newer version of the driver than the one that is on the
1.7 Install disk?  This can be locked up by corrupt data from the
AT drive (I think)
Thanks,
Jim

==========
amiga.com/software #954, from peabody, 261 chars, Thu Jan 11 03:16:07 1990
----------
TITLE: CIA handlers
The RKM cia.doc makes no mention of which registers other than D0/D1/A0/A1
are scratch in a CIA interrupt handler (AddICRVector()).  Based on
SetIntVector() and AddIntServer(), I'd guess that A5/A6 are also
scratch, but it doesn't say so.

==========
amiga.com/software #955, from afinkel, 214 chars, Thu Jan 11 12:17:09 1990
Comment to 951. Comment(s).
----------
It works for now; Bryce winces every time I bring it up, and
removed all mention of the concept from manuals and autodocs.

He was also muttering about time travel...

If you can avoid using it, please do.

		andy

==========
amiga.com/software #956, from jdow, 112 chars, Thu Jan 11 16:16:04 1990
Comment to 955. More refs to 955.
----------
Yeah - moving into the realm of tracked resources and memory management might
break this idea REAL quick.
<^_^>

==========
amiga.com/software #957, from vertex, 130 chars, Thu Jan 11 19:18:35 1990
Comment to 955. Comment(s).
----------
Thanks, in the meantime I found another solution to my problem and I
no longer have the need to do two FreeMems on one mem block.

==========
amiga.com/software #958, from afinkel, 58 chars, Thu Jan 11 19:57:14 1990
Comment to 957. Comment(s).
----------
Great!	I'll tell Bryce; he'll be so pleased :-)
	andy
.e

==========
amiga.com/software #959, from cheath, 110 chars, Thu Jan 11 21:41:16 1990
Comment to 958.
----------
Glad you've set Bryce free to identify this sort of problems ... hopefully
it'll pay dividends down the line.

No more unread
Hit <RETURN> for next
Rf:


