6502.org

I've set myself a challenge that might seem a bit silly to some, but helps me to learn and discover in a way that is fun to me...

Imagine that you are in a locked room (or on a nice Island or whatever you fancy), and you have a pile of chips and data sheets, wire and basic electronics-making supplies and equipment. Not in the room is there any preprogrammed non-volatile storage or already designed and built computer systems. Your goal is to incrementally build up a fully working 6502 computer with keyboard, video, storage and the ability to program it nicely, and maybe create some video games.

So here is where I am in this process: This has just gotten to the point where I can program in machine language. entering bytes into NVRAM using a hex keypad, and watch the CPU run, either using the LED address/data/control line visualization when single stepping the clock, or using an oscilloscope to look at the various lines when running up to 12.5875 MHz so far.

There is one module per wireless proto board. The first one I built is the clock/counter module in the upper left, with a crystal oscillator module starting a divide-by-two chain at 25.175 MHz. The second module is in the lower left, which turns hex keypad presses into keypress events. The third is in the lower right. That takes hex keypress events and turns them into a nonvolatile RAM byte editor. There is no hex-to-segment/font decoding yet, so the address and data values are displayed in binary for now. Finally, the programmed NVRAM can be moved to the upper right CPU module to be executed. The CPU module proper is the upper half, with the CPU, clock half-stepping circuit, address decoding and RAM control logic. The lower half has a bunch of LEDs to visualize the address, data, control and memory-mapped output latch (the latch is the chip just to the right of the LEDs).

My long-winded journal of the design and build process, with a number of tangents, is captured at http://cognigraph.com/6502. I'll put more at that web link as I go along and post here on the forum as well.

The key chips I'm using so far are:

• CPU: W65C02S PDIP
  NVRAM: amazing CY14E116L-ZS25XI (acts like a static RAM, similar performance, but saves itself to a NV store on the same chip on power down)

The rest is mainly more mundane 74Fxxx gates, latches, counters and glue logic, and a 25.175 MHz clock module,
Here are some details on each of the four prototype modules so far.

CLOCK MODULE

I started by using the 12-bit ripple counters tied to the 25.175MHz crystal oscillator module, but realized the ripple counters have nasty glitches in the count values if you use their outputs directly. While it is possible to do some sort of latching to fix this, that seemed overly complicated. Searching around, there is a sweet 74xx163 counter chip that deals with this latching nicely. I also played with using 74xx175 flip flops directly, maybe combined with some logic similar to what the 74xx163 has. This would have the advantage of providing normal and inverted outputs per clock counter bit.

My second build-out after the ripple counter demo was using straight 74F163’s clocked directly from the 25.175MHz clock. This worked when chaining together around six of them (4*6=24 bits count out of the 32 bits I was aiming for), then the seventh counter chip would not count. It turns out this was due to the chained propagation delays of the carry lookahead logic: it just could not manage that many chips in the chain at the high clock speed. So I placed a one-bit flip-flop counter using a 74F175 at the beginning to divide the fast video clock in two, to 12.5875MHz, and was able to chain eight 4-bit 74F163 counters off of that. With that fix, I think the clock module is adequate, and will supply the following interface lines: GND, +5v, clear input, 25.175MHz (640x480 VGA dot clock), 12.5875MHz (CPU clock), and count bits 0 to 31. Total lines used: 37. It turns out that the big soldered proto boards I have include 37 pins on the edge connector array. What luck!

The clock module counter has 32 bit, with cycles time going from 6.29375MHz in powers of two divisions:

• Bits 0-3:
  6.29375mHz/158.9ns, 3.146875mHz/317.8ns, 1.5734375mHz/635.6ns, 786.71875kHz/1.271us
  Bits 4-7:
  393.359375kHz/2.542us, 196.6796875kHz/5.084us, 98.33984375kHz/10.169us, 49.169921875kHz/20.34us
  Bits 8-11:
  24.5849609375kHz/40.68us, 12.2924804688kHz/81.35us, 6.14624023438kHz/162.70us, 3.07312011719kHz/325.40us
  Bits 12-15:
  1.53656005859kHz/650.80us, 768.280029297Hz/1.30ms, 384.140014648Hz/2.60ms, 192.070007324Hz/5.21ms
  Bits 16-19:
  96.0350036621Hz/10.41ms, 48.0175018311Hz/20.83ms, 24.0087509155Hz/41.65ms, 12.0043754578Hz/83.30ms
  Bits 20-23:
  6.00218772888Hz/166.61ms, 3.00109386444Hz/333.2ms, 1.50054693222Hz/666.4ms, 0.75027346611Hz/1.333s
  Bits 24-27:
  2.666s, 5.33s, 10.66s, 21.33s
  Bits 28-31:
  42.65s, 85.30s, 170.60s, 341.2s

HEXADECIMAL KEYPAD

Inputs: 10 consecutive clock lines (bits 6-15), ground and +5v
Outputs: positive-edge clock line, 4 data lines, for hexadecimal keypress events

The keypad is scanned 192 times per second. For each keypad row, four R-S latches are set initially, and selectively cleared should a key down be detected for the respective key in the row. Near the end of the per-row time slot, these R-S latches are copied/clocked-out to a set of four serial-in/parallel-out shift registers, and before the row increments, the shift registers are scanned one-at-a-time to look for key up-to-down (keypress) transitions. Each keypress event found generates a positive-going pulse on the output clock line, and the four associated data lines are the row and column bits appended together to form the hexadecimal value of the key being pressed.

NVRAM DATA ENTRY MODULE

Based on keypress events from the hexadecimal keypad module, the data entry module allows setting up a 16-bit address and 8 bit data value, visualized 1:1 as an LED per bit, and has a ‘write’ button to store the byte at the address. The NVRAM reads the byte at the selected address and visualizes this in a separate 1:1 LED display.

The data entry module is fully functional and tested on a cheap 32kB SRAM as of 2023-06-30. Next step: try getting the expensive NVRAM working. This will require delicate soldering to the proto adapter board, plus hardwiring the extra unused address lines.

By mid July 2023 the NVRAM editing was working. The first NVRAM module got borked, the data MSB stuck high, likely due to the difficulty of soldering the dang TSOP II chip to the DIP adapted board. My second try soldering a second NVRAM worked. The NVRAM indeed remembers the data I have written to it, despite power downs.

INITIAL 6502 MODULE

To start, I am making the 6502 setup run off or a manual half-cycle-step clock, with an S-R latch set high/low with respective pushbuttons. I’ve also added a reset pushbutton and lots of 1x10 LED arrays to visualize all the state, including address, data and clock/control/output lines. I’ll put in a simple clock/counting program in the NVRAM, add memory-mapped output to an 8-bit latch, and see how it goes.

[July 20 or so....] It worked! The memory-mapped output latch shows the count incrementing correctly during half-step execution, and the latch bits show the correct frequencies on the oscilloscope when running at various CPU clocks.

-----------------------

Okay, that is it for the moment. I have a lot more details to document on the work so far, but this gives you an outline. The timing diagram on the keypad scanning is fairly involved/tricky. The CPU/RAM/latch address decoding and control/timing logic is I'm sure well known here, but I should document that in case I'm doing something weird.

I'd love to hear what you all think or would like to know more about.

--Mark Duchaineau

Splendid!

We've discussed minimal bootstraps before: a small ROM, or even very small ROM function implemented in diodes or CPLDs (or maybe PALs) should be enough to load some minimal code which allows for more code to be loaded and tested.

In the case of NVRAM, I'm thinking a good way to proceed is to have two copies of software - the known-good, and the new code under test. One might swap two chips (or modules) in a socket, perhaps a ZIF socket, or one might have a high and a low bank of code and swap between them using a jumper or a switch which feeds into the glue logic.

I think bootstrapping is both an interesting challenge and also a great learning experience, for anyone who isn't already crystal clear on the role of firmware in a minimal machine. And therefore potentially a teaching experience too. These are both themes we've touched on here before.

