Aha!  A good argument is developing...  Eric Greene writes:

I hate to be stubborn (actually I LOVE to!) but Eric's own figures tend to
support my claim, at least to the extent that there are some tasks for which
there wouldn't be a vast difference in speed between a 6502 and a 68000.
If we compare AVERAGE times, based on Eric's figures, then the average time
per instruction for the two machines would be:

                8-MHz 68000                     1.76-MHz 6502
        -------------------------------------------------------------

         13 cycles (avg)                     4.5 cycles (avg)
       ------------------ = 1.625 usec      ------------------ = 2.556 usec
          8.0 MHz clock                       1.76 MHz clock

for a 1.573:1 advantage in favor of the 68000.  This is considerably less
than the 4.5:1 ratio of the clock speeds or the "4 times faster" that Eric
alludes to.  Probably much of the power of the 68000 comes from getting more
power per instruction rather than more instructions per second.

-John Sangster

I have a question, maybe someone from Atari can answer it, or maybe not.
Is Atari purposely killing the 8-bits?

This question is, for the most part, brought on by the recent "high"
prices put on the XE machines. Coupled with the already low ST prices
it's obvious that the decision to go with either an XE or an ST is being
made for the buyer. Other things that seem telltale are A.) The "game"
title was slapped on the new XE machine, B.) The 3.5" drive and 80
column card do not exist. (Sorry gang, but unless I can _buy_ it, it
doesn't exist. That's only fair. I dont buy things with promised money,
and I can't purchase promised products.) C.) When ICD wanted more
Parallel bus information to build the MIO box, they had to sign
non-disclosure agreements. A _FAR_ cry from the open-architecture of
Atari past which even distributed the source code to the OS, D.) Atari's
recent telling the guy who did the ST's 8-bit emulator that he couldn't
touch the OS code.

None of these events are the actions of a company with an interest in
the 8-bit's future. That's fine, since they aren't making as much on the
8bit as they are on an ST, but I'd like to know if this is the
committed direction. I, and something like 2 or 3 million other people
have hundreds (or thousands!) of dollars tied up in 8-bit hardware, and
would like to think that if Atari is no longer interested in marketing
the machine, they would at least release it to the public domain to
allow third party small time vendors support the existing owners of the
machine or build compatible upgrades. Like the Commodore-128 or the
Coco-3, a new machine that would only really interest existing owners,
but would give them a 'full power' machine that they can keep their
existing software and periperhals going on.

Terry Conklin
ihnp4!msudoc!conklin            The Club    (517) 372-3131  now w/2400
conk@mich-state.edu         The Club II (313) 334-8877

As for the 80 column card I saw one working at the Allentown Atari
Expo! Recently there was a posting on GEnie from one of the ATARI Base
SYSOPS concernig the XEP-80.  He said it is in production.  He didn't
say when it should be out.  Also the 1200baud modem it getting ready
to come out.  As for the 3.5" drive I don't remeber hearing an
OFFICIAL announment just a lot of rumors.

Now the non-disclosure agreement is a standard form for all companies.
Just because the old Atari didn't make people sign them doesn't mean
the NEW Atari should do the same.  All the agreement says is that the
info we give is not to be given out.  Now I'm sure if you had a valid
reason for the info they would be glad to give it you.

I really don't think ATARI is killing the 8bit.  Things just take
time.  There are new version of AtariWriter Plus coming out for the
XEP-80.  Also if you think they're killing it, how about giving some
suggestions.  All I've seen is complaints!
--
                            Marc L. Appelbaum                          
 Arpa:appel@topaz.rutgers.edu            Bitnet:appelb@zodiac.bitnet    
 Uucp:rutgers!topaz!appelbau                GEnie: M.APPELBAUM

In article <1@topaz.RUTGERS.EDU> appel@topaz.RUTGERS.EDU (Marc L. Appelbaum) writes:
A very kind and pious thought, but the fact that nobody (except Ian
Chadwick, the author of "Mapping the Atari") has been able to get
listings or documentation for the XL operating system would appear
to be cause for disagreement with this.

We come again to that perpetual question: is Atari intent on killing the
8-bits?

