Conference hydra::amiga_v1

    Re "getting down to the hardware"
    
    Makes you want to strangle these people, no?  My blood boils whenever
    I hear people advocate this sort of rulebreaking.  If I
    wanted to reboot every time I wanted to change programs I'd buy
    a C64.  I realise that it's possible for a programmer to take over the 
    machine and then return it when he is through, but most just grab
    the machine, and then force you to reboot to regain control.
    Unforgivable in a environment such as the Amiga's.  
    
    But what do you expect from a company who has made its name by by
    writing books which advocate the same sort of "squeeze the last drop of
    performance out of the machine by getting down to the hardware"
    mentality. 
    

    Off of the soap box....
    
    Gary

    Re: .0
    
    Dave, could you post the ISBN number for this book please ? 
    
    				Alan T.

                                  -< ISBN # >-

<    Dave, could you post the ISBN number for this book please ? 

I've always wondered, what does "ISBN" stand for and when was it first 
introduced? Sorry to get off the subject.

Dave

>I've always wondered, what does "ISBN" stand for and when was it first 
>introduced? Sorry to get off the subject.

International Standard Book Number
1969

Part of the ISBD ("International Standard Bibliographic Description")
it is a 10 digit book identifier assigned by some designated organization
within each country, with a country identifier prepended to it. Since each
ISBN is unique to a specific edition, an absolute identifier.

                     -< always wondered what an ISBN was >-
    
    Amiga System Programmer's Guide
    ISBN 1-55755-034-4
    
    Suggested retail price: $34.95
    Optional program diskette available: $14.95
    
    438 pages including the index
    
    It can be ordered directly from ABACUS,
    1-800-451-4319  (8am-8pm EST)
    Abacus Software Inc.
    5370 52nd St. S.E.
    Grand Rapids, MI 49508
    
    The ads in the back of it mention more Amiga books coming soon:
    Amiga Disk Drives Inside and Out
    AmigaBASIC 3-D Graphics
    Amiga 'C' for Beginners
    Advanced Amiga 'C'
    
    -dave

Damn. This credit card has got to GO! It makes calling and ordering TOO easy!


Just ordered one. Thanks for the info Dave!

John

    Prior to getting the System Programmer's Guide, I got ASSEMPRO
    (half price show sale, I read the review in Amigaworld) and the 
    ABACUS book Amiga Machine Language.
    
    Same bad "bypass the OS" stuff in the Machine Language book.  At
    least they are consistent.  But it also has more bugs in the listings.
    (instructions appended on to the end of the previous line, and in
    one case, made into a comment)
    
    ASSEMPRO's four windows update about as slow as AmigaBASIC's.  Seems
    to assemble the example programs fairly fast.  The books assume
    you use ASSEMPRO or SEKA, you have to modify the listings if you
    use any other assembler.
    
    -Dave
    

    	You've got to give the Amiga one big hand, though.  You aren't
    trapped from getting down to the hardware just in case you wanted
    to.  "Amy" gives us a good set of options.
    
     - Chris
    

Just recieved mine last night. Decent (typical) manual with disk.

I've read about 20 pages so far. To re-iterate on the base note, the first 
paragraph praises the OS for it's multitude of functions which provide
for almost anything you'ld ever want to do. The next paragraph says - But
lets be real, folks, you *need* to violate every rule of a multitasking
environment to get any decent performance. What a crock!

The rest of the chapter is dedicated to the hardware (68000, 8250s, custom
chips) gearing up for the big takeover.

Lots of good information though. I did see *several* typo errors, some of
which made me do a double take (maybe it was just late!).

I haven't even looked at the disk yet. They claim it has all examples
from the book. The package it comes in has a directory by chapter.
Looks like they included both source (mostly .ASM) and executable.

All in all, I think I will enjoy this one. It should make the RKM series
easier to digest as reference manuals as this book provides a condensed
overview...

