Path: utzoo!attcan!uunet!mcvax!unido!tub!tmpmbx!netmbx!hase
From: hase@netmbx.UUCP (Hartmut Semken)
Newsgroups: comp.sys.atari.st
Subject: Re: cartridge port addressing
Message-ID: <2845@netmbx.UUCP>
Date: 26 May 89 07:59:44 GMT
References: <419@carroll1.UUCP>
Reply-To: hase@netmbx.UUCP (Hartmut Semken)
Organization: netmbx Public Access Unix, Berlin, West Germany
Lines: 83

In article <419@carroll1.UUCP> dnewton@carroll1.UUCP (Dave Newton) writes:
>   A lot of people (including myself) have wanted ATARI to put expansion
>slots on their machine.
>   What I need to know is this:  A bus error (illegal address) is generated
>when writing to the cartridge port.  Is this error hardware or software
>generated?

It's a BUS ERROR, right.

Let's have a short look at the 68k Bus interface (the asyncronous one):
Let's say the MPU wants to read (write) from (to) memory. It asserts its
adress lines and puts out an "adress strobe" (-AS signal).

After -AS the 68k waits for one of the following signals: -DTACK, -VPA
or -BUSERR. -DTACK means, the adress was ok and the memory has put out
(read in) the data. -VPA switches the 68k to the synchronous bus (to
adress slow, cheap peripheral chips like the 6850 ACIA); forget that.

-BUSERR signals an invalid adress ("no memory here, you fool!"). This is
used for virtual memory (paging or the like) with the 68010 or 020.

The ST GLUE generates the -BUSERR signal in a siple fashion: a monoflop
(a circuit that stays in one, unstable state for some time, then "falls
back" to the stable state) is triggered by -AS (the output stays HIGH
for some time after -AS). If there is no pulse on -AS for some time, the
output goes low; the output is connected to the -BUSERR pin of the MPU.

If no invalid adress is given, the MPU does something, and therefor does
something with memory (and therefor issues -AS pules): no bus error.
If the MPU outputs an invalid adress and neither -DTACK nor -VPA
acknowledge the request, it does not put out a new adress and there is
no new -AS pulse for some time: the monoflop issues -BUSERR.


Without hacking the hardware (DTACK generation and generation of a R/-W
line for the ROM port adesses), it is almost impossible to write to the
ROM port.

Almost means, it is impossible to put data on the data lines (D0 to D15)
to the ROM port.
Adresses are "written" to the ROM; so we can use these lines, to put out
our data:

When reading an ROM port adress (move.b $FA 0000, D0 or tst.b
$FA0000,D0) the adress FA0000h is put out. If we put the adress in an
adress register and read the port "adress register indirect" after
ADDing our data to that register, the adress $FA0000+data is put out.

To make things shorter: we can "write" data on the lower byte of the
adress bus to some external logic added to the ROM port (basically a
register/latch that fetches the low byte of the adress when reading ROM
adresses and puts it to the outer world...) without hacking the ST's
internal hardware.


This idea got realised by some german engeneer: he added an "universal
I/O port" to the ROM port, and later a more complex logic to mimick an
ECB slot (ECBus used by "old" Z80-CP/m machines), a PC Slot (yes, IBM
PC) and adress a 1 Megabyte EPROM disk.

This does work (even with a PC harddisk controller...) but is rather
expensive.


There is another fast port to consider: the DMA interface.

Ataris "almost SCSI" protocol is'nt too hard to handle (a simple 8031
does it all and is very flexible, even a bunch of PALs could do it
togerther with some software in the ST) and you could even mimick an
SH205 harddisk for I/O or write your own driver... 


But there will no be a "standard" without Atari Corp. supporting and
distributing it.

Not the best best ideas/machines/... do it. Standards are made by the
manufacturer (look at the Mac, the Pissi, the Amiga, the VAX...)

hase
-- 
Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP
If there is something more important than my Ego, I want it caught and shot.
Now! (Zaphod Beeblebrox)