19 Feb
2010
19 Feb
'10
10:46 p.m.
From: "Ethan Dicks" <ethan.dicks at gmail.com>
Sent: Friday, February 19, 2010 10:18 PM
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: Solderless breadboarding (and 68010 vs 68000)
On 2/19/10, Tony Duell <ard at
p850ug1.demon.co.uk> wrote:
Indeed. Quite distinctive.
Yes, the 68000 and 68010 are almost as impressive as the J11 :-)
Yes, I
have been using breadboards for more than 20 years and never
had a problem with them. Sure, you must not try to stick thick wires
... ... ...
BTW, the article says it is an MC68008, so you
did not need to count
24 pins (on one side) :-)
Oh, I didn't . I noticed it was a 0.6" wide package. The 68000 and 68010
DIL packages are 0.9" wide. >> The 68010 is pin compatible to the 68000, but
if you are in OS stuff,
>
> Indeed. There is also a PGA version of the 68010, which is used in some
> HP machines IIRC there's a 68012 which had more addres mins bought out,
> but otherwise had the same PGA pinout
I have a 10 MHz PGA 68000 somewhere IIRC.
I have read about the 68012, but don't think
I've seen one in the wild.
Me neither.
>> you have to modify some software if you are
handling stack frames.
>> Those are not identical on the 68000 and 68010.
>
> IIRC, the 68010 pushes more onto the stack on an interrupt.
Yes, it pushes a few more bytes to save the CPU state for recovery.
It does. The difference isn't onerous - at least
starting with
AmigaDOS 1.2 if not 1.1 (not sure about 1.0), you could upgrade your
68000 to a 68010 for an approximate 5% effective speed "boost" - this
was entirely due to the one-instruction DBcc "loop-mode cache" in
random places in the OS and in applications. As long as your
applications didn't try to execute any "MOVE from SR" instructions
(http://www.cpu-world.com/CPUs/68010/), no changes were required. If
you _did_ have some apps that did that, there a trap handler for that
on, IIRC, an early Fish disk. It would catch the privilege exception,
grab the status/condition code value and return the value to the
trapping instruction.
And for that 2-instruction cache I upgraded from 68000 to 68010 in my
StarShip. It has a tiny OS for start/stop/suspend/resume tasks and some
synchronization mechanisms (semaphore and timed-wait). The ship's code
runs in User space and the OS in Privileged space, so when a task gives
up the CPU it was via a TRAP.
One app that was used to tell if you had the patch
applied was the
AmigaDOS 1.1 calculator. With AmigaDOS 1.2, the app made an OS call
to get the required value. The older app used a "forbidden
instruction" so it made a good test.
I never thought of using a forbidden instruction, so I changed the code from
68000 to 68010. The test and then processing the stack frame accordingly
is clever, but would cause performance drop. May more than was to be
gained by the 2-instruction caching. I don't know.
If you are rolling your own OS or writing embedded
code, it's not
really that hard to determine what size of stack frame you'll have and
handle both. I was responsible for replacing 68000s with 68010s in
the final COMBOARD product (partially to take advantage of "loop mode"
when dumping buffers across the DMA interface, increasing the block
speed of the board with a $50 chip). I don't think the code changes
relating to the 68010 took me more than part of an afternoon to
implement.
Yeah, if you know the CPU at the assembler level, a few hours work is
what it takes :-) I've done that. I hope to put some new life into my
StarShip
later this year and brush up the 68000/68020 assembler knowledge. It's
5 years ago and I have plenty of ideas to code :-) Will be fun and looking
forward to that too!
It's good to remember that it's so, but rather
easy to accomplish once
you are that deep in the code.
Indeed.
- Henk.