Slashdot Mirror

I begged my parents to buy me a KIM-1, so I could build this robot - but they would not be persuaded.

I'm thinking of trying it again (not via my late parents) only this time building a KIM-1 or emulating one with an Arduino

The Dice program warns that rolling the dice 5,000+ times will take a long time. A typical hobbyist computer back then had a 1MHz processor.

It's all in the choice of a good algorithm. I program for a 1.8 MHz 6502-based computer as a hobby. When I need pseudorandom numbers in a game, I usually use Greg Cook's CRC16, which takes about 70 cycles to spit out 8 bits (0-255). Rescaling to 0-5 is a matter of shifts and adds, equivalent to d = (((x >> 1) + x) >> 6) + 1. With nearly 30,000 cycles per frame, I could easily produce several dozen 2d6 rolls per frame. Is two seconds "a long time"?

(clicks the link) Oh, it's interpreted floating-point BASIC. That explains the slowness.

BCD (Binary-Coded Decimal) mode was cool because it changed the way adding and subtracting worked. If you added 0x01 to 0x29, you'd get 0x30 instead of 0x2A. This was possible because there were actually two carry flags on the 6502 — one (named C) which was set upon overflow of values greater than 255, and the other (named D) which was set upon overflow of the low nybble (e.g., the low 4 bits).

6502.org Tutorials: Decimal Mode

Sure, some company would have to re-manufacture the parts that couldn't be made at home

Thankfully, a lot of the early computers used commodity parts that are still manufactured, such as the 7400 series of discrete logic gates (e.g. 7400 = quad NAND gate, 7404 = hex inverter, etc.). The Apple I's 8-bit microprocessor, the MOS 6502, is still commercially available, too.