One way to answer that would be to give you a tour of our warehouse.  If you
could see the number of 8-bit computers and software in inventory, you'd
know we are highly motivated to keep the line going.

Regarding the new XE Game System, which on the first glance is a slap in
the face to those who know how powerful the 8-bitters are -- this system is
purely a strategic move on our part.  In order to keep the 8-bit line going,
we must do two things:

1. Get the computers available in more stores, and
2. Get new software developed for them.

Software is not being developed by and large because of problem #1.  So
which stores do we go to?  The mass merchants, who sold the bulk of the
hundreds of thousands (not, unfortunately, millions) of Atari 8-bit
computers out there, are currently retreating from the computer business.
K-Mart carries NO computers.  Ditto for Montgomery Wards.  And for J.C.
Penney's.

On the other hand, these same stores are doing a fabulous business in game
systems like Nintendo, Sega, and, of course, Atari.

The solution, from a business point of view, was to develop a product that
would be appealing to the mass merchants (and also to the public which buys
there), one that also accomplishes the corporate objective of revitalizing
the 8-bit line.

So what we have with the XE Game System is essentially a 65XE in disguise.
Internally it contains 64K of RAM, the standard OS and BASIC in ROM, two
joystick ports, SIO port, etc.  It is completely compatible with the current
8-bit line, including software.

Physically it is more appealing to those who don't want a computer but who
do want to play games.  The main console simply has the 4 console keys from
the XE (Start, Select, Option, and Reset), plus the cartridge port and
connectors.  The keyboard is a separate unit which plugs into the console.

When someone buys the XE Game System, they get the complete package --
console, keyboard, light gun, and 3 programs (including a new version of
Sublogic's Flight Simulator including scenery, all on a single cartridge).

We expect stores to do a great business in these.  We'll make available the
current library of cartridge software, plus we're converting some disk
programs into cartridge format for this system.  As time goes by, we expect
to see dramatic increases in sales for 8-bit software -- hopefully, this
will also include practical applications as well as games.  This should in
turn encourage developers to create new titles for the 8-bits.

Once things get moving again in the mass merchants, the current supply of
8-bit computers should also get moving through the dealers -- after all,
they make a better value than the game systems, and take up less space.

So, those few of you out there who are looking at Atari management as the
evil group who are plotting to quash the 8-bit line, you have it all wrong.
We're trying hard to keep things moving forward.  Without the distribution
and the software, no amount of advertising and new hardware development
could work.  The XE Game System is our best hope to keep things moving.
--
--->Neil Harris, Director of Marketing Communications, Atari Corporation
UUCP: ...{hoptoad, lll-lcc, pyramid, imagen, sun}!atari!neil
GEnie: NHARRIS/ WELL: neil / BIX: neilharris / Delphi: NEILHARRIS
CIS: 70007,1135 / Atari BBS 408-745-5308 / Usually the OFFICIAL Atari opinion

ditto on the addition for me as well.  

Bob Greenwald
{ihnp4,cepu,uiucdcs}!bradley!gandalf

Chuck Lane, c@cithex.bitnet, writes with some questions about Action!,
the "premier" compiled language for the 8 bit Atari.   Also John Sangster
had some questions, and no doubt some other new Action! users will be
interested in this.

Bruce Langdon who used to contribute a lot of Action! code and hints to this
newsgroup sent me a lot of material.  I will post some of it here--

1) reply on negative steps in DO loops, from the now-defunct Action! BBS
   written by the author of Action!, Clint Parker.   WHILE constructs
   will let you use negative steps, and Clint explains why DO doesn't allow
   negative steps.

2) Action! bug sheet number 3; part 2 of this bug sheet tells how
   to identify the version number of your cartridge.

---------------------------------------------------------------------------
 #: 108   size: 304
Sb: re: #105 - Negative STEPs
Fm: 1  SYSOP

#108  23:14:27  15-May-84

Warren,
     No, that isn't the problem.  The problem has to do with the code
generated for the ending condition.  It is different for positive and negative
step sizes.  There is no way to generate it for both cases at compile time
without making the FOR loop code much larger and slower.

      - Clint

replies:
     114

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

    ACTION! BUG SHEET #3 - part 1

This document supercedes the previous
two bug sheets published for ACTION!

