Interesting Fred Bowen post from COMP.SYS.CBM circa 1989

[nikoniko]

I've been mining the net for VDC info and came across this very old but interesting posting from former Commodore engineer, Fred Bowen. The discussion was about some of the shortcomings of the 128's design, and Fred pops in with some fascinating insider information. The most surprising bit to me came at the end, when he mentioned that he extended BASIC 7.0 to support graphics on the 80 column screen... and wasn't allowed to release it. I suspect there was only one person in the world was happy about that... the guy who made and sold BASIC 8.0.

From:      Fred Bowen - view profile
Date:      Tues, Mar 21 1989 11:50 am

        Hindsight is 20-20, of course... but 4 years ago we had a very
        tight schedule (less than a year for a new system, OS, several
        new custom chips, new peripherals (REUs, 1571), etc.) and a very
        strict cost target.  Some folks call it amusing, some call it a
        nightmare, and some call it the best 8-bit system built.  From
        my perspective, no machine is ever "finished."  Unfortunately,
        whatever system is at hand when the window of opportunity opens
        is what you get- just a slice of its evolution.

In article <1856.2423B...@isishq.FIDONET.ORG> (Geoffrey Welsh) writes:
>(1) Why didn't the C128 include 64K video RAM from the beginning? Considering
>that the VDC was designed to handle 2 4416s or 8 4164s (but has also proved
>workable with 2 4464s), it seemed the logical thing to do...

        When production was first ramping up, indeed the 8563 had problems
        with bitmap screens- hell, it could not even do text screens right.
        The system ROMs were release before I had bug-free silicon (hence
        some "workaround" code still exists in the Kernel).  In fact, the
        product specification called for 80-column text only, using a 6845
        (which was always our fallback if the 8563 was not working in time.
        Incidentally, the 8563 was to be used for text on both the C128 and
        the C900).  By the time the C128 was released to production, the bugs
        had been worked out of the 8563 but nothing was done to test the
        functionality of the bit map modes since they were not part of the
        product spec.  Coupled with the lack of graphic support in the OS,
        16K was more than enough video RAM for text support and kept the cost
        closer to target.  Why 80-column text at all?  The C128 was a sort of
        "joining" of the C64 and PET/8032/B-series lines.

>(2) Given that the 128's MMU could handle FOUR 64K banks of memory, why was
>that capability not used? 41256s were a commodity chip at the time and I find
>it difficult to believe that Commodore was afraid that the C64 wouldn't clear
>out its inventories of 4164s...

        A 256K machine was part of the original plan, as evidenced by the MMU
        documentation and provisions in the operating system, but the system
        was already beyond the target cost.  Hence the shift to expandability
        via the REUs.  In my opinion this is better in most repects anyway;
        the performance of the DMA device gives the system a real kick.  One
        of the chief problems of the C128 is the banking via the MMU- it's
        slow and awkward.  The current MMU does not support 256K- a revision
        to the chip would be necessary, although a prototype C256 was built
        (I have it :-).  

>(3) I find it incredibly amusing that the Z80 runs at an effective 2 MHz even
>though the VIC-II is enabled because it runs 4 MHz, 2 cycles on and 2 off.
>Would producing a 4 MHz 8502 have ben so expensive that a similar scheme could
>not have been used to allow 128 mode to support 2 MHz, even in 40-column mode?
>Better yet, why does there not seem to be a way to shut doen the VIC-II chip
>in CP/M mode and run the Z80 flat out at 4 MHz (Jeez, it would have been nice
>to do that in C128 mode as well)...

        You don't understand the bus interface at all.  The "shared bus" is
        the very heart of the VIC video processor.  Furthermore, a Z80 bus
        cycle is much different from a 65xx family bus cycle, especially its
        interface to the data bus (the Z80 actually does run during the VIC
        cycle (AEC low) but the data bus interfaces with it only during AEC
        high).  In 2MHz mode, the VIC is removed from the system, and can
        devote the full clock cycle to the processor.  So your idea is not
        without merit- and in fact a prototype with a 4MHz Z80 was built
        (I have that one, too :-).

> >Interlaced screen resolutions up to 640x600 (that's six full Doodle screens
> > complete with color) are possible.
>   That's what I thought from reading the VDC specs, but I wasn't able to
>achieve it. Since I am not a video specialist (that is probably the area where
>I lack experience most), I figured at first that it was me. However, I have
>been told by several people (including a fellow named Jeff Solomon, who claims
>to be a "Commodore rep") that there is a bug in the VDC that prevents bitmap
>and interlace modes from being enabled at the same time.

        The "bug" was in the 8563's designer's docs, not in the chip.  As
        soon as I had the chance to add more video memory (the US version of
        the C128D), I did.  Still could not add the extra banks of memory,
        faster processors, ACIA, etc. though.  Even lost the damn fan (but
        I kept the vents & mounting holes for ya).  I even extended BASIC 7.0
        graphic commands to support the 8563 bit map mode, but could not get
        the okay to release them (yes, I have that system too, which also
        happens to have a built-in ACIA :-).

>   Thanks for the info, Fred.

        You're welcome.

[RobertB]

Wow, if only we could get the schematics/code/plans for these!  Then perhaps someone could reproduce the items for retrofitting our C128s.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug

[XmikeX]

Regarding the following, as posted in this thread ~3 yrs ago :

From:      Fred Bowen - view profile
Date:      Tues, Mar 21 1989 11:50 am

[...]
So your idea is not without merit- and in fact a prototype with a 4MHz Z80 was built (I have that one, too :-).   

[...]