Did you check _any_ of the links for the 6502? Not one of the companies listed sells (any more) a 6502 or a 65C02 Not a single one of them :(
If those are the only providers, then it means the 6502 is actually not manufactured anymore.

Sure, some company would have to re-manufacture the parts that couldn't be made at home

Thankfully, a lot of the early computers used commodity parts that are still manufactured, such as the 7400 series of discrete logic gates (e.g. 7400 = quad NAND gate, 7404 = hex inverter, etc.). The Apple I's 8-bit microprocessor, the MOS 6502, is still commercially available, too.

well do you want to see pics of men who have done sw for 3 decades?

I guess the real problem with the feat is this http://www.6502.org/homebuilt/

Well, it was not obvious.

I originally wanted to optimize the sign extend using some carry tricks, like asl/lda #0/sbc #0, but realized that it was unnecessary.
In fact, you can improve it even more, as follows:

lda stepx,x ; & y
                        bpl *+4
                        dec rayposxh,x
                        adc rayposx,x
                        sta rayposx,x
                        bcc *+4
                        inc rayposxh,x

Saving 6 bytes !

This trick is mentioned here:
http://forum.6502.org/viewtopic.php?p=5262

BTW, your tsx/txs trick is really horrible, it forces the stack at the bottom of $100.

You apparently don't either. That's C64 Basic not 6502 assembly.

I poked the op codes in directly. To be pedantic, It's C-64 machine code poked in with a BASIC program. Unfortunately as another poster pointed out, I got the endian wrong. this has the op-codes all layed out. In retrospect I should have just googled "6502 endian" but a good Slashdot post is a race to beat the clock on irrelvancy, and a guess as to whether or not it's worth the potential karma burn. So. I just looked up the op-code for JMP and blasted it out there as AC. FWIW, I used to know LDA immediate, STA immediate and absolute, and a handful of other op codes in various addressing modes, by heart.

Oh, BTW if you're wondering what the intent of the code was, go back to the top of this thread or visit Apple's campus.

There are advantages to having first learned programming on a computer whose memory was only 5Kb, with a 1 Megahertz processor. (A Vic 20.)

One of them undoubtedly is being able to say with a certain smug satisfaction:

Only real men program in assembly!

ADC seems pretty cheap, straightforward and common in the kind of FPGA board you'd put in a PC and run an Atari simulation on.

The real question is whether ANTIC, POKEY and other complex circuits are available as FPGA cores, since a 6502 core is available.

from the link: "using 30-year-old or older machines."
from the fine article: "First released in 1981; discontinued in 1994 using 30-year-old or older machines."

I recently (three weekends ago) fired up my Commodore PET 2001 (a *genuine* pre-1980 computer) and have been writing a Forth for it. It's really a lot of fun, and I'm finding that 30 years experience in various high-level languages has improved my "6502 assembler golf" game a lot. It's very incomplete, but the inner interpreter mostly works. Feel free to throw down on it here

Charlie

I am waiting for someone to shrink the 6502 to 45nm and fill the die with cores. 1024 core commodore 64 will do nicely to run the multithreaded 6502 OS http://www.6502.org/users/andre/icapos/osa65.html

Bricking a system usually means that the only way or ways the system has to boot now has something unbootable on it. Now the only way to boot it is to remove the firmware chips and write them with external hardware.

If you can boot your own code, that doesn't necessarily give you full control over the device, but it's certainly a big step in that direction, so all the closed platforms do their best to prevent this. As a side effect, this makes it a lot easier to brick, because if they fry their one-and-only path in, you lose.

I didn't find anything right away, but if the Pandora can boot off of its SD card, and it would be really stupid for an open platform built on hardware that can probably already do that to make that move, then it may be effectively impossible to permanently brick the thing, barring some sort of Killer Poke. You can always boot with the SD card and reload whatever you screwed up.

Closed systems brick easily. Open systems don't. I wouldn't call that so much an advantage of the open system as a disadvantage of the closed one. We know nothing stops consoles from booting off of writable optical media; the Dreamcast could.

Looks like 6502.

Actually, it would have to be 65C02 or better. You couldn't do "ldx #$FF" on a 6502, you had to do "lda #$FF" and then "tax" (transfer A to X). The ability to load immediate into the X or Y registers was added on the 65C02. And, don't quote my on this, but I think the 7800 predated the 65816, so I suspect 65C02 is the right answer...

BZZT! WRONG! Thanks for playing...

I have written hundreds of pages of 6502 code, on systems old enough (Apple 1) to have original MOS Technologies 6502s in them, and the "immediate" addressing mode (denoted by the # symbol in the argument) was DEFINITELY in the original 6502.

Don't believe me? Take a look at this listing of the (nearly completely unused) Floating Point routines that were included in the original Apple II monitor ROM. You will see an immediate load of the X register (LDX #$2) within the first couple of lines of code. This code was written by Steve Wozniak WAY before the Rockwell R65C02 was even on the drawing board!

What you MAY be thinking of is the fact that you couldn't load the STACK POINTER REGISTER (S) "immediate". You had to do a LDX #STACKTOP (usually set to $FF), and then use the TXS instruction to get the value into the Stack Pointer. This listing of Microchess (originally written in 1976 for the MOS Technologies KIM-1 computer, shows (at the label "CHESS" near the top of the listing) the LDX #$FF then TXS instruction pair mantra used to initialize the stack pointer on the 6502. The comment mentioning "Two Stacks" is referring to a software PSEUDO "stack pointer" (variable "SP2") that doesn't have anything to do with the 6502's hardware-implemented Stack Pointer (S register).

Now get off my lawn!!!

Looks like 6502.

Actually, it would have to be 65C02 or better. You couldn't do "ldx #$FF" on a 6502, you had to do "lda #$FF" and then "tax" (transfer A to X). The ability to load immediate into the X or Y registers was added on the 65C02. And, don't quote my on this, but I think the 7800 predated the 65816, so I suspect 65C02 is the right answer...

BZZT! WRONG! Thanks for playing...

I have written hundreds of pages of 6502 code, on systems old enough (Apple 1) to have original MOS Technologies 6502s in them, and the "immediate" addressing mode (denoted by the # symbol in the argument) was DEFINITELY in the original 6502.

Don't believe me? Take a look at this listing of the (nearly completely unused) Floating Point routines that were included in the original Apple II monitor ROM. You will see an immediate load of the X register (LDX #$2) within the first couple of lines of code. This code was written by Steve Wozniak WAY before the Rockwell R65C02 was even on the drawing board!

What you MAY be thinking of is the fact that you couldn't load the STACK POINTER REGISTER (S) "immediate". You had to do a LDX #STACKTOP (usually set to $FF), and then use the TXS instruction to get the value into the Stack Pointer. This listing of Microchess (originally written in 1976 for the MOS Technologies KIM-1 computer, shows (at the label "CHESS" near the top of the listing) the LDX #$FF then TXS instruction pair mantra used to initialize the stack pointer on the 6502. The comment mentioning "Two Stacks" is referring to a software PSEUDO "stack pointer" (variable "SP2") that doesn't have anything to do with the 6502's hardware-implemented Stack Pointer (S register).

Now get off my lawn!!!

Here http://www.6502.org/tutorials/6502opcodes.html

the long hand stuff are just remarks

Actually, there is a software package for Commodore 8-bit systems called GeckOS that includes a TCP/IP stack with serial SLIP support. You could hook a Commodore 8010 acoustic couple modem to your PET and surf at 300 baud.

Not that you'd want to. But you could.

And it'd implement the entire IEEE standard with every peculiarity and requirement?

When Woz did the same thing a year before 754 was first drafted, I don't think he worried about it. Can we now please quietly admit that 754 is a standard way of doing floating point, but isn't the only implementation? Sure we can!

Indeed, early Commodore PETs reportedly suffered a "killer POKE" via their BASIC.

Fantastic! You should re-publish it for example's sake. Another one I love looking at is Peter Jenning's MicroChess for 6502 which is just a bit over 1 K byte as well.
--jeffk++

Well the Pet put the BSOD to shame that's for sure:

http://www.6502.org/users/andre/petindex/poke.html

And I have fond memories of my C64s - several because they kept crapping out. One exchange - actually began to catch fire as the power supply fed enough juice into the system for it to pour smoke out the side. Repeat sales must have been a boon to the bean counters.

As far as lucking out for Desktop Publishing, well - I think Adobe might disagree. They seemed to put in some concentrated effort to the point they're a pretty large company these days.

The PICAXE is in essence a Microchip PIC microcontroller with a custom bootloader to load programs into memory and execute them on reboot/reset.

I was sort of expecting a general CPU, even if a vintage chip like the ZiLOG Z80, MOS Technologies' 6502, Motorola's 6800 / 6802, or intel's 8088 / 8086 microprocessors.

It seems more suited to O'Reilly's MAKE magazine and their blog, then on Slashdot.

I beg Volton's pardon-- never argue with a giant mecha robot that'll kick your butt for being impolite-- but the 6502 predates him by several years: 6502 V flag

Why is the parent poster getting modded up as informative? I'd trust Amit over what appears to be an obvious troll. I'd also trust the 6500 spec sheet and the original Apple manual that I managed to dig up.

For example, it says in the Spec sheet "Addressable memory range of up to 65K bytes", "On-the-chip clock options: Crystal time base input", etc:

6500 data sheet

"Microprocessor Clock Frequency: 1.023 MHz"

Apple I Manual

Sure, it's nice to have a laptop instead of hauling a desktop, but back when I was an undergrad, even a low-end stereo system was bigger than most current desktop machines, but after first semester, books outweighed any electronics I might have owned.

The computer, of course, was a mainframe that lived off-campus and you negotiated with it with punchcards, or in later years paper terminals; instead of laptops we had programmable calculators (or non-programmable ones, or sliderules) and either portable or not-really-portable typewriters. I did have one housemate senior year who had a KIM-1 microcomputer. And some grad students or researchy undergrads, mainly physicists or chemists, had access to labs with PDP-11s in them, so they could do real work themselves.

So year, that laptop with the built-in CD player and the wireless access that lets you work anywhere on or near campus that has coffee or beer is a definite luxury. (Of course, we were allowed to have beer on campus, unlike kids these days...) [geezer-mode] You punk kids, get off my LAN.... [/geezer-mode]

just by opening it, it could physically destroy your computer.

I think Commodore beat everyone up in terms of being ahead of time...try 1977!

You are right, I finally found this :

Handy PDF giving the 3 clock options for the 6500 series that commodore used. I can't however find a datasheet specifically for the transitional 6502 they used when going from the VIC-20 over to the first Commodore 64 which was the one I was thinking about.

However if the prior, and latter models used an external or on chip clock, I'd imagine so does the one I was thinking of.

I remember reading about a clockless MP they were putting into production and I can't remember the name of it. This is going to bother me.

My Dad brought it home from work when I was in 5th grade (ca. 1975/1976). I taught myself assembly language by simply reading thru the KIM manuals, in conjunction with a Rockwell 6502 databook.

I still have all that stuff in my junk drawer at home...

My first was a KIM-1. The level of excitement I experienced playing Hunt the Wumpus has rarely been matched since.

Yeah, me too, I loved the 6502, 68000, then ARM. I really need to have a go on the PowerPC. It looks cool too.

Oooh, and there's one right in this Mac!! ;-)

Well, that myth might be based on this reality:

http://www.6502.org/users/andre/petindex/poke.html

in short, on Commoodre Pets (builtin monitors) you could change a user accessible memory location and change the voltage to the screen.

The bit about the loop with no exit and self-modifying code sounds like a truly grand version of some self-modifying code I was particularly proud of.

Back in the days of Apple GEOS while working at Geoworks (nee Berkeley Softworks), my first task as a co-op was to port Commodore GeoCalc (a spreadsheet program) to run on Apple GEOS (not too bad since they were both 6502 family processors: "6502 -- the original RISC chip...there's no multiply instruction!") and add some new features. I ended up writing a new floating point math libary, too.

At some point during the work, I noticed that it took a really long time for operations on the whole spreadsheet (easy for users since there was a 'select all' button like in the upper left of Excel), even when there was no data in most of the cells. After some profiling, I determined that it was the busy indicator that was chewing up all the cycles. Users like to know the program is busy doing something, after all. But the code had to push a bunch of pseudo-registers (zero-page locations that had been given symbolic labels, for you 6502 fans), load up some coordinates, call the invert rectangle routine, pause a tiny bit, call the invert rectangle routine again, then pop the pseudo-registers. Doesn't seem like too much, but done a bunch of times on a 1MHz machine, it added up to quite a few cycles.

So I replaced the invert-a-rectangle-twice code with some much simpler code that inverted a smaller rectangle (7 pixels wide, to match the wonderfully bizarre hi-res Apple ][ graphics screen) twice by XOR-ing specific memory locations in the graphics memory. The code was now down to a blazing few dozen cycles.

Feeling quite proud of myself, I told a number ^H^H^H a lot of people in the office about my discovery and great solution. One person (Hi, Matt T., if you're reading this) took it as a challenge, and we sat down and optimized the routine further. 40 cycles. 33 cycles. Could we do better?

Finally, with much fanfare, we had it -- 11 cycles or somesuch (yeah, yeah -- I'm sure someone will point out that the following must total X cycles, but frankly I don't care :-) and 7 instructions (though I vaguely remember it as being 1 cycle per instruction, regardless). With an XOR of one graphics memory location, an XOR of the next one, a couple of INC instructions to modify the address of the previous XORs, and (here's the part I especially liked) ANDs to make the addresses wrap around within the same group of 8 memory locations without the need for a comparison. Thus was the birth of the "Frankenstein indicator", because it looked like a tiny little Jacob's ladder (in reverse) of mad-scientist / monster-movie fame.

The routine had gone from who-knows-how-many cycles (in the low thousands, IIRC) down to a dozen. It was fast enough that I could call the 'busy' subroutine once for every cell processed instead of once for every block of 256 cells, and it was still an order of magnitude faster. Operations that had taken minutes before were done in few seconds.

And I'm amazed (and frankly, a bit disturbed) to see that there are still people doing work with the 6502. And I'm definitely disturbed to realize I still remember the hex values of some 6502 instructions ($EA - NOP, $60 - RTS).

The I/O port was on pins 23-30, and was 8 bits wide, although two of those were, in the case of the 64, wired for the bank-switching, leaving only 6 for other purposes. No, I realize that the bank-switching wasn't on-board the MPU -- I suppose it must have sounded like I thought so.

It's gotta be buried there somewhere. :-) http://www.6502.org/

Don't really do it for any modern architecture. Visit 6502.org and look at the sample operating systems they have there.

Why? Because on your first (and second, and third, and forth...) you're not going to want to learn all about the inner workings of the Intel architecture. Segmented memory. *shudder*

The 6502 is still small enough that you can wrap your head around it easily. 6502 emulators are plentiful. An operating system for a 6502-based machine would be small and simple, but still a useful tool.

Once you get your head around that, then try the 6510 - same instruction set, but up to 16MB of memory.

Finally, when you feel good with all that, try Intel, or Sparc, or PPC. My personal favorite processor to code for (assembly-language speaking) is Motorola's 68k.

I also had an SDK-85, the Intel single board computer which showcased the 8085 chip. This was about like the Sym-1, but less neat-o hobby-oriented stuff in the rom. It actually had a proper area to which I could attach a breadboard, so projects on this looked a little less kludgy. Since I never really took a shine to the Intel chips, this collected more dust than the Sym.

Then, there were my portables: First an HP-41c, then a Sharp PC-1500 (also known as the TRS-80 PC2). The Sharp was a hand held, calculator sized (like a 10 inch long chunk of 2x4), basic programmable calculator. Its basic was almost entirely comaptible with the MS GWBasic which was shipping with PC-DOS at that time (1982 or so), so I could develope programs on it, then retype them on the PC. The little CMOS CPU on the Sharp ran at a slower clock speed than did the IBM PC's CPU, but the programs were still nearly as fast. I had the plotter/cassette interface, which let me print out circuit diagrams and so on in class, for tests. Since there weren't enough PCs in the classroom for everyone to use at once on tests, I got a big advantage out of this.

Of course, before I owned any of these, there was the Honeywell mainframe (lousy link, that'll give you an idea of how obscure Honeybucket computers were and are) I used at UAF.

Then, there were some that I worked on, but never owned:

The Otrona Attache. These were wonderful little CPM machines, with a Z80 CPU and a TI screen controller chip which I was never able to find a source for (Not sure about the TI part, but definitely sure about the hard-to-get part.). I never owned one, unfortunately, because none of the people who owned them would ever part with them, including the owner of the one with the chip I couldn't replace.

Then there were the various models of Altos and Vector Graphics machines. Both of these were multi-user, multi-CPU CPM machines.

You're mostly right on that. I liked the C64 so much that I got one for my father for Christmas one year (He was a ham, and the C64 had excellent RF shielding.), but I never got very deeply into it myself. I had a nifty single board computer that I did most of my playing on. One of the neatest things about it was that it could use an oscilloscope as a CRT.

I do not know about compatibility, but why not build one yourself... No joke. This very cool project is one of the many available at the 6502.org page. Then you could port LUNIX to your own computer...

LOL! Me too, man!

P.S. Take that, ya cowards! :-)

URL: http://dunkels.com/adam/contiki/links.html

System information and emulators

Commodore 64/128

The Commodore 64 is based on the 6510 CPU, which is a 6502-derived 8-bit CPU. It has 64k of RAM and 16k ROM which includes a BASIC interpreter and some basic I/O services. Graphics is provided by the VIC chip which has 16 colors and a maximum resolution of 320x200 in hi-res mode. It provides a 40x25 raster of characters in character mode. The three voices of digital sound is produced by the SID chip.

The Commodore 128 is an extended version of the Commodore 64 that contains a 8510 CPU which is capable of 2 MHz operation and can address 128k RAM (hence the name Commodore 128). It also has a Commodore 64 compatibility mode which is extremely similar to a regular C64 but with a few minor differences.

The SuperCPU is a 20 MHz 16-bit 65816-based computer that is plugged into the back of the Commodore 64 or 128. It uses the C64 keyboard and joysticks for input and the VIC and SID chips for audiovisual output. The SuperCPU is capable of addressing several megabytes of memory and is usually used together with a 16 megabytes RAM expansion board.

There are no SuperCPU emulators avaliable.

• The VICE emulator is capable of emulating a large number of Commodore machines. It emulates the C64, the C128, the VIC20, most of the PET models, and the CBM-II. VICE runs under Windows, Linux, FreeBSD, and a number of other host systems.
  
• Joakim Eriksson's Web C64 emulator, written in Java, runs as an applet within a web browser.
  
• Per Håkan Sundell's CCS64 emulator works under Windows and DOS.
  
• The ec64 emulator is developed for Linux and was originally written entirely in x86 assembler.
  
• An article by Simon N Goodwin about C64 emulators.
  
• The Commodore emulators category in the Dmoz has more links.
  

Commodore 64/128

There are plenty of alternative operating systems for the C64, mostly written in 6502 assembler. Some of them are far from complete, however, and only appear as dark shadows on a few web pages - MagerValp's SMOS and my own osT are among those.

• GEOS from 1986 probably is the most well-known graphical operating system for the C64. It is still sold commercially by CMDKEY.com.
  
• LUnix NG is an open-source multi-tasking operating system with TCP/IP/PPP-support, a *nix-like command shell, and a number of *nix-like utilities such as ls and cp.
• Craig Bruce's ACE is a text-based single-tasking operating system for the 64 and the 128. It provides a *nix-like command shell, a text-editor, a terminal program for the SwiftLink RS232 interface, as well as device drivers for a lot of devices
  
• GeckOS/A65 is a multi-tasking operating system with TCP/IP support and a *nix-like command shell.
  
• Wheels is a version of GEOS that requires RAM expansion to run.

With its 20 MHz and megabytes of memory, the SuperCPU is powerful enough to run fully-fledged graphical operating systems that rival early Machintosh or Microsoft Windows systems.

• Wings is a TCP/IP-enabled graphical operating system for the SuperCPU. It includes a MOD music player, JPEG viewer, web page download utility, etc.
• JOS is an older version of Wings.
  

TCP/IP and PPP connectivity

To surf the web, send or read email, etc., the first step is to actually get in touch with the Internet. This requires both physical access to an ISP, either via a modem and a phone-line or an Ethernet broadband connection, and the TCP/IP software running on the C64.

There are a number of programs that make it possible to reach the Internet with a C64/C128.

• LUnix NG contains a TCP/IP stack and a PPP implementation which makes it possible to reach the Internet using a modem and a dial-up ISP.
  
• GeckOS/A65 also contains a TCP/IP stack, but no PPP dialer.
  
• My own uIP TCP/IP stack has been used for some time to run a web server on a Commodore 64. uIP currently does not include a PPP dialer.
  
• Novaterm 10 contains a PPP dialer and enough TCP/IP code to be able to run telnet over the Internet.
  

SuperCPU

All of the above mentioned SuperCPU operating systems have TCP/IP support.

• The Wave is a web browser for the SuperCPU (and not for the Commodore 64/128 as the web page claims) that runs under the Wheels operating systems. Here is another page with information about The Wave (that also falsely claims that The Wave is for the Commodore 64/128). The latter page also includes screenshots of The Wave in action.
  

Small graphical user-interfaces (GUIs)

User interfaces for embedded systems range from the simple buttons on the front of a washing machine to those of fully fledged web browser type interfaces on information stations. The underlying technology varies from simple electronic circuits to full-scale PC compatibles.

• PicoGUI is a GUI architecture designed for embedded systems to desktop machines. It does not require any supporting GUI system and can be used on anything from graphical screens to text based systems. Their smallest target system are handheld terminals and the compiled object code size is on the order of hundreds of kilobytes.
  
• Microwindows/NanoGUI is a graphical user interface system designed to run without support from an underlying system. On 16-bit systems Microwindows is about 64k large.
  

The smallest web browsers are usually specially designed for the limitations of embedded systems and other specialized computers such as car navigation systems, set-top boxes and medical equipment. There are also a few small web browsers for old DOS PCs available.

• Interniche's NicheView Portable Embedded Web Browser is probably the smallest full-featured web browser around with its 35 kilobytes code footprint. There is also an additional JavaScript module available.
  
• AU-systems' AU Mobile Internet Browser supports both HTML/TCP/IP and WML/WAP as well as SSL. It occupies 340 kilobytes of code (plus an additional 190 kilobytes for the protocol stacks) and uses 5 kilobytes of RAM when idle (plus 8 kilobytes used by the protocol stacks). Extra RAM is used when downloading web pages.
  
• The Fusion WebPilot Embedded Micro-Browser supports much of the features found in modern web browsers including frames, authentication, and JavaScript. The web page does not specify memory footprint.
  
• MicroDigial's Graphical MicroBrowser supports tables, frames, images as well as FTP as uses 260 kilobytes of code memory and requires a minimum of 210 kilobytes of RAM apart from that. A demo version is available.
  
• The 2net Alice Web Browser is intended for handheld computers and PC based architectures and requires 400 kilobyte of free RAM and 200 kilobytes of code memory. It includes a TCP/IP stack.
  
• WebBoy is a fully-fledged browser with SSL support intended for 386 DOS boxes with more than 4 megabytes of memory. Includes a TCP/IP stack.
  
• The Arachne web browser runs under MS-DOS or Linux and requires at least 1 megabyte of memory. Does not include a TCP/IP/PPP stack.
  
• Lynx is probably the most well-known text-based web browser around. It is ported to many different operating systems and architectures including MS-DOS.
  
• The Off by One Web Browser has been labeled as the smallest web browser ever, but is quite large in comparison with other small web browsers. It is 1.1 megabytes large and requires support from an underlying Windows operating system.
  
• Mirko Sobe's BOSS-X HTML browser for 8-bit Ataris is not a full web browser, but an off-line HTML viewer with hyperlinking abilities written in three days.
  
• The pre-alpha v0.3 GEMWeb browser supports 640x480x16 VGA.
  
• The Atari Phoenix Web Browser is a non-existant vapor-ware web browser project intended for the 8-bit Ataris.
  

URL: http://dunkels.com/adam/contiki/links.html

System information and emulators

Commodore 64/128

The Commodore 64 is based on the 6510 CPU, which is a 6502-derived 8-bit CPU. It has 64k of RAM and 16k ROM which includes a BASIC interpreter and some basic I/O services. Graphics is provided by the VIC chip which has 16 colors and a maximum resolution of 320x200 in hi-res mode. It provides a 40x25 raster of characters in character mode. The three voices of digital sound is produced by the SID chip.

The Commodore 128 is an extended version of the Commodore 64 that contains a 8510 CPU which is capable of 2 MHz operation and can address 128k RAM (hence the name Commodore 128). It also has a Commodore 64 compatibility mode which is extremely similar to a regular C64 but with a few minor differences.

The SuperCPU is a 20 MHz 16-bit 65816-based computer that is plugged into the back of the Commodore 64 or 128. It uses the C64 keyboard and joysticks for input and the VIC and SID chips for audiovisual output. The SuperCPU is capable of addressing several megabytes of memory and is usually used together with a 16 megabytes RAM expansion board.

There are no SuperCPU emulators avaliable.

• The VICE emulator is capable of emulating a large number of Commodore machines. It emulates the C64, the C128, the VIC20, most of the PET models, and the CBM-II. VICE runs under Windows, Linux, FreeBSD, and a number of other host systems.
  
• Joakim Eriksson's Web C64 emulator, written in Java, runs as an applet within a web browser.
  
• Per Håkan Sundell's CCS64 emulator works under Windows and DOS.
  
• The ec64 emulator is developed for Linux and was originally written entirely in x86 assembler.
  
• An article by Simon N Goodwin about C64 emulators.
  
• The Commodore emulators category in the Dmoz has more links.
  

Commodore 64/128

There are plenty of alternative operating systems for the C64, mostly written in 6502 assembler. Some of them are far from complete, however, and only appear as dark shadows on a few web pages - MagerValp's SMOS and my own osT are among those.

• GEOS from 1986 probably is the most well-known graphical operating system for the C64. It is still sold commercially by CMDKEY.com.
  
• LUnix NG is an open-source multi-tasking operating system with TCP/IP/PPP-support, a *nix-like command shell, and a number of *nix-like utilities such as ls and cp.
• Craig Bruce's ACE is a text-based single-tasking operating system for the 64 and the 128. It provides a *nix-like command shell, a text-editor, a terminal program for the SwiftLink RS232 interface, as well as device drivers for a lot of devices
  
• GeckOS/A65 is a multi-tasking operating system with TCP/IP support and a *nix-like command shell.
  
• Wheels is a version of GEOS that requires RAM expansion to run.

With its 20 MHz and megabytes of memory, the SuperCPU is powerful enough to run fully-fledged graphical operating systems that rival early Machintosh or Microsoft Windows systems.

• Wings is a TCP/IP-enabled graphical operating system for the SuperCPU. It includes a MOD music player, JPEG viewer, web page download utility, etc.
• JOS is an older version of Wings.
  

TCP/IP and PPP connectivity

To surf the web, send or read email, etc., the first step is to actually get in touch with the Internet. This requires both physical access to an ISP, either via a modem and a phone-line or an Ethernet broadband connection, and the TCP/IP software running on the C64.

There are a number of programs that make it possible to reach the Internet with a C64/C128.

• LUnix NG contains a TCP/IP stack and a PPP implementation which makes it possible to reach the Internet using a modem and a dial-up ISP.
  
• GeckOS/A65 also contains a TCP/IP stack, but no PPP dialer.
  
• My own uIP TCP/IP stack has been used for some time to run a web server on a Commodore 64. uIP currently does not include a PPP dialer.
  
• Novaterm 10 contains a PPP dialer and enough TCP/IP code to be able to run telnet over the Internet.
  

SuperCPU

All of the above mentioned SuperCPU operating systems have TCP/IP support.

• The Wave is a web browser for the SuperCPU (and not for the Commodore 64/128 as the web page claims) that runs under the Wheels operating systems. Here is another page with information about The Wave (that also falsely claims that The Wave is for the Commodore 64/128). The latter page also includes screenshots of The Wave in action.
  

Small graphical user-interfaces (GUIs)

User interfaces for embedded systems range from the simple buttons on the front of a washing machine to those of fully fledged web browser type interfaces on information stations. The underlying technology varies from simple electronic circuits to full-scale PC compatibles.

• PicoGUI is a GUI architecture designed for embedded systems to desktop machines. It does not require any supporting GUI system and can be used on anything from graphical screens to text based systems. Their smallest target system are handheld terminals and the compiled object code size is on the order of hundreds of kilobytes.
  
• Microwindows/NanoGUI is a graphical user interface system designed to run without support from an underlying system. On 16-bit systems Microwindows is about 64k large.
  

The smallest web browsers are usually specially designed for the limitations of embedded systems and other specialized computers such as car navigation systems, set-top boxes and medical equipment. There are also a few small web browsers for old DOS PCs available.

• Interniche's NicheView Portable Embedded Web Browser is probably the smallest full-featured web browser around with its 35 kilobytes code footprint. There is also an additional JavaScript module available.
  
• AU-systems' AU Mobile Internet Browser supports both HTML/TCP/IP and WML/WAP as well as SSL. It occupies 340 kilobytes of code (plus an additional 190 kilobytes for the protocol stacks) and uses 5 kilobytes of RAM when idle (plus 8 kilobytes used by the protocol stacks). Extra RAM is used when downloading web pages.
  
• The Fusion WebPilot Embedded Micro-Browser supports much of the features found in modern web browsers including frames, authentication, and JavaScript. The web page does not specify memory footprint.
  
• MicroDigial's Graphical MicroBrowser supports tables, frames, images as well as FTP as uses 260 kilobytes of code memory and requires a minimum of 210 kilobytes of RAM apart from that. A demo version is available.
  
• The 2net Alice Web Browser is intended for handheld computers and PC based architectures and requires 400 kilobyte of free RAM and 200 kilobytes of code memory. It includes a TCP/IP stack.
  
• WebBoy is a fully-fledged browser with SSL support intended for 386 DOS boxes with more than 4 megabytes of memory. Includes a TCP/IP stack.
  
• The Arachne web browser runs under MS-DOS or Linux and requires at least 1 megabyte of memory. Does not include a TCP/IP/PPP stack.
  
• Lynx is probably the most well-known text-based web browser around. It is ported to many different operating systems and architectures including MS-DOS.
  
• The Off by One Web Browser has been labeled as the smallest web browser ever, but is quite large in comparison with other small web browsers. It is 1.1 megabytes large and requires support from an underlying Windows operating system.
  
• Mirko Sobe's BOSS-X HTML browser for 8-bit Ataris is not a full web browser, but an off-line HTML viewer with hyperlinking abilities written in three days.
  
• The pre-alpha v0.3 GEMWeb browser supports 640x480x16 VGA.
  
• The Atari Phoenix Web Browser is a non-existant vapor-ware web browser project intended for the 8-bit Ataris.
  

The SNES uses a 65c816

..which is still a processor in the 6502 family.

The problem is, the situation that FORTH is great in is becoming increasingly rare. Most FORTHs still require programmers to constantly think about how to juggle the stack if they receive a number of parameters (yes, there are some extensions). FORTH has essentially no type-checking, and the combination of these two factors means that it's extremely easy to (1) make a mistake and (2) for that mistake to have nasty consequences.

Many program language implementations generate intermediate stack-based code (think Java class files, Python, Perl, etc.); in FORTH, you're writing the stack-based code yourself, so you are essentially writing in an assembly language for a simulated stack-based system. FORTH thus has some of the similar properties as assembler: fewer development system resources are required, but it's more work for the programmer. This isn't completely true; FORTH is definitely much higher-level than the typical assembly language program, but many programs take more work to implement in FORTH than, say, Python (which is also interactive, and it executes a stack-based program, but lets people express code in a more Algol-like way and then TRANSLATES that code into a stack-based approach).

I do think Forth is a good language to learn, because many systems are built on stack-based intermediate languages (Java, C#, Perl, Python), and being able to directly interact with a stack-based language helps to learn how they really work.

An implementation of Forth for 6502 is freely available.

First of all you should decide on exactly what you want to do. Do you want to design and build your own computer, or are you happy to build a computer that other people have already designed? I started building other people's designs (the first computer I built was a Z-80 kit computer) and managed to teach myself enough to tackle designing and building a simple 8-bit computer. 8-bit computers are reasonably simple to design and build and there's quite a lot of resources on the net available.

I would suggest that you look at sites like 6502.org, www.coprolite.com, Mark-8, POD 6502 or Grant Searle's collection of sites build your own UK101, build your own ZX-80 and build your own Jupiter Ace...

These are all quite good sites, and you can study their designs to learn how they work.

Hope this helps!

Speaking of the C=64...

My first PC (stiil works!) was an IBM PS/2 55SX with a 60MB hard drive. I bought it (with a student discount) in 1991 for about $3,000.

Since you brought it up... [from the CBM-PET FAQ]:

WHAT IS THE 'KILLER POKE' AND SHOULD I WORRY ABOUT IT?

This is THE POKE of computer lore, the command that WILL physically break a
computer! Of course other commands and methods are known that can
potentially cause damage (usually to disks, hard drives or other mechanical
units), but this is the most notable mainly because it was a command somewhat
commonly used and it affects solid-state circuitry.

History of 'the killer poke'
When the first PETs (small 9" screen) models came out, the display wasnt all
that fast.

The old PETs were slow because the print character ROM routine
waited for the interval between screen scans before updating the screen
memory. This reduced conflicts over the screen RAM which would have resulted
in random pixels (snow) being illuminated on the screen. There was an input
on one of the I/O chips which was hooked up to the video circuitry and told
the routine when to access the video RAM.

It wasn't too long before someone learned they could impove the
character display speed via a poke to location 59458; which would set the
video controller to update more readily. It was a noticible improvement of
speed on programs using PRINT often, it was kind of like a free upgrade.
It was mentioned in a few publications and used in many programs that relied
on printing to the screen. I had learned of the poke through Cursor Magazine,
a monthly tape-based publication. They printed the command in one of the
'newsletter' flyers included with an issue which you could insert into their
game "joust" to make it play faster.

Later on, when Commodore released the larger display (14") PETs, they had
improved the display controller which made that POKE unnecessary. An
unfortunate side effect was that the POKE to 59458 affected a different
register which adjusts one of the newer screen display capabilities, which
could result in damaging the PETs video curcuitry when left running. I
discovered it by accident after our school received some large-screen 4016s.
When active, the screen starts to warp after about the third line and the
display stops around the fifth, the keyboard is also unresponsive. When a PET
is in this mode, the only solution is to turn it off, FAST! Fortunately none
of the school's PETs were damaged due to this POKE. Later Cursor Magazine
published a 'fix' that would allow older PETs to use the poke and keep the
large-screen units from frying. Unfortunately there are still many programs
that do not have this fix.

If you're interested in doing bizzaro stuff with your C64, you might want to check out these links:

LUnix (Fully functioning SLIP-TCP/IP stack for C64)

GeckOS/A65 (Multitasking Unix-ish OS for C64s)

Lemon for a good stockpile of C64 warez. :)

I seriously doubt the NES could run Linux as you would very likely need an MMU for memory management which the 6502 is fairly incapable of. However, I see no reason why someone couldn't kludge up a primitive DOS for it now that you're fairly unlikely to find a Famicom disk drive. Anyone for porting over Microsoft's BASIC 2.0 kernel? :)