Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I decided to build a nine-bit computer

madned.substack.com

Post reply on HN
Print view View original

51–60 of 71 posts

Re: I decided to build a nine-bit computer

#51

Post by oh_sigh »

wolfram74 wrote: post #33
giovannibajo1 wrote: post #32

Nintendo 64 had a 9-bit RAM (Rambus RDRAM). Only 8 bits of each byte were accessible from the MIPS CPU for obvious reasons; the 9th bit was only used by the GPU (called "RDP") to store extra information while rendering (begin a UMA architecture, the CPU used the same RDRAM used by the CPU). Typically it contained a flag called "coverage" that was used to discriminate pixels on the edge of polygons, that were later su…

Yet another weird bit of N64 lore, I'm amazed mupen64 works as well as it does.

> weird bit

Quite literally

Re: I decided to build a nine-bit computer

#52

Post by jacquesm »

uvesten wrote: post #47
jacquesm wrote: post #34

https://en.wikipedia.org/wiki/UNIVAC_1100/2200_series Had a 36 bit word length resulting in a 9 bit 'byte'.

I went way down the rabbit hole on this one. Seems that they are still made and used, fascinating!

They are pretty impressive machines. The loadable microcode store is especially interesting, they allow you to emulate an arbitary CPU. Diagnostics in 'IBM' mode was a real possibility on these!

Re: I decided to build a nine-bit computer

#53

Post by klodolph »

giovannibajo1 wrote: post #32

Nintendo 64 had a 9-bit RAM (Rambus RDRAM). Only 8 bits of each byte were accessible from the MIPS CPU for obvious reasons; the 9th bit was only used by the GPU (called "RDP") to store extra information while rendering (begin a UMA architecture, the CPU used the same RDRAM used by the CPU). Typically it contained a flag called "coverage" that was used to discriminate pixels on the edge of polygons, that were later su…

The 9th bit was also used by the depth buffer.

To add to this, the reason that the RAM was available with 9 bits in the first place is so that it could be used to make systems with ECC. It's just that you didn't have to use that 9th bit for error correction, you could use it for extra data, if you designed the system to use it that way.

Re: I decided to build a nine-bit computer

#54

Post by klodolph »

jacquesm wrote: post #34

https://en.wikipedia.org/wiki/UNIVAC_1100/2200_series Had a 36 bit word length resulting in a 9 bit 'byte'.

36-bit was a common enough word length. Not just UNIVAC, but IBM 360, PDP-6/PDP-10, and some others. Convenient both for octal (multiple of 3 bits) and working with pre-ASCII, 6-bit character encodings (multiple of 6 bits).

Which is why we have UTF-9 and UTF-18, as defined in RFC 4042.

https://datatracker.ietf.org/doc/html/rfc4042

(Spoiler: It's an April Fool's joke.)

Re: I decided to build a nine-bit computer

#55

Post by nneonneo »

vient wrote: post #26

See also cLEMENCy 9-bit middle-endian (sic) arch from DEF CON CTF 2017 https://2017.notmalware.ru/89dc90a0ffc5dd90ea68a7aece686544/... (link from https://blog.legitbs.net/2017/07/the-clemency-architecture.h... )

Ah, I have fond memories of hacking on that architecture for DEF CON. We wrote a lot of tools for it: by the end (less than 3 days after getting the spec), we had disassemblers, debuggers, binary rewriters, and even rudimentary decompilation support. It was quite a fun journey :)

Re: I decided to build a nine-bit computer

#56

Post by coryrc »

sillyquiet wrote: post #6

Regarding the interesting bit (to me) in there about the advantages of FPGAs over an SBC like the Pi (speed)- does anybody know of any blogs or projects where an FPGA's speed helped in a hobby project where software running on an SBC wasn't fast enough? I can imagine a few, mostly real-time projects involving expensive computations (image or pattern recognition maybe?), but I would love to see some concrete examples.

Only useful if a microcontroller peripheral doesn't already exist for the thing you want to do and you have some sub-millisecond latency requirements. If a calculation can be vectorized a CPU or GPU is really fast.

At normal speeds, an image can take 10-15 ms to clock out of the sensor. At that point, there's little reason not to run your image processing on a $3 CPU rather than $$$ FPGA because what's another < 30ms at that point and what would need a reaction that quick anyway?

Re: I decided to build a nine-bit computer

#57

Post by coryrc »

PragmaticPulp wrote: post #16
sillyquiet wrote: post #6

Regarding the interesting bit (to me) in there about the advantages of FPGAs over an SBC like the Pi (speed)- does anybody know of any blogs or projects where an FPGA's speed helped in a hobby project where software running on an SBC wasn't fast enough? I can imagine a few, mostly real-time projects involving expensive computations (image or pattern recognition maybe?), but I would love to see some concrete examples.

Basically anything with significant real-time requirements or high bandwidth requires an external FPGA or microcontroller. Embedded Linux is great, but if you’re trying to do something like read from a high-speed ADC then the only way to do it is with an FPGA. The FPGA reads from the ADC at precise intervals and buffers the data. The embedded Linux system can then periodically read the buffer with all of the jitter a…

> read from a high-speed ADC

You just have the peripheral DMA and flag/interrupt when done. If you need an "immediate" reaction you use a DSP. There are only so many useful calculations you can do with a single input stream and DSP can handle them.

Re: I decided to build a nine-bit computer

#58

Post by einpoklum »

IncRnd wrote: post #42
einpoklum wrote: post #25

> I decided to build a nine-bit computer Somehow I was sure that sentence was going to end with "... in MineCraft!"

Here is a computer created in MineCraft! Wow, it's actually v5.0. The intro starts at 1:22. [1] [1] https://www.youtube.com/watch?v=SbO0tqH8f5I

8-bit... amateurs :-)

Re: I decided to build a nine-bit computer

#59

Post by sbierwagen »

tyingq wrote: post #29
andai wrote: post #18

Earlier quoted context omitted.

Noob question, in this instance would a realtime OS or a unikernel also solve the problem?

It's better, but still not the same level of timing guarantees. I suppose, left to right, you would have something like: SBC/Linux -> SBC/Real-time OS -> General Purpose MCU -> Specialized MCU (Parallax Propeller, for example) -> FPGA/CPLD/DSP With perhaps some additions to the diagram to account for bit-banging vs actual drivers, speeds where some portion of the left side just isn't fast enough to even kind-of work,…

There are also some some hybrid SOCs, like TI's Sitara chips that the Beagleboard is built around, that have a ARM core for linux, then a couple MCU cores for doing fast-ish realtime stuff. (TI's FAQ says a four instruction busyloop that just toggles a pin can run at about 50MHz on a PRU)
Post reply on HN