(Edit: PM sent)

What a great idea.

Pondering idly ...

Video is probably the hardest module - depends on the output device I guess - simple monochrome video (NTSC/PAL) vs. VGA.I suspect I'd pick a simple 320x240 video or 320x192 which fits into 8KB of RAM and might yield a 40x24 character display with an 8x8 font.

Although if you just want characters then Sinclair ZX80 was effectively bit-banged by a sub 4Mhz Z80 and had just 1KB of RAM to give a character display of 32x24 in 768 bytes.. The quality of video output was questionable though, but it did work on most TVs or the era...


Also looking at the history of the Apple 1. That' was pretty much a bootstrap process from ground zero and from what I recall of the history of that, Woz had access to a cross-assembler for the Apple II ... But using a big shift-register for the display memory was an interesting idea to take it out of the system RAM too..

And today we have the luxury of NVRAM for storage rather than tapes...

-Gordon

Nice work!
How are you chaining them together? Some of the datasheets have several options documented that perform better in long chains - the specific ways of chaining are not intuitive but help the carry to propagate quickly enough to support higher clock rates.

Woz is my hero, and a really nice guy the two times I've had a chance to chat with him in person. I absolutely love the creativity and minimalism of his designs, and how open he was with the schematics and code. I haven't read his autobiography yet -- does that go into the design/build bootstrapping or is that from somewhere else?

I'm thinking of working incrementally up to full 24bpp VGA, maybe 640x480 60Hz. My next immediate step is to drive a single 8x8 LED matrix to support editing an initial font. After that, I've got a really nifty 128x64 LED module that I'll try and drive Apple ][ style using the low phase of phi2, when the W65C02S is not using the RAM. At that point (and with a real keyboard hacked and hooked up), I can start building my own editor and assembler and various support libraries. To get to full 24bpp VGA 640x480 I will need to push for a lot more compute, such as more CPUs or higher clock rates, or add some hardware rasterization support (primitive GPU sort of stuff). I was tentatively thinking 6 CPUs would work out nicely with the other requirements, like needing almost a megabyte of memory and six bytes read during phi2 low. From other 6502ers clocking experiments I see that running at 25.175 MHz should be fine, so that would help a lot.

The NVRAM is amazing but, as I discovered, dangerously easy to corrupt/overwrite if something goes haywire in the CPU execution. Copying backups and keeping old versions around seems like the smart move. The NVRAMs I got were also really expensive, over $50 each in quantity 5, so I will move away from them to cheap big flash storage once I get the I/O routines written.