John

    re: 9
    
    I've been typing in some of the more interesting example programs.
    ASSEMPRO isn't as bad as I initially thought, it is nice to be
    able to expect the programs to run without doing any conversions.
    
    By going direct to the hardware, they have simplified the code needed
    for the example program and have made it easier to follow with the
    debugger.
    
    But I've found I do need to RKMs to explain some sections of the
    book, just as I need the book to explain some sections of the RKMs.
    The RKMs are written as "it should all work this way".
    The Guide is written as "we tried it, it works this way".  But then
    they leave out some of the details that the RKM has, possibly because
    they didn't try those parts.
    
    -Dave

>The next paragraph says - But lets be real, folks, you *need* to violate
>every rule of a multitasking environment to get any decent performance.
>What a crock!

    My feelings on this subject are mixed.  When I started programming on
    the Amiga, I began by following all the rules and using all the
    standard interfaces, in an attempt to be well behaved.  The performance
    of this well behaved program was terrible!  This program was trying
    to read a MIDI keyboard, timestamp the incoming messages, and place
    them in preallocated memory.  I used the timer and serial device
    interfaces.  Block chords would come out as rolled chords.  Sometimes
    events were just dropped if they came too quickly.  Totally unusable.

    So now I'm reading the hardware directly.  All the record/playback
    code is in hand-optimized assembler.  Performance is fine (so far,
    but I haven't pushed *too* hard).  I do use some OS calls that are
    supposed to reserve/release these devices for exclusive use, which
    I call before and after record/playback.  So I don't take over the
    machine, just the timer and serial devices when I'm using them. This
    is all just to make the point that there *are* valid reasons for
    going at the hardware directly.  But I only do it if the standard
    interfaces don't provide the performance I need.

    And in code that I write that does not have a real-time response
    requirement, I use the standard interfaces.

    -jim

Re: .11

You are right there.  If there has been anything universally acknowledged,
it is that the serial.device (the software device driver, not the hardware)
isn't sufficient to do midi.  The problem was the the serial device doesn't
provide midi timestamps, and for an application program to timestamp the
data when it receives the data results in very unreliable timing.

The correct solution would be for Commodore to provide a midi.device
(again a software driver--the hardware doesn't need to change) that
follows the usual Exec I/O programming model but includes a timestamp
with the data in the message.

At one time the Amiga had a rotten reputation in music circles due to
this problem.  A few of the developers wised up and either did what you
did (an acceptable solution) or wrote their own drivers.  The problem
went away.

It would be nice if Commodore wrote an official midi.device (it would
help all of the homebrew folks), but it looks like it is no longer
needed for the musical success of the machine.

By the way, although you went down to hardware, it sounds like you did
it in a compatible and safe way.  I'd let you play with my system software.

    Another solution would be to write an interface to the Roland MPU-401,
    which would handle all the time stamping and some buffering chores
    for you.  This probably obviate "going to the hardware".
    
    len.
    

Re: .13

Since this has turned in a sort of true confessions note about going to
the hardware, I must admit that the program I wrote to calibrate an
Amiga 2000's battery backed up clock does do direct reads from the
registers associated with the battery backup up clock and the line
frequency timer.  (The program is described in note 1721.)

However, since I only read those registers and never write into them,
this is safe to do under multitasking.

I had to read the memory locations associated with the battery backed
up clock because that clock generates no interrupts and there is no
system service to read it (unless you call spawning a process to run
the SETCLOCK OPT LOAD command a system service to read the clock).
Furthermore, I had to poll the that clock because it only presents
its time to the Amiga to the nearest second.  I had to spin on the clock
value waiting for it to change.

Of course, the program was heavily influenced by the need to be able
to detect a 0.0001% error in the measurement of a 10 second period
of time.  It was sort of fun that the resulting program could be
run on a system with other tasks running, and not interfere with
them at all except for a half second interval that occurred every
ten seconds during which throughput of other tasks in the system
greatly decreased.