fentonc

Thanks - I'm looking forward to going back to commuting someday, so I can actually use it!

Turbo Pascal also supports overlays, which allows you to chunk up your code and swap it into memory. I genuinely enjoy using the Turbo Pascal IDE on either my 1984 Kaypro or the monster 16-core “Zedripper” Z80 laptop I built. It’s great!

I had a much more recent update in this now decade-long adventure: http://www.chrisfenton.com/digital-archaeology-part-2/

Although this one was a lot less work than the first attempt. My original 1/10-scale Cray-1 is actually now sitting in the Computer History Museum!

It's as awesome as you imagine: http://www.chrisfenton.com/the-zedripper-part-1/

What type of Kintex-7 part were you thinking? This is a little more svelte than my 16-core Z80 "ZedRipper": http://www.chrisfenton.com/the-zedripper-part-1/

I’ve done it, and it’s great! http://www.chrisfenton.com/the-zedripper-part-1/

I made one of these about 8 years ago!

https://www.thingiverse.com/thing:113044

Although theirs is a much better execution =)

I use Kermit 4.11, which is readily available and works fine with a Wifi232 (or a normal serial cable + null modem adapter) at up to 19.2 kbps. Turbo Pascal is super fun!

The '84 model Kaypros are surprisingly fun to write games for: http://www.chrisfenton.com/dd9-kaypro-edition/

I have a machine of similar vintage (A Kaypro 2/84), and I would highly recommend getting a copy of Turbo Pascal 3 to play around with. It looks like the Osborne has 4KB of video RAM - I bet you could make some fun demos for it.

I managed to get fairly high video performance by doing some careful register fiddling of the CRT controller chip: http://www.chrisfenton.com/exploring-kaypro-video-performanc...

I agree! I'm a computer architect, and I love playing around with FPGAs for doing 'fantasy architecture' projects (like a 16-core Z80 laptop, or a USB adapter for an old nCube supercomputer). A modern FPGA is like being able to tape out your own 350-nm chip for <$100 (and in many respects much better, when you get to make use of hard-macros like SRAM or PCIe/DDR controllers).

The actual logic requirements are pretty minimal (~1000 LUTs, maybe?), so it mostly depends on what kind of memory hierarchy you want. The ZedRipper relies entirely on internal BlockRAMs, which are a much more precious resource - I think I'm using all of the largest BlockRAMs, but only like ~3% of the logic resources in my chip. An easy solution to this is to replace the full 64KB of BlockRAM with a small cache, and then arbitrate for access to a large DRAM. So you wind up with a knob that you can turn to shift resources between more CPU cores with less non-cache memory bandwidth per core, or fewer CPU cores with more bandwidth. I went with the latter, but if I cranked the knob all the way in the other direction, I might be able to get somewhere in the range of 256-512 Z80 cores on this chip But with only ~1-2KB of cache per chip).

At that point, the performance will depend on the nature of your application - if it involves a tiny amount of RAM in terms of instructions and working set, the caching scheme will give you great performance - if each core needs full-speed, random access to its entire 64KB of memory, keeping everything on-die is the way to go.

Oops, changed to 'horde'! The distinction is mostly architectural, in that the 'horde' is composed of an undifferentiated mass of CPUs (currently 8, could probably be expanded up to 128 with a cache-based memory hierarchy, which would certainly feel more 'horde-like'). The application processors can be accessed individually, whereas the horde can only be accessed as a group.

I have a real Kaypro 2 computer with a 4MHz Z80 in it, which I also use Turbo Pascal on - on the Kaypro, it's perfectly usable, but you get used to waiting a few seconds when you're loading files, compiling, etc. On the ZedRipper, when things are executing out of RAM everything is instantaneous. I think the CPU core I'm using is close to cycle-accurate, so it probably is ~35x faster than the Kaypro when executing actual code.

That's an interesting question that I haven't explored much - the network on the ZedRipper is a unidirectional synchronous ring operating at the full 140 MHz, with a round-trip latency of ~32 clocks or so, but the interface exposed to the Z80 is a sort of re-targetable serial port (you write an 8-bit 'destination' register, and then you push bytes to that node). The current buffer depth on the receive side is only a single byte, so the sender needs to wait until the destination node has read the byte and the credit gets returned. Turbo Pascal uses the 'Real48' format for floating point - 6 bytes per number - and I believe floating point operations take several thousand clock cycles. So in a tight loop on both sides, you might transfer a floating point number to a neighboring node in ~500 cycles.

Especially if I improved the network a bit - deeper receive buffers at a minimum, maybe a simple DMA engine - you could probably get it down to <100 cycles to forward a Real48 to a neighbor. The performance of emulated floating point on an 8-bit CPU is sufficiently bad, and the network performance is sufficiently good, that you probably could get away with some very fine-grained parallelism that way! When I'm back to commuting, I should write an n-body gravity simulator or something for it so that there is lots of numerical work to spread around, and see how much of a speedup I can get.

