Hi, I am having trouble finding a value for Tpd for the 74AC283. The TI datasheet only mentiones minimum and maximum values in a wide temperature range, while I'm more interested in a realistic value at 25 degrees. Does anyone have a tip ?

You sleep better if you use worst case timing for all delays.

My 74AC book doesn't have the '283. However, having worked in the mid-1980's for a semiconductor manufacturer (actually a VHF/UHF power transistor manufacturer), I can tell you that the performance from one lot to the next, even one wafer to another, even one part of the wafer to another, can be different. If you're making a product to sell a lot of, you basically have to go with the worst-case guarantees or do your own extensive testing. For one-off projects, I like to just run the clock speed up until things start failing, then back it down about 25% for some safety margin. There was a British home-computer manufacturer in the 1980's—I don't remember which one—that sold a design that worked reliably in the lab (at 25°C), but they didn't take into consideration what would happen when customers ran the computer in warm weather with no air conditioning. An awful lot of units failed.

Ok, I counted the worst delays for the AC chips and it seems there is enough margin.

Today I finished the assembler/simulator of the Kobold K2. It loads a "Hello World" program at startup, you can assemble and run it online.

You can edit programs, load/store programs from/to your own PC, and there is an integrated manual for the assembly instructions.

Try the assembler/simulator here: http://www.enscope.nl/simas_kobold2/

Main project page is here:https://hackaday.io/project/167605-kobold-k2-risc-ttl-computer

"Hello World!" - very good!

Today reached a new milestone, the datapath of the hardware is working !
see: https://hackaday.io/project/167605-kobold-k2-risc-ttl-computer/log/172608-datapath-working

That's excellent progress, congratulations for that important milestone !

Thank you Joan ! First tests of address registers also looks good.

One week ago I got the RPi Flash programmer working. And yesterday the Kobold executed its first program steps from the Flash, switching an indicator LED on and off ! It was single stepped by the RPi. But I found a problem in the reset circuit, fixed that today, it will now also blink the LED stand-alone.

Also had progress on the C compiler, a few more C features are implemented now, and it does several optimizations.

Just placed a new logfile: https://hackaday.io/project/167605-kobold-k2-risc-ttl-computer/log/173333-blinking-led

Well done!

HELLO WORLD ! Big milestone today !

see: https://hackaday.io/project/167605-kobold-k2-risc-ttl-computer/log/173420-milestone-hello-world

Well done!.
(and it doesn't cease to amaze me that you are using a Rpi running an interpreted language on the other side)

Thanks Joan ! What is so amazing about running interpreted Python on the RPi ?

Well, it's just that any low spec avr based card would do it.
(and that I generally have a greater appreciation for "compiled" languages, but that's just me, of course )

Well, an AVR does not normally have a screen connected to it for the terminal, the RPi has.
But more important, the RPi runs a webbrowser. The browser has my webpage with the web-based JavaScript assembler. If I download the binary, it is available on the RPi and a simple script can program it into the Kobold. So the RPi is already connected and can easily provide both functions.

I understand your dislike of interpreted languages, I think... They just don't work efficient.