Still could not add the extra banks of memory, faster processors, ACIA, etc. though.  Even lost the damn fan (but I kept the vents & mounting holes for ya).  I even extended BASIC 7.0 graphic commands to support the 8563 bit map mode, but could not get the okay to release them (yes, I have that system too, which also happens to have a built-in ACIA :-).

Could one of these machines be the one that Al Anger acquired, as seen here:

http://alanger.net/comm/proto/index2.html

Please note the picture of the Z80 area.

I understand that 128, as seen above, is now in the hands of Bo Zimmerman.

Is this computer blessed/cursed with 4 MHz Z80 fix ?  =)
--

A friend of mine has been looking into Z80 on the 128.  He sent me some timing code recently. Here's some Z80 memfill-timing runs with his code:

   ; LDIR, slow mode = 10.6 cycles/byte
   ; LDI + JP = 13
   ; LDI*8 + JP = 8.63
   ; PUSH BC/DE/HL = 5.5 cycles for 2 bytes (2.75 cycles/byte) <-- applicable to 2/4/6 byte patterns

All "cycles" above always refer to 1 MHz clock, since we've used CIA timers to count @ 1 MHz ticks.
As noted elsewhere, 8502 @ 2 MHz (even on 1 MHz bus) + relocatable ZP + relocatable stack tricks can still wipe Z80's rear end in many cases.. but a 4 MHz Z80 fix.. would likely change that.  =)

  -- Full source code will be pasted once testing ends and source is properly commented.

XmX

[Hydrophilic]

I too would love to see the plans of the 4MHz Z80.  The 2MHz Z80 really hurt the C128 as a CP/M machine, in my opininion.

I've studied the bus timing off and on again over the years, but have never worked up the courage to try modifying my C128.  I mean with the VIC-II running, the Z80 must be limited to only 2MHz, but because the VIC-II can be disabled, it has always seemed it wouldn't require too much glue logic for full 4MHz with VIC-II off.

The thing that gets me is the bus interface.  As mentioned above, the Z80 actually runs when the VIC is (normally)active.  After studying the schematics and other CBM info, what I think happens is this:

Phase 1 - VIC has controll of data/address bus, Z80 runs and can fetch data latched from previous cycle(s), Z80 address lines are tri-stated
Phase 2 - Z80 and VIC are halted.  Z80 address lines enabled and data is latched (input) or gated (output)

I'm not looking at the schematics now, but as I recall, the address bus tri-stating is handled with "formal" control signals, but the Z80 Halting is done with a trick.  Specifically, the clock cycles are turned off when the VIC is active.  With no clock cycles, the Z80 is halted.  The Z80 has a /HALT input (or some equivalant) but it is not used.

The clock-cycle-turn-off "trick" is accomplished by the VIC-II which of course knows which phase the VIC is in.

For the 8502, the AEC line tells if the VIC-II is active or not.  When in 1MHz mode, things proceed similar to that described above (VIC gets 1 part and 8502 gets part 2).  When in 2MHz mode, the 8502 gets both parts (except for DRAM refresh, where the VIC becomes active for 5 cycles each raster).

So my idea has been: disconnect Z80 clock input from VIC.  Then route the raw 4MHz clock through a AND/NAND gate with AEC and output to the Z80 clock input (might need an inverter somewhere).

So then when is VIC is active, it should act like original: 1/2 time for VIC and 1/2 time for 4MHz Z80 (i.e., 2MHz Z80).  But when VIC is disabled, it should give full 4MHz to Z80.

Also I think you would have to re-wire the data latch/gate circuits.  I think they are tied to AEC which only operates at 2MHz.  Just not sure how to do it!

Also, I don't think the RAM chips can handle 4MHz.  However, we are in luck because the Z80 can not access memory faster than 3 clock ticks of 4MHz, which works out to 1.333MHz.  Since we know 2MHz works, it shouldn't be a problem.

The I/O access might be a problem, but the VIC will stretch out the 2MHz clock in these cases.  So might need some combination of 2MHz clock + AEC.  With all those cascading gates, I would image TTL LS logic would be too slow and you'd need ALS or F chips.

In regards to normal C128 cycle timing of Z80, this is very simple!  Look up cycle time in Z80 data book (often called "T states") and divide by 2.  Examples:
LDI 16 ==> 8 us
JP 10 ==> 5 us
LDI + JP = 26 ==> 13 us
LDIR 16 or 21 ==> 10.5 or 8 (repeat or not) us
PUSH BC/DE/HL 11 ==> 5.5 us
(where "us" means approximately microseconds, or more exactly cycles of 1MHz clock cycles which of course differs slightly among PAL and NTSC units)

[redrumloa]

@Hydrophilic

You will have a proof of concept modification done by the end of the weekend? 

[XmikeX]

Hydrophilic.  Agree on all points.

How many flat C-128s would be needed as sacrifice?  =)

XmX

[Hydrophilic]

No demo this year, sorry.

I am very reluctant to sacrifice my only C128 for an experiment.  Perhaps if I work out the details of the data bus latch/gate, I might work up the courage to try a modification.

Now that I think about it, the data bus issue is the only thing that has stopped me.  I would REALLY love to see Fred Bowen's schematics before I mod / kill my 128!!

[XmikeX]

I wrote "How many flat C-128s would be needed as sacrifice?  =)"

I did not write "Hey, sacrifice your only specimen!"
--

In a parallel universe, I'd do something about this with some local tech vs. my cache of flat 128s.  Local area action is important since I'd insist on continued ownership of all sacrificial lambs, even if magic smoke came out.

Before I get ahead of myself, I should check if any of these cached units still work --post +11 yrs in storage.

XmX

[StyleCHM]

Love the plan, and Im happy to send the occasional 128 as a sacrifice