[HN Gopher] Scamp CPU: A homebrew 16-bit CPU with a homebrew Uni...
___________________________________________________________________
Scamp CPU: A homebrew 16-bit CPU with a homebrew Unix-like-ish
operating system
Author : akkartik
Score : 66 points
Date : 2021-12-01 19:27 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| bullen wrote:
| Checkout this awesome mock for a C64 OS:
| http://move.rupy.se/file/C64-NaxOS.jpg
| homarp wrote:
| or the real thing: https://www.c64-wiki.com/wiki/GEOS and
| http://toastytech.com/guis/c64g.html
|
| (previous discussion of GEOS:
| https://news.ycombinator.com/item?id=10188367 )
| dusted wrote:
| Very impressive!
| juice_bus wrote:
| Are there many resources available for someone who has an
| interest in putting together a basic OS on top of older hardware?
| Lets say 6502 for an example - where would someone who is
| experienced with much higher languages (C#/Java, etc) begin to
| even learn something like that?
| Syonyk wrote:
| Learn C and dive in.
|
| The various "osdev" communities are good places to hang out,
| though I personally find IRC to be somewhat better than the
| forums and such.
|
| If you can reason about the code you write in a memory-byte-
| accurate and handwavingly "what it actually uses in assembly"
| manner, you can start in. Most hobby OS projects don't ever get
| past toy stage, a few do.
|
| Unix, however, was designed to be portable, so getting Unix-
| like OSes running on all sorts of random stuff is easier than
| writing from scratch.
| wk_end wrote:
| C on the 6502 is pretty painful.
| homarp wrote:
| see https://news.ycombinator.com/item?id=27324653 A project
| to port LLVM to the MOS 6502
|
| and http://calc6502.com/RobotGame/summary.html comparing
| ASM, C and Forth of the same program
| duskwuff wrote:
| Extremely painful.
|
| * There are only three data registers (A, X, Y), and they
| aren't interchangeable. Values get spilled to the stack or
| memory constantly.
|
| * Memory addresses are 16 bits, so they cannot be stored in
| registers at all, and performing even simple operations on
| them (like incrementing an address) requires carry
| handling.
|
| * The stack is hard-limited to 256 bytes, so pushing too
| many temporary values onto the stack risks stack overflow.
|
| * Addressing modes are limited. There is no "address +
| immediate offset" addressing mode, making pointers to
| dynamically allocated structures awkward to work with, and
| some indexed addressing modes will roll over if they're
| used to index past the end of a 256-byte page.
| wvenable wrote:
| Do I have the website for you: https://eater.net/6502
|
| I've build the computer and simple OS/Monitor.
| jstanley wrote:
| (Hi, this CPU is my project).
|
| I got into this stuff by buying an RC2014[0] kit and putting it
| together, and learning a bit about how CP/M works on it.
|
| If you're interested in that sort of thing, you could do much
| worse than buying an RC2014 and just writing low-level programs
| for it for fun.
|
| CP/M is really incredibly simple. You have some "kernel" type
| stuff towards the top of memory, with routines for
| reading/writing files on disk, and interacting with the console
| and a paper tape "reader + punch". When you type a command, the
| named program is loaded from disk into memory starting at 0x100
| and then execution starts at 0x100. To interact with hardware,
| the program calls the kernel's routines (analogous to system
| calls). And that's basically all there is to it.
|
| The OS for my CPU is very similar in operation to CP/M, but
| more pleasant to use for someone coming from a Unix background.
|
| [0] https://rc2014.co.uk/
| martijnvds wrote:
| Wait a minute, is that why DOS .com files are loaded at
| 0x100? CP/M compatibility?
| jstanley wrote:
| Not sure! I doubt they would actually be compatible anyway
| since the CPU is too different. It seems likely that prior
| experience with CP/M COM files being loaded at 0x100
| influenced the design though.
| monocasa wrote:
| Yeah, QDOS was a CP/M clone for 8086. It wasn't source
| compatible, but was 'major ideas and structure
| compatible'.
| wvenable wrote:
| Yes. The Program Segment Prefix is designed for CP/M
| compatibility:
|
| https://faydoc.tripod.com/structures/13/1378.htm
| naikrovek wrote:
| yep, lots of other things, too. MS-DOS was
| CP/M-compatible.
|
| Windows 95 was DOS-compatible.
|
| and so on. and even though the base OS changed starting
| with Windows 2000, lots of compatibility things were kept
| because they were supported in previous versions of
| Windows or MS-DOS.
|
| All the way down to files with special names such as
| "AUX" or "CON", and the backslash as directory path
| separator are all from CP/M, though the path thing
| happened to maintain CP/M compatibility, and not because
| CP/M had filesystem directories, because early on (maybe
| always?) it didn't have directories.
| monocasa wrote:
| In fact, DOS 1.x didn't have directories either. Those
| were added in DOS 2.0
| wk_end wrote:
| The 6502 is a CPU, not a full machine - and the OS really is
| about interacting with the whole machine. You need to learn
| about a specific 6502-based system - the C64, the Apple II, the
| NES...
|
| Moreover, usually when you're writing a 6502 program, you're
| writing a program targeted towards an individual machine, with
| no OS in the way - the program you're writing is written
| against a particular machine; it effectively _is_ the OS.
|
| So the answer is: learn how to write programs for a 6502-based
| machine first. Then, make your program an OS. Your ability to
| make it anything like a modern OS is going to be limited,
| though.
| glhaynes wrote:
| Nice work, congrats!
|
| I think the most surprising thing to me is the lack of
| interrupts. If you read this, jstanley: did you struggle much
| with that decision? I think of interrupts as nearly universally
| available on 8-bit micros, much less 16, but I have also wondered
| before how important they really were for what those machines
| ended up being used for. The (S)NES polled their controllers'
| shift registers in a really inefficient way, but it turned out
| fine. On the other hand, though, the vertical blank interrupt was
| pretty critical to their software and, of course, it became
| extremely common for NES cartridges to add extra chips to raise
| interrupts on particular horizontal scanlines. But, aside from
| neat graphical tricks, maybe interrupts just weren't all that
| important?
___________________________________________________________________
(page generated 2021-12-01 23:00 UTC)