[RC5] ATARI ST?
peter at llama.nslug.ns.ca
Mon Jan 15 04:03:01 EST 2001
On Sun, Jan 14, 2001 at 01:21:01PM -0600, David McNett wrote:
> On 14-Jan-2001, Denie Andriessen wrote:
> > Altough it looks quite feasable to me to port the existing 68000 code to the
> > ST, I wonder if it's worth it, as the ST (If I recall correctly) runs at
> > 8Mhz, hence you'd need to have quite a bunch of those machines lying around
> > to make it worthwhile..
> I'd love to see an Atari ST port. I suspect the biggest difficulty would
> be the lack of an IP stack. Still, as you said, since it's a slow 68k
> cpu, you wouldn't have to sneakernet very often. :)
There is a PPP/IP/TCP stack. A friend of mine uses it. It might not work
on a 1MB machine, though. It's called STing, and is usually used with a
browser called cab, IIRC. Also, I think all of that is supposed to run
under MiNT (= MiNT Is Not TOS, a real multitasking OS for the Atari.)
I've long since given up on the atari, since the M68k is anemic, and only
really really expensive ones that come in a tower with an MC68060 have PCI
and therefore can easily do ethernet. Without ethernet, a computer is not
much use to me. Also, without shelling out for a TT or better, it can't
even run linux or a similarly decent OS. Linux on a PC or PowerPC Mac (like
my quad PPC604 @ 150MHz mac clone :) is much more interesting.
I think it's safe to call a computer totally obsolete when it sucks to much
to even be possible to use it to browse the web in decent comfort.
Having dumped on the Atari, I'll have to say that I quite like them for
what they can do. I've fixed a few of them (hardware, usually the power
supply), and I learned assembly on them. They have a lot of good features.
Some people still use them. I'm a bit less casual about computers than most
people, so I demand more than most people (e.g. a decent OS like Linux).
Anyway, if somebody writes a client for the Atari, it would probably be
best to not multitask, unless whoever writes it is feeling ambitious.
As for how much CPU power the Atari ST has, it has an MC68000 at 8 MHz, with
no cache. (cache wouldn't help, there aren't stalls because the memory
keeps up.) The memory bus runs at 16MHz, since it's shared between the CPU
and the video chip. (There is no separate vid ram. You tell the video chip
what memory address to show on the screen :) The floppy disk (and hard
disk, if you have one:) use DMA, so that doesn't load the CPU.
Basic ALU operations between registers (8 data, 8 address, all are 32bit)
take ~6 clock cycles. Move reg->reg takes 4. Memory accesses make things
take longer. The 68000 is not pipelined at all. Later versions are
pipelined, and so take far fewer cycles per instruction on average. The
killer, for RC5 anyway, is that the on MC68000 (used in the ST), shifts and
rotates take 8 + 2*shift count cycles. i.e. they suck royally at shifting.
At least they have a rotate insn... I think they would be best off sticking
to OGR. This changed in the 68030, which does constant-time shifts.
The Mega STe is between the ST and the TT. the e is for enhanced. They
could do fancy colours and stuff, unlike the 4 bit colour ST :) It has a
16MHz MC68000, but the same 16MHz memory bus shared with the video hardware.
However, it has 16 or 32kB of cache, so that un-cripples it, unless you set
it to cache off. (you can set 8 or 16MHz and cache on/off with software, in
case you want to run a game that runs at the right speed because the CPU is
the speed it is, or if a program does something dirty that depends on excact
instruction timings, and is calibrated for an 8MHz machine.
When I started programming, I had gcc installed on my [dad's] 4MB mega STe.
One of the reasons I did stuff with assembly language was
that the C compiler is really slow, but the assembler is nice and fast! I'm
glad I learned, since understanding assembly made it really easy for me to
do well in most CS classes.
Back to the speed estimate: As a rough estimate, assume that the CPI
(cycles per instruction) of the OGR core on a SPARC is 1. Running on a
270 MHz Ultra2 processor, it gets ~1.4MNodes/s. (client ver 460). Assume that
it will be 6 on the ST (which is optimistic!). By this reckoning, the ST
1.4 MNodes/s * 8/270 * 1/6 = 6.9 kNodes/s.
This is abysmal. It will take forever to do anything. We would have to
run RC5 if we wanted to get a packet short enough to ever be able to submit
it, but RC5 will be sucky because the 68000 doesn't shift quickly. (It
doesn't do anything else quickly either, so maybe slow shifts won't be too
big a bottleneck :->
> Give me an excuse to dig my 1040ST out of the closet. :)
Hehe, I used to have >5 old STs in various states of disrepair stashed under
my bed. I think I could make at least a couple working STs out of them. I
was the local Atari club technician, and sometimes actually got around to
fixing some stuff, but I ended up with a lot of crap.
Well, that was a nostalgic experience :)
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter at llama.nslug. , ns.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BCE
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5