Thanks! The actual logic required for the Z80 core is tiny - you could probably make a dual-core version with something like this: https://www.tindie.com/products/tinyvision_ai/upduino-v30-lo...

FPGAs are super fun to play around with.

If anyone's got questions about my extensive upgrades to the world's least useful laptop, fire away

Lol - the 'overkill' approach was mostly one of expediency, since I had spent most of the summer I had to work on this project just trying to get my hands on the disk drive and then powering it on without blowing a fuse. I only had 2-3 weeks to throw everything together, so the 'robot' was basically the Z-stage of a Makerbot 3D printer with some acrylic widgets to push the read-head, then the signal was fed into an analog comparator chip and then into a shift register in my FPGA board. The craziest part is that it worked, and I was able to recover the data!

The Cray vector processors had a set of 8 64-element x 64-bit 'vector' (V) registers, as well as 8 64-bit 'scalar' (S) and 8 24-bit 'address' (A) registers - so it would sort of be similar to 4096-bit wide SIMD. When you did an operation like a vector add, you could do "V0 V1+V2", and it would automatically do 64 consecutive adds, and it would be done in 64 + a few cycles (since the hardware was still only doing 1 add per cycle). As someone else mentioned, it also supported "Vector chaining", so if your next instruction was "V2=V0*V3", it could take the result from the adder and pipe it into the multiplier so now your addition and multiplication are nearly fully overlapped (and you're cruising along at 160 MFLOPS in 1976!). I think it might have supported 3 chains, so you could very briefly peak at 240 MFLOPS, but you couldn't sustain it because of the startup latencies involved.

As a 'practical' example, I was able to write an N-body simulator of Jupiter and 63 of its moons (using the vector registers) orbiting one another in only 127 total instructions!

All of the early Cray mainframes (even the Cray-1 discussed here, although maybe only the somewhat later Cray-1/S) supported a "Solid State Disk" peripheral, which was basically a refrigerator full of RAM that was accessible via DMA channel. The intent was to be used to swap in and out large data sets from memory - I think even the early ones went up to a gigabyte in size.

To create the 'programmable filament,' you only switch over to each color once as they generate the toolpath in such a way that the nozzle doesn't interfere with previously printed filament (and the printer resets the z-axis back to 'layer 0' each time it switches colors).

For making relatively small, multi-material / multi-color prints, this really is a pretty clever system that looks reasonably practical on a wide variety of existing low-end 3D printers. With good software support, I could imagine being able to make things with interesting physical properties by making hybrid rigid / flexible materials (integrated hinges or other deformable parts, for instance).

A friend of mine wrote a simple program to try to evaluate the Collatz Conjecture on my electromechanical computer! http://www.chrisfenton.com/the-numbotron/

As a skill, I think it’s just called “engineering in a competitive market.” Anything you can do to make your chip more attractive to customers is a win, so designers go to great lengths to do so. Things like caches, pipelining, branch predictors, register renaming, out-of-order execution, etc. aren’t in any way fundamental to how processors work, they’re just tricks to make your program run a few percent faster. Designing a simple CPU in an fpga that executes everything in a single cycle and uses on-chip block ram is probably only a few hours of work for a novice. It would probably take you longer to download and install the fpga software!

I happen to be a computer architect both professionally and as a hobbyist, but the basics of it really aren't that complicated. All of the _hard_ parts are people being terribly clever to eek out the last bit of performance in a given technology. Getting any modern <$100 FPGA board and designing a really simple processor is definitely do-able as a complete novice. I haven't read it, but I've heard good things about the Nand2Tetris book someone else in this thread mentioned.

That's great! The idea of a cluster with a wireless interconnect is hilarious to me for some reason.

It's current manifestation is very much a 'good enough' solution. I just wanted a scheme for simple all-to-all connectivity to map the serial ports to, and the only traffic it carries at the moment is either terminal traffic or disk data from the SD card, so it's not even close to being taxed. The obvious improvements are to add deep buffers to hide the latency of credit return, crank up the clock and to make the bus wider. This board could probably handle a 200-bit wide bus at 100 MHz+ speeds with no problems. Computer architecture is a fun hobby =)

I love all of the weird computers that got built by academics in the 1980s! That sounds like such a cool machine.

Yeah, if you just replaced the 64KB of RAM with a 4KB cache backed by DRAM, you could probably fit 64 cores in one of those no problem, but 1) the performance wouldn't be quite as good, and 2) this project was mostly an exercise in excess since I was trying to find something to do with my giant FPGA board.

I had never heard of that machine until I posted this and someone sent me a link to it. The architecture of the ZedRipper is actually incredibly similar - each CPU has its own dedicated 64KB of memory and then an I/O mapped high-speed synchronous ring bus connects them all. On a MHz * CPUs basis, mine should actually be slightly faster =)

I misremembered, I think the CTSS source was actually written in a language called LRLTRAN. I just remembered it was something obscure.