November 6, 1984

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

         GENERAL INFORMATION

Before getting to the bad stuff (the
bugs), here are some goodies about
ACTION! which we would like to pass
on to you:

ACTION! BULLETIN BOARD

In order to speed the distribution of
ACTION!-related information, Clinton
Parker (author extrordinaire of
ACTION!) has set up a bulletin board
system.  His company, Action Computer
Services, is located in Rochester,
New York, and you may try calling his
bulletin board at
(716) 235-3394
and hit [RETURN] when asked for a
password.

Clinton welcomes comments,
suggestions, and praise.  Complaints
and their perpetrators will be
ignored.  That is, of course, our
joke.  But please, if you must offer
criticism, keep the remarks construc-
tive.  And remember that OSS is
responsible for distribution, etc.
Clinton is the author and is (we
feel) generous in making himself so
accessible.

TIPS ON TEMPS

The magazine article titled "Lights,
Camera, Action!" (by Dave Plotkin)
which appeared in the July issue of
ANTIC featured a set of routines to
facilitate writing ACTION!-based
interrupt handlers.

The article gave the listings for two
routines (more properly, two DEFINEs)
named "SaveTemps" and "GetTemps".
These routines are adequate only if
no math beyond addition and
subtraction is performed in the
interrupt service routine.  The
following versions of these two
routines will work properly in the
more general case:

Make the following DEFINEs in your
program before you declare your
interrupt routine (comments may be
omitted-- they exist only for clari-
fication):

DEFINE SaveTemps=
  "[
     $A2 $07     ;       LDX #7
     $B5 $C0     ; LOOP  LDA $C0,X
     $48         ;       PHA
     $B5 $A0     ;       LDA $A0,X
     $48         ;       PHA
     $B5 $80     ;       LDA $80,X
     $48         ;       PHA
     $B5 $A8     ;       LDA $A8,X
     $48         ;       PHA
     $CA         ;       DEX
     $10 $F1     ;       BPL LOOP
     $A5 $D3     ;       LDA $D3
     $48         ;       PHA
  ]"

DEFINE GetTemps=
  "[
     $68         ;       PLA
     $85 $D3     ;       STA $D3
     $A2 $00     ;       LDX #0
     $68         ; LOOP  PLA
     $95 $A8     ;       STA $A8,X
     $68         ;       PLA
     $95 $80     ;       STA $80,X
     $68         ;       PLA
     $95 $A0     ;       STA $A0,X
     $68         ;       PLA
     $95 $C0     ;       STA $C0,X
     $E8         ;       INX
     $E0 $08     ;       CPX #8
     $D0 $EF     ;       BNE LOOP
  ]"

Use these routines inside your
interrupt routine as follows:

; Your interrupt routine.
PROC InterruptRoutine()
  ; Local declarations, if any.
    BYTE a, b, c, etc.

  ; First line of code within
  ; procedure
    SaveTemps

    ... ; Your interrupt
        ; code goes here.

    GetTemps      ; Last line of code
                  ; within procedure.
[$6C OldVBI]      ; A special way to
                  ; end for VBIs- see
                  ; below.

For example, the following program
will set up the routine ChangeColor
as a vertical blank interrupt routine
(hit the START key to exit the
program):

DEFINE SaveTemps=
  "[ $A2 $07 $B5 $C0 $48
     $B5 $A0 $48 $B5 $80
     $48 $B5 $A8 $48 $CA
     $10 $F1 $A5 $D3 $48 ]"

DEFINE GetTemps=
  "[ $68 $85 $D3 $A2 $00 $68
     $95 $A8 $68 $95 $80 $68
     $95 $A0 $68 $95 $C0 $E8
     $E0 $08 $D0 $EF ]"

CARD OldVBI    ; Will hold previous
               ; contents of vertical
               ; blank interrupt
               ; vector.

; This procedure will change the
; background color to random values.
; The main routine will set up this
; code to operate during the
; deferred vertical blank interrupt.
PROC ChangeColor()
    BYTE hue, lum

    SaveTemps
    hue = Rand( 16 )
    lum = Rand( 16 )
    SetColor(2,hue,lum)
    GetTemps
