Geos for Z80 4mhz
Jack Tseng
Geos use Z80 4mhz instead of ????
JT
VanessaE
The Z80's clock in the C128 runs at an effective speed of about 2 MHz (two ~4
MHz pulses, then two ~4MHz periods of no clock activity, then repeat).
That aside, after much debate in past flamewars, it was established by a
number of experienced, seasoned programmers that once you account for
memory control and architecture differences, more specialized benchmarks show
that the Z80 needs around the same number of cycles as the 6502/8502, but
2.5x to 3x as many cycles as the 6502/8502 to handle a real-world task.
So when clocked at the same speed, the Z80 is usually far slower.
Had the Z80 been running at the full 4 MHz at all times (and assuming it
could access all ROMs and I/O devices at that speed), it would have been able
to pull ahead of the 8502 by a small but measurable margin.
--
"There are some things in life worth obsessing over. Most
things aren't, and when you learn that, life improves."
http://starbase.globalpc.net/~ezekowitz
Vanessa E <vaDEneLEssaTE...@gmail.com>
Steve Nickolas
It would be even slower. IIRC, 4 MHz Z80 is generally considered to be
about on par with a 1 MHz 6502.
-uso.
BruceMcF
wrote:
> Had the Z80 been running at the full 4 MHz at all times (and assuming it
> could access all ROMs and I/O devices at that speed), it would have been able
> to pull ahead of the 8502 by a small but measurable margin.
That's what wait states were for, to allow the processor clock to out-
run the slow memory clocks of the mid/late 70's.
Indeed, I wished they could have hung it off the 8MHz dot clock with
wait states to synchronize it to the 6502 system clock.
Piotr "Curious" Slawinski
not really. when it comes to i/o z80 is indeed slower - it uses unnessesary
wait states for in/out instructions. it's clock should be also considered
divided by 4, so 4mhz z80 is qbout equal to 6502 ... but z80 has more
registers , can perform 16 bit inc/dec, can operate in memory adressing
modes (i.e. load hl,adress(16bit) , load (hl),a(8bit accumulator) ) which
all makes z80 much more efficient - 6502 has to perform all memory
operations in 8 bit split operations, which means at least twice as much
instructions.
also z80 has several 'bundled' instructions which help saving memory, like
ldir. while they are slow, usage of them greatly reduces code size in places
where speed is not a concern, leaving room for code where one needs i.e.
loop unwinding, or duff arrays.
otoh z80 code consumes more memory in general (longer opcodes) and puts more
stress on memory bus (more to-ram cycles required to prefetch instructions)
ps. frankly i think easiest way to make geos run lightning fast is to run it
using ... emulator ;)
--
Tinkerer Atlarge
> On Dec 3, 11:11 am, VanessaE <vaDEneLEssTEaezeTHkoISw...@gmail.com>
> wrote:
>
> > Had the Z80 been running at the full 4 MHz at all times (and assuming it
> > could access all ROMs and I/O devices at that speed), it would have been
> > able to pull ahead of the 8502 by a small but measurable margin.
>
> That's what wait states were for, to allow the processor clock to out-
> run the slow memory clocks of the mid/late 70's.
I think it might have had something to do with the need to support
40-column mode. IIRC the Z80 was only clocked during phase 2 because the
VIC II chip needed unrestricted access to memory during phase one.
BruceMcF
> BruceMcF <agil...@netscape.net> wrote:
> > That's what wait states were for, to allow the processor clock to out-
> > run the slow memory clocks of the mid/late 70's.
> I think it might have had something to do with the need to support
> 40-column mode. IIRC the Z80 was only clocked during phase 2 because the
> VIC II chip needed unrestricted access to memory during phase one.
AFAIU, the wait state is not used as effectively as it could be, which
could have been either the time, experience with the Z80 bus, or the
cost of getting the circuit right for the /WAIT line.
But if you are holding the /WAIT low at the right time, the Z80 runs
through its internal operation T-cycles and then waits until /WAIT is
released before it treats a memory access instruction as being
finished. You have a longer M-cycle required for the first memory
cycle in an instruction, the M1 cycle, which is signaled by the /M1
line, and each memory access of course involves either the /RD or the /
WR line going low.
So when /RD and /WR are both high, you can just let the clock run, and
then wait the memory for memory accesses when /RD or /WR go low out of
phase with the system clock. Memory bus (M) cycles in the Z80 require
different numbers of processor clock (T) cycles, from three to six ...
and some M-cycle operations are internal to registers except for the
opcode, so under the "don't wait until it needs to", the 3 M-cycle
internal register address operations would get the biggest speed
boost. For example, a lot of the inner loop for a multiply are those
kind of instructions.
The Z80 user manual ...
http://www.zilog.com/docs/z80/um0080.pdf
... gives example of use wait states to stretch a memory access, but
not to delay the start of a memory access, so there might be buffering
required in there, which would drive the part count up.
commodorejohn
<curi...@bwv190.internetdsl.tpnet.lp> wrote:
> not really. when it comes to i/o z80 is indeed slower - it uses unnessesary
> wait states for in/out instructions.
the 8502? I could be wrong, but that's what I thought I remembered.
It's my understanding that the general problem with the 128's Z80 is
less a technical-capability issue and more that it was awkwardly
kludged into the design at the behest of management - from Bil Herd's
story, it sounds like they had a heck of a time just getting it
working at all.
BruceMcF
I hadn't heard that but it makes a lot of sense. The idea of having CP/
M would have been great if it had been implemented well, but trying to
patch it into an already designed system is hard, especially for
people who'd been designing a memory-clocked system for a memory-
clocked processor.
A 1MHz processor, with refresh in the alternate phase (P=processor,
R=refresh), which is being retained for some access for backward
compatibility:
P R P R P R ...
If you have an 8Mhz clock available, and can access memory each second
clock, when the 1MHz subsystem does not have it:
T1 T2 T3 T4 T5 T6 T7 T8
M1 Mx M2 Mx R1 R2 R3 R4
Then if you /WAIT to synchronize /RD and /WR to the 1MHz clock, you
have 6 T-cycles for each memory clock, and the Z80 can finish all
memory cycles in six processor cycles or less, and when you are lucky,
an instruction has a memory cycle that accesses the register file
rather than RAM, and it can just run straight through on those.
Its obviously faster for the CPM/M to give the VIC 64K, the Z80 64K
(since the Z80 can refresh too), with a DMA into the VIC 64K to swap
blocks of bytes for I/O, and the C128 mode the ability to bank into
either, with the C64 subsystem doing terminal duties in CP/M mode in
parallel with the Z80 and the Z80 making a ramdisk available to the
C64 mode, and then you can make memory expansion off the Z80 bus
without having to build DMA circuitry into the memory expansion.
But that would require building it in from the start, rather than
adding a bag to the box at the end.
Tinkerer Atlarge
> On Dec 5, 9:50 am, commodorejohn <commodorej...@gmail.com> wrote:
> > On Dec 4, 4:14 pm, "Piotr \"Curious\" Slawinski"
> > <curi...@bwv190.internetdsl.tpnet.lp> wrote:
> > > not really. when it comes to i/o z80 is indeed slower - it uses
> > > unnessesary wait states for in/out instructions.
>
> > IIRC, didn't the 128 use memory-mapped I/O for the Z80 as it did for
> > the 8502? I could be wrong, but that's what I thought I remembered.
>
> > It's my understanding that the general problem with the 128's Z80 is
> > less a technical-capability issue and more that it was awkwardly
> > kludged into the design at the behest of management - from Bil Herd's
> > story, it sounds like they had a heck of a time just getting it
> > working at all.
>
> I hadn't heard that but it makes a lot of sense. The idea of having CP/
> M would have been great if it had been implemented well, but trying to
> patch it into an already designed system is hard, especially for
> people who'd been designing a memory-clocked system for a memory-
> clocked processor.
There is a lot of duplication in C128 terminology which could make it
difficult for others to follow this type of discussion, "mode" and
"refresh" being two prime examples.
64 mode and 40-column mode, strictly speaking, are not the same thing
even though they made use of the same display hardware.
64 mode could output only to a 40-column display whereas 128 mode and
the so-called CP/M mode could operate in either 40-column or 80 column
modes. The difference was the video controller chip being used.
40 column mode also came in PAL and NTSC, depending on the TV standard
of the country where the C128 was purchased.
128 mode also had overriding FAST and SLOW modes, but I'm not sure how
or if CP/M mode took advantage of FAST mode. In 128 mode, if you
switched to FAST mode while in 40-column mode, the screen would blank to
the border colour whereas the 80-column vdc was not affected, allowing
80-column mode to continue working while the cpu ran twice the "normal"
(= C64) speed. (That implied to me that the VIC-II chip had relinquished
phase 1, thereby losing its opportunity to access Screen Memory.). I am
not sure if the same applied to the Z80 in CP/M mode or whether any such
limitation I vaguely remember was a function of hardware or software.
> A 1MHz processor, with refresh in the alternate phase (P=processor,
> R=refresh), which is being retained for some access for backward
> compatibility:
>
> P R P R P R ...
In 40 column mode the VIC-II "owned" phase one. It used it like a C64
for screen as opposed to ram refreshes, although maybe it did both.
Although 40-column "Colour memory" had its own dedicated ram, 40-column
"Screen memory" was located in the C128's regular dram. Both were memory
mapped within the cpu's 16-bit address space even though Color Memory
was a dedicated chip only 4 bits wide. The normal way to access either
Screen or Color Memory in Z80 mode was via a 16-bit address in the z80's
BC register. Even 8-bit indirect I/O instructions specifying a "port
number" via the C register silently combined it with the B register to
obtain a 16-bit memory-mapped address. (Or, put another way, the BC
address register could be split into two independently addressable
registers, B = memory page number and C = byte offset).
I gained the impression the Z80's R register was not utilized for
refreshing memory although I can't remember what gave me that
impression.
Cheers
Piotr "Curious" Slawinski
> The Z80 user manual ...
>
> http://www.zilog.com/docs/z80/um0080.pdf
>
> ... gives example of use wait states to stretch a memory access, but
> not to delay the start of a memory access, so there might be buffering
> required in there, which would drive the part count up.
for delaying memory (and other i/o) accsss one uses /BUSRQ and gets
confirmation of z80 going high-Z by recieving /BUSACK . most famous example
of it's use is 'slomo' circuit but it's also used by various dma circuits.
unfortunatelly BUSRQ is quite slow, and ppl usually merely hacked clock
lines (i.e. in zx-spectrum and it's clones) when i.e. delay related with
videoram priority was required.
--
Merman
Because that would have involved re-coding the whole GEOS system and
its applications in Z80 code instead of 6510 code...
David Murray
ran with the Z80 other than CP/M?
BruceMcF
> I gained the impression the Z80's R register was not utilized for
> refreshing memory although I can't remember what gave me that
> impression.
That is at least what I've assumed above, I have no idea whether I
ever knew it as a fact or am just presuming. It was the mid-80's since
I found the innards of the C128 fascinating, and its easy to
misremember things over that span.
BruceMcF
The Wikipedia doesn't say so explicitly, but make it seem to be
hardware ~ and there definitely were more than enough CP/M gurus at
that point in time to fix the problem if it was only software:
QUOTE
Unfortunately, the C128 ran CP/M noticeably slower than most dedicated
CP/M systems, as the Z80 processor ran at an effective speed of only 2
MHz (instead of the more common 4.77 MHz), and because it used CP/M
3.0, whose complexity made it inherently slower than the earlier, more
widespread, CP/M 2.2 system. From the source code of the C128 CP/M
implementation, it is clear that the engineers originally planned to
make it possible to run CP/M in the "fast" mode as well, with the 40-
column output turned off and the Z80 running at an effective 4 MHz;
however, this feature did not correctly function on the first
generation C128 hardware.
UNQUOTE
http://en.wikipedia.org/wiki/Commodore_128#CP.2FM_Mode
David Murray
> however, this feature did not correctly function on the first
> generation C128 hardware.
> UNQUOTEhttp://en.wikipedia.org/wiki/Commodore_128#CP.2FM_Mode
I wonder if that means the 128D could run the CPU faster?
xlar54
> Out of curiosity, were there ANY programs designed for the C128 that
> ran with the Z80 other than CP/M?
I have wondered this myself. I cant think of any reason that you
couldnt write code soley for the Z80 processor, but it seems no one
ever did, except for CPM.
Tinkerer Atlarge
> Out of curiosity, were there ANY programs designed for the C128 that
> ran with the Z80 other than CP/M?
Not that I ever heard of, although I made no efforts to find out. I
gained my little bit of Z80 experience extending the C128's built-in
machine language monitor to also work with the Z80. Most of it was
written in 8502 machine code although I used the Z80 for executing the
user's z80 code and accessing Z80 registers.
Using the Z80 to access memory for Z80-targetted commands also proved
necessary because the built-in monitor used 20-bit addresses. The upper
4 bits represented the bank number. Some banks were configured
differently in Z80 mode than in 128 mode. For example I had to use bank2
to enable z80 user access to the normal 128 mode text screen becauses
the BIOS chip overlay the bottom 4K of ram in bank 0 but not in the
nominally identical bank 2.
Also an image of "Color Memory" appeared at 0x1000 in some banks in z80
mode, making it accessible to z80 block instructions like LDIR, whereas
only specialized I/O instructions like IN and OUT could access it at its
normal location in the dedicated I/O block D000-Dfff.
I refer to it as Z80 mode rather than CP/M mode because what I did had
nothing to do with CP/M. In fact it overwrote the CP/M BIOS ram,
rendering even the Z80 ROM's built-in I/O routines unusable from within
the monitor.
As my main interest was exploring the C128's internals, I never got
around to looking at GEOS.
Cheers
Tinkerer Atlarge
I expect it would be a simple exercise in translating the source code
from one cpu's assembly language to the other.
You can organize your code to run from either Z80 mode or 128 mode at
your discretion and run it using either mode's normal commands.
Mode switches are trivial. You would switch back to the 8502 to perform
Kernel routines. That would typically involve nothing more than
inserting small wrapper functions around the Kernal calls used by the
existing code.
I expect GEOS would have its own custom routines for screen output. If
you choose an appropriate configuration you can write direct from z80 to
screen memory (40 col) or vdc (80 col) without any need to alter modes
or contexts.
You might want to support both screen modes even though the extra speed
you are after would not be available in 40 column mode. I can't confirm
whether it is available to the z80 in 80 column mode either. You would
need to conduct your own speed tests before spending too much time on
the GEOS source code.
Another consideration might be that a lot of commercial 128 mode
software was previously ported from the C64. That sometimes resulted in
a bank-switching scheme optimised for making the port easy for the
programmer rather than to take advantage of the C128's extra hardware.
If such turned out to be the case, it could nullify some of the speed
boost you are hoping to achieve unless you are also prepared to look at
revising the previously implemented bank switching scheme.
Cheers
David Murray
> I refer to it as Z80 mode rather than CP/M mode because what I did had
> nothing to do with CP/M. In fact it overwrote the CP/M BIOS ram,
> rendering even the Z80 ROM's built-in I/O routines unusable from within
> the monitor.
Hmmm.. makes me wish I hadn't sold my 128. Now I'm sort of wanting
to write some code for the Z80. I wonder how hard it would be to take
some simple program from another system that uses the Z80 such as the
Sinclair ZX81 or MSX and make it run on the C128.
In fact, a more interesting project, one that I'm nearly 100% certain
could be achieved would be to write an emulator for the ZX81 that runs
on the C128. Being how little RAM and lack of a graphics mode, this
should be very doable. Don't suppose anyone has the source code to
the ROM BASIC inside the ZX81 do they?
David Murray
> could be achieved would be to write an emulator for the ZX81 that runs
> on the C128. Being how little RAM and lack of a graphics mode, this
> should be very doable. Don't suppose anyone has the source code to
> the ROM BASIC inside the ZX81 do they?
Actually.. I just found the memory map and source code to the ZX81.
I'm fairly certain this could be done. The ZX81 only uses 16K for
both ROM and RAM. That means the entire project could fit in a single
bank. Of course, the Z80 probably doesn't use banks the same way as
the 8502 anyway. All that would essentially need to be done is:
1) Recreate the ZX81 character set
2) remap the keys
3) change the I/O routines in the ZX81 ROM so that characters are
displayed on the VIC (or VDC?) and keys are read from the C128
keyboard.
Have I missed anything?
commodorejohn
> Out of curiosity, were there ANY programs designed for the C128 that
> ran with the Z80 other than CP/M?
On Dec 6, 4:13 pm, BruceMcF <agil...@netscape.net> wrote:
> On Dec 5, 11:59 pm, tinke...@optusnet.com.au (Tinkerer Atlarge) wrote:
> > I am not sure if the same applied to the Z80 in CP/M mode or whether any such limitation I vaguely remember was a function of hardware or software.
>
> The Wikipedia doesn't say so explicitly, but make it seem to be
> hardware ~ and there definitely were more than enough CP/M gurus at
> that point in time to fix the problem if it was only software:
Yes and no. The rather speed-crippled Z80 certainly didn't help
things, but the software was partly at fault as well - the 128-
specific BIOS was not very well-written, and a later third-party re-
write sped things up significantly.
On Dec 6, 11:34 pm, tinke...@optusnet.com.au (Tinkerer Atlarge) wrote:
> xlar54 <scott.hut...@gmail.com> wrote:
> > On Dec 6, 1:40 pm, David Murray <adri...@yahoo.com> wrote:
> > > Out of curiosity, were there ANY programs designed for the C128 that
> > > ran with the Z80 other than CP/M?
>
> > I have wondered this myself. I cant think of any reason that you
> > couldnt write code soley for the Z80 processor, but it seems no one
> > ever did, except for CPM.
>
> I expect it would be a simple exercise in translating the source code
> from one cpu's assembly language to the other.
Not at all. The Z80 and 6502/8502 are pretty significantly different
designs - the Z80 is way more register-oriented, while the 6502 is all
about memory operations, but the Z80 is much more flexible in its
memory addressing than the 6502 unless you're using zero-page
pointers, but the 6502 uses far fewer cycles per instruction...you
could probably implement some kind of translator software, maybe, but
getting anything near efficient conversion would take pretty much a
full re-write.
Tinkerer Atlarge
I am very much stabbing in the dark here as I know nothing about the
ZX81 and have never looked at trying to emulate another computer myself.
I mainly perceive the Z80 as just one of many interesting chips which
can be activated by writing to the appropriate D-block register. Thus my
perception of the Z80 is very Commodore centric.
I seem to remember that the C128 has a lot of new kernal style calls in
its Screen Editor which will hopefully cover much of what you want.
Here are some things which MIGHT warrant a closer look.
At what level does the ZX81 support bit-mapped graphics?
Without CP/M you will probably need to set the Z80 up to handle timer
IRQs which occur while it is running. You might need to pass them on to
the 8502 or handle them in an identical way if the keyboard is to work
in Z80 mode. Z80 firmware or maybe even the Kernal might or might not
support this.
Do the two computers' screen dimensions match? If not, you might be able
to match them up for text output using the 128 mode ESC T and ESC B
functions. Also, IIRC the 80-col VDC had some adjustable display
parameters.
Disk and file formats. How compatible are they? Do ZX81 disks rely on
MFM or GCR recording? You might need to extend your search to Z80
firmware and/or CP/M or perhaps patch in the ZX81's own low level disk
drivers if you want to use disks not normally compatible with the C128.
That is all I can think of right now. Probably others will be able to
find some gaps.
Cheers
Tinkerer Atlarge
> the 128-specific BIOS was not very well-written, and a later third-
> party re-write sped things up significantly.
vm appreciate if you could provide more info on when/where/what was
done.
> > I expect it would be a simple exercise in translating the source code
> > from one cpu's assembly language to the other.
> Not at all. The Z80 and 6502/8502 are pretty significantly different
> designs - the Z80 is way more register-oriented, while the 6502 is all
> about memory operations, but the Z80 is much more flexible in its
> memory addressing than the 6502 unless you're using zero-page
> pointers, but the 6502 uses far fewer cycles per instruction...you
> could probably implement some kind of translator software, maybe, but
> getting anything near efficient conversion would take pretty much a
> full re-write.
I was assuming it would be done by hand rather than using a translator
program. Doing a one-to-one translation of 6502 instructions into z80
instructions is not what I was thinking of, but it could possibly be
done by adding macros to the language. That might be the quickest way to
translate it manually, but it would end up with a slower rather than a
faster program and a risk of exceeding available memory.
What I was alluding to was a manual translation at the code block level
-- the level where blocks of code are typically set off with full-line
comments in the source code. Just how mechanical or inspired a
translation occurred would depend on the programmer's level of
familiarity with both CPUs, GEOS, the C128 architecture, and the time he
had available for experimenting and revising his approach on the job.
One fairly mechanical technique (if you chose to do it that way) would
be to reassign some 8502 memory variables to z80 registers. The obvious
candidates are high-use variables, but it might turn out that keeping
the registers loaded with values which needed to survive frequent
context switches would be a more efficient approach in some situations.
Bank switching can introduce a significant overhead if you bankswitch
every byte of data the way BASIC 7.0 does. Arranging things so that code
and related data are within the same configuration could itself result
in a significant performance boost.
For someone with no prior experience, just getting something to work,
regardless of how ponderously, might also be the best way of gaining
enough initial experience to get the project seriously started.
As for a full re-write, yes, that is the way I would probably want to do
it myself, unless I decided that the original software already used what
appeared to be an optimal approach. In that case I would probably prefer
taking advantage of work already done.
Cheers
David Murray
> IRQs which occur while it is running. You might need to pass them on to
> the 8502 or handle them in an identical way if the keyboard is to work
> in Z80 mode. Z80 firmware or maybe even the Kernal might or might not
> support this.
Yeah, I've been pondering whether to have the IRQ routine run on the
8502 and use the standard kernal routines for the keyboard or to try
recreate those routines on the Z80.
> Do the two computers' screen dimensions match? If not, you might be able
> to match them up for text output using the 128 mode ESC T and ESC B
> functions. Also, IIRC the 80-col VDC had some adjustable display
> parameters.
No, the ZX81 used a 32x24 layout, which shouldn't be too hard to work
around. It also had no official graphics mode, everything was text
made out of 64 characters in ROM that cannot be redefined. However, a
very few games were able to used a hacked graphics mode, but I
wouldn't worry about those.
> Disk and file formats. How compatible are they? Do ZX81 disks rely on
> MFM or GCR recording? You might need to extend your search to Z80
ZX-81 pretty much used tape-loading only. I would imagine it could be
setup to read ZX-81 tapes but I doubt I'd go through the trouble. I'd
probably create some kind of custom routine to read binary files from
disk and plop them right into RAM.
This is all theoretical, of course. The ZX81 is so darned primitive,
it really is one of the easier systems to emulate. It doesn't even
have a real graphics chip. The screen is actually drawn pixel-by-
pixel with careful timing of the Z80. This makes the Z80 run very
slowly. So in fact, the software should run lightening fast on the
C128 since we can use dedicated video hardware.
Tinkerer Atlarge
> > Disk and file formats. How compatible are they? Do ZX81 disks rely on
> > MFM or GCR recording? You might need to extend your search to Z80
>
> ZX-81 pretty much used tape-loading only. I would imagine it could be
> setup to read ZX-81 tapes but I doubt I'd go through the trouble. I'd
> probably create some kind of custom routine to read binary files from
> disk and plop them right into RAM.
Or you could embed normal Kernal calls within Z80 wrappers which handle
the mode switch, and let the 128 mode Kernal do the grunt work using
Commodore's normal filesystem. Tap in to the roms at the right point and
you'll get stop key and error messages thrown in for free. You can also
make shortcuts like writing from the z80 direct to the same locations
where Kernal routines like SETNAM and SETBANK save their args, thereby
avoiding unnecessary overhead.
> This is all theoretical, of course. The ZX81 is so darned primitive,
> it really is one of the easier systems to emulate. It doesn't even
> have a real graphics chip. The screen is actually drawn pixel-by-
> pixel with careful timing of the Z80. This makes the Z80 run very
> slowly. So in fact, the software should run lightening fast on the
> C128 since we can use dedicated video hardware.
You might have to add a delay loop somewhere to slow things down so
users realize it actually did something :-)
I don't want to spoil your fun by giving away too much, but another
potentially baffling gotcha is that both processors have a one-byte
pre-fetch queue known as a pipeline. That means the currently inactive
cpu has already fetched but not yet executed the opcode of the
instruction it will execute next time you start it.
If you come across seemingly redundant NOP instructions, they are
probably there to fill that inaccessible spot in the pipeline. You
steer the other processor by overwriting the first instruction it will
fetch next time you restart it by getting the current one to stop. There
will always be one processor executing instructions. The MMU mode-switch
toggles between CPUs without the computer so much as missing a beat.
commodorejohn
> commodorejohn <commodorej...@gmail.com> wrote:
> > the 128-specific BIOS was not very well-written, and a later third-
> > party re-write sped things up significantly.
>
> vm appreciate if you could provide more info on when/where/what was
> done.
variety of speed-up patches for the BIOS at
http://www.zimmers.net/anonftp/pub/cpm/sys/c128/system/index.html and
http://www.zimmers.net/anonftp/pub/cpm/sys/c128/patches/index.html
(there's one for the BDOS as well, but that's just rewriting it to
take advantage of all the features the Z80 added over the 8080, so
that doesn't really have to do with the 128 specifically.)
BruceMcF
> I have wondered this myself. I cant think of any reason that you
> couldnt write code soley for the Z80 processor, but it seems no one
> ever did, except for CPM.
Not much point, since there is not going to be a speed benefit ~ you
program in CP/M to do something supplementary to existing CP/M code.
If you could work out a way for the Z80 to run in parallel with the
8502 in C64 mode, there might be a point, since you'd effectively have
parallel processing. Say set up a multiply for the Z80 to perform, go
on and do something else, come back and fetch the multiple ... but
that would require a hardware hack of some kind, and since on hardware
I would be challenged by stuff that the designers of the C128 would
see as a cakewalk, I would not imagine tackling something they
struggled with.
Dombo
Not compared to a ZX81 in FAST mode ;-)
Alan Jones
No. The 128D was just a repackaging of the 128, with 64K if video
memory standard, integrated 1571 drive, and some cost cutting redesign
with no impact on functionality.
The C64/128 was never a "serious" computer, rather it was a hugely
successful computer for for hobbiests and hardware hackers. There
were a number of hardware hacks for the 128 mode, but nothing for the
often neglected Z80. I've often thought that the Z80 mode could be
significantly enhanced, even without resorting to a CMD SuperCPU type
enhancemment. With a stock 128, anything you could do in Z80 mode
could be done juast as fast or likely faster in 128 Mode, except for
actualy running legacy Z80 code, particularly CP/M.
CP/M did work well enough on the 128. I do note that CP/M tended to
be more closely coupled to disk I/O and use than with 128 mode, and
even fast mode drive access was not as fast as more serious CP/M
machines. The REU of course provided a wonderful RAM drive. CBM's
inteligent disk drives were quite useful to the CP/M community. A
C128 was the machine to have to read and rewrite CP/M disks from many
different computer systems.
CP/M use itself was declining even as C128 users were increasing.
Still, some critical utilities were available in CP/M before they were
available in native C64/128 modes. For a time, my internet access
came via an indirect route that required me to extract PKzip files.
They kept increasing the version number of PKzip that they used, and I
had to go into CP/M to unip them, and then go back to 128 mode. Big
Blue Reader was my favorite utility. Eventualy, I had to buy a used
386 PC, just to do the unzipping. It was a sad day when I accidently
formated my BBR disk. Rather than buy another BBR disk, I got by with
LRR, but that was the end of my easy use of CP/M.
I never used Geos, other that just to take a look at it from time to
time. I was essentualy just a me-too GUI. The quetion to ask is if
there was any GUI sytem available for CP/M, not just Geos. The core
CP/M systems are fairly standard (2.0, 2.2 + 3.0, etc.) but the screen
interface is generaly customized for each machine, so a CP/M GUI would
not likely be standard or widely accepted.
Alan
Jim Brain
>>> It's my understanding that the general problem with the 128's Z80 is
>>> less a technical-capability issue and more that it was awkwardly
>>> kludged into the design at the behest of management - from Bil Herd's
>>> story, it sounds like they had a heck of a time just getting it
>>> working at all.
I just saw this, so I'll respond here. I wouldn't say it was awkwardly
kludged into the system at the behest of management. Management didn't
want to do it at all.
Bil tells the story better, but essentially, the Marketing folks, in an
effort to fill out bullet points for "features", decided to tout CP/M
compatibility. The rationale was that C128 buyers could purchase the
C64 CP/M cart and thus the feature would be satisfied.
But, CBM Engineers knew the CP/M cart was horrid, abusing the bus, and
didn;t even work on newer models of the C64. But, the mandate was to
make it work.
Bil, being the maveric he was (and maybe still is), finally turned the
problem on it's ear and simply designed a Z80 into the motherboard.
This solved the problem for him. He no longer needed to be compatible
with the horrid CP/M cart, as it was superfluous. I'm sure, though Bil
doesn't state as such in his stories on the subject, that Bil initially
fought an uphill battle with the new design, as CBM was notoriously
stingy and the Z80 would have added a non trivial cost to the design.
But, though I am sure there were other ways to solve the "Magic Voice"
cart compatibility dilemma (Google for it), Bil justified the existence
of the Z80 in solving for a whole class of carts that messed with the
bus lines. Since it was now "needed" to support Marketing's requirement
of "C64 compatibility", he won the battle.
> 128 mode also had overriding FAST and SLOW modes, but I'm not sure how
> or if CP/M mode took advantage of FAST mode. In 128 mode, if you
> switched to FAST mode while in 40-column mode, the screen would blank to
> the border colour whereas the 80-column vdc was not affected, allowing
> 80-column mode to continue working while the cpu ran twice the "normal"
> (= C64) speed. (That implied to me that the VIC-II chip had relinquished
> phase 1, thereby losing its opportunity to access Screen Memory.). I am
> not sure if the same applied to the Z80 in CP/M mode or whether any such
> limitation I vaguely remember was a function of hardware or software.
VIC-IIe still accesses in Phase I in FAST mode, as something had to
refresh DRAM. But, as you note, it disabled the 40 column screen,
meaning it did not fetch any RAM during Phase 1, and it did not steal
anyt Phase 2 cycles for sprites and such.
This is why the Z-80 can only have two cycles during the high half of
the Phi2 clock.
I believe this was a function of expedient engineering of the VIC-IIe.
Although designers no doubt made some small changes to the VIC-II core
to make the VIC-IIe, I don't think they messed with it that much, save
to add the additional registers and things needed to prep it for a 2MHz
fabrication technique. Of course, this means that the VIC-II maintains
it's need to take over half of the main clock cycle, no matter the speed.
Jim
Jim Brain
It would be nice to put some additional context around this, because
making the machine do 4MHz would have required quite a bit of
engineering effort. In light of the story on how the Z80 came to be
included in the C128, I can't imagine any of the engineering staff
caring enough. Maybe they are using "engineer" as a placeholder for the
CP/M software developer, whose name I can't recall at the moment. Maybe
he was told by CBM to make it work at 4MHz, in case the code was used in
a more standard CP/M machine, or maybe it was a requirement of the DRI
contract, that all changes had to be port-able to a normal 4+MHz CP/M
machine.
Jim
Joel Koltner
news:m3icg6pd9oonuvbam...@4ax.com...
> The C64/128 was never a "serious" computer, rather it was a hugely
> successful computer for for hobbiests and hardware hackers.
...and gamers...
And despite the fact that, yeah, they weren't really "serious" computers,
plenty of people still did plenty of serious work on them -- many a student's
first word processor was on a C64.
> I never used Geos, other that just to take a look at it from time to
> time. I was essentualy just a me-too GUI.
Not really -- it was the only GUI that had a "serious" :-) company behind it:
There were far more applications for GEOS than any other GUI environment for
the C/64, and this was only doable because GEOS was trying very hard to be a
complete OS and not just a pretty interface.
> The core
> CP/M systems are fairly standard (2.0, 2.2 + 3.0, etc.) but the screen
> interface is generaly customized for each machine, so a CP/M GUI would
> not likely be standard or widely accepted.
Agreed. Given that CP/M came out in the early '70s, this is understandable.
BruceMcF
> It would be nice to put some additional context around this, because
> making the machine do 4MHz would have required quite a bit of
> engineering effort.
Speeding up the Z80 processor clock relative to the system bus clock
seems like it would have been more effective in speeding up things
like spreadsheets and DBASE, they are processor clock bound rather
than memory bus access bound. An 8MHz processor clock Z80 on a 1MHz
system bus seems like it ought to be faster in multiply-intensive
operations than a 2MHz processor/system bus 6502.
Alan Jones
<zapwireD...@yahoo.com> wrote:
>"Alan Jones" <ala...@nospam.mchsi.com> wrote in message
>news:m3icg6pd9oonuvbam...@4ax.com...
>> The C64/128 was never a "serious" computer, rather it was a hugely
>> successful computer for for hobbiests and hardware hackers.
>
>...and gamers...
So how many professional C64 gamers were there?
>And despite the fact that, yeah, they weren't really "serious" computers,
>plenty of people still did plenty of serious work on them
I did develop some "serious" hobby related aps for my C64, and I even
took my C64 to grad school and used it to solve some engineering
homework assignments. This was not a typical usage, but since I had
it and knew how to use it, I did.
-- many a student's
>first word processor was on a C64.
Sure, but every system had usable word processors. For a time the C64
was at the forefront of home telecommunications. But these and many
other aps are I/O bound, and the performance of the computer hardly
mattered. I was happy writing letters and reports on my C128 with
Paperclip III, but if I had to write and submit a real book, I would
probably use Wordstar under CP/M. (I never could get TeX to work on
the 128.) )
>
>> I never used Geos, other that just to take a look at it from time to
>> time. I was essentualy just a me-too GUI.
>
>Not really -- it was the only GUI that had a "serious" :-) company behind it:
>There were far more applications for GEOS than any other GUI environment for
>the C/64, and this was only doable because GEOS was trying very hard to be a
>complete OS and not just a pretty interface.
True enough. I was only trying to communicate the extent of my
familiarity with GEOS. At this point, I can barely pretend to have
familiarity with CP/M. You do bring up the major problem with GEOS.
It could not run nonGeos programs, and it was more difficult for users
to develop their own Geos programs. Even the disk access and format
was a bit unique to Geos. I think a large part of that had to due
with an anti piracy philosophy, rather than efficiency and robustness.
Furthermore, given that CBM drives were slow, a cartridge based Geos
system would have made more sense. The whole point of putting the Z80
CPU in the 128 to enable it to run CP/M and the existing CP/M
programs. Running something like Geos on the Z80 makes no sense.
Alan
Jim Brain
Regrettably, it's impossible to do beyond 3x or 4x. I think nearly all
of the Z80 opcodes had to access memory at least that often. And, since
the access would have not fallen neatly on such boundaries, all kinds of
wait states would have been required. Blech!
Still, my point was that the Z-80 was designed into the C128 basically
because it was easier than trying to support the crappy CP/M cart. I
find it hard to believe that the CBM Engineering staff actually cared
about the Z80 beyond that. Heck, Bil notes that CBM Europe (or some
portion thereof), threatened to rip the Z80 off of each C128 landing in
their country. Doesn't sound like a company too interested in 4MHz CP/M.
But, hey, I can be wrong. Maybe we can scare up Bil Herd and he can
tell us the full scoop.
BruceMcF
> Regrettably, it's impossible to do beyond 3x or 4x. I think nearly all
> of the Z80 opcodes had to access memory at least that often.
There are from three to six processor clocks required between memory
clock, but not every memory clock requires a memory access, since some
memory clock accesses are to the internal register file.
> And, since
> the access would have not fallen neatly on such boundaries, all kinds of
> wait states would have been required. Blech!
But the generation of the wait state is straightforward, latching the /
WAIT line low when either /RD or /WR is brought low out of phase, and
then releasing it when memory is in phase. As long as the /M1 cycle
can complete in a single clock when the wait state releases, then
since the processor will always be *in* a wait state when /M1 goes low
(since AFAICT there are not eight processor clock operations), it
would only be /RD /WR generating a /WAIT until the clock phase
releases it.
That would be part of the POINT of aiming for 8Mhz, to get /M1 fast
enough that there is only one wait state required.
> Still, my point was that the Z-80 was designed into the C128 basically
> because it was easier than trying to support the crappy CP/M cart. I
> find it hard to believe that the CBM Engineering staff actually cared
> about the Z80 beyond that. Heck, Bil notes that CBM Europe (or some
> portion thereof), threatened to rip the Z80 off of each C128 landing in
> their country. Doesn't sound like a company too interested in 4MHz CP/M.
> But, hey, I can be wrong. Maybe we can scare up Bil Herd and he can
> tell us the full scoop.
I wasn't saying that they should have been. I was talking about how to
have done the Z80 inside the C128 so that CP/M mode in the C128 was
not so glacially slow.
Indeed, a better CP/M cart, with its own RAM and talking to the C128
through one of the cartridge I/O pages, and with a 6502 ROM to provide
the terminal and disk support code, seems like it would have been a
better solution, and would allow ticking the exact same "supports CP/
M!!" checkbox. And the sync would have been designated memory
locations in the page, $IOx+$FE where the CP/M gave the function
request code, after filling in the request data, and $IOx+$FF where
the C128 wrote the result code, after.filling in the result data.
Jim Brain
> But the generation of the wait state is straightforward, latching the /
> WAIT line low when either /RD or /WR is brought low out of phase, and
> then releasing it when memory is in phase. As long as the /M1 cycle
> can complete in a single clock when the wait state releases, then
> since the processor will always be *in* a wait state when /M1 goes low
> (since AFAICT there are not eight processor clock operations), it
> would only be /RD /WR generating a /WAIT until the clock phase
> releases it.
they were too expensive.
> I wasn't saying that they should have been. I was talking about how to
> have done the Z80 inside the C128 so that CP/M mode in the C128 was
> not so glacially slow.
blurb in Wikipedia (which I know is the Gospel Truth(tm).
> Indeed, a better CP/M cart, with its own RAM and talking to the C128
> through one of the cartridge I/O pages, and with a 6502 ROM to provide
> the terminal and disk support code, seems like it would have been a
> better solution, and would allow ticking the exact same "supports CP/
> M!!" checkbox. And the sync would have been designated memory
> locations in the page, $IOx+$FE where the CP/M gave the function
> request code, after filling in the request data, and $IOx+$FF where
> the C128 wrote the result code, after.filling in the result data.
"C128 Dev Team, We've already got a CP/M cart. No need for a new one.
make the existing one work!"
You and I know that's easier said than done, but I've worked with many a
person over the years that thought, given enough creativity, anything is
possible. (Well, and it is, I guess, but not of time or money are finite)
I like your cart idea. Put a ROM in 64/128 address space, and then use
it to run all the IO, like the C128 CP/M does. Use the IO space to pass
data back and forth.
Hmmmm.....
Jim
BruceMcF
> Ah, yes, that does make sense. Maybe getting 8MHz Z80s was an issue, or
> they were too expensive
Could be either, the Z80H was introduced in 1982 so I don't know what
volumes were like at the time. And given the market they were produced
for, too expensive is quite possible.
Also possible is just not grokking the Z80, as its a quite different
mental model of the processor and its little register file over here,
and the memory system over there, and the I/O access over on the other
side there, unlike the memory clocked, memory mapped I/O 6502.
> I like your cart idea. Put a ROM in 64/128 address space, and then use
> it to run all the IO, like the C128 CP/M does. Use the IO space to pass
> data back and forth.
I'd think a Z180, basically four registers for ports and memory window
mapped into the top four address of the top half of IOx, 128 byte
window to the cart RAM in the bottom half of IOx ... one 8bit register
gives 32K, so a second 4 bits can access up to 512K and leave four
bits for whatever else is needed other than the basic terminal
pipeline.
And no ROM at the Z180 side at all, the Z180 doesn't do anything until
its loaded up by the C64 side.
BruceMcF
> I'd think a Z180, basically four registers for ports and memory window
> mapped into the top four address of the top half of IOx, 128 byte
> window to the cart RAM in the bottom half of IOx ... one 8bit register
> gives 32K, so a second 4 bits can access up to 512K and leave four
> bits for whatever else is needed other than the basic terminal
> pipeline.
No, no, no, no, wait a minute, extend the GEORam design, a page
accessible in IO1, a page register in $FE and $FF of IO2, and the
portals addressed at $FC and $FD of IO2, mirrored through the top half
of IO2, so its just IO2 low and A15 high select to the 2x4 select
demux. Another cart in IO2 that sits in IO2 $00-$7F would be clear if
it does not mirror into $80~$FF or if there is a A7 mask jumper.
Oh, and invert A16 up in the page ram register on loading from the C64
side, so that the bottom Z180 64K is the top 64K from the C64 side.
With 256Kx8 Static RAM, it can be used as a 256K CP/M Plus system, a
128K CP/M Plus and 128K GEORam, or 256K GEORam.
> And no ROM at the Z180 side at all, the Z180 doesn't do anything until
> its loaded up by the C64 side.
One of the C64 reply bytes has to be a cold start, I guess #$00 for a
wired or /RESET.
Wait states are simple: to avoid bus contention for the Static RAM,
generate /WAIT from (/RD + /WR)*(/IO1)*(6502 process memory clock),
which is the same time that the latched GEORam high address is on the
cartridge bus.
I always think of the hardware for that in discrete logic, but I guess
that one or two CPLD could handle all the logic, memory and /WAIT in
one, the /IO2 communication portals in the other.
Add the Z180, Static RAM, and ROM.
Could clock it off the dot clock (it will not stay in precise syn, but
with a better-safe-than-sorry wait state, no matter) for ~8Mhz, and
seems likely effective 6Mhz+ no wait state speed. Add a crystal and a
faster Z180 for more speed.
Jim Brain
> On Dec 15, 4:24 am, BruceMcF<agil...@netscape.net> wrote:
> No, no, no, no, wait a minute, extend the GEORam design, a page
> accessible in IO1, a page register in $FE and $FF of IO2, and the
> portals addressed at $FC and $FD of IO2, mirrored through the top half
> of IO2, so its just IO2 low and A15 high select to the 2x4 select
> demux. Another cart in IO2 that sits in IO2 $00-$7F would be clear if
> it does not mirror into $80~$FF or if there is a A7 mask jumper.
C64/C128 for I/O, then much of the work can be done with a small page of
RAM. The only things I can see that would require lots of RAM would be
moving data to/from the 40 column bitmap screen. Disk is limited by bus
speed, so a simple 256 page and a set of APIs to read/write blocks would
suffice, in my opinion. It would be easy to design a ROM that sits in
the external util ROM space on the 128, $8000 on the 64.
On start, the 64/128 would run the boot code, then find the signature
bytes in the external ROM. After setup, control would pass to the Z80
for bootup. Z80 would tristate the 8502/6510, run init code, and then
prep an API call to the 8502/6510 for disk IO. The 64/128 CPU would
come out of tristate, read the API call, run the appropriate code from
the ROM, and then return control to the Z80.
> Wait states are simple: to avoid bus contention for the Static RAM,
> generate /WAIT from (/RD + /WR)*(/IO1)*(6502 process memory clock),
> which is the same time that the latched GEORam high address is on the
> cartridge bus.
I think it's easier. Have the Z80 run out of fast RAM at all times, and
simply have a page of that RAM mapped into the 6502 IO space. No wait
states needed. If fast memory copy is needed from the Z80 side, you
always have DMA.
Having the pages of RAM seems to only benefit if you have lots of video
mem to move and you can't afford the cost of a DMA to move it from
64/128 RAM to Z80 RAM. Otherwise, it's far simpler to use the single
page of RAM.
Jim
BruceMcF
> Why do you need to provide so much paged RAM? If the Z80 only needs the
> C64/C128 for I/O, then much of the work can be done with a small page of
> RAM.
The C64/C128 is booting the Z80, so its writing BIOS and BDOS to z180
RAM.
File I/O operations are faster if the C64/C128 writes the 128byte
sector directly into its target location.
However, the independent portal is redundant if any z80 RAM space page
can be used for portal, so ditch that idea and just have a recognized
space to write the hardwired tokens to suspend the z180, continue from
where it was, reset it, and generate an IRQ. I expect that needs far
less state than a two-ported portal register.
> The only things I can see that would require lots of RAM would be
> moving data to/from the 40 column bitmap screen. Disk is limited by bus
> speed, so a simple 256 page and a set of APIs to read/write blocks would
> suffice, in my opinion. It would be easy to design a ROM that sits in
> the external util ROM space on the 128, $8000 on the 64.
> On start, the 64/128 would run the boot code, then find the signature
> bytes in the external ROM. After setup, control would pass to the Z80
> for bootup. Z80 would tristate the 8502/6510, run init code, and then
> prep an API call to the 8502/6510 for disk IO.
Aha, there you go. I have no boot rom for the z180, it's all done C64
side.
> The 64/128 CPU would
> come out of tristate, read the API call, run the appropriate code from
> the ROM, and then return control to the Z80.
> > Wait states are simple: to avoid bus contention for the Static RAM,
> > generate /WAIT from (/RD + /WR)*(/IO1)*(6502 process memory clock),
> > which is the same time that the latched GEORam high address is on the
> > cartridge bus.
> I think it's easier. Have the Z80 run out of fast RAM at all times, and
> simply have a page of that RAM mapped into the 6502 IO space. No wait
> states needed. If fast memory copy is needed from the Z80 side, you
> always have DMA.
> Having the pages of RAM seems to only benefit if you have lots of video
> mem to move and you can't afford the cost of a DMA to move it from
> 64/128 RAM to Z80 RAM. Otherwise, it's far simpler to use the single
> page of RAM.
Having the equivalent of a GEORam there and not being able to use it
when the z80 is idle seems a wasted resource.
But if instead of that, the cartridge is set up so that the Z180 can
pointed to C64 memory and do DMA during 6502 processor cycles, that is
heading toward the main memory expansion capabilities, except more
flexible since its presumably possible to load a z180 routine to do
DMA as part of a routine. Then the wait state would be set up for
accesses for the C64 memory system bus.
Christian Brandt
> But if instead of that, the cartridge is set up so that the Z180 can
> pointed to C64 memory and do DMA during 6502 processor cycles, that is
> heading toward the main memory expansion capabilities, except more
> flexible since its presumably possible to load a z180 routine to do
> DMA as part of a routine. Then the wait state would be set up for
> accesses for the C64 memory system bus.
Actually CBM did it that way with the B256/CBM730.
But instead of the already fading Z80 it used an 8088. My old school
used it in 1982 as their first MS-DOS-System until 1992. We - thats some
kids and some teachers - napped the computer and looked inside it,
figuring out its workings and voila, the 8088-Board is really just a
complete computer inside a computer with its own RAM, some parts and two
small ASICs which should be relevant to the conntact to the 6502-side.
Nowadays I am working part time at my old school and I think I saw it
sitting in a storage room a couple of years ago. Should be still there,
next to a very early BBC Acorn and a AppleII.
And no, it is NOT IBM-compatible, it is "only" MSDOS-compatible.
Running 1.25 and a handpatched 2.11.
Christian Brandt
BruceMcF
> Am 16.12.2010 19:36, schrieb BruceMcF:
> > But if instead of that, the cartridge is set up so that the Z180 can
> > pointed to C64 memory and do DMA during 6502 processor cycles, that is
> > heading toward the main memory expansion capabilities, except more
> > flexible since its presumably possible to load a z180 routine to do
> > DMA as part of a routine. Then the wait state would be set up for
> > accesses for the C64 memory system bus.
> Actually CBM did it that way with the B256/CBM730.
> But instead of the already fading Z80 it used an 8088. My old school
> used it in 1982 as their first MS-DOS-System until 1992.
There are a boatload more MS-DOS programs, and a massive share of them
assume PC-compatible. Mature CP/M Plus always assumed that it would
run on whatever compatible BIOS was available. So as a hobbyist
excercise, bringing up a workalike for CP/M Plus is likely easier.
Jim Brain
> The C64/C128 is booting the Z80, so its writing BIOS and BDOS to z180
> RAM.
than the need to move RAM twice (64 to page, page to Z80 RAM).
>
> File I/O operations are faster if the C64/C128 writes the 128byte
> sector directly into its target location.
and a few cycles to move it in the Z80, so I posit that the speed
advantage is negligible, as you'd be waiting on the drive most of the
time. However, given other things on the design, creating a paging
mechanism ala GEORam is probably trivial, so my argument is academic.
> Aha, there you go. I have no boot rom for the z180, it's all done C64
> side.
Z80 address space, and I still believe there is value for a 6502-based
ROM to hold the interCPU transfer routines and for autostart. I say put
the FLASH ROM on there, make it field flashable, and allow it the option
of being paged out of the Z80 address space if desired. The cost for a
small FLASH ROM is minimal, and I think the autoboot feature is worthy.
My other thought was to ensure the cartridge would work standalone
(ROM would have 2 BDOS copies, 1 for CBM use, and 1 for standalone use,
with a way to solder a SD card, a KB controller, and a RS232 IC on the
board. The cost of putting the footprints on the board is minimal, and
then you have two use cases (C64 enthusiast is one, and standalone Z80
person is another).
> Having the equivalent of a GEORam there and not being able to use it
> when the z80 is idle seems a wasted resource.
and GeoRAM is trivial to implement, so no worries.
> But if instead of that, the cartridge is set up so that the Z180 can
> pointed to C64 memory and do DMA during 6502 processor cycles, that is
> heading toward the main memory expansion capabilities, except more
> flexible since its presumably possible to load a z180 routine to do
> DMA as part of a routine. Then the wait state would be set up for
> accesses for the C64 memory system bus.
simple REU (don't use the Z80 portion).
If the cart was designed right, I see it fulfilling many functions:
RAM + CPLD = GeoRAM
RAM + CPLD = REU
RAM + CPLD + Z80 = C64 Z80 cart
RAM + CPLD + Z80 + ROM = autostart cart
RAM + CPLD + Z80 + ROM + uC = standalone Z80 SBC (uC would handle UART,
KB, and SD)
Jim
BruceMcF
> RAM + CPLD = GeoRAM
Yes, this was my idea, that even a very small pin count CPLD would
have enough state to hold the top 11bits for a 512Kx8bit Static RAM.
> RAM + CPLD = REU
Given correct bus arbitration, the Z80 is the DMA chip. And since the
routine is in software, fine tuning for things like sufficient
interrupt processing time for video or soft RS232C is available, its
not necessary to have all bases covered at the outset. So:
RAM+CPLD+Z80 = REU
> RAM + CPLD + Z80 = C64 Z80 cart
> RAM + CPLD + Z80 + ROM = autostart cart
For this, the cleanest design may be a 32K flash-backed RAM ~ the kind
that auto-saves to flash contents on power down and auto-loads on
power-up ~ and addressed at 992K ~ 1023K from the z80 side.
Then, if the C64 can write to it, its soft programmable.
OK, the lower Georam control byte is a8~a15. 1 bit in the third
control register selects the RAM page between Permaram and Georam
(powers up low for /Georam), independently, 1 bit controls whether 8K
external ROM is active, and 2 bits controls which one of four 8K
windows in Permaram show up in 8K external ROM.
Ideally, a physical button would allow the bit that controls whether
the 8K external ROM is active to be toggled
I guess need one bit in the external control register to generate a
z80 IRQ and one bit in the external control register to generate a z80
reset.
So now its an insystem programmable autostart card, write to the high
RAM to program it entirely in software.
> RAM + CPLD + Z80 + ROM + uC = standalone Z80 SBC (uC would handle UART, KB, and SD)
Z8S180 has UART and SPI built in, hardware SPI gives SD, an SPI based
USB host controller would allow keyboard, USB flash drive, etc. Can
run 20mhz on internal clock.
This would, of course, provide SD and USB to the C64 with suitable
support running on the Z80, so I'd prefer that path to a standalone
z180 SBC.
This is the option that I can see justifying any extra complexity in
fitting the ROM into the z80 side bus. Need to both /WAIT accesses
when the 6502 is reading rom. I've no if the /WAIT state floats the
z80 address lines ~ would be nice if it did ~ if not then instead of /
WAIT need to suspend the z80 clock until the 6502 read cycle is
finished (since the z8s180 is fully static, you can do that, but it
demands more complete state logic ~ generating /WAIT during non-memory
access processor cycles is harmless, while nothing can get done until
the clock suspend ends).
Jim Brain
>> RAM + CPLD = REU
> Given correct bus arbitration, the Z80 is the DMA chip. And since the
compatibility using a Z80 are the controller. I would get hate mail if
I created a RAM cart that was GeoRAM compatible but not REU compatible.
>> RAM + CPLD + Z80 + ROM = autostart cart
>
> For this, the cleanest design may be a 32K flash-backed RAM ~ the kind
> that auto-saves to flash contents on power down and auto-loads on
> power-up ~ and addressed at 992K ~ 1023K from the z80 side.
> This would, of course, provide SD and USB to the C64 with suitable
> support running on the Z80, so I'd prefer that path to a standalone
> z180 SBC.
a moderate FPGA option with a Z-80 soft core, a USB core, UART core, and
a DMA engine for the REU. For $13.00 in singles, you can get a 250K
FPGA, which would hold the Z80 and have 50% of space left over for other
things. Though a Z80 + CPLD + USB->SPI bridge combo might compete,
there is more flexibility in an FPGA option.
Jim
BruceMcF
> On 12/18/2010 5:58 PM, BruceMcF wrote:>> RAM + CPLD = REU
> > Given correct bus arbitration, the Z80 is the DMA chip. And since the
> Well, perhaps, but I think it would be very hard to ensure complete REU
> compatibility using a Z80 are the controller.
Since it would be driven by a routine on the z80 side, initial bugs
could be polished out. Since you write the routine into the cartridge
and then set it running, upgrading is a matter of getting the new
routine uploader program.
> I would get hate mail if
> I created a RAM cart that was GeoRAM compatible but not REU compatible.
Well, OK.
>> RAM + CPLD + Z80 + ROM = autostart cart
> > For this, the cleanest design may be a 32K flash-backed RAM ~ the kind
> > that auto-saves to flash contents on power down and auto-loads on
> > power-up ~ and addressed at 992K ~ 1023K from the z80 side.
> That sounds expensive. You have some part numbers for this type of option?
The Cypress CY14E256L 16Kx8 nvSRAM is about $16 by the one from
digikey.
If that is too pricey, I see a 128Kx8 5v parallel flash DIP at digikey
for around $2. That could be 8 8K external ROM windows for the C64
side and a 64K boot up ROM for the Z80, which would include ample
space for routines to emulate the cartridge port REU, serial port, and
SD access routines for the C64.
Ideally, access to writing the flash could be done on either side, so
that the C64 could master an initial configuration, but it could also
upload data by DMA for the cart to write to flash, or command the cart
to just go to an SD card and download a configuration block.
> I could get there. In the end, I think the cost is better served using
> a moderate FPGA option with a Z-80 soft core, a USB core, UART core, and
> a DMA engine for the REU. For $13.00 in singles, you can get a 250K
> FPGA, which would hold the Z80 and have 50% of space left over for other
> things. Though a Z80 + CPLD + USB->SPI bridge combo might compete,
> there is more flexibility in an FPGA option.
Well, its about a $10 processor in low volume, so it depends on the
complexity of the CPLD, but best to use the stock z8s180 if its going
to be used for an SBC, since the code to support the built in UART,
SPI, real time clock and DMA ought to be floating around somewhere
requiring a few tweaks.
After looking up the AT keyboard interface, I think it can just be bit-
banged directly, the keyboard clock is only 20khz~30khz, and the
Z8S180 would be clocked at around 20MHz.
That would be Z8S180, 20MHz crystal, CPLD, 512kx8 SRAM, 128Kx8 Flash,
SD socket, DE9M socket for the serial port, PS2 keyboard socket for
keyboard.
Jim Brain
> Since it would be driven by a routine on the z80 side, initial bugs
> could be polished out. Since you write the routine into the cartridge
> and then set it running, upgrading is a matter of getting the new
> routine uploader program.
There are many nuances to REU support (the portion of the cycle that the
transfer starts, BA/AEC support, etc.) A CPU would need to run far
faster than 20MHz to properly emulate all of it.
> The Cypress CY14E256L 16Kx8 nvSRAM is about $16 by the one from
> digikey.
Ouch. FOr that, I can grab a huge SRAM, a small uC, and a SD connector
and roll my own :-)
> If that is too pricey, I see a 128Kx8 5v parallel flash DIP at digikey
> for around $2. That could be 8 8K external ROM windows for the C64
> side and a 64K boot up ROM for the Z80, which would include ample
> space for routines to emulate the cartridge port REU, serial port, and
> SD access routines for the C64.
Yes, FLASH is available at very cheap prices.
> Ideally, access to writing the flash could be done on either side, so
> that the C64 could master an initial configuration, but it could also
> upload data by DMA for the cart to write to flash, or command the cart
> to just go to an SD card and download a configuration block.
It would be not a major issue to allow writing from both sides.
> That would be Z8S180, 20MHz crystal, CPLD, 512kx8 SRAM, 128Kx8 Flash,
> SD socket, DE9M socket for the serial port, PS2 keyboard socket for
> keyboard.
The CPLD is going to be the issue, I think. Once you get around 200+
registers, you're better off going FPGA, and when you do that, then the
world changes.
Still, it sounds worthy. I wonder how many CP/M folks would be
interested in a proper CP/M cart for the C128?
JIm
BruceMcF
> > Since it would be driven by a routine on the z80 side, initial bugs
> > could be polished out. Since you write the routine into the cartridge
> > and then set it running, upgrading is a matter of getting the new
> > routine uploader program.
> There are many nuances to REU support (the portion of the cycle that the
> transfer starts, BA/AEC support, etc.) A CPU would need to run far
> faster than 20MHz to properly emulate all of it.
Remember that its not just a CPU emulating DMA, its an actual DMA
engine inside Z8S180. It would need some hardware support on sync to
C64 bus, but it seems like part of the logic will be shared.
> The Cypress CY14E256L 16Kx8 nvSRAM is about $16 by the one from
> > digikey.
> Ouch. FOr that, I can grab a huge SRAM, a small uC, and a SD connector
> and roll my own :-)
Except that on powerdown with data in the huge SRAM, you probably
won't be in a position to write it to the SD. nvSRAM has power in its
capacitor to write all of RAM to flash.
> > If that is too pricey, I see a 128Kx8 5v parallel flash DIP at digikey
> > for around $2. That could be 8 8K external ROM windows for the C64
> > side and a 64K boot up ROM for the Z80, which would include ample
> > space for routines to emulate the cartridge port REU, serial port, and
> > SD access routines for the C64.
> Yes, FLASH is available at very cheap prices.
> > Ideally, access to writing the flash could be done on either side, so
> > that the C64 could master an initial configuration, but it could also
> > upload data by DMA for the cart to write to flash, or command the cart
> > to just go to an SD card and download a configuration block.
> It would be not a major issue to allow writing from both sides.
OK. I've never done anything on the hardware side with flash.
> > That would be Z8S180, 20MHz crystal, CPLD, 512kx8 SRAM, 128Kx8 Flash,
> > SD socket, DE9M socket for the serial port, PS2 keyboard socket for
> > keyboard.
> The CPLD is going to be the issue, I think. Once you get around 200+
> registers, you're better off going FPGA, and when you do that, then the
> world changes.
The design I was thinking of, I was pretty sure it was well under
that. But I had the ROM on the C64 address bus, plus a couple of lines
from the CPLD, and only A0-A7 and D0-D7 common. Plus, A0-A7 are two-
state, out or isolated, and only D0-D7 are tri-state, in, out, or
isolated.
{BTW, I've been focusing on the cartridge bus ~ when does the C64 bus
not care about what is going on with the Cartridge A0~A7 and D0~D7
lines?}
A8-A12 would route straight to the ROM (flash), A13-A15 would not be
connected. And the lines required for logic is much simpler. Hang the
ROM (flash) on the C64 side (bused on the C64 side of the CPLD to C64
A0~A7 lines, a select of the ROM from the C64 is one case that
isolates the two buses), there's no contention to worry about, so no /
WAIT or zCLK to worry about driving for ROM accesses. The only state
from the CPLD is from its internal $dffd register to the top four bits
of the flash (for 128k).
The only way that the C64 gets into the common z80 address space is
via IO1 (IO2 is going internally into the CPLD), so /WAIT is dead
simple. 11 address lines in from the Z80, 11 address lines out of the
CPLD, 11 registers for the five bits of block select in $dfff and six
bits of page select in $dfffe, and A6&A7 are already lines coming into
the CPLD ... together they form the address of the static RAM which
goes onto the z80 bus when /WAIT is low. And the GeoRAM registers are
simple latches, they cannot be read back out.
I'd think it would be on the order of 100 at worst, less depending on
whether the combination of don't cares on the C64 bus and don't cares
on the z80 bus allow direct busing of address or data lines.
Add the REU, and now its the full 16-bit address bus on both sides and
the logic to support making the built-in DMA in the z8s180 sync with
the bus like an REU.
So, OK, its not a memory cartridge, its a lightning fast ultra-smart
UART and SD drive with up to 500K of input/output buffers, accessed in
an already established legacy protocol.
Now, since in C64/C128 cartridge mode, the flash is entirely in one
address space, with A8~A12 bused on the C64 side of the CPLD and only
A13~A15 coming out of the CPLD, bring the z80 A13~A15 into the CPLD
and use two hex jumpers to connect the z80 A8~A12 to the flash and A19
to the CPLD, and when the A19 line is high, it puts the z80 addresses
on A13~A15 rather than the
> Still, it sounds worthy. I wonder how many CP/M folks would be
> interested in a proper CP/M cart for the C128?
I dunno. There's a small handful working on z80 SBC's. Whether it
would excite their interest, I've no idea.
If there's built in PS2 keyboard support, RS-232C serial, SD, and a
set way to attach an SPI dongle, which can give USB, LCD modules,
floating point, etc. ... maybe it'd be possible to get them excited.
That really only takes 10~12 lines out of the CPLD, since it's only
necessary to write to four bit registers to multiplex the SPI select
line, and then /SEL in, /SEL1 and /SEL2 to two SD card slots, /SEL3
and /SEL4 to two DE9F connectors for the future SPI dongle expansion.
BruceMcF
> If the cart was designed right, I see it fulfilling many functions:
> RAM + CPLD = GeoRAM
> RAM + CPLD = REU
> RAM + CPLD + Z80 = C64 Z80 cart
> RAM + CPLD + Z80 + ROM = autostart cart
> RAM + CPLD + Z80 + ROM + uC = standalone Z80 SBC (uC would handle UART,
> KB, and SD)
It occurs to me that with the price of flash, the easiest way to avoid
bus contention is to have one dedicated z80 bus ROM and one dedicated
6502 ROM. Then access to the 6502 ROM from the z80 side is on a jumper
that is selected when using the cart as a SBC.
Anyway, since the stock z8s180 has built in DMA, UART and SPI, and a
PS2 keyboard port can be easily bit banged, the list could well be:
RAM + CPLD = GeoRAM
RAM + CPLD + Z80 = 256K-REU
RAM + CPLD + Z80 = C64 Z80 cart
RAM + CPLD + Z80 + cROM + zROM = autostart cart
RAM + CPLD + Z80 + zROM + RS232 level shifter = Turbo232 cart
RAM + CPLD + Z80 + zROM + PS2 port = PC keyboard cart
RAM + CPLD + Z80 + zROM + SD socket = SD cartridge
RAM + CPLD + Z80 + zROM + SPI "slot" = utility expansion (LCD
interface, USB, etc)
RAM + CPLD + Z80 + ROM + RS232 level shifter + SPI "slot" + PS2 port =
SBC
The DIP version of the z8s180 only has 512k of RAM (no A19 pin), so if
the system is designed to allow that chip to be used for hobbyists
that don't want to handle the small packages, the zROM would be
addressed high, the bottom 256 of RAM would be addressed low, and the
top 256 RAM would be addressed as IO (it would be used as a RAM disk
accessed via DMA if not being used by the C64). That leaves a 128K
hole in the RAM, filled either by cROM in SBC mode, or as below in REU
support mode.
I think making the REU registers pseudo registers in a locked slot in
RAM is the key to keeping the size of the CPLD down. Since you don't
want the REU to be able to trample its own registers, that implies a
256K REU, but OTOH a 256K REU turbo232 autostart cartridge that can
hold up to 8 soft selectable 16K ROM images. And run CP/M on the side.
The REU may not be as tricky as I thought. One cheat is required ~
while the REU registers are mirrored through $DFxx, the top of $DF is
where the GeoRAM register is located, so the emulation would be
limited to $DF00~$DF7F. So:
/REU = /IO2 + A7
With 256kB addressed from the z80 side as IO, DMA needs the C64 to be
memory-mapped, so:
/C64RAM = (~A18)+A17+A16
... to put it at the first 64K above 256K.
That means that the C64 A8~A15 lines in the cartridge only need to be
bi-state ~ isolated or driving ~ which saves a chunk of logic.
The z80 never access that directly, but it sets up the DMA registers
based on RAM address. Since that it tied to the C64 DMA access lines, /
WAIT is free to be tightly synchronized to the /C64 clocks when /
C64RAM is asserted ...
/WAIT = (/C64RAM * /IO1 * /IO2) + (/RD * /WR) + (c64 clock logic)
There's no doubt that the DMA in a 20Mhz processor will be spending
most of its time waiting on the /WAIT to clear. And since its a
hardware DMA, it will be a regular process that should be
straightforward to synchronize with the timing and bus assert protocol
for the C64 DMA.
That just leaves how the REU register values themselves are stored and
got into the z80 DMA registers. Most direct is to register the address
in the CPLD and lock the register bank to the top 16 bytes of the RAM
block of static RAM, with the CPLD addressed from the z80 side as any
memory address in the hole between C64RAM and zROM:
/REU-regaddress = (~A18)+A17+(~A16)
To avoid placing that block in the middle of the GEORam space, the top
bit of the GEORam address latch selects the IO RAM when low and the
datatspace RAM when high.
Paul Förster
On 2010-12-20 05:53:23 +0100, Jim Brain said:
> Still, it sounds worthy. I wonder how many CP/M folks would be
> interested in a proper CP/M cart for the C128?
... yes, two for me, please. :-)
--
cul8er
Linards Ticmanis
> I think it might have had something to do with the need to support
> 40-column mode. IIRC the Z80 was only clocked during phase 2 because the
> VIC II chip needed unrestricted access to memory during phase one.
If you read Commodore's CP/M source code, it becomes clear that they had
planned to run the Z80 at 4MHz when the 40-column screen is disabled,
basically implementing SLOW and FAST for the Z80 just as for the 8502
CPU. But obviously they never got that working, as all the code dealing
with it is commented out in the sources.
Once very long ago I tried enabling FAST mode while running on the Z80.
If you had interrupts enabled it crashed. With IRQ disabled, it worked
and seemed to be somewhat faster than running the Z80 in SLOW mode, but
far less than twice as fast. I used a stop watch for the timing and I
don't remember the details, but I know I made sure everything else was
the same, for example, disabling the 40 column screen by setting the bit
in the VIC that makes it display only the border color.
Since I don't have an oscilloscope I never got around to check what the
VIC actually outputs on its Z80 clock output line when it's running in
FAST mode.
--
Linards Ticmanis
Linards Ticmanis
> It would be nice to put some additional context around this, because
> making the machine do 4MHz would have required quite a bit of
> engineering effort. In light of the story on how the Z80 came to be
> included in the C128, I can't imagine any of the engineering staff
> caring enough. Maybe they are using "engineer" as a placeholder for the
> CP/M software developer, whose name I can't recall at the moment. Maybe
> he was told by CBM to make it work at 4MHz, in case the code was used in
> a more standard CP/M machine, or maybe it was a requirement of the DRI
> contract, that all changes had to be port-able to a normal 4+MHz CP/M
> machine.
Just a belated answer to this part, since I was the guy who originally
wrote that part of the C128 article on Wikipedia - the places where the
CP/M source code has these conditionally-compiled FAST and SLOW thingies
(using the symbol called use$fast to decide) deal with exactly two
fairly C128-specific things.
Namely, 1 MHz mode is enabled while switching between the two processors
(whether Z80 to 8502 or 8502 to Z80) and while accessing the REU (which
is done from the 8502 side). It's always re-enabled immediately
afterwards. Oh, and the sign-on message adds the word "Fast". That's all
there is to it. Needless to say, compiling with these parts enabled
results in a non-working system file.
So I doubt these bits were for "generality". And on a "normal" 4+Mhz
CP/M machine you wouldn't need them.
--
Linards Ticmanis
Linards Ticmanis
>> the 128-specific BIOS was not very well-written, and a later third-
>> party re-write sped things up significantly.
>
> vm appreciate if you could provide more info on when/where/what was
> done.
If you're talking about the thing called "FastBIOS" that I came up with
around 1997 or so, the problem was actually a bit different. Firstly, it
should be made clear that we're talking about that which the CP/M
manuals call BIOS, which is a piece of code in RAM, contrary to PC lingo
where BIOS means firmware. We're not talking about the 4K of "Z80 ROM
BIOS" that's tucked away in the C128 ROMs and that is quite C128-specific.
The problem with the RAM BIOS was that it was, in large parts, NOT
C128-specific. They had just taken the Digital Reasearch-supplied, very
general CP/M 3.0 BIOS code and added a bunch of C128-specific stuff
around that. That original DR code is in Intel 8080 assembly only, which
doesn't help its speed.
Also it does some things that aren't all that smart in practice - for
example, for every single character that's being sent to the screen via
the BIOS output function, the BIOS will use a long loop of bit shift and
rotate operations to query every all 16 positions of a bit-table of
devices whether any device is currently set up to receive characters
that go to "the screen" from the user program's point of view. Now -
unless you are a total masochist and using CP/M in 40-column mode - in
99% of all cases, only the 80-column screen is set to receive characters
sent to "the screen" and the 15 other devices, of which most don't even
exist in the C128, are not. So I used a simple 16-bit compare opcode to
compare the whole bit-table to the value noting that condition; and if
equal, bypassed the whole loop and went directly into the 80-column
output routine.
Then that routine checked for all possible control codes one by one;
only when the character equaled none of them would it be regarded as a
printable character and sent to the VDC memory. I flipped it around so
that a check for "printable character" preceded everything else, as
these occur far more often than any control code.
There were a few more changes and some additions of functionality, but
these two things alone brought the vast majority of the speed gain.
--
Linards Ticmanis
Linards Ticmanis
Yes, compatibility would be crap as almost all "serious" ZX81 programs
use direct I/O to write to the screen, and there is tight coupling
between screen and CPU in the ZX81. To have text appear on the screen,
you have to make the CPU "run" the character data. Some tricky
electronics will then use the data that the CPU reads during this to
generate the screen display, and feed NOPs to the CPU instead of the
data that it actually read.
Also the ZX81 has variable line lenghts for text. So if you have only 10
characters in the first line of text, you will use only ten bytes of
video ram for that, then an "end of line" byte, then in the 12th byte of
video RAM the second line of text will start. That was the only way to
get a usable system with only 1 kilobyte of RAM. Without it, the screen
would need 768 bytes, leaving only 256 bytes for code and data, which
even in 1981 wasn't enough.
--
Linards Ticmanis
BruceMcF
> Hey Jim,
> On 2010-12-20 05:53:23 +0100, Jim Brain said:
> > Still, it sounds worthy. I wonder how many CP/M folks would be
> > interested in a proper CP/M cart for the C128?
> ... yes, two for me, please. :-)
How about a proper CP/M cart that can also function as a stand-alone
Z80 SD based SBC, with 256K Ram and 256K ramdisk? Either RS-232C
terminal or PS2 keyboard and SPI LCD display? And 256K of built in
Flash ROM storage?
:)
Jim Brain
> If you're talking about the thing called "FastBIOS" that I came up with
> around 1997 or so, the problem was actually a bit different. Firstly, it
> should be made clear that we're talking about that which the CP/M
> manuals call BIOS, which is a piece of code in RAM, contrary to PC lingo
> where BIOS means firmware. We're not talking about the 4K of "Z80 ROM
> BIOS" that's tucked away in the C128 ROMs and that is quite C128-specific.
I was referring to the original note that the source showed provisions
for 4MHz operation, which you clarified in another post. However, the
information you provided is very valuable.
Is there a document that describes how the C128 CP/M system boots? I am
confused by the BIOS in the C128 being in RAM, since it's in ROM in
other machines, and if it is in RAM, how does it get loaded?
>
> There were a few more changes and some additions of functionality, but
> these two things alone brought the vast majority of the speed gain.
How does your work compare to BIOS-r6 by Randy Winchester?
Jim
Jim Brain
commentary on the C128 development, I asked him to weight in on the
topic. He read the postings, and here is his response (I'm just the relay):
---------------------------------------------------------------------
*** Why a Z80 ***
To sum up why I put the Z80 in the C128 instead of the cart: I
especially liked when I could address several issues with one “fix”. At
the point we did the Z80 we had a little over 60 days to CES, not doing
something would have resulted in a “liar liar pants on fire” moment for
any credibility of C64 compatibility because the existing CPM cart
simply didn’t work reliably on the c128. (I wouldn’t be drawn into the
rationalization of sometimes it works.)
Truth was that the better the timing was on the C64, as in when you
stopped violating the DRAM timings internally, the worse it worked on
the CPM cart. We pretty much nailed the DRAM timings on the 128 which
means we pretty much ensured that the CPM cart wouldn’t work at all. We
also had a batch of carts that wouldn’t work with any R7 VIC chip as
proof of the concept that there was no good answer. When you used
address multiplexers on the cart fast enough to meet address set up
times, they tended to oscillate on “floating” cycles which is really
really bad (you short internal address rows together, etc) So there were
two major issues and the odds of the stars lining up were virtually nil.
We also would have had to oversize the power supply for the possible
addition of the CPM cart. On the C64 it’s a linear supply; overload it
and the voltage goes down and the power supply gets hotter. On the 128
it was a switching supply, it would either shut down or pop the fuse
(against odds I got a fuse put in, I am told they removed it after I
left). So my problem is that I would have had to increase the cost by
about $.50 for 5% of the population. The $.50 was worth $2mil in
production qtys.
Then as it turned out the Magic Voice cart did something we didn’t
expect, they took a signal that is normally soldered to ground to
tri-state the ROM bus for games, and they toggled it dynamically. If we
went to grab $FFFC they would trounce the bus. There were just two
problems: the 128 didn’t tristate its bus for just anybody (collision)
and even had we done so the cart didn’t know how to set up the MMU. We
literally moved a jumper from the inverted to non-inverted reset signal
that was already on the board (the 02 resets low, the z80 high) and put
in about 20 lines of code to have the Z80 look for the cartridge and if
it saw it or any other reason to jump to C64 mode, it would prep the MMU
and let ‘er fly. This is where we said “what the hell” and made holding
down the C= key be one of the conditions for sailing into C64 land.
So putting the Z80 on the board (something we did overnight and didn’t
tell management until we rev’ed the board) allowed us to continue saying
we were compatible, actually run CPM, save a couple of $Mil and keep my
power supply in a certain size class, and boot C64 games regardless of
yet undiscovered shenanigans.
Only later did it dawn on anyone that we had a dual processor system or
another OS native. Only later after that did it dawn on anyone that it
also meant there was more “day one” software available out of the gate.
*** Z80 Performance ***
There is a very fundamental difference between the 6502 and the Z80 and
it deals with how it accesses DRAM memory. The issues talked about in
the list were really about when DRAM cycles could occur, not the speed
of the clock which actually doesn’t change when the DRAM cycles can start.
The 6502 has a clock that toggles once per machine cycle. Two DRAM
cycles fit neatly in this clock, one on the low (PhiLow) and one on the
high (PhiHi). The ’02 absolutely needs memory available on PhiHi, it
puts out addresses at the start of PhiHi and latches Data at the end.
The Vic chip neatly gets the Phi low and then will also hold off the ’02
when it need more access for refreshes and DMA sprite data fetches. This
also why the Motorola family works nicely in the Amiga architecture (and
why read-modify-writes are problematic)
The Z80 has a 4mhz clock and the machine cycles comprise a variable
number of clocks per machine cycle, a cycle can take 2 to 4 clocks
depending on what it’s doing. Over time the Z80 will ask for a DRAM
cycle at any one of those clocks in relation to the 1mhz clock instead
of the two specifically set windows when DRAM is actually available. It
then utilized “ready” signals to wait for DRAM to finish since there is
no master clock that synchronizes the whole operation. We simply were
not set up for either a RDY type DRAM logic or for DRAM cycles to be
gated/clocked/latches at any time except the two windows already
defined…. Hell I spent all of September getting DRAM to work to begin with.
So one thing is that a Z80 takes at least 3 clocks to finish a DRAM
based instruction. The CPM cart worked by letting 2 clocks go by and
then stopping for a DRAM cycle, 2 clocks, DRAM cycle. You were always
guaranteed that a DRAM cycle would occur since no more than 2 clocks
went by. A few instructions don’t do this and consequently don’t work,
some kind of IO or read-modify-write if I remember.
So even when you knock the 6502 clock into 2mhz, you still only have two
set windows for Dram to start and finish. To make the Z80 run faster
you would need to start DRAM cycles half way through PhiHi and PhiLow,
and you would also need to use RDY logic so that the Z80 knows when to
starts back up. Some instructions catch 2 DRAM cycles before they can
complete, so slower yet. Again it would need a different kind of bus
logic to change that.
Here in lies the real reason that the CPM cart was so flakey. When you
caught one of the cycles that would otherwise experience 2 DRAM cycles,
the Z80 isn’t quite ready when it’s frozen for the first DRAM access.
Unfortunately it’s address bus internally is floating even though it’s
address buffers are turned on… an amplified (low impedance) float
condition holding the bus around 1-1.2v throughout a DRAM cycle. Why?
The Z80 was never designed to be stopped between the 1st and 2nd clocks
of an instruction. This 1v would trip different address buffers on the
cart based on manufacturer and VCC and they would oscillate destroying
DRAM integrity. The original person that noticed TI’s worked better than
Signetics (or vice versa depending on temp and VCC) assumed it was speed
when really it was about when a Logic Low stopped being a Logic Low and
became metastable. Pull ups did nothing since the address bus was being
driven at 1v and was not in a Hi-Z state.
To counter this where the C64 cart did not, we put in some logic that
said either held off the Z80 using it’s ready logic if we saw that
particular kind of cycle coming at that particular time or letting one
more clock to squeak through so it could get to a valid state. We also
modified the reset circuit to not wake up in the middle of a sprite data
fetch as the Z80 wasn’t yet ready to listen to the rdy and bus enable
logic, CPM carts failed to reset properly 100% of the time when the vic
chip was already running. Why would this happen on a C128 and not a
C64?? We had a reset switch and didn’t have to power cycle to reset.
Truthfully that dam synchronization logic dam near cost us a CES show,
we kept thinking we found yet another thing the Z80 would do that we
couldn’t account for and by the next morning we had it working thanks to
an engineer named Frank Palaia.
So has anyone heard the story how Von Ertwine saved a third of the CES
booth by ”rewriting” CPM using a disc editor and a calculator on set-up
night of the show?
Bil
-----------------------------------------------------------------------
Jim
PK
> Since some of this information seemed to contradict Bil Herd's earlier
> commentary on the C128 development, I asked him to weight in on the
> topic. He read the postings, and here is his response (I'm just the
> relay):
I adore these kind of post. tnx! :)
Rudolf Harras
>The Z80's clock in the C128 runs at an effective speed of about 2 MHz (two ~4
>MHz pulses, then two ~4MHz periods of no clock activity, then repeat).
By the way: How did CP/M actually activate the Z80 after switching the
C128 on? Was there any other program using the Z80?
Tinkerer Atlarge
> o has anyone heard the story how Von Ertwine saved a third of the CES
> booth by "rewriting" CPM using a disc editor and a calculator on set-up
> night of the show?
I recently saw him relate that story in an article called "The Herd
Mentality" in C=Hacking Issue 17
> Bil
> -----------------------------------------------------------------------
> Jim