Hacker News Reader

Comment by tombert | Hacker News Reader

Wait, so if I understand this correctly (what I don't know about hardware is a lot!), is this basically a "macroprocessor"? As in, it functions the same way as a vanilla 6502, but done at a larger scale?

Actually pretty cool that it's able to get 1/20th the speed when it's this big!

View on HN

It's a discrete CPU. This is how processors were made before microprocessors. Before 1970, we had discrete component mainframe machines, in fact running at multi-MHz speeds (e.g. CDC 6600).

https://en.wikipedia.org/wiki/CDC_6600

60 bit, 10 MHz processor, introduced in 1964.

Article says that was 10 times faster than other contemporary machines; but that still leaves those at around a solid megahertz.

Discrete logic circuits can be fast because they have a lot of area over which to dissipate heat and can guzzle current.

The main issue isn't the CPU as such, it's memory. You can reasonably make a usable CPU using relays even, but a non-trivial amount of memory takes up sooo much space.

I learned this in Minecraft. I’d wired up ttls in college for intro to ee for cs majors, which was fun. But ram was a beast. I guess I’ll build another tower and upgrade to a full 1k.

Ram takes so much space.

The Virtual Circuit Board game/sandbox at Steam offers an external memory, presumably for this reason.

I remember a Minecraft mod from way back that let you do "modular" redstone, going "into" blocks to build redstone inside them, which you could then reuse as a single block. I wonder if it's been updated.

> Discrete logic circuits can be fast because they have a lot of area over which to dissipate heat and can guzzle current.

... but not too fast either, because the long trace lengths are antennas so you'll end up in EMF emission regulations hell on the one side, and signal integrity issues on the other side. On top of that come losses from inductive and capacitive coupling.

Discrete logic circuits can be fast because they have a lot of area over which to dissipate heat and can guzzle current.

Moreover, most of them used either ECL or TTL, which are logic families much faster than P/N/CMOS. This being a transistor-level replica of an NMOS 6502, it can't go much faster.

Yep. The bummer is that the Apple ][ relies on the clock speed of the 6502 to handle some of its functionality (most notably video handling), so you can’t just run a cable to the CPU socket on the Apple motherboard. I wonder if any of the other classic 6502 machines (Commodore, Atari, Acorn, BBC, etc.) would work?

Again, I know basically nothing about hardware, so this is likely a dumb question: could you conceivably get an oscillator/clock chip that also operates at 1/20th the speed, wire that into the Apple ][, and then wire in this giant CPU?

Unfortunately, no. The CPU would work, but memory retention would be unreliable (because the DRAM is now going ~20x too long between refreshes), and the composite video output would fail to display on a monitor (because it's the wrong frequency).

Well now I'm wondering; it might not directly run an Apple ][, but what about the Apple ][ compatibles like the Laser 128 [1]? It doesn't use the same ROM as Apple, they licensed Microsoft Basic directly from Microsoft and then added the missing functionality themselves.

I guess someone would have to see how similar it is to a vanilla Apple ][.

[1] https://en.wikipedia.org/wiki/Laser_128

From what I can tell from documents like [1], the Laser 128 was very similar (possibly even identical) to an Apple II on a hardware level. It'd have the same issues running at a higher/lower clock speed than it was designed for.

[1]: http://www.applelogic.org/files/VTECHL128.pdf

Again, the answer is almost certainly no, unfortunately.

A Laser 128 isn't that fundamentally different to an actual Apple II. In fact, from a wider point of view, they are "almost identical".

DRAM needing timely refresh is universal to DRAM itself: It's because DRAM is literally made of a transistor and a capacitor holding your bit, and if you don't access it every so often, that capacitor discharges eventually. The most realistic path to "slow DRAM" would be to replace DRAM with SRAM altogether, which is effectively made of transistors only, and holds its content as long as just power is applied. It's not that hard to replace DRAM with SRAM: Apart from not needing refresh, SRAM behaves similar to DRAM. It's just more expensive (and usually faster, which is also not a drawback), and the DRAM refresh, while not doing anything useful, wouldn't hurt.

But as for video output, that's just a consequence of how Apple II's (most microcomputers of that era, actually) video output works: By literally controlling the electron gun in the CRT, with only some analogue electronics in between. The monitor however wants to move the electron beam at a certain speed (or, if you had a fancy Multisync monitor, a set or range of speeds). But even if that wasn't the case, the phosphor on the screen glows only for a short amount of time, so draw your picture too slow, and you will only see small parts of it.

The latter can be demonstrated by just pointing a camera at a CRT. In all likeliness, the camera's frequency will be slightly off from the CRT's frequency, so that you capture different parts of the beam's path at each frame, simulating what it would look like if you'd slow down the beam itself: https://pub.mdpi-res.com/sensors/sensors-22-01871/article_de...

Would it be possible to decouple the video output circuit from the microprocessor's timing? Absolutely! And this is in fact what virtually any modern computers has been doing for many decades by now: Even if you still can find analogue VGA with a CRT, that VGA card had its own clock that is completely independent of the CPU's clock. But that's just not how simple home computers of that era usually operated.

1.023 MHz is basically the Apple ]['s fine structure constant. Change that, even by a tiny amount, and the whole universe comes unglued. Video, disk access, you name it.

There were accelerator boards, but they ran at integer multiples of the original clock speed for that reason.

You’d need to run an NTSC screen at 3Hz

You’ll need additional circuitry to "upscan" your 3Hz display to 60Hz.

There was a moment many years ago when I considered constructing a mechanical 6502. I quickly learned that transistors are fabricated in silicon for economic reasons.

The fun path would be to modify the display to run at 3Hz (and also implying the much slower horizontal scan rate), but due to the phosphor coating's short persistence, you'd at best see only a small sliver of the full picture at any time. Exactly like you see if you point a video camera to a CRT whose frequency does not match up exactly.

But if you'd take a long exposure photo of the CRT, it would likely work! (EDIT: Might fry your phosphor, though... as for any other components, like filters or components that may get damaged by the now only slowly changing current, I just assume you replaced or retuned that as part of the conversion process.)

There are CRTs with long-persistence phosphors too; they found applications in radar and the like:

https://en.wikipedia.org/wiki/Phosphor#Standard_phosphor_typ...

https://tubetime.us/index.php/2015/10/31/crt-phosphor-video/

http://www.labguysworld.com/crt_phosphor_research.pdf

The P10 phosphor there claims "Persistence from several seconds to several months"(!)

Due to the way the video is interleaved with CPU cycles, you'd have to do something like divide the 1 MHz CPU clock by 20, and then when writing carefully only put data on the data bus for one of those 20 cycles. And the disk accesses would surely fail due to the CPU not keeping up, among other problems.

http://www.apple-iigs.info/doc/fichiers/TheappleIIcircuitdes...

Thinking more and more about it in this thread (yes, I'm procrastinating doing something else), I'm beginning to come to the conclusion that the way with the least modifications to the computer itself is to replace the DRAM with SRAM, and to "just" slow the video circuit down as well (including color burst, horizontal scan, etc.), but to attach a custom buffered display instead of a regular monitor to the computer.

However, I wouldn't be surprised in the slightest if any other of the integrated circuits don't work at the slower speed for some reason. (Filters etc. you'd just replace/retune.)

It is well worth understanding how these older computers worked. All the components were doing double or triple duty, so that together all the tasks like refreshing memory, reading/writing memory, generating video, generating audio, and I/O worked. This involved interleaving bus access and similar "tricks".

There are an excellent series of talks at CCC titled "The Ultimate X talk" [0] where you are shown exactly how. I recommend The Ultimate Acorn Archimedes Talk [1] which introduced the ARM chip, but also shows how shared bus access and optimisation was the core principle of performant designs at the time.

[0] https://media.ccc.de/search/?q=the+ultimate+talk

[1] https://media.ccc.de/v/36c3-10703-the_ultimate_acorn_archime...

This is true of the Commodore 64 as the VIC-II chip timing is closely coupled to the NTSC color burst (note below joke about "up-scanning to 60 Hz")

Also disk I/O and RS-232 are bit-banged.

> Also disk I/O and RS-232 are bit-banged.

You could easily slow that down as well.

The big problem is really the CRT (and possibly other ICs in the computer that don't like the extreme slowdown). As noted below, if you went through the arduous process of replacing and retuning components to be able to slow the beam down, your phosphor coating is still too fast, and probably doesn't like having the beam passing only slowly over it. (You thought regular burn-in was bad!)

However, replace the CRT with something else, like an LCD with some extra buffering circuit, and it could work. Yes, the color burst will be at a much lower frequency as well, but just demodulate color at this lower frequency, then.

Yeah, I’m thinking that the solution would be something that takes the analog monitor signal and uses it to control a digital display.

Still, you could compile your own custom microsoft basic like Ben Eater did on youtube recently.

The software is really not an issue. I saw the MOnSter 6502 live running BASIC, and it was MS BASIC as far as I recall. It just wasn't simply hooked up as the CPU of an Apple II or similar.

Reply on news.ycombinator.com