18 Jan
2022
18 Jan
'22
1:37 p.m.
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