Rumor has it that Eric Smith may have mentioned these words:
>The 6809 tends to take at least as many cycles for simple instructions
>as the 6502, and sometimes more. In an inner transfer loop of a
>device driver, the 6809 will win if you need to do unalinged transfers
>because it can do a 16-bit increment. But I'm not convinced that
>it's good enough.
Erm... I looked up the 6502 instruction set, and while I don't think it's
much slower, I don't think (overall) it's much quicker, either. I'll have
to double-check my 6809 references, tho. Cycle times seem to be a bit rusty
in the noggin... I've not coded in 6502 so I don't know how efficient it
is, but with the auto-increment index/stack pointers in the 6809 (and
having 4 of them), it makes for some very tight, fast loops.
>IIRC, on the Color Computer you can turn off the video and run
>the processor at double speed. That should probably be sufficient,
>but somewhat ugly unless you didn't want to use the console.
I've never turned off the video on a CoCo, and I'm not really sure you can.
The main (read: only) crystal that controls all the timing in a CoCo is a
stock colorburst crystal fed straight to the video & into a divider for the
rest of the system timing. When you use the double-speed poke, you're
changing the divider, so you're not touching the video. However, anything
else off the main CoCo bus (including anything plugged into the cartridge
port, the serial ports (big-banged :-( ), the cassette port, will get a
serious case of heartburn unless you know how to account for it. (and yes,
it was *sweet* to save/load proggies from tape at ~3000 baud... I could
load a 32K datafile from tape faster than my buddy could with his Commie 64
from *disk*. ;-)
One good side effect of this is enough hackers tinkered with the
double-speed poke timings to fix or patch most any problem you could think
of... When the CoCo3 came along which could run at double-speed naturally,
when Tandy was so thoughtful to not give any RS-DOS control to the speed,
everything was already figured out to get around Tandy's shortcomings.
>> It is just a matter
>> of counting the cycles carefully and not having any
>> extra operations.
>
>Don't imagine that you can just write a loop (or inline code)
>to transfer a byte every 16 us. You *must* poll the DRQ bit,
>because the motor speed control is nowhere near good enough to
>maintain a constant transfer rate. And even if it did, there's
>no guarantee that the machine that wrote the disk wasn't a
>little fast or a little slow.
Right... I'm not sure if the disk hardware can even handle the datarate
very well (or at all) so all the programming in the world may not be enough
to do the task if the hardware falls on it's face. Just didn't know if it'd
been done before, and if so, how?
Thanks,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger --- sysadmin, Iceberg Computers
Recycling is good, right??? Ok, so I'll recycle an old .sig.
If at first you don't succeed, nuclear warhead
disarmament should *not* be your first career choice.
Received on Tue Nov 09 1999 - 21:08:45 GMT