17 Jan
2014
17 Jan
'14
8:04 a.m.
On Thu, Jan 16, 2014 at 09:31:30PM +0000, Peter Corlett wrote:
--
Eivind
On Thu, Jan 16, 2014 at 12:08:43PM -0500, Sean Conner
wrote:
That really does sound close to completely non-functional.
It was thus said that the Great Eivind Evensen
once stated:
> On Tue, Jan 14, 2014 at 10:28:20AM +0000, Peter Corlett wrote:
>> [...] (I hope they are a bit more reliable than the 14MHz 68010 I tried
>> back in 1990, and which was sent back within the week as Not Fit For
>> Purpose.)
> Just curious, were the problems related to hardware or software relying
> on cpu timing and the likes?
In the case of that specific device, they obtained the 14MHz clock for the
68010 by doubling the 7MHz clock that drove other system components. A hack
that breaks all sort of things, in other words. The most obvious casualty was
trackdisk.device, whose waits for floppy drive heads to settle had halved and
it caused all sorts of disk problems. The widget came with a custom bootblock
that fiddled with trackdisk.device's timings, but it was still not satisfactory
as much of the software I ran already had its own custom bootloader. Presumably they saved a couple of quid on 74-series
chips with that design. I
doubt they saved money overall with the number of returns they must have had.
My kickstart 1.3 says (C) 1987 so probably even earlier.
First off, the 68000 and the 68010 had a
different stack layout for
exceptions, so the operating system needed patching. Also, at least one
instruction (MOVE SR,dest) was bumped from a user instruction to a
priviledged instruction, so further changes to the operating system were
required (to emulate that instruction in userspace).
The Amiga's exec.library abstracted the differences away. Under the hood,
although the default was the plain 68000, it probed the CPU and switched in new
functions to provide a CPU-neutral API. As far back as Kickstart 1.2 (which was
what, 1987?) it understood the 68000 through 68020. I routinely booted
Kickstart 1.3 on my 68040 box to run the more recalcitrant software, and it all worked. To the probe code, a 68040 looks just like a
68020 without FPU or MMU,
and it turns out to emulate that combination nicely!
Which may be why (although I haven't disassembled it) the cpu checker in
for example Cube-O-Matic/Spreadpoint tells that my a1240/40 combination
has roughly the same speed as the machine it was written on, which I
believe had a 020. That was very uncommon equipment in the demoscene
in the late 80-s.
I'm not
sure of any timing issues, as I am more into the software side of
things than hardware.
The 68010 provided some minor improvements, both in performance and
functionality. Unless one was playing silly buggers with timing loops, there
were no real surprises except that code tended to execute slightly quicker.
Generally it wasn't worth it though, and one was better off going for the 68020.
-spc (Who loved programming on the 68000 ... )
It was a reasonably elegant and orthogonal processor. Howerver, I've finally
realised I'm not smart enough to be a hardcore assembly-language guru, so
wandered off and found other niches.
I'm probably a heretic here, but x86-64 isn't actually all that bad once
it's
in long mode. All of the segmentation hacks and special-purpose registers
pretty much sod off. There is some lack of orthogonality, but it doesn't
seem any worse than the 680x0's occasional distinction between D and A
registers.