Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!oliveb!ames!killer!elg
From: elg@killer.Dallas.TX.US (Eric Green)
Newsgroups: comp.sys.cbm
Subject: Re: C128,C128D, and C128C??? Questions
Message-ID: <7664@killer.Dallas.TX.US>
Date: 27 Mar 89 05:06:32 GMT
References: <1896.24298458@isishq.FIDONET.ORG>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 64

in article <1896.24298458@isishq.FIDONET.ORG>, izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) says:
>    From this table, I can conclude that you're probably better off using the 
> 128's 2 MHz 6502 than its Z80.

For disk i/o, yes, I can see that. One processor-switch for 128 bytes
is not excessive overhead.  Besides, the Commodore disk routines work
via voodoo and glue, and have been so hacked over the years that I
doubt you could implement them on another processor without special
hardware (e.g. a 6526's serial register to clock data in & out).

For modem and screen i/o, though, the overhead of the processor-switch
is way too slow. Especially for modem i/o.

>    I should also mention the 6809 here. It offers 16-bit registers 
> (accumulator, two index registers, user & system stack pointers), a direct 
> page register (to move zero page around, as is possible with the 128's MMU), 

I love the 6809. Ever since I bought a surplus 6809 book from a
defunct SuperPet dealer, I've wanted to put together something that
used one. The 6809, Forth, and real-time operation go together like
macaroni & cheese or cereal & milk. However, it simply cannot compare
with the 68000 as a systems-oriented device, due to the 16-bit
addresses. (but it's such a pleasant-to-program device that I intend
to use it for any imbedded applications I find, even if there ARE more
space-efficient solutions).

>    Miklos Garamzeghy has published a C128 CP/M disk I/O toolkit. Admittedly, 
> RS-232 would be faster if it didn't have to "spawn" a processor switch at 
> every interrupt. Fred: would VDC DMA work with the Z80 controlling the bus?

The VDC doesn't have DMA in the first place, except internally on its
own isolated bus -- which could care less whether the 6502 or Z-80 is
controlling.

>  > I solved the screen i/o problem by buying an Amiga ;-).
>  
>    Problem NOT solved. Have you ever tried scrolling a 16-colour screen at 
> 9600 bps? EVen an 8-colour? The time lag between the scrolling of

A 16-color screen uses a large chunk of the Amiga's video DMA time,
leaving little for the blitter to operate in. If you're doing
interlace as well as 16 colors, video DMA even cuts into CPU time,
slowing things down even more.

With a 4-color screen there is no hardware reason for slow scrolling,
though. Two 16-K blits should occur almost instantaneously. The main
reason for slow scrolling in commercial terminal programs is that I
have never seen a commercial terminal program worth a bucket of warm
spit -- whether for Amiga, C-64, C-128, or whathaveyou. Most Amiga
term programs use the console.device for their terminal output, which
does NOT seem to be particularly speedy.

I might note that the VDC in the C-128 only has to block-move a whole
2K of RAM to scroll the screen. I suspect the VDC would have no
trouble keeping up with 19,200 baud or even 32kbaud -- although the
rest of the computer probably would get pretty stressed out at 32kbaud
(my brother says 19.2kbaud with a real ACIA sucks up about half the
CPU power of a stock C-64, so I guess 32kbaud would do the same for
the 128). If I was going to build a terminal... the VDC is such a
natural for such an application, it's a shame that Commodore will
never release it onto the consumer marketplace.

>  Geoffrey Welsh - via FidoNet node 1:221/162
>      UUCP: ...!watmath!isishq!171!izot