[comp.sys.atari.st] 68020 Extension-board PAK-68

csch@tub.UUCP (07/27/87)

Here's some more detailed information about the 68020 extension-board for
the ST and other 68K machines.

(I know it must be a very strange request, but if some kind soul could
 transfer this note into the comp.amiga.* newsgroup ??? We don't get 'em
 on this site ...)

The board is called PAK-68. It was developed by the editors of the
computer magazine c't here in Germany. You'll find it in the August issue
on pages 68ff (!!! --- Though I know some of the guys personally I can say
they're very humorus people --- page 68 ...:-}

TECHNICAL DETAILS :
-------------------

	PAK-68 is a PCB with two sockets for a 68020 and a 68881 FPU
	and 11 additional standard TTL chips. There's a 64 pin connector
	on the bottom of the board, so you can plug it directly into
	the 68000 socket of YOUR FAVORITE MICROCOMPUTER (:-}) ...

	It TECHNICALLY (from the hardware-aspect) fits into the ST,
	the Amiga and nearly any other 68K system. 

	Unfortunately the current TOS version DOES DEFINITELY NOT WORK
	together with the PAK-68 board. Some problems were already mentioned
	in this newsgroup some days ago:

		- The STACKFRAME during exception handling is quite different

		- TOS uses simple DELAY-LOOPS which (un-???)fortunately run
		  much faster within the 68020 cache ... :-}

		- additional minor problems

	But there's an operating system, which runs together with PAK-68.
	The (in Germany) well known RTOS/UH. A realtime multitasking OS (not
	only) for the ST. It's also distributed by c't. If you're interested
	I can write another report about this.


	AMIGA users might be more lucky! Though the AMIGA supports the 68010
	the step to the 68020 is not that far - so the OS RUNS with PAK-68 in-
	stalled ... but the author mentioned some doubts about the application
	software ... 


NOW MY CRITIC : (personal)
---------------

	Grrrrrrmbl! What should I do with my (probably Mega-ST) with up
	to 4 Meg. and a 68020 (dream ...) WITHOUT a MMU ????????

	Damned imagine about all the freaks in NETLAND starting to port
	some version of UNIX to that micro ??? Wouldn't this be great.

	I MYSELF would have much more interest in a MMU rather than in a
	FPU. Don't you ?


ADDITIONAL DATA :
-----------------

	Ok, now the most interesting, the PRICE ...

	You may buy the PCB directly from c't (Heise Publications) at the
	price of DM 49,- (that's ~ $30 incl. shipment).
	There's also a company selling parts or the complete board for:

		- complete board (12.5 Mhz) WITH FPU: DM 1098.00 (~ $600)
		-     "      "       "   WITHOUT FPU: DM  798.00 (~ $435)
		- complete parts (WITHOUT FPU & PCB): DM  695.00 (~ $380)

THE ADDRESS :
-------------

	c't Magazine
	Helstorfer Str. 7 
	PO-BOX 61 04 07

	D-3000 HANNOVER 61	(that's WEST(!!)-Germany :-}

	Yes, they do have phone:

		+49-511-53 52-0
		+49-511-53 52-129	(FAX)

		(I do have the direct number for the editor-in-chief, but
		 I think he'll kill me, if I would send it through NETLAND :-}

		 Ask for either

			Mr. Johannes Assenbaum (Author)
			Mr. Christian Persson  (,,Editor-in-chief`` *)
				*= I don't know the english word for this ...

	You may also reach 'em via TWX (or TELEX)

		923173 heise d

	I will offer them a account on our machine, and if they would like
	to, you may send mail directly to them. I'll announce the address,
	if they're really online ...

	I don't want to send the address of the other company via news,
	because I don't like advertising in the newsgroups. You may
	ask me directly for the address.


Clemens Schrimpe (csch@tub)

UUCP:(from the US)	seismo!pyramid!tub!csch
UUCP:(from Europe)	mcvax!unido!tub!csch
BITNET:			csch@db0tui6.BITNET
TWX: (Telex)		186672 rdt d
PHONE:			+49-30-332 40 15	(Office)

bryce@COGSCI.BERKELEY.EDU (08/07/87)

> Here's some more detailed information about the 68020 extension-board...
>
> (I know it must be a very strange request, but if some kind soul could
> transfer this note into the comp.amiga.* newsgroup ???...
>
> Unfortunately the current TOS version DOES DEFINITELY NOT WORK...
>
> AMIGA users might be more lucky! Though the AMIGA supports the 68010
> the step to the 68020 is not that far - so the OS RUNS with PAK-68 in-
> stalled... but the author mentioned some doubts about the application
> software ... 

Information for your technical amusement:

On powerup the Amiga detects the 68020, enables the instruction cache,
twiddles the stack frame and sets a bit for all the world to see.  As
far as the OS, compatibility is 100%.
As is usual there are one or two naughty programs that don't follow the
rules and won't work (Most notably Microsoft BASIC, but since when
has Microsoft written good code for *ANY* machine? :-).  Other software
that does not work includes "Barbarian", an old version of the calculator
and an old version of the Transformer.


The leading cause of problems is the use of the officially blacklisted
MOVE SR,<EA> instruction which is privileged on the '010 and '020 but
not the 68000.  There is an easy patch for that one, it's called decigel.
Write to me if you want a copy to port to the ST, but really it's quite
trivial.  (It is also available from any Motorola distributor).

The second most common cause of death is good 'ol timing loops as part
of disk [protection].  Often they muck with reading the disk DMA
registers directly, rather than letting the full-track DMA hardware
do it for them.

The third most common problem is programs that leave garbage in the upper
8 bits of a pointer.  While this would not be a problem for a board
that plugs into the 68000 socket, it would kill a *real* 68020 system.
Microsoft BASIC seems to be guilty of this crime.
The design team of an as-of-yet-unreleased, low cost double-speed 68020 plug
in for the Amiga decided to place their 32 bit memory *within* the 16 Megabyte
68000 address space because of BASIC.  (I argued that they should simply
include the address of a company that sells a real BASIC :-) :-) :-)


Very few programs actually fail, but there are those programmers that always
want to give their programs that "special touch" :-) :-) :-).

The last native C compiler to generate 68020 dirty code was quashed by a free
update a long, long, time ago.  (The bug went away when Lattice C went
to rev 3.03 (or something close to that))

	-Cheers!-