"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exupery

I bought a kit recently which came with a project book, a breadboard and a bunch of discretes to go with the base microcontroller. The contents of that project book represent a lot of the value of the kit: a series of experiments which start with an LED lighting up and build up to more ambitious things. We too should be thinking in terms of a series of steps, where a functioning but primitive 6502 computer is the first step.

Computers need I/O, and they need to boot. Programs have bugs, so you need to debug them. So a newbie computer should be very visible, as well as being simple and needing the fewest external pieces of equipment. It should also be extensible which means exposing the data bus and either the address bus or some decoded addresses.

Looking at the KIM-1, the Fignition, the COSMAC ELF, we don't see a great concern about ergonomics: it's about making something and getting it to do something. The newbie project is not a replacement for a PC.

There are certainly two schools of thought about a serial or USB connection: hooking up to a "proper" computer gives you easy access to copy and paste and a file system, as well as an ergonomic keyboard and screen. But it makes the 6502 less of a computer and more of a peripheral. So a serial connection should be an expansion project. (Using USB purely as a 5V power source is fair game: can run the computer from a phone charger.)

Likewise, once the machine is built and has been bootstrapped, hooking up an alphanumeric LCD display would be a first project, and then perhaps hooking up an improved keyboard. But I'm thinking both of those should not be part of the base design.

So, I'm thinking of a ROMless machine with a front panel type of interface, with everything exposed so it can be built up into something more, but keep all those extras as expansion projects. Eventually it can gain EEPROM, serial connection, mass storage: but it doesn't need those things to start with.

- No ROM. Hook up a 3v battery and a diode to make the RAM non-volatile.
- There must be a single-step capability, for debugging and also for booting.
- Output should be 7-segment displays, on a latch (Not a PIA or VIA because they need to be programmed, and they hide complexity). Need at least 8 bits, which is two digits, on the data bus. Ideally this can be both a peripheral and a data bus monitor, by fiddling the latch enable. Could be discrete LEDs instead of 7-segment, if you're prepared to read binary.
- Preferably, for debug, another four digits to show the address bus. But this is optional.
- Input should be buttons or a keypad. Again, we need a latch if this is to be an input peripheral, but can it also be a front-panel bootstrap device in conjunction with single-step? Minimum is 8 push-buttons or even a tiny and inconvenient 8-wide DIP switch or rotary hex switch. (Maximum is 64 push-buttons and diodes as a key matrix: sounds like an expansion project to me.)
- Blocking input! If we are to key in a bootloader while single-stepping, we want that to be only a few dozen instructions. That bootloader can then free-run, if we arrange that reading the 8-bit input port will stop the machine for each read. The user then flips switches or holds down buttons and presses go, the read completes and the program runs on until the next read.

For bootstrapping, see a previous conversation, and for a tiny monitor program, see here.

Edit: see also the Veronica journey and Ruud's debugger (schematic)

If I were stranded on a desert island and needed to program a system without the use of a computer, I would build a manually-controlled EPROM programmer. A toggle switch per data and address line and a simple timing circuit for producing the 50ms pulse (555 maybe?). I would also add 8 LEDs so that I could read back a device I had programmed to make sure I got it right. This is basically what I'm doing with my 6502 system, except I'm using an Arduino in place of the toggle switches & timing circuit.

Drawbacks of this approach is 1) moving the ROMs back and forth between boards is painful and you risk tearing them (both systems & ROMs) up and 2) it's a lot of work for something you might only use during the first phase of the project.

Going with Ed's idea, you could attach 8 toggle switches to an input latch and map that latch into $F000-$FFFF. You would then single step the processor, starting with $00, and $F0 to arrange a jump back to $F000. You would then provide a series of LDA databyte, STA address instructions to copy the boot code a byte at a time into RAM. You would have to toggle in 5 bytes for every byte of boot loader code. This would allow up to 819 bytes ($FFFF-$F000 / 5) to be loaded before the PC rolls over into your RAM.

However, once the boot loader is jumped to, it could then poll $F000 to get the remaining bytes. That would only require a single toggle per byte of object code.

I might also put the boot loader into a separate RAM that can be write protected

Write protecting the RAM, or part of it, is a good idea! It should be easy to write protect half of it using one of the address bits - which one depends on the size of the RAM.

It'll be necessary to map the RAM redundantly to cover boot vectors and zero page - but that's a good lesson in the freedoms of address decoding!

It would be worth putting LEDs on sync and r/w - perhaps use the decimal points of the 7-segment displays.

Cheers
Ed

I think Charles F. "Boss" Kettering also said that, but in more pragmatic terms. "Parts left out cost nothing and can't fail.", or something to that effect.


That's where a ZIF socket comes in handy. The BIOS ROM was in and out of my POC unit countless times, and nothing got torn up or otherwise discombobulated in the process. I also made use of a ZIF socket while testing an add-on ROM meant to be plugged into the empty ROM socket inside the C-128. Only real disadvantage of using a ZIF socket is that it has a larger footprint than the typical 28 pin DIP socket.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

My concern is the scope, part count, and complexity of the keyboard and display circuit. On the KIM it's a simple matrix and some 7 segment displays, but both of those are driven by the the CPU.

In the dark ages, probably in an issue of Kilobaud computing, I think I saw a circuit for a stand alone hex pad/ display programmer, and it was not trivial. When the complexity and magnitude of the keyboard and display overwhelm the logic of the system itself, I fear the design is going in to the wrong direction. "See, you only need 5 chips for a computer, but you need 15 more for the the display, plus you get to solder 20 buttons and the 50 connections to the LEDs."

