dnewton@carroll1.UUCP (Dave Newton) (05/24/89)
A lot of people (including myself) have wanted ATARI to put expansion
slots on their machine. What I am considering is this: get a whole big
bunch of people to come up with a standard interface, publish it, and get
hardware for it.
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? If it's software generated, we can re-code the ROMS to get around
it, bring out a WRITE line, and stick an expansion box onto the cartridge
port. If it's hardware generated, we'll need to come up with a relatively
easy hardware hack to get all the signals out.
What I would propose in this latter case is this: the hardware hack would
consist of unsoldering (? or is it socketed?) the 68000 MPU, inserting a
socket with a ribbon cable, then sticking the 68000 back in. The cable would
lead to a box with a buffering system on it and a bunch of expansion slots.
All signals necessary for healthy ST operation would be there.
On a mega ST this would be easier, since there's already a port--the 520/
1040's would need more work.
Anyone interested? I think it's necessary for ST survival. The reason
the Amiga is growing faster is because of this feature alone--the desktop
looks awful. Expandability/versatility is needed desparately on this
machine.
--
"If I cannot create it, I do not understand it"
-Richard Feynman
David L. Newton (414) 524-7465 dnewton@carroll1.cc.edu
=8-) (smiley w/ a mohawk) (414) 524-7343 uunet!marque!carroll1!dnewtoncs163afu@sdcc10.ucsd.EDU (Some call me...Tim) (05/24/89)
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 am considering is this: get a whole big >bunch of people to come up with a standard interface, publish it, and get >hardware for it. > 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? The error, so I'm told, is generated in hardware. It's hardwired into one of the custom chips of the ST--probably the MMU, though someone tried to tell me it was the GLUE chip. A better interface would be DMA based--1.3 Megabytes per second is a sufficient transfer rate for almost anything. A card cage with a simple bus based on the DMA port would be best. Of course those of us with Megas have a bus expansion option that could easily be brought out into a card cage, with some simple electronics. Depending on what kinds of loads you expect, it may also need its own power supply. One alternative that works for simple expansions (home grown ones come to mind, but a multi-joystick expansion uses this path) is through the parallel port. For some reason, it's bi-directional-- you could communicate with a device plugged in there. I've yet to do any hardware hacking on the ST (other than installing many ROM sets and a 4096 color board), though I've done some hacking on other computers...but the DMA port is somewhat intimidating, probably because of my lack of documentation covering it... _________,_________ /im |\/|ensch | "Life is full of infinite absurdities, which, ' | strangely enough, do not even need to tmensch@ucsd.edu | appear plausible, since they are true." --Luigi Pirandello.
dvlsan@apollon.cs.umu.se (05/24/89)
In article <116@sdcc10.ucsd.EDU> cs163afu@sdcc10.ucsd.edu.UUCP (Some call me...Tim) writes: >... >One alternative that works for simple expansions (home grown ones >come to mind, but a multi-joystick expansion uses this path) is >through the parallel port. For some reason, it's bi-directional-- >you could communicate with a device plugged in there. >... Gee... I wanna know how to do this, could you please post info about it( or e-mail, if that feels better). (I guess it involves low level programming of whatever chip drives the centronics interface, but there's no need to reinvent the wheel :-)) Some time ago i saw an article in byte about writing to the ST cartridge port. It involved using special hardware (fairly simple, as I recall it) to multiplex data and adress out on the adress bus, thereby performing a "write". If there is sufficient interest, I could dig it out of my bookshelf, and post a summary. /Stefan +------------------------------------------------------------+ | DISCLAIMER: Did I write this? I must be out of my mind... | +------------------------------------------------------------+
hase@netmbx.UUCP (Hartmut Semken) (05/26/89)
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)
whack@nmsu.edu (Warren J Hack) (05/29/89)
My first posting to the net fell victim to inexperience and was posted under the wrong subject heading: my apologies. Please see the response to ST at 38k baud for a discussion concerning a way to WRITE to the port via a 24 bit I/O board. Again, sorry for the inconvience.