seeking Motorola M68MM01A2 documentation

[Chris Elmquist]

On Tuesday (01/18/2022 at 03:37PM -0600), Mike Katz wrote:
> If the software is using ROM routines then the address doesn't matter for
> the applications.  If not, you can create an abstraction layer (set of
> drivers for the ACIA, 6875 Timer and PIA) and if all of the code is written
> to the abstraction layer then all you need to do is link in the appropriate
> binary for the abstraction layer. This will work for both C and machine
> language.

Understood but I don't want to force the developer to make different code
for this machine than for the real 680.  This is an attempt to get him
something that he can use to make code for the real 680 without having
a real 680.

I have a real 680 myself but I'm not up to shipping it around, loaning
it out, etc. yet still want to help the effort.  But since I am not the
one actually doing the effort, I wanted to help by providing something
that was usable without having to change his approach.

Thanks for the suggestions though.

Chris

> On 1/18/2022 2:14 PM, Chris Elmquist wrote:
> > On Tuesday (01/18/2022 at 02:01PM -0600), Mike Katz wrote:
> > > I think it might be easier to modify the 680 prom for the I/O addresses of
> > > the board rather than modify the board to match the ROM.
> > Agreed-- except the goal, which I failed to elaborate on, is to come
> > up with an Altair 680 development environment so that someone can port
> > some code to the platform without having the real thing.  I wanted to
> > make that environment as close to real as possible (without having front
> > panel switches and LEDs)-- which means having the I/O in the same place
> > as the original as well as the authentic PROM code running.
> > 
> > > Especially if the address decoding for the I/O is done in PAL (10L8 for
> > > example).
> > No PALs on the board but there is a bipolar PROM (82S129). I'm not
> > adverse to making a new one of those or bodging something that drops
> > into that socket to modify the decoding if neccessary.  I was just hoping
> > to not have to butcher the board itself too much.
> > 
> > > Some 6800 address decoding was done with 74LS138s.  This had the potential
> > > to be inefficient in terms of memory usage or if the '138s were cascaded
> > > then propagation delay could become an issue.
> > Yes.  This seems to be a limited function CPU board and I suspect it takes
> > that approach just to get the four PROMs and I/O decoded very coarsely.
> > 
> > Chris

-- 
Chris Elmquist