Entering code in to a KIM was not a terrible experience, it worked pretty well. Entering code in to a binary front panel, I've done that too, and it was terrible. No doubt it may get easier if you did it more, but's its really off putting up front. I can't imagine entering code with a set of dip switches. That would get old in about 4 instructions.

I appreciate the feeling that a serial connected device seems like a peripheral, but the experience is pretty routine today, even commonplace among the masses simply by folks comfortable connecting cell phones and mp3 players to their machines.

And if there were some off the shelf, self contained keypad/display (perhaps an 2x40 LCD), that wasn't particularly expensive, it would most likely have a serial interface anyways. Doesn't discount its utility as a standalone component of the board, but, well, there's this serial interface and folks already have a component that can talk to that.

For sure we can envisage a machine with a serial interface, but here I'm exploring an alternative.

The bootstrap which has to be entered in binary should only be needed once as we have non volatile RAM. The process of bootstrapping through two or three levels is actually educational.

I think the same keypad or matrix could be used for the binary stage and then later accessed via a stateful driver which allows eg hex input. Either as is, or by repurposing/rewiring.

For sure, wiring up 64 push buttons or key switches is work, but it's not complexity, and shouldn't be too hard to debug. And of course 20 is easier, and adequate for the second stage of experiments.

A later experiment could of course add an ACIA and USB bridge - but not the base machine.

Cheers
Ed

If you make a separate module, for instance 2 or 4 digits of 7-seg displays on a little PCB with a header connector, then you can stick this on the main board. With a standardized layout, you could stick it straight on the address/data bus for single step debugging/code entry, or you can stick it on the output port of a latch/VIA for user display. You can even use it in completely unrelated projects to quickly look at 8 or 16 bit buses.

Similarly, you could make a little module with 8 toggle switches. With series resistors, this could be plugged straight into the data bus to enter code, or it could be plugged in the input port of a buffer/VIA for user input.

So, when first bringing up the board, these modules could be used for lowest level bootstrapping, and as soon as the user has built that functionality, the same modules could be re-purposed for other functions.

Yes, a reusable/pluggable construction of the 8-bit I/O is a good idea. It suits breadboard too. (Breadboard has to be the most accessible, visible and flexible approach - at the possible cost of reliability and top speed. But top speed is irrelevant here, and in my view reliability of even just a few hours is quite enough to do a lot of interesting and educational things.)

It's easy to imagine a late sub-project is to consolidate the machine into a soldered (or wire-wrapped) form - whichever of several approaches seems best.

Cheers
Ed

Here's an idea for a ROM

http://qrp.gr/coreROM/

This sounds like a good idea, but you will need some "analog" glue circuit to drive this ROM safely. I think you will end up in a much more complex circuit then the rest of the 6502 system. Nevertheless id would be really cool to crochet your bootloader

_________________
How should I know what I think, until I hear what I've said.

Just another idea, to build something like this as a TTL-Version.

Several 4-to-16 or 3-to-8 decoder could be cascaded to create a 8-to256 or 7-to-128 decoder providing simple address-line decoding for the"ROM"-input.
A octal latch could aggregate the data-lines to provide a 3-state output.

Just take the picture as example. If you remove a diode, you set a bit to "0" if the diode is present, the bit is "1".
It should be possible to create a PCB the provides two pin-header for each byte in rows of the several "bytes". Up to 4 or 8 bytes could go in one row.

Then you can start to set bits to "1" with a diode, or leave it "0" by let the connection open. A set of 100 schottky diodes is about 8 or 9 bugs maybe less if you get a good price.

You end up with a PCB that has 7 or 8 address lines, 8 data-lines and a "/OE" line that could act as a simple 128 or 256 byte ROM you can mask by your own.

are 128 bytes enough for bootstrapping code?

_________________
How should I know what I think, until I hear what I've said.

Yes, you can surely do it with diodes, and despite Arlet's "Practical guide"(!) I think diodes might be more practical than cores...
In a previous thread it looked like 32 bytes should be enough for a minimal bootstrap over a UART. Bootstrapping from other kinds of peripherals might be harder, of course.

Cheers
Ed
(See http://research.microsoft.com/en-us/um/ ... 000356.htm)

Heh how about a board with a customizable diode matrix ROM (e.g. 32 bytes) with a couple of I/O chips to decode the address and a connector that's compatible with a 27XX EPROM. Those with too much time on their hands can solder their own bootstrap ROM together. Others can use an [E]EPROM.

Or how about an EEPROM combined with a diode matrix? Maybe combined with switches to single-step through the EEPROM and change the code as you go?

I think the amount of time that users want to spend bringing up their system varies almost from person to person. Some just want it working instantly and don't care if they can never change the boot ROM. Others are willing to spend a lot of time doing things within the confines of some limits they set themselves (no EPROM / no FPGA / no "magic chips" etc).

===Jac

To analogize Jac's post, I built my own house (POC V1) with the floor plan and features that I wanted, but didn't fell trees and fire clay to do it. There's only so much time allotted to all of us. My philosophy is to use that time to create the things that can't be readily purchased. Lumber and bricks aren't in that category.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

So you're now advocating purchasing a Raspberry PI and a few Arduinos ?