[comp.sys.atari.8bit] 1200xl and the cpu and OSe

Cothrell@DOCKMASTER.ARPA (09/07/87)

Ok, I have just found out that the 1200xl (and I presume everything else
but the 400 and 800) does NOT have a standard 6502 in it.  Can anyone
answere the questions of the day?  Namely, what was done to the
processor to make it non-standard?  I suspect that the boot vector (as
well as some others) have been changed from the standard 6502 vectors.
If you dont know for sure, but could tell me how to talk to somebody at
Atari...I would appreciate that greatly.  Otherwise, suggestions and
comments are welcome...results will be posted (if there are any).  The
second question concerns the OS source code.  Has the OS source been
published for the xl/xe machines (i have a 1200xl and a 130xe).  If it
has been published, who and where???  If not...does anyone have a
suggestion for writing an OS?  I want to use a regular 6502 in my 1200xl
and I think I will need to change the OS startup vectors (see question
number 1 above).  Better yet, are there any "alternate OS" available for
the ataris...and would any of the authors be willing to release the
source under a non-disclosure agreement or make a custom version?

please address replies to Cothrell -at DOCKMASTER.ARPA or to Info-Atari8
thanks...Scott Cothrell Cothrell -at DOCKMASTER.ARPA.

knutsen@aramis.rutgers.edu (Mark Knutsen) (09/09/87)

In article <870907174221.284781@DOCKMASTER.ARPA> Cothrell@DOCKMASTER.ARPA writes:

> Ok, I have just found out that the 1200xl (and I presume everything else
> but the 400 and 800) does NOT have a standard 6502 in it.  Can anyone
> answere the questions of the day?  Namely, what was done to the
> processor to make it non-standard?

	While talking to the "doctor" after my 800XL's recent brain
transplant, I also learned to my surprise that the CPU is not a stock
6502.  I believe I was told that there is a small amount of extra
circuitry in there for address decoding, but am not sure.  Can check
it out if you wish.

> number 1 above).  Better yet, are there any "alternate OS" available for
> the ataris...and would any of the authors be willing to release the
> source under a non-disclosure agreement or make a custom version?

	For playing around with the OS, I suggest you get The Boss
alternate OS.  In addition to being a good substitution for the
Translator disk, it offers coldstart from the keyboard, and has a
special mode where it deselects the OS ROM in favor of the RAM
underneath, and copies itself there.   What you get is a RAM OS that
you can POKE around with.

--Mark Knutsen
-- 
_________________________________ Jersey\\\\\\\\ _____________________________
ARPA: knutsen@rutgers.edu       | \\\Atari\\\\\\ | GEnie GE Mail: M.KNUTSEN
UUCP: {...}!rutgers.edu!knutsen | \\\\\\Computer | The JACG BBS: (201)298-0161
--------------------------------- \\\\\\\\\Group -----------------------------

hans@umd5.umd.edu (Hans Breitenlohner) (09/16/87)

The XL and XE systems, as well as some 400s (maybe all), have a 6502C cpu 
chip.  Its main distinction is the fact that it can tri-state the address
bus, a feature which none of the standard 6500 family chips have.

I recall reading that there is a chip in the 65c00 family which does have
the tri-state feature (maybe 65c11), but have no information as to whether
its pinout is compatible with the Atari chip.
Being somewhat non-standard, it might also be considerably more expensive
or harder to find.

As far as I know there are no programming differences between the 6502 and
the 6502c.  

As far as souping up the XL with a faster cpu, I have two concerns:
1. coordinating a faster cpu and the standard Antic might be quite a
challenge.  You would need memory which can run at slow and fast cycle 
rate, depending on who is talking to it.  And while there is a fair amount
of slack in memory timing with the current design, a significant speedup
might cause much difficulty.
2. The i/o bandwidth is about 1920 bytes/second, and unless you main goal is
to compute prime numbers, or do Mandelbrot pictures, any speedup is likely
to make the i/o restrictions seem even more painful.  Of course you might
have disks on an MIO or similar device, but then you need to re-visit the
first point I made.