[ $6C OldVBI ]  ; Vertical blank
                ; interrupts must end
                ; like this ($6C is a
                ; 6502 indirect jump
                ; instruction).

PROC Test()     ; Main routine
 BYTE critic=$42, ; Critical I/O flag
      console=$D01F ; Console key
         ; hardware location
 CARD VBIvec=$224 ; Deferred vertical
         ; blank interrupt vector

    ; You must install a VBI
    ; routine like this:
    critic = 1
    OldVBI = VBIvec
    VBIvec = ChangeColor
    critic = 0

    ; ChangeColor is now running
    ; as the vertical blank interrupt
    ; routine-- since our mainline
    ; code has nothing more to do,
    ; we just go into a loop waiting
    ; for the START key to be
    ; pressed.
    WHILE console&1
      DO
      OD

    ; Now turn off the VBI routine.
    critic = 1
    VBIvec = OldVBI
    critic = 0
RETURN

This method of saving and restoring
ACTION zero page variables may also
be used to write BASIC machine
language subroutines in ACTION!  Your
main ACTION routine should then have
SaveTemps as the first executable
line, and GetTemps as the last
executable line before the RETURN
statement.

actbug2         508119184   302   52    100600  10553     `
   ACTION! BUG SHEET #3 - part 2

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

   BUGS IN THE ACTION! CARTRIDGES

The following is a list of all bugs
we currently know exist in the
ACTION! cartridge.  We list these
bugs separately from those in the
RunTime library and/or the PAD disk
or ToolKit, which occur in following
pages.  Each bug is described in
detail and, when possible, bug fixes
are given.  Many of these bugs deal
only with specific versions of
ACTION!.  To find out which version
of ACTION! you own, type the
following from the ACTION! monitor:

  ?$B000 [RETURN]

Below is an actual copy of what
printed following that command for
one of our cartridges.

  45055,$B000 = 0 $0730 48 1840
              ^

To find out the version number, look
at the character to the right of the
equals sign (here printed with a
caret under it).  The "0" in this
case implies that the cartridge is
version 3.0.  If yours has a "6", you
own version 3.6, etc.  As of the date
of this bug sheet, the current
cartridge version is 3.6.

1.  OFFSETS -- Using a TYPE
    declaration will generate a
    spurious error whenever the code
    offset (contents of location $B5)
    is non-zero.

    Affects:  All versions of the
    cartridge to date.  (Presumably
    only noticed if using RunTime
    disk, though.)

    Fix:  Make all TYPE declarations
    before changing the code offset.

    Example:
        ; Beginning of program --
        ; First, declare TYPEs
        TYPE IOCB =
         [
          BYTE Id, Devnum,
               Command, Status
         ]

        ; Then, if desired,
        ; change offset
        SET $B5 = $1000
        ; example: offset=4096

2.  OFFSETS -- Using a code offset
    greater than $7FFF (i.e., a
    negative offset, if you consider
    it to be of type INT) causes the
    compiler to generate improper
    code.

    Affects:  All versions,
    especially when used with the
    RunTime disk.

    Fix:  No direct fix, but you may
    use the relocator program
    described later in this document
    (which is also usable with
   embly language).

3.  ATARI DOS -- Exiting to Atari DOS
    from ACTION! can cause a system
    crash if DUP.SYS is not present
    on the disk in drive 1.

    Affects:  All versions, but only
    when used with Atari DOS.

    Fix:  Use DOS XL (or be careful
    when exiting to DOS).

4.  ARRAYS AND ELSEIF -- We have just
    learned that there is a
    relatively obscure bug in ACTION!
    related to the use of ELSEIF.  In
    particular, statements similar to
    the form
      ELSEIF a(i) = 0 THEN ...
    (where a is an ARRAY and i is a
    CARD OR INT), or statements like
      ELSEIF p^ = 0 THEN
    (where p is a POINTER) produce
    incorrect code.  

    Affects:  All versions

    Fix:  There is no direct fix at
    this time.  The best way around
    the problem seems to be to code
    something like this:
      t = a(i) ; t is an INTEGER
         ...
      ELSEIF t=0 THEN ...
    This works properly.

5.  WRITING OBJECT FILES -- If a
    monitor Write command fails
    because of a disk error (e.g.,
    disk full, 162, or device done,
    144), the IOCB is not properly
    closed.  If the disk is changed
    before another disk operation is
    performed, the new disk can have
    invalid data written to it.

    Affects:  All versions

    Fix:  If you get an error when
    writing an ACTION! object file,
    type the following command to the
    monitor:
      X Close( 1 ) [RETURN]
    You can then erase the file which
...

 

For John Sangster and any others interested, here is a short Action! module
for block i/o  (originally posted by Clint Parker on his BBS system)

NOTE: re prior bugsheet posting: the Action! BBS is no longer up...

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

MODULE ; BLKIO.ACT

; Copyright (c) 1983, 1984, 1985
; by Action Computer Services (ACS)
;
; This software may be incorporated in
; other software packages providing
; that this copyright notice is also
; incorporated as well.

; version 1.1
; last modified May 8, 1985

BYTE CIO_status

CHAR FUNC CIO=*(BYTE dev, CARD addr,
          size, BYTE cmd, aux1, aux2)
; see hardware manual for description
; of CIOV.
;   IOCB# = dev
;   ICCOM = cmd
;   ICBA  = addr
;   ICBL  = size
;   ICAX1 = aux1
;   ICAX2 = aux2
; ICAX1 and ICAX2 are not set if aux1=0
; The first byte of addr is passed to
; CIO in the A register.  The status
; on return from CIO is stored in
; CIO_status.  If status=$88 then
; EOF(dev) is set to a non-zero value.
; No other error checking is performed
; and the result of the CIOV call is
; returned as the result of this FUNC.
[$29$F$85$A0$86$A1$A$A$A$A$AA$A5$A5
$9D$342$A5$A3$9D$348$A5$A4$9D$349
$A5$A6$F0$8$9D$34A$A5$A7$9D$34B$98
$9D$345$A5$A1$9D$344$20$E456
$8C CIO_status$C0$88$D0$6$98$A4$A0
$99 EOF$A085$60]

CARD FUNC ReadBlock=*(BYTE dev,
                    CARD addr, size)
; Reads size bytes from dev into addr.
; Returns number of bytes read (may
; be < size if EOF).  Set EOF flag if
; EOF is encountered.  Status is  
; saved in CIO_status.
[$48$A9$7$85$A5$A9$0$85$A6$A5$A3$5$A4
$D0$6$85$A0$85$A1$68$60$68$20 CIO
$BD$348$85$A0$BD$349$85$A1$60]

PROC WriteBlock=*(BYTE dev,
                    CARD addr, size)
; Writes size bytes from addr to dev.
; Status is saved in CIO_status.
[$48$A9$B$85$A5$A9$0$85$A6$A5$A3$5$A4
$D0$2$68$60$68$4C CIO]

PROC PutCD=*(BYTE chan, CARD n)
  BYTE c=$AA, lo=$AB, hi=$AC

; save args
  [
    $85 c
    $86 lo
    $84 hi
  ]

; PutD(c, lo)
; PutD(c, hi)
  CIO(c,lo,0,11,0)
  CIO(c,hi,0,11,0)
RETURN

CARD FUNC GetCD(BYTE chan)
  CARD out
  BYTE lo=out, hi=out+1

; lo = GetD(chan)
; hi = GetD(chan)
  lo = CIO(chan,0,0,7,0)
  hi = CIO(chan,0,0,7,0)
RETURN(out)

MODULE ; for user

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

                                Dick Curzon
                                Digital Equipment of Canada
                                PO Box 13000
                                Kanata Ontario      K2K 2A6
                                Canada.

(DEC E-NET)     KAOA01::CURZON
(UUCP)          {decvax, ucbvax, allegra}!decwrl!kaoa01.dec.com!curzon
(ARPA)          curzon%kaoa01.@decwrl.ARPA

For John Sangster and any others interested, here is a short Action! module
for block i/o  (originally posted by Clint Parker on his BBS system)

NOTE: re prior bugsheet posting: the Action! BBS is no longer up...

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

MODULE ; BLKIO.ACT

; Copyright (c) 1983, 1984, 1985
; by Action Computer Services (ACS)
;
; This software may be incorporated in
; other software packages providing
; that this copyright notice is also
; incorporated as well.

; version 1.1
; last modified May 8, 1985

BYTE CIO_status

CHAR FUNC CIO=*(BYTE dev, CARD addr,
          size, BYTE cmd, aux1, aux2)
; see hardware manual for description
; of CIOV.
;   IOCB# = dev
;   ICCOM = cmd
;   ICBA  = addr
;   ICBL  = size
;   ICAX1 = aux1
;   ICAX2 = aux2
; ICAX1 and ICAX2 are not set if aux1=0
; The first byte of addr is passed to
; CIO in the A register.  The status
; on return from CIO is stored in
; CIO_status.  If status=$88 then
; EOF(dev) is set to a non-zero value.
; No other error checking is performed
; and the result of the CIOV call is
; returned as the result of this FUNC.
[$29$F$85$A0$86$A1$A$A$A$A$AA$A5$A5
$9D$342$A5$A3$9D$348$A5$A4$9D$349
$A5$A6$F0$8$9D$34A$A5$A7$9D$34B$98
$9D$345$A5$A1$9D$344$20$E456
$8C CIO_status$C0$88$D0$6$98$A4$A0
$99 EOF$A085$60]

CARD FUNC ReadBlock=*(BYTE dev,
                    CARD addr, size)
; Reads size bytes from dev into addr.
; Returns number of bytes read (may
; be < size if EOF).  Set EOF flag if
; EOF is encountered.  Status is  
; saved in CIO_status.
[$48$A9$7$85$A5$A9$0$85$A6$A5$A3$5$A4
$D0$6$85$A0$85$A1$68$60$68$20 CIO
$BD$348$85$A0$BD$349$85$A1$60]

PROC WriteBlock=*(BYTE dev,
                    CARD addr, size)
; Writes size bytes from addr to dev.
; Status is saved in CIO_status.
[$48$A9$B$85$A5$A9$0$85$A6$A5$A3$5$A4
$D0$2$68$60$68$4C CIO]

PROC PutCD=*(BYTE chan, CARD n)
  BYTE c=$AA, lo=$AB, hi=$AC

; save args
  [
    $85 c
    $86 lo
    $84 hi
  ]

; PutD(c, lo)
; PutD(c, hi)
  CIO(c,lo,0,11,0)
  CIO(c,hi,0,11,0)
RETURN

CARD FUNC GetCD(BYTE chan)
  CARD out
  BYTE lo=out, hi=out+1

; lo = GetD(chan)
; hi = GetD(chan)
  lo = CIO(chan,0,0,7,0)
  hi = CIO(chan,0,0,7,0)
RETURN(out)

MODULE ; for user

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

                                Dick Curzon
                                Digital Equipment of Canada
                                PO Box 13000
                                Kanata Ontario      K2K 2A6
                                Canada.

(DEC E-NET)     KAOA01::CURZON
(UUCP)          {decvax, ucbvax, allegra}!decwrl!kaoa01.dec.com!curzon
(ARPA)          curzon%kaoa01.@decwrl.ARPA

the real C that I mentioned recently was an allusion to some work that
steve kennedy has been doing with the dbc sources to extend them.
i don't know what he plans to do with it when he gets it going, but he
has an Atari simulator running on a Vax which has given him plenty of
productivity to extend dbc... his problems, the last i talked to him,
involved shrinking this improved C to fit in the Atari...

let's get on him to try to convince him to bring this out pd or sell it!
he is adding structures and some other neat stuff.

the difference between what he has done and what Ralph Walden has done
is that in the course of developing ACE C and Lightspeed C, Ralph added some
nonstandard features to the C such as comments that cannot cross line
boundaries and some other stuff.  (I have also talked to ralph) don't get
me wrong, ralph has done a very good job with several programs
(including ACE C) for the Atari's, but isn't it time that we stand up and
demand a standard (for once) language?  i think so.

steve is smk on the net... i don't know his address at this moment.

--
                        Brad Banko
                        Cleveland, Ohio ...!decvax!cwruecmp!ncoast!btb

"The only thing we have to fear on this planet is man."
                        -- Carl Jung, 1875-1961