When designing mine, I disconnected the uP when the front panel is activated. In fact my main intent was to be able to load memory without a processor.

I thought about having a separate processor just for the front panel, which would have met my design criteria, but I chose to drive the buses directly from the switches (via transceivers) anyway. The obvious downside is that every time "Deposit" is pressed, the address switches all have to be correct. This makes data entry three times as tedious as the normal tedium.

So, the more I dig into the processor as counter concept, the more complex it becomes. It can't really be made modular, because you have to split the data bus with a bidirectional transceiver and gate it correctly. You have to count cycles from the last sync so you can gate the correct things to the processor. You have to store a number of predefined bytes to gate onto the data bus. You can select increment/decrement by replacing the NOP with a BRA $01 or BRA $FF, and you have the logic to do multiple bytes for the JMP case, but past a certain point you want to put all these bytes into a PROM and address them. At that point, why bother with the switches?

Maybe this trick works better with the 8080, but I'm not going to investigate further. I was hoping to be able to stop the processor, do stuff, and continue at a particular point in memory, but maybe that's not really necessary. I can set the reset vector to whatever I want, so that's probably a better way to go for controlling execution. Now I need to look at 74HC up/down counters...

If I were doing this, the motivation for a toggle-switch bootstrap would be to toggle in a more user-friendly bootstrap, which would allow for general peek and poke and maybe checksums. So the idea would be to make the hardware minimal with the understanding that it's used rarely - preferably only at power-on. If you have some RAM which you can write-protect that makes it safer - if you can add a battery backup then the bootstrap could stay in place for weeks or months.

Steve Furber of Acorn (and later ARM) fame did something like this: the lights-and-switches interface was used only to load a slightly more convenient program. Once you've loaded a program which supports LEDs and a keypad, or a serial interface, or indeed if you've loaded the program and then written it to non-volatile storage, you don't need to use it again.

We had a thread about minimal bootstraps:
viewtopic.php?f=6&t=1526

So, I've done some sketching using the reset/BE and external counter concept, and it really doesn't do what I want. For boot loading it's clearly the superior solution, but I'm more interested in controlling the µP and being able to single step through small programs. Deadstart loading is necessary, but not sufficient. Therefore, I'm going back to the Altair concept for the front panel. It isn't practical, but it's great for demos and I'm interested in the design problem. Studying the 8800's schematic shows that it's less extra circuitry for the Altair because it already has bus drivers everywhere, making the bus easy to gate. A 65C02 doesn't use external buffers, so I'll have to add what I need to get that functionality. Sadly, BE doesn't help me, because I need to isolate the data bus but leave the address bus intact.

Rwiker, that's a good link for the switches!

I think I need to look a little harder at the overall design for the machine, taking into account the possibilities of force-feeding the µP to get interesting features. I see that Jeff Laughton has done some interesting things with this idea, going way further than I think I would.

Thanks for the mention, grey-lensman. It was Don Lancaster whose books and articles inspired me regarding what "lying to the machine" can accomplish. I describe his Cheap Video technique here.

Long-time forumites are already aware of this, but two machines which incorporate Cheap Video and use related ideas to expand the 65xx instruction set are:

• my heavily-modified KIM-1
• the "KimKlone" or KK (so named because it extends my KIM's extensions)

As a simpler example, undefined opcodes can become single-cycle 'C02 I/O instructions, as described here on Garth's site. He and I are presently honing some related ideas for '816.

The Front Panel application is another case where there may be benefit in some broad thinking about what our favorite microprocessors actually do and can be coaxed to do.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Done traveling for the holidays, and still thinking about the front panel design. Here's a block diagram of how I think it will go at this point. I want to keep the clock local on the processor board, so the front panel will inhibit the processor clock and generate its own clock pulses for its actions. (probably at a kHz rate instead of MHz.)

Still here, still working on the front panel concept. Life of course has intervened, with the early sale of my house and delays for my new house causing all my hardware and tools to be in storage! So, this is a paper exercise for now. I do have a bit to show, the attached photo is a partial design for the examine circuit that jumps to a location in memory. I'd been thinking of stopping the clock to halt the 6502, so there are a few gates for that in this schematic. I think I'm going to go to de-asserting RDY instead, so I don't have to gate the clock all over the place or run a second source. The outputs will go to the /OE inputs of a series of '244 tristate buffers to provide the appropriate bytes to the bus in turn.

Here's a video of a very nice home made front panel:

https://www.youtube.com/watch?v=IXu8P2qGoj8

Yes, it's a 6809 based micro, but I assume that's a minor detail. What I love about that panel is the switches, and the hex seven seg displays. If anyone knows where to get those I'd love to know. Unfortunately I can't find the schematic for that panel, but I suspect it could be deduced from watching it in operation.

_________________
8 bit fun and games: https://www.aslak.net/

Looks like a TIL311 display, unfortunately not produced anymore. You could make a replacement with 7x5 dot matrix displays and a controller.

Edit: it looks like there are TIL311 sellers on e-bay.

Ah thanks! I did not know what they were called. Of course they are not seven segments. Hmm, about £3 a pop. Not cheap, but very, very nice.

_________________
8 bit fun and games: https://www.aslak.net/

Reviving an old thread, finally back to this after -- a year!? I ultimately dropped the random logic concept, as the parts count explodes when you start adding functionality. Taking a closer look at using the processor to do things, it becomes obvious that you need some form of PLD to hold all the states you want the processor to assume to do things. Basing on what I have and can program, I designed a little state machine using EPROMs and a latch to run command sequences. This avoids having to break into the address bus, as long as you only use relative commands and use the processor to adjust the PC. Inputs are through 3 8-bit switch registers that are enabled by the state machine at appropriate cycles, and command bytes are decoded from the states by a second EPROM. There's some steering logic to disable RAM output to allow the state machine to take the data bus, and I added a sequence to intercept reset and provide the reset vector from the switch registers. The whole thing runs at the system clock rate, so you don't have to stop the clock to enter data -- you assert the idle state (BRA #$-2 loop), then run sequences at the clock rate.

The attached schematic is what I have worked out so far -- note that there's no clock, reset logic or power yet. Although I have DIP switches shown on the schematic, that's just to keep the size down, proper switches will be used in the hardware. I'm kind of proud of the vector decode -- it turns out that which vector is requested can be discriminated using only A1 and A2. I haven't seen anyone actually using VP\ before. The schematic is drawn with KiCad.

The attached table is the event sequences that will be triggered by the inputs. There's some work to do there, translating that into a ROM image that takes into account the don't care states. There's probably some optimization that can happen there with selecting which inputs are on which address lines as well. Sequences can have up to 32 states with this setup, assuming all inputs are don't cares after a sequence begins.

The computer itself is pretty minimal for now, but my memory map should allow relatively simple expansion between $8000 - $AFFF. I'm still hoping to prototype this on a breadboard, then fab a PCB for a permanent build.

Hopefully more to come...

Glad you're back on the case!