seeking Motorola M68MM01A2 documentation

[Mike Katz]

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.

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