[HN Gopher] MOnSter 6502: a working transistor-scale replica of ...
___________________________________________________________________
MOnSter 6502: a working transistor-scale replica of the classic MOS
6502
Author : harporoeder
Score : 85 points
Date : 2024-04-03 19:31 UTC (3 hours ago)
(HTM) web link (monster6502.com)
(TXT) w3m dump (monster6502.com)
| tombert wrote:
| 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!
| dhosek wrote:
| 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?
| tombert wrote:
| 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?
| duskwuff wrote:
| 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 wrote:
| 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
| duskwuff wrote:
| 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
| anyfoo wrote:
| 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.
| CamperBob2 wrote:
| 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.
| jameshart wrote:
| You'd need to run an NTSC screen at 3Hz
| basementcat wrote:
| 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.
| anyfoo wrote:
| 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.)
| pulvinar wrote:
| 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...
| anyfoo wrote:
| 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.)
| rogerbinns wrote:
| 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, generating video, 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_ar
| chime...
| basementcat wrote:
| 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.
| anyfoo wrote:
| > 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.
| geon wrote:
| Still, you could compile your own custom microsoft basic like
| Ben Eater did on youtube recently.
| anyfoo wrote:
| 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.
| kazinator wrote:
| 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.
| magicalhippo wrote:
| 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.
| mschuster91 wrote:
| > 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.
| grishka wrote:
| A macroprocessor.
| apantel wrote:
| This is the Japanese Cloisonne of circuit boards. Beautiful,
| well-done.
| warbled_tongue wrote:
| I'm always slightly disappointed that I can't just Buy Now one
| of these passion projects for my wall. Truly wonderful art.
| hyperthesis wrote:
| what nm node is this?
|
| when would it have been state of the art?
| Palomides wrote:
| maybe around 1956 or so
|
| I think it's a question of mm rather than nm!
| actionfromafar wrote:
| https://en.wikipedia.org/wiki/Bendix_G-15 was much slower.
| anyfoo wrote:
| And had much larger "nodes", given that those tubes are
| much, much larger and farther apart than the SMT
| transistors on this 6502 replica. It's not even close.
|
| But I think IBM's SLT from the 1960s might come close:
| https://en.wikipedia.org/wiki/Solid_Logic_Technology
|
| Those little square "chips" are not actually integrated
| circuits, but effectively small PCBs with surface mounted
| discrete components (including transistors).
| NikkiA wrote:
| The early PDPs used discrete CPUs, so they'd probably be
| the closest examples, the 12-bit PDP-5 is the smallest
| those CPUs went though, which isn't hideously more
| complex than a 8-bit CPU.
| ooterness wrote:
| I love this art/engineering project. The whole concept of extra-
| large unintegrated circuits is just so amusing.
|
| The team behind this project sells kits for two classic ICs, the
| 741 op-amp [1] and the 555 timer [2]. Sadly, they've said the
| Monster6502 is too big and complex to make a practical kit.
|
| [1] https://shop.evilmadscientist.com/tinykitlist/762 [2]
| https://shop.evilmadscientist.com/tinykitlist/652
| lnx01 wrote:
| The Apple A8X, found in the iPad Air 2, contains about 3
| billion transistors. (This is comparable to the number of
| transistors in modern desktop computer CPUs as well.) At the
| scale of the MOnSter 6502, that would take about 885,000 square
| feet (over 20 acres or 8 hectares) -- an area about 940 ft (286
| m) square.
| pnw wrote:
| I signed up for the mailing list when it was first on HN a few
| years ago, but haven't seen many signs of progress. Website still
| says mid 2023 for a launch.
|
| 6502 was my first CPU so I'm totally down to buy one, even though
| it's going to be pretty expensive. I'd be pleased if they could
| make them for less than $5k.
| dylan604 wrote:
| This would be a great piece of art for a very niche space, like
| my office =)
|
| The fact that it actually works is just bonus.
| dang wrote:
| Related. Others?
|
| _Complete working transistor-scale replica of the classic
| MOS6502 microprocessor_ -
| https://news.ycombinator.com/item?id=33841901 - Dec 2022 (38
| comments)
|
| _MOnSter 6502_ - https://news.ycombinator.com/item?id=26507525 -
| March 2021 (31 comments)
|
| _The MOnSter 6502: transistor-scale replica of classic MOS 6502
| microprocessor_ - https://news.ycombinator.com/item?id=17969472 -
| Sept 2018 (81 comments)
|
| _A working, transistor-scale replica of the MOS 6502
| microprocessor_ - https://news.ycombinator.com/item?id=14386413 -
| May 2017 (44 comments)
|
| _The MOnSter 6502_ -
| https://news.ycombinator.com/item?id=11703596 - May 2016 (74
| comments)
| tocs3 wrote:
| I would like to see a mechanical version of something like this.
| henry_bone wrote:
| I wonder if it's correct right down to the errata. Was there
| undocumented instructions on the 6502? If so, I wonder if it
| supports those.
| zik wrote:
| Yes, there are some undocumented instructions [1]. They say
| it's a transistor-for-transistor replica so it should be 100%
| compatible with them.
|
| [1] https://www.masswerk.at/nowgobang/2021/6502-illegal-opcodes
| th4tg41 wrote:
| Wonder if it's feasable and how much work it would be to record a
| run of eg Super Mario Land and play the processor instructions
| back on this thing hanging on the wall. Would be a nice
| conversation piece.
| th4tg41 wrote:
| Plus a small LCD in the frame that displays the level and a
| progress bar for that level.
| johnwbyrd wrote:
| Fun project, but fairly old news at this point.
___________________________________________________________________
(page generated 2024-04-03 23:00 UTC)