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@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