Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Scamp – a homebrew 16-bit CPU (incoherency.co.uk)
129 points by nickt on May 31, 2021 | hide | past | favorite | 20 comments


Hi, I'm the author.

Thanks for posting this!

If anyone wants to read more about this project, you might enjoy the "cpu" tag on my blog: https://incoherency.co.uk/blog/tags/cpu.html or the "doc/" directory in the git repo: https://github.com/jes/scamp-cpu/tree/master/doc

The latest state is that I have now got the UART and CompactFlash card working, and have booted up the kernel all the way to the shell, at 1 MHz, and it is close to fast enough to use interactively.


That's brilliant, congrats. Typing on a terminal of a machine you built from scratch must be so satisfying. I like that this runs an OS also, as many home brew CPUs run much simpler SW.


Keep it coming!


Nice project. Reading through some of the gotchas is interesting, though one stood out - the RT related gltich. Having some combinatioral logic control a reset is in general a no-no, for exactly this reason, a race can happen and combo logic that starts a (say) a 0 and ends at 0 can toggle to 1 and back to 0 multiple times as its boolean equation revolves and if this signal is ever used to drive an async pin like a reset, its a ticking time bomb. May never happen. May happen only when things heat up, may happen only for some logic transitions, etc. All because delays changing slightly can alter the glitch. The fact it didnt happen on the FPGA may be luck, as the logic gates there (LUTs) can and do glitch as they settle, if more than one is connected. However if this particular piece of logic fit in a single LUT, it may avoid the glitch, though still not guaranteed.


Indeed, async resets should usually be used only for things like whole-system master resets, and even then you need to be careful. Otherwise signals should always be synchronous to a clock.

If you're really (un)lucky, part of the circuit can even turn into a ring oscillator.


Interesting, thanks.

This makes me fear that I may have some complicated and confusing issues in my future!


Not homebrew, but there's also the MOnSter 6502 "dis-intigrated circuit": https://monster6502.com/


Both projects are amazing. We forget how much we where able to do with so little.

Modern CPUs can do so much more, but the basic stuff, that could be done on a MOS 6502, that's less than 5000 transistors.


This is really cool and unique. I poked around a bit, and the kernel is vaguely POSIX like, but written in a homegrown language with a compiler written in Perl[1].

[1] https://github.com/jes/scamp-cpu/blob/f260f52d950be90c2279f5...


I'm only a perl novice, but the code here seems well written and would be easy to follow if I knew the subject matter better. Seems like a few globals and a bunch of subroutine calls. I like that it avoids the complicated OO features commonly seen in Perl (either the built-in hacks or the Moose or Moo or whatever libraries).


Also the repo is here: https://github.com/jes/scamp-cpu


This is fascinating work, mate. I wouldn't even know where to begin! Any plans to implement something like a RISC-V instruction set in the future? :)


Some links for you:

  * https://hackaday.io/project/18491-worlds-first-32bit-homebrew-cpu 
  * https://hackaday.io/project/178826-pineapple-one
  * https://hackaday.io/project/18859-risk-vee
  * https://hackaday.io/project/168894-rv7400-computer 
  * https://www.youtube.com/playlist?list=PLEeZWGE3PwbZTypHq00G-yEX8TEI95lw4
There are lots of soft cores available for RISC-V too of course.


Also, is the name Scamp inspired by this old Scottish made electric car?

https://www.scotsman.com/regions/glasgow-and-strathclyde/sco...


The name 'scamp' has been used by another CPU, National Semiconductor's SC/MP:

https://en.wikipedia.org/wiki/National_Semiconductor_SC/MP

National Semiconductor's INS8060, or SC/MP (pronounced scamp) for Simple Cost-effective Micro Processor, is an early microprocessor which became available in April 1976. A unique feature of the SC/MP is a daisy-chained control pin that allowed up to three SC/MP's share a single main memory to produce a multiprocessor system.

To lower cost, the system used a bit-serial arithmetic logic unit (ALU) and was thus significantly slower than contemporary designs which had parallel ALUs like the Intel 8080 or MOS 6502. Another oddity was that the program counter could only access the lower 12-bits of the 16-bit address, and the upper 4-bits had to be set using special instructions. The result was that instructions accessed main memory as sixteen 4 kB "pages".[a] The combination of slow speed and paged memory limited its attractiveness, especially in the markets that might need a multiprocessing system.


There's another chip w/ the SCAMP name, too. Unisys did a version of their "Series A" mainframe (which has a lineage back to thr Burroughs "large systems" of the 1960s) called SCAMP: http://www.retrocomputingtasmania.com/home/projects/unisysas...

I worked in an environment that had one of these. The host system was a Pentium Pro server that booted Windows NT and hosted a Series A instance using this chip.


There was also the IBM SCAMP, which evolved into their commercial 5100 computer:

https://www.si.edu/object/nmah_334628


I just like the name. It's kind of a backronym for "Simple Computing and Arithmetic Microcoded Processor".


Amazing. Is this x86 ? http://mikeos.sourceforge.net/


This is fantastic work by James, such a great project! Well done.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: