In turbo mode, the computer runs at 6.67MHz (one third of the 20 MHz oscillator). In normal mode, it runs at the conventional speed of 4.77MHz.
I've tried to run it at 8MHz using a 24MHz oscillator but that was way too unstable.

Here is the system booting


Here is a top-down view of the breadboards. The video adapter takes the seven breadboards on the right, the CPU and other peripherals are on the left.


Running the basic benchmark. On line 250, there is an actual ^G character between the quotes. It doesn't show on screen, but it can be heard when listing the program


Showing a region of the Mandelbrot set. Here, the 8087 FPU makes all the difference.


Note that the white dot alone in the middle of the large green area is not a bug or an artifact: it's the mouse pointer

Can you run the chip in 8080 mode?

I suppose I could

Actually, I don't know much about 8080/Z80, and I have absolutely no idea what is needed to run the V20 in that mode.
The architecture is actually very close to the IBM PC, with the video text buffer at address B8000h, so at least that would require dedicated support.
The I/O space is 64k in both 8080 and 8088, so I don't see why it wouldn't work.

That could be a nice project, actually...

Having created the Sieve benchmarking code for the LALU Computer (written in LANG), I have spent about the last week trying to make it go faster! Attached is a summary of the changes I've made and the improvements in run time that resulted.

One of the most effective changes was to reduce the number of lines in the program. That makes sense because every time a line is parsed it must first be loaded into the Keyboard Stack. The line loading procedure also had some wasted motions, and these were eventually reduced by creating a character count parameter for each line that specified exactly how many characters to load.

I also modified the LALU ROM and removed the multiplication operation (which was not very good) and replaced it with a lookup table for converting a pair of ASCII characters to the hexadecimal number. Every little bit helps.

My next step is going to be changing the hardware architecture of the Keyboard Stack. More about that later! Michael

Following along with interest. Reminds me of calculating PI to ridiculous numbers of digits.

> Isaac Newton devised an arcsine-like scheme to compute digits of π and recorded 15 digits, although he sheepishly acknowledged, “I am ashamed to tell you to how many figures I carried these computations, having no other business at the time.”

Having made the changes previously listed for running the Sieve program I was able to get the time down to 110 seconds. I decided further improvement required a change in the stack operations. There are 3 stacks: Data, Return and Keyboard. The Data Stack is used as a scratchpad space for doing math and logic. The Return Stack is used for nesting and subroutine jumps.

The Keyboard stack is something different. Although I have been calling it the Keyboard stack, it really is a space for holding the ASCII characters forming the program line that is being parsed by the interpreter. Everytime a new line is to be parsed the line is moved from SRAM storage to the stack. This was slowing things down!

Therefore I made a hardware change to allow multiple Keyboard Stacks. This actually was fairly easy to do, as it only required added a register to hold a stack address. (Previously the upper SRAM address lines were connected to ground, that is to say not used.) I also added an instruction to 'zero' the stack counter. This also was fairly easy to do because the 74LS169 counters have a preset feature.

So the long and short of it is I have a an array of stacks for the keyboard stack. Jumping from one to the other is quick and simple. Rerunning the Sieve program with the multiple stacks has reduced the execution time down to 57 seconds. I'm happy with that improvement, and have started to think about additional changes. Michael

Is that something like an indexed addressing mode? Or more like a limited (but adequate) number of cache lines for parsing?

Yes, it is like a set of cache lines for parsing. There are 16 caches that can be sent to the Parser. Any cache can be selected with a single machine language instruction byte. The top nibble of the instruction is E for Stack Select, and the bottom nibble is the cache number. So the instruction to select cache zero is "E0". The Go To instruction in LANG is really just a Stack Select.

Loading each cache is done with a line editor I have written. The line editor is engaged when the first character in the line is a "#" symbol. So, to fill Cache #1 and #2 with code you might enter something like this...

#1 "HELLO WORLD" :This prints HELLO WORLD on the LCD
#2 QUIT : This exits from List Mode
RUN : This runs the program starting with Cache #1

Hi, I have been toying with the idea of designing and building a video card for LALU. There really are alot of different directions I could go... I have some of the old project books from Don Lacaster "Cheap Video" and "Son of Cheap Video" which might be a direction to take. Another idea might be to go with something like the Monochrome Display Card (MDA) that was used on the IBM PC. Having posted many photos of my project, you can see that I generally go with 74LS TTL logic with through hole support components and double-sided PCBs. It would be nice to stick with that. Creating and buring ROMS is also no problem, and that might actually be a nice fit since I use ROMs for the ALU, Controller and Code.

I'm wondering if you might have some thoughts or ideas about what might be a nice fit for a video display output on LALU, that is better than the single line LCD being presently used? Thanks! Michael

One possibility is the Parallax Propeller chip, I think it is a 40-pin DIP. It can do lo res VGA video and has built in RAM. CAn probably interface with a minimal number of chips. It has one benefit of being more recent. I have not used it myself but noted it in several projects. A TI9918 series part also needs only a few supporting chips. There are other chips 6847, I’ve used which has a built-in char ROM and tri-state bussing. It may be hard to find though. 6845 has been popular in the past. Progressing to video circuits that need more and more chips here.
A 6845 CRTC controller, if it can be programmed will save a lot of counter chips. Otherwise, another circuit I studied was the AppleII video schematics in the AppleII Red book. The video there is timed with a bunch of TTL counters and logic gates to decode sync signals.

Thank you for those suggestions! They saved me alot of time doing background research. I am partial to the MC6847 solution running in basic text mode. I found a few websites with some introductory information on using the MC6847. I see this IC solution was also used in the TRS-80. Browsing EBAY it looks like almost all the sources are from China now.

https://pmig96.wordpress.com/2020/07/15 ... t-circuit/

http://homebrewcpu.blogspot.com/2009/02 ... rator.html

For a display device, I used a surplus car rear-view monitor. About 3" squarish. Had a simple composite input.

With the 6847 more greyscale levels can be had by including the phiA, phiB chrominance outputs in the output. I think the outputs are just voltages with some buffering a simple set of resistors can be used to combine output levels. I had a circuit sketch for this somewhere, I'll try and find. The luminance output by itself only gives about four different levels of grey. Getting a composite color display is trickier and probably requires a MC1372 which I think is rare.

Well, this post definitely falls into the category of don't ask a question unless you are ready for the answer! Since I started the LALU computer project I have been working with a 1 MHZ crystal clock and a ring counter with 6 rings per cycle. I have a 50 line bus on my motherboard for distributing the hardware signals to the various plug-in boards. The only precaution I took for noise was to tie each of the 50 lines to ground through a 1K resistor and an LED (For indicating voltage level.) Data lines 1-8 also have a 390 ohm resistor to ground to stop the lines from floating when I was doing the development.

Not a single capacitor anywhere for IC supply line buffering. I know, bad on me! Surprisingly this arrangement has been solid at 1 MHZ, but of course I had to push the envelope! I installed first a 1.8 MHZ crystal, and then a 4.0 MHZ crystal. The machine actually boots up OK at 4 MHZ, but fails when executing a standard program (Prime Number Sieve).

I put a scope on the hardware signal for LA, which tells the Accumulator to Load from the data bus. Here are screenshots from 1 MHZ and 4 MHZ. Some pretty nasty stuff is evident. I'm not sure if I want to start chasing this, but if anyone has ideas for obvious things to try I might go for it. This computer is built with 74LS series TTL chips. I guess I am asking what might provide a bang for the buck on this issue...

There are others more knowledgeable than myself regarding bypass capacitors, but I have found out they are indeed needed, especially for TTL logic.

I think it is very fortunate that LALU has worked at all without bypass caps. It is mostly easy to rectify. I would solder 0.1 micro-farad caps across the top of the IC’s between the power pins. Use as short a lead as possible. I often solder the caps to the IC’s before putting them in sockets. Next solder something like a 10 uF cap across the power rails where the power comes into the board.

Then I would look at the signals again to see if other bypassing or filtering needs to be done.