Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!snorkelwacker!bloom-beacon!eru!hagbard!sunic!mcsun!unido!mpirbn!p554mve
From: p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst)
Newsgroups: comp.arch
Subject: Re: harvard architectures
Message-ID: <1320@mpirbn.mpifr-bonn.mpg.de>
Date: 18 Oct 90 21:00:05 GMT
References: <9010160322.AA13808@lilac.berkeley.edu> <3468@bnr-rsc.UUCP> <7883@darkstar.ucsc.edu> <2773@crdos1.crd.ge.COM>
Reply-To: p554mve@mpirbn.UUCP (Michael van Elst)
Organization: Max-Planck-Institut fuer Radioastronomie, Bonn
Lines: 18

In article <2773@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
>  This has been applied "after the fact" in some cases. The old Z80 CPU
>has only 64k addressing. One hack done by several people in many ways
>was to use the "M1" bit (opcode fetch) as a bank selector. This allowed
>64k code and 64k data. Alas, the popular o/s was CP/M, and it must have
>messed with its own code, because it wouldn't run that way.

Oops. That seems to be difficult. The M1 signal is asserted during the
opcode fetch only, any memory cycles for immediate data or addresses
in the instruction can't be distinguished from other data fetches.
You have to decode the opcode byte to guess the size of the instruction.

Regards,
-- 
Michael van Elst
UUCP:     universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p554mve@mpirbn.mpifr-bonn.mpg.de
                                "A potential Snark may lurk in every tree."