I just connected all the clock lines together and chained the RCO outputs to the ENT and ENP inputs, which I tied together on each 74F163. Thanks for the tip that there is a faster way to chain them that has O(1) instead of O(N) propagation delays. I think I've convinced myself I understand how that works. Here is an example thread out there with details, for those who would like to dig into this: https://electronics.stackexchange.com/q ... -4-bit-syn.
[EDIT: thinking some more, I see it is still O(N) with the fast `163 connection style, but around 16x more stages are possible, which in practice for me is way beyond what I need]

I’ve converted the clock module to a soldered breadboard. Testing it isolated from the other modules was fine, all power-or-two count bits measured correctly on the scope. However, when connecting to the hexadecimal keypad module and the NVRAM byte editor module the keypresses went haywire. It turns out the long wires were getting too noisy, picking up some clock-switching spikes, and creating false keypress signals on the keypress event line. Adding a 22pF capacitor on either or both ends of the event line cleaned that up. Here is the state of the modules with the soldered clock module in place, and the upper left breadboard cleared and starting to be populated for a font editing module. I'm planning for the font editor to have the CPU in the loop. One byte of memory mapped input to grab switch up/down states, and three bytes of output to drive the 8x8 matrix and the address LED bar.

Glad you got the project working, but I won't be surprised if problems like this continue to crop up. And you're not the first to experience issues. The outputs of modern WDC CPU's and WDC peripherals (also certain modern RAMs and logic families) have aggressively fast rise and fall times, making AC performance problems -- especially on solderless breadboards -- a recurrent theme on this forum.

It's partially missing the point to think long wires (meaning signal lines) are the source of the trouble. The other half of the equation is the power/ground network that carries the signal line's return current back to the signal's origin.

The signal line and its return path form a loop which, like it or not, behaves as an inductor... and this unplanned inductance wreaks havoc where high frequencies are concerned (such as the high frequency components of the fast rise and fall times I mentioned). Hence it becomes desirable to reduce the area of the loop and thus its inductance. Shorter wires will reduce the loop area but another remedy, usually more easily applicable, is to provide return paths that are physically close to the signal paths.

You may want to evaluate your project's power/ground network from the perspective described here. The real-world relevance of the matter is validated by other posts in that thread, notably including plasmo's.

Have fun, and keep us posted!

-- Jeff

Thanks Jeff! Indeed, shoring up the power network stabilized the modules wonderfully -- I'm running solidly at 12.5875 MHz as desired with no issues.

Here is my latest progress, a font editor module (used already to create a decent 5x7 font for all the printable ASCII characters):

FONT EDITOR


The next module I built is the font editor. Since I can now program the W65C02S by byte editing the NVRAM, it made sense to go with minimal hardware and put most of the logic into software. The finished solderless version as of 2023-08-23 looks like this while in use: I tried to make the user interface as intuitive and self-explanatory as possible. The use of grayscale for highlighting what you are editing means you can get a feel for what the button presses do quickly. My son, with no instructions, was able to figure it out and make a heart shape in 5 minutes of playing around.

The software interface from the font editor module to/from the CPU consists of:
Output latch at $C000 that drives a bar of LEDs (8 of 10 are used). For the font editing, this shows the ASCII value of the character being displayed and edited.
Output latch at $C001 that drives the 8 row anodes of the 8x8 LED font matrix display. We typically activate (set high) just one row at a time, with the row scan clocking at 12.3 kHz. The whole array is thus scanned at 1537.5 Hz, and with 3-bit (8 levels) grayscale via PWM we end up with full grayscale scanning effectively at 192.2 Hz.
Output latch at $C002 that drives the column cathodes (bit set means LED on).
Input buffer at $C003 that allows reading of bit 10 of the clock module in the high bit and four push button states in the lower four bits (the remaining bits are unused for now). The buttons are:
Bit 0: down button
Bit 1: up button
Bit 2: right button
Bit 3: left button

The hardware interface of the font module to previous modules is:
The clock module bit 10 signal,
the 8 CPU data R/W lines,
the CPU RWB line,
the active-low write enable line (combination of RWB and CPU clock), and
four memory-mapped I/O address decode lines for $C000-3.

The hardware specific to the font editor module is:
3x 74F374 8-bit latches
3x 74F240 inverter/buffers
1x TBD62783APG 8-bit anode driver
8x 330Ω current-limiting resistors to avoid burning out the 8x8 LED matrix
1x SIP bank of 8 330Ω resistors connected together on one end to limit current to the LED bar.
1x 74F32 quad positive OR gates to generate the latch clock signals from the write enable and respective address selection lines.
1x 74F00 quad NAND gates to generate the output enable of one of the `240s to output to the CPU data lines, based on the $C003 address decode selection line and the CPU RWB line.
A 10 LED bar (currently using only 9 of them)
An 8x8 LED matrix
4x push buttons
I’ll work on putting out some schematics.

After shoring up the power bus wiring, I’m now running stably at 12.5875MHz with all five modules hooked together: clock/counter, hexadecimal keypad scanner, NVRAM byte editor, CPU module, and now the font editor.

To keep my sanity, I modularized the code into moderately small subroutines, since I am only using a byte editor to code in machine language right now, and don’t have the ability to add or remove code from a routine except at the end of it, and thus end up rewriting the whole thing if there is an error or modification needed.

The memory state for the font editor consists of:
$00,$01: low and high byte of a 16-bit loop counter for timing. One application loop takes 81.4 usec (12.3 kHz). 256 loops takes 20.82 msec, and the full 65536 loops before wrapping takes 5.333 seconds.
$02: the ASCII value of the character being edited.
$03: indices of the row and selection of ASCII/row/column being edited at the moment.
Bits 0-2: index of row being edited
Bits 3-6: 4-bit code of what is being edited
0000: up/down add/subtracts $10 from the ASCII value.
0001: up/down add/subtracts 1 from the ASCII value
0010: up/down moves the row being edited up/down.
0011: leftmost/bit 7 pixel column for row is turned on/off with the up/down buttons.
0100-1010: Bits 6 through 0 are similarly edited using the up/down buttons.
Bit 7: always 0
$04-$07: up/down state and timers for buttons 0-3 respectively.
$08-$0B: The auto-repeat countdown timer for buttons 0-3 respectively.
$E000-$E7FF: the font itself, with 8 bytes per character (8x8 bit mask), 2kB total for 256 character bitmaps.

The font-editing code is broken up into the following routines:
Generic main loop that does general 6502 reset initialization (stack pointer to $1FF, $00 into status register), calls the application-specific initialization routine, and then in a forever loop calls the application per-loop work routine.
Font-editor init routine: clears $00-$07 to zeros, a reasonable initial state, then calls the clock sync routine so that the first-loop timing relative to the clock edges is the same as the Nth loop, in case that matters.
Get column mask in A from $03 edit selection variable.
A = A >> Y
A = 1 << Y
Wait for the clock line to change (used for synchronization/timing).
$10,$11 = address low,high of first byte of font memory for ASCII value in $02
Font editor per-loop work:
Handle key press events
Handle button indexed by X for X=3,2,1,0, generating key press events on first down press with debouncing, and for key press auto repeats for long button holds.
Handle button X key press event. The left/right buttons navigate what is being edited, and the up/down buttons change state on whatever is being edited.
Update display. The ASCII value is put in the LED bar using $C000, the active row in the 8x8 LED matrix is set using $C001, and the highlighted font row is output using $C002.
Highlight font row bits in A based on frame number modulo 8, to get grayscale visual cues as to what is being edited.
Increment loop count $10,$11
Clock sync
Overall the font editor code comes in at under 768 bytes, and lives at $F000-$F2FF. Boy, that was a lot of tedious hexadecimal data entry! I’m really looking forward to getting a more proper display, full keyboard input, and assembler going.

Great! It's really nice to see all this authoring happening on the actual hardware being built without cross-development.

Well done! Good progress and a fantastic learning experience.
Reminds me of my HP1000 days, there was no BIOS on those machines, they were pretty-much dead electronics when powered-up. You had to toggle-in (in binary) some bootstrap code and the microcode was then able to get at the OS file on disk or tape and boot into it. If you made a mistake when building the OS file (it was called system generation, or sysgen) - you were left with a very expensive system that refused to work. Only choice (if you didn't have a fallback copy), more toggling and then using the amazing HP2645 VDUs with mini data cassettes to get a minimal system running to re-do the sysgen. As you may have guessed : been there, made lots of backups afterwards!

I'm trying to resist building a 'toggle the initial program load' in by hand approach, per the IMSAI...

Neil

The hexadecimal keypad is definitely a step up from toggling switches for binary input! I'm really glad I took the time to design and build that. I would probably make it a bit easier to use given my experience now putting in the better part of a kilobyte of machine code...

On bootstrap loading: eventually I am planning to have the CPU running purely in SRAM (the volatile kind) and have a hardware bootstrap circuit that loads maybe 256-4096 bytes into the top of memory from e.g. flash storage on power up and jumps to it.

Here is a quick update on starting the display module using a nifty RGB LED matrix module.

LED RGB PANEL

Next up, after getting a complete 5x7 font edited, is a display to put text onto. After considering generating NTSC or VGA analog video, or directly driving an LCD panel digitally, it looks like the easiest option is RGB LED matrix modules, the kind intended to be mosaiced into large billboard or stadium video displays. The one I got is a 2mm pitch 128x64 module for under $60. The first one that arrived was somewhat damaged, as the wee RGB led pixels can break off easily with rough handling, but still usable for developing the driver circuitry: These display panels are quite bright, and draw a lot of current, hence the beefy power cable. Here is a close up of where some teensy surface mount pixels got knocked off: There are some great resources online of folks reverse engineering how to drive these types of modules. A Google search for HUB-75E led panel pinout will get you some of these. It turns out these modules are super simple to talk to in a TTL prototyping environment, much simpler than trying to cook up a VGA signal or drive an LCD panel. I boldly hooked my module up to my power supply, and with no additional chips was able to display all white with a few minutes of wiring: There is a 16-pin ribbon cable with a simple serial TTL type interface. You are driving two scan lines at any one time, 32 pixels apart, and provide a five input address of which scan lines to activate . I just hooked these to five contiguous power-of-two clock lines from the clock module. There is a clock line for loading two RGB pixels at a time, shifting the data into the two row shift register chains. There is a latch line to put the loaded data into the drivers. And finally an output enable line. I hooked the LED data clocking line to a faster clock line in the clock module. The RGB inputs I hooked to 5v. I moved the latch and output enable lines by hand between ground and 5v. And voila!

Note that I rearranged the placement of the NVRAM byte editor module to make room for the future LED display module driver module. This was easy since the byte editor only has connections to the hexadecimal keypad module, and is independent of everything else. I did need to improve the power/ground wiring network some more, mainly since the clock module only had a single connection each to ground and 5v that was too far from the modules it was not directly connected too. So I connected it at all four corners to all four modules that it talks to, respectively. So I’m still good to go running all these modules at 12.5875 MHz as they spread out more and more in the build-out process. Eventually I will be converting the designs that seem stable and are “keepers” to soldered bread boards. I’ve ordered a bunch of Samtek SSA-132-W-G stacking “shield” type headers to make a vertical stack of well-connected modules. I’ll either use my initial breadboard design that I got three of from OSH Park, or refine it a bit first and do another run. Here is the manufactured board:

Update 2023-08-28: LED panel timing circuit

Looking at the back of my LED 128x64 RGB panel, I see the critical chip type is labeled ICND2038S. Google search gave this data sheet:
https://olympianled.com/wp-content/uploads/2021/05/ICND2038S_datasheet_EN_2020_V1.6.pdf
This is written in a fairly confusing way, but gives some good hints and min/max specs. Playing with driving the panel, I came up with the following timing circuit that works great: The idea is to clock in 128 pairs of pixel data (two pixels in two rows are loaded per clock pulse), then, while the clock pulse is low just after this finishes, generate a positive latch pulse and a positive output enable pulse (OE is active low, but latches with a positive pulse). So there is a kind of double latching sequence going on. The neat things about this timing circuit are: 1) it does not require any timing gap between transmitting double rows, and 2) it uses only two chips (in the context of having the power-of-two set of clocks from the clock module) – a 74F175 acting as a serial-in-parallel-out shift register, with positive and inverted outputs, and a 74F08 positive AND gate. The use of the flip flop to sample the MSB pixel count signal serves to grab the count signal at a safe/stable point in time, not right at the count signal edge in other words.

Here is the result in action, using some power-of-two clock signals as pixel data to get some color patterns. This timing circuit updates cleanly and correctly when I switch the input data, such as hooking one of the color inputs to 5v or ground. My next step is to get data during phi2 low, Apple ][ style. This will involve some surgery to switch the RAM’s address/data/control lines back and forth between the CPU and the video every phase of phi2, likely with a bit of delay/lag needed since the W65C05S needs 10ns beyond phi2 going low. My NVRAM, when powered, is equivalent to a 25ns SRAM, so I’ve got some timing margin to work with. I obtained some impressive-on-paper fast FET bus switches (both 2:1 and 1:1 styles). We’ll see how those work out.

Nice! I love the brightness and colour of that display, it'll be great when you have your font on it!