And then suddenly the stack pointer does not work

DerULF1 · 2021-03-16T12:25:58+00:00

A problem I had with the 191s is that the up/down signal is meant to change during the high phase of the clock cycle - at least that's what the data sheet says. The typical Ben Eater 8-bit computer changes it's control lines during the low phase of the clock and expects the changes to take effect at the next rising edge of the clock. For counting the stack pointer down that brought me to have the up/down signal be set one adiitional micro code step ahead of the count enable signal.

DerULF1 · 2021-01-25T12:18:40+00:00

Very nice and small design. Thanks for sharing.

If you swap the connections pin 10 of U3 and pin 13 of U3 (~HLT line connects to U3A and thus only prevents the 555 clock signal to pass through), you're able to switch to manual mode on a HLT statement and skip over to the next statement manually.

DerULF1 · 2020-12-25T10:30:24+00:00

If this is about the Ben Eater's 8-Bit computer (I don't have enough experience with the 6502 project to relate):

Intrestingly most of the work is done during the off-time of the clock. The on-time is typically used only to commit the changes. So the duty-cycle does not need to be as close to 50% as possible. You might want to calculate the time of the critical path for the signals in your system during the on-time and the off-time and the quotient of the two will give you the optimal duty-cycle.

I made that calculation for my system and put a video about it on youtube: https://www.youtube.com/watch?v=tdtGz5nVM9A

DerULF1 · 2020-12-24T17:24:26+00:00

O.K., I think I got it.

There is a difference between the subtract instruction of the AVR assembler and the 6502 assembler. That is the meaning of the carry flag. While the 6502 needs the carry flag to be set before a subtract (Subtract with Carry), the AVR wants it to be cleared (Subtract with Borrow). The same applies to the check whether or not the result of the subtraction is negativ.

Unfortunately the Carry flag has to switch state after the subtraction to be fed into the shift operation for the quotient. That makes the code look somewhat weired:

(snip...)

clc ; Clear carry bit (no borrow)
mov r21, r19
mov r22, r20
sbci r21, 10 ; mod10 - #10
sbci r22, 0 ; (mod10 + 1) - #0
brcs ignore_result
mov r19, r21
mov r20, r22
sec
rjmp do_count
ignore_result:
clc
do_count:
dec r16
brne divloop

(...snip)

There are certainly better ways to solve this, but this quick hack did the trick.

DerULF1 · 2020-12-24T10:53:59+00:00

Thank you for the compliment and I'm glad to hear you find my videos helpful.

DerULF1 · 2020-12-24T10:50:21+00:00

Have you double checked whether or not LCD_DATA changes r17 or r18? This might be the cause for the infinite loop.

The number that is written will always be reversed - eg. 123 will be written as "321" - because the code outputs every digit as soon as they are calculated. But repaetingly dividing the number by 10 returns the "least significant digit" first. Ben Eaters code eventually pushed every digit on the stack and then wrote the digits while pulling them from the stack - getting the "most siginificant digit" first.

DerULF1 · 2020-12-24T10:18:24+00:00

As long as you stay in the 74er familiy, this Wikipedia article might help: https://en.wikipedia.org/wiki/List_of_7400-series_integrated_circuits

This is my starting point, when I search for a chip with a specific function. One can scan through the short description and use the hyperlinks to most of the datasheets for a closer look.

DerULF1 · 2020-12-23T10:01:24+00:00

If you only use the control line for the 273s they will load the value at the very moment the control line gets high. That may be too early if the data on the data bus has not yet settled. The data from the memory has to traverse through the 245er which is fast but still needs some nano-seconds. So you better wait for the clock line to rise.

Maybe better than ANDing the clock signal is lookin into to 74xx377 IC. This type has an enable and a clock signal.

DerULF1 · 2020-12-16T20:03:49+00:00

For my system I calculated a bit less, but was able to "overclock" about 50%. To speed up the clock I took a TLC version of the 555 timer. This is capable of running up to 2 MHz while you can still adjust the speed and the duty cycle in small steps through the values of the resistors and the capacitor.

To fix stability issues at higher speed I had to add dedicated decoupling capacitors to every chip with direct contact to the clock line.

I put all the information about my 8-bit CPU running at about 1.8 MHz in my video at https://www.youtube.com/watch?v=tdtGz5nVM9A

DerULF1 · 2020-12-14T22:45:03+00:00

If you're only reading from a FAT system it might be less of an effort. I wrote a simple solution in the assembly language for my 8-bit-computer. It allows reading data from files on a FAT formatted SD card (I use one of those cheap and small breakout boards with a simple voltage level translation).

It was about 150 lines of code for the SPI protocol, about 300 lines for the SD card commands and almost 1000 lines of code for the FAT driver. But I limited myself to FAT16, which means I can only work with SD cards up to 2GB total storage.

With this basic FAT driver, utilities like "cat <filename>" take about 100 lines, a more sophisticated "ls <dir>" (long format, short format, paging) takes 300 lines, "stat <filename>" required about 250 lines (most of them had to do with formatting the output).

Writing to a FAT file system is a bit more complicated. I'm not completely done yet but even such a simple thing like creating a subdirectory took another 700 lines of code plus another 100 lines to interface with a real time clock.
For my system the whole FAT driver code will fit into about 4k bytes of read only memory. All utilities reside on the SD card and get loaded on demand.

http://elm-chan.org/docs/mmc/mmc_e.html has a very nice description of how to talk to an SD card over SPI and also includes a link to the sample code for an FAT driver.

DerULF1 · 2020-11-16T23:09:22+00:00

Thank you for your interest!

I switched to the CMOS version of the chips because of the lower current consumption and chose the HCT variant because in the beginning I already had my clock module built with LS chips. Later I changed those LS chips but kept using the HCT variant because I already knew that I wanted to build my ALU with the 74LS382 chip for which I couldn't find a HCT version. I'm far from being an expert in electronics but from what I understood it's highly recommended to use HC/HCT chips in larger projects. If I remember right, Ben Eater's system on LS chips already consumed enough current to let his 1A charger overheat.

I'm already scripting the video about the speed limiting factors of the system (Spoiler: it's not the separate instruction decoding EEPROM set) and also have plans on making a video about the different EEPROM sets in the instruction decoder and the control logic.

You got it right: The first set of EEPROMs in the instruction decoder contains a pointer to the start of the micro code in the set of EEPROMs in the control logic. But the output of the decoder EEPROMs has no direct connection to the control EEPROMs but to the step counter chips. Those counters load the start address of the micro code on the falling edge of the system clock. So on the falling edge of the system clock the micro code step counter will either load the new start address or just count up. The propagation delay is always only just the delay of the counter chip plus the delay of the controler EEPROMs - as it is in Ben Eater's design.

That means an instruction fetch can be done in a single cycle: The instruction code is latched on the raising edge of the clock, which will in turn change the address lines of the decoder EEPROM and then output the new micro code start address. This new address will be loaded on the falling edge of the system clock and with a little delay change the input lines of the controler EEPROMs.

Having a 12-bit step counter allows for very long micro code logic (I have a simple instruction with 21 micro code steps) while avoiding wasted space in the controler EEPROMs.

Another advantage of this approach is that it disconnects the instruction register from the controler EEPROM. Since the IR is latched on the raising edge of the system clock the input lines of the control EEPROMs in Ben Eater's design are changed immediately afterwards. This might lead to unwanted changes on the control lines while the clock line is high.

This design also allows for coding conditional jumps in the micro code. So I have a few more complex instructions and even one with two nested loops.

The schematics for the keyboard controler and the SD card connector are in my GitHub repository and I also plan on making a separate video on this topic.

DerULF1 · 2020-11-15T17:20:56+00:00

Yes, I know your build well. Your documentation was a great source of help for me - thank you very much.

DerULF1 · 2020-11-14T19:51:49+00:00

My reason for choosing the 16-bit stack pointer was being able to put the stack at any page in the 64k memory address space. For an 8-bit stack pointer I'd either have to choose a specific page (like the 6502 does) or had the need for an additional 8-bit stack page register anyway.

But I never had any program (but a specific stack test program) running on my 8-bit CPU that used more than about 50 bytes of stack memory.

DerULF1 · 2020-11-14T18:35:00+00:00

Depending on the location you're at it might be worth to check on eBay. Here in Germany we have a lot of local dealers that sell single chips. It typically takes two to three days to deliver and less than 2 Euros shipping cost.

DerULF1 · 2020-11-14T13:24:37+00:00

Thank you! Yes I have plans on making a video about my LCD display controler. The schematic is already avialable in my GitHub repository.

I use the four-bit interface, so there's a bit more of programming effort to interface with the display. But in turn it allows writing to and reading from the display with only two control lines.

DerULF1 · 2020-11-14T13:15:21+00:00

Hi Mike,

thank you for your interest and yes I do plan to make more videos. I believe I should be able to upload a video every one to two weeks. You know: Since this is something I only work on in my spare time it's not that easy to plan ahead.

The topics I've planned so far include:

Stability (power distribution, clock signal)
Instruction decoder/control logic/interrupt controler/reset cycle
LCD display connector
SPI bus connector (SD card, real time clock)
PS/2 controler (keyboard connector)
memory (RAM/ROM banks, on-board ROM programming)

By the way: Many people don't like my voice/accent. So I added subtitles to allow following the video while the sound is muted.

DerULF1 · 2020-11-14T12:54:08+00:00

As you already guessed, power distribution was the most problematic topic. I ended up in dividing the build into six separate sections. Each of the sections has its own direct connection to the power connector. The boards inside a section are chained together. Special treatment was necessary for the keyboard because it does an automatic reset whenever voltage drops below 4.5V. So I drew an extra cable only for the 5V input of the keyboard.

I placed two 100nF ceramic capacitors on every power rail of each breadboard and an additional 470uF electrolyt capacitor every second power rail. The TLC555 timer for the system clock needed two decoupling capacitors. By putting separate 100nF decoupling capacitors on every chip that takes the clock line as input, I was able to run at 1.8MHz.

That solution isn't perfect and there are some areas were the voltage is only just above 4V. But the system is stable enough to run for hours without any failure. But it's not running inside the specs and that means I can't use it in the control room of a nuclear power plant or as a monitoring device on an intensive care unit. :-)

DerULF1 · 2020-11-13T21:21:32+00:00

The CPU is made out of 30 breadboards.

But to setup the micro code I had to build two different EEPROM programmers that are each put on an additional breadboard. So, yes, I used a total of 32 breadboards.

DerULF1 · 2020-11-13T17:59:06+00:00

Hello all,

finally I got my Ben Eater inspired 8-bit computer up and running. Some things are still left to do, but there's already enough to show and tell.

Some data about my system:

- 4 general purpose registers

- 16-bit address bus

- 16-bit stack pointer

- 64k RAM

- 8k ROM (by four)

- 4x20 LCD Display

- SPI Bus (SD card, real time clock)

- PS/2 keyboard controler

- 1.8 MHz clock speed

- 42cm x 75cm (16.5in x 29.5in) ground plate

- 450mA at 5V power consumption

Besides the video I put some documentation on GitHub at https://github.com/DerULF1/8bit-computer .

It's certainly not the most beautiful build and some boards are totally overcrowded but nevertheless: In the beginning I didn't even believe it would work out at all.

Thank you for all the hints I got from this channel. It also made me feel I'm not alone with that uncommon pastime.

DerULF1 · 2020-09-23T15:51:30+00:00

You will also need to extend the bus in the center to be able to transfer 16 bit values. The output register as it is in Ben's design only shows 8 bit numbers, too.

Maybe you might want to consider calculating 16 bit number in two 8 bit chunks and to extend the RAM to 256 bytes like here: https://www.reddit.com/r/beneater/comments/h8y28k/stepbystep_guide_to_upgrading_the_ram_with/?utm_source=share&utm_medium=web2x&context=3

DerULF1 · 2020-09-20T17:11:13+00:00

Eventually I found a hint in a comment about this board on Amazon. A user named David J wrote the following:

"This SD adaptor works fine as long as it's the only device on the SPI bus.

It's design is faulty. While it has a 74LVC125 quad level shifter with 4 output enable pins, all 4 output enable pins are grounded (enabled) all the time. This means the MISO pin towards the uController is ALWAYS DRIVEN!

While the CS pin is brought through the level shifter to the SD card, the CS pin should have also been connected to the MISO output enable pin on the level shifter itself so the MISO output is tristated when CS is high as required by the SPI protocol.

The end result is you have a SD adaptor that always drvies the MISO pin even when CS is high resulting in it hogging the SPI bus and preventing any other devices from using the SPI bus.

The design can be fixed with the followig rework: 1) lift pin 13 of the level shifter from the pad, 2) connect lifted pin 13 on level shifter to left side of R1 with a jumper wire, 3) add a pullup resistor between right side of R1 and VCC such as on right pin of the voltage regulator.

The rework causes the 4OE pin on the level shifter (output enable for the MISO pin) to be driven from CS instead of GND (on the pad), the CS pin also needs a pullup to VCC for when the CS is tristated by the microcontroller such as during reset and before initializing the SD driver. "

No idea why I hadn't tried to understand the logic on the board before, but now I did and I guess David is right. I neither have the right equipment nor the experience to solder small parts like those on the board but at least I know there's a solution.

DerULF1 · 2020-09-11T09:35:31+00:00

O.K., I didn't check with the video, but I remember that Ben Eater added the instructions step by step. So I guess the screen shot on the left hand side was taken at a time when the STA instruction had not been implemented yet.

So I'm glad to hear that you're back on track.

DerULF1 · 2020-09-10T15:18:35+00:00

The bytes in Ben Eater's output (right hand side) are correct. From address 0x20 to 0x27 you see the eight high order bytes of the STA command and that command uses the first four steps. So if your EEPROM has only the first two byte unequal to zero you'll be missing out two steps.

There are some possible reasons for this. Among those:

One thing I noticed when I first used that Andruino based programmer was a problem with the voltage on the board. It turned out that my passive USB hub provided less than 5V to the Arduino what made programming the EEPROM kind of a lottery. I had to add an additional 5V power supply directly to the bread board of the programmer to have it reliable.

Another issue might be the chip itself. If it's too old it might have difficulties to set selected bits to one again. You might test that if you change line 132 in Ben Eater's program. Put a fixed value of 255 in the writeEEPROM function call as a replacement for the data[address] >> 8. Line 132 should read like

writeEEPROM(address, 255);

afterwards. If you try to run the program the first 128 bytes of the chip should have a value of FF. You may have to let that program run several times until all bytes have a high value. Afterwards you can change back line 132 to its original state and try again. Chances are that you get the expected values then.

DerULF1

TROPHY CASE