seeking Motorola M68MM01A2 documentation

[Jonathan Chapman]

How's about a Glitchbus board set that's compatible? I was planning on doing it anyway.

Thanks,
Jonathan

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Tuesday, January 18th, 2022 at 16:45, Chris Elmquist via cctalk <cctalk at classiccmp.org> wrote:

> 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