4 ms·
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 composi
by duskwuff 3y ago
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).
- tombert 3y agoWell 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 https://en.wikipedia.org/wiki/Laser_128
- duskwuff 3y agoFrom 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 http://www.applelogic.org/files/VTECHL128.pdf
- anyfoo 3y agoAgain, 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_deploy/html/images/sensors-22-01871-g010.png?1646125960 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.
- CamperBob2 3y ago1.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.