Slashdot Mirror

I'm having trouble thinking of a proprietary piece of software I need... depends on your hobbies I suppose.

Apart from games, a lot of people need proprietary video player software to stream rented non-free films and non-free TV shows. The software is non-free due to compliance and robustness rules imposed by the movie studios. And a lot of people need proprietary tax preparation wizard software to prepare income tax returns. This software is non-free because tax software publishers treat their machine-readable interpretations of annual tax law amendments as a valuable trade secret.

Its at the point where I assume if there is no Debian package of a cool piece of software its because its not DFSG free

There is a DFSG-free (zlib license) 6502 assembly language development toolchain called ca65, but it's not in Debian (and thus not in Ubuntu) because it's bundled with a non-free C compiler called cc65. I filed a needs-packaging request for ca65 years ago.

http://www.cc65.org/ Free compiler for 65xx CPU targets
http://vice-emu.sourceforge.net/ Multi-platform emulation of all Commodore 8bit computers

Libraries and repositories
  http://www.gb64.com/index.php
  http://www.lemon64.com/

Exactly for what stupid reason the CPU core instruction set are "proprietary and confidential"?

It is the case; see this post on ca65's mailing list. But I don't know why it is the case because I don't know how to contact Sunplus.

As for the additional sales for Linux users, well, fuck that! Let's don't use that hardware maker then.

Sometimes people don't have the choice not to use that hardware maker. For example, if all makers of one kind of component of home PCs act this way, such as all makers of mobile broadband cards, is one supposed to just not buy and not use that kind of component? Or they might be using donated hardware, such as a birthday/Christmas gift or a charitable in-kind donation to a nonprofit organization.

Oh, and by the way, what's the issue with DSPs? Why are they different from any other CPUs?

DSPs have specialized instruction sets, and they rely on compiler optimizations rather than hardware support of out-of-order processing. DSP makers see a compiler that produces code two to five times as efficient as GCC's output as a valuable work of authorship on which to enforce scarcity.

Just wanted to point out making NES games would probably be much easier nowadays. Compilers have become very good so the developers could probably move up from assembly to C.

There are people on nesdev.com/bbs who are trying to make some support libraries for programming the NES in C, but it's not practical so far, for two reasons:

1. The widely available C compiler targeting the 6502 CPU fails at optimizing. Do you know of a better free or semi-free C compiler targeting the 6502 CPU?
2. The NES has 2 KiB of RAM; cartridges can have 8 KiB more at an additional cost (address decoder + SRAM chip). This makes typical C programming idioms, such as a stack bigger than 256 bytes, look inefficient.

How many computers do you keep around for 20 years?

I still have the Apple IIe my parents bought new in 1985. If push came to shove, I could press it back into "daily-driver" use. I've even knocked together some new apps for it now that there's a not-bad C cross-compiler that targets the Apple II.

...and also, the classic Z80 CPU (plus peripherals like the CTC and PIO) is *still* manufactured - you can still homebrew an old-skool 8 bit computer.

More importantly, the 6502 is still available, along with the support chips it used. There's even a free-as-in-speech C cross-compiler available for it. I used it recently to rewrite the software for my Apple II beer-fridge controller, and that software will be ported to a 6502-based (65C02-based, really, but that's a minor difference) controller board I've designed (still need to send the board out for fabrication).

Wake me up when I can download (for free) the Generation NEX development kit

To make NES compatible software, you just need CA65 or another 6502 assembler, a tile editor supporting NES format, and your favourite programmer's editor.

Using C on low-end hadware is not very exciting :). For me, programming C64 in C with http://www.cc65.org/ feels a lot like doing it in plain 6502 assembly with lots of useful macros. Simlar thing with AVR uC.

I coordinate a certain OSS project that will remain nameless, and while I would not say that "Porting OSS to minor platforms is harmful", I have seen first hand some of the problems that he is experiencing.

I've been in situations similar to Drepper's AIX situation, where there is a situation where either myself or someone else wants to make an improvement, and finds themselves breaking a minor platform or derivative project that we might not have the development resources to fully investigate. And usually, it is because of a legitimate error on the part of the contributor. But whether the error is legit or not is beside the point; the point is who is actually responsible for preventing breakage?

The dilemma comes down to the idea that even in the OSS world, developers are not free, and if such a breaking change is introduced that only manifests itself on a minor platform, what is the best way to move forward? Should anybody that makes a submission be responsible for tesitng that submission on every port and derivative project?

It all comes down to a balancing act. Is it worth it to you that GCC releases get released a week later so that AIX can be supported? Or should the AIX people (or the GCC VAX people, or the GCC C64 people) have their own separate fork and their own release schedule, so they can handle their own regression testing? The answer is suprisingly not always obvious, and the wrong decision may have political costs in the amount of people working on the project.

Contiki/Linux just needs to be compiled on a real compiler with a back-end that produces code that the Meccano CPU can run. As for which OS to try out, try and compare the size of a Contiki kernel to thet of a Linux kernel, and go with the smallest (question: Is there a size comparison of the two kernels on a machine that is capable of running both OS's?). As all the flip-flops for memory/storage will have to be built by hand, it would make sense to try the smallest OS on the machine. I suspect that Contiki would be the smallest, but I am not sure if Contiki can run as a server OS, so it would be useless, unless you also made user Input/Output devices out of Meccano as well.

So you're still smoking the crack, just switched pipes.

Got to be the longest trip then.

I thought these were the real crack smokers...

So you're still smoking the crack, just switched pipes.

Got to be the longest trip then.

I thought these were the real crack smokers...

You want an 8-bit Apple ][ development environment, dump some ROMs and get a copy of Dapple ][ (Note for you OSS weenies: the ASMLIB source is all that hasn't been released yet of the stuff I *didn't* write, and you can probably run ndisasm on it. The rest is GPL). Then download CC65.

You may have to add a header consisting of the following to the cc65 binary file, if loading it doesn't work. (And give it a ".pg2" extension)

struct load_header
{
unsigned short int /*16*/ load_address;
unsigned short int /*16*/ load_length;
};

You get 3,136 KB of RAM and a 1.44 MB floppy drive (the one sticking out of the front of your PC), in addition to all the usual //e niceties. *g* No Z80 yet, but we're working on that. No hard disk either, but that's trivial.

-uso.
</plug>

The above program will not link correctly on the cc65 compiler when targeting the Commodore C16-Plus/4, as there is no stdio at *all* in the C16 runtime.

It also won't work with my cc86 project (Turbo C++ 1.01 to CP/M-86 cross-compiler), because cc86 has *no* runtime at all, except for the startup code that calls main(). See below for an example of how to use cc86 to write a hello world program.

-uso.
/* Hello World program for cc86 */
#include <8088.h> /* may need to be cpm.h on the current version */

int lputc (int c)
{
if (c==0) return 0;
if (c=='\n') lputc('\r'); /* newline translation */
_CL=2; /* put char to console */
_DL=c;
geninterrupt(224); /* CP/M */
return c;
}

void lputs (char *s)
{
while (lputc(*(s++)));
}

void main (void) /* XXX: how to pass argc/argv in start86? */
{
lputs ("Hello world\n");
}

See also www.cc65.org

Now I shall demonstrate why Ada is a better choice for this sort of thing.

In this bit of documentation, it is suggested that you get better code by putting an extra cast into an expression which keeps everything nicely eight bitted. The C language definition AFAIK requires that the compiler behave in this (odd) way.

The Ada equivalent is this:

A : Octet;
...

if (A and 15) = 0 then

You don't have to remember to cast, and it's all 8 bit. Ha!

In the future, all new Commodore 64 software will be written in Ada :-)

It's using the cc65 compiler, available here. My TRS-80 CoCo 3 port will use gcc, however, since I took the time to look at some old work done on targeting the 6809 with gcc.

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.
  

Check out CC65. It is a pretty good freestanding implentation of ANSI C89 on the 6502 (C-64, Apple //, Atari 800, Nintendo, etc). Projects such as uIP and uVNC have been built with it.

cc65 is an ANSI C compiler for 6502 machines. It's sweet.

Damn those Amigas are cool... They can survive a slashdotting!

If you think that's cool, remember the time someone posted a link to a webserver running on a Commodore 64. That thing just kept serving stuff for a while at an acceptable rate. Yeah, not all night long, but for an amazingly long time. I think what brought it to halt was the link to the CGI script =)

Maybe it was this one. in this posting.
I was just looking for IP-stack fo microcontrollers and found it (again).

Don't you mean serve with?

Check out this other C64 web server, running on the same server setup, just no streaming audio: http://c64.cc65.org/

Orange

This one is running a httpd on a C64, but is slip connected to a Linux box for its connectivity rather than having its own ethernet. http://c64.cc65.org/

If you like, we could get you an internet capable Commodore 64 for you to write it on.

That'd be any C-64. Or did you have a WWW server in mind?

16GB on that machine is completely nuts. You could quite possibly store every c64 game ever made (which I estimate at over 30,000 .d64 images total) and still have room left over for the applications.

Lisa? MAC SE?!

Of course your modern day super computers can handle a web server. OTOH, it's only recently that web server technology has filtered down to the humble computers that people can actually afford to buy.

(Check the link, yes it's a C=64...) I guess the poor machine will be slashdotted to hell even though this is a late entry in an old thread. So, a short summary:

c64.cc65.org is a web server hosted on a C=64 connected by SLIP through a serial cartidge to a Linux computer (which in its turn is connected through ADSL). The IPstack and all processing is on the C=64. The C=64 has not been expanded in any way, save for the IO cartridge (SwiftLink 38400bps serial).

The page is small, but there is a few images on it... The server was created by Adam Dunkels as a part of his uIP TCP/IP stack for the C=64.

If you think this is cool, you might want to check out this. It is a Commodore 64 that is running as a web server, and has been up 24/7 since november 2001. It is connected to the Internet via a 38400 bps SLIP link so it is quite slow.

For those of you who doesn't remember the Commodore 64, it was a very popular home computer in the 80's and early 90's. It has 64k RAM and an 8-bit 1 MHz 6502 CPU.

The C64 web server is running the small uIP TCP/IP stack that is less than 4k large and uses only a few hundred bytes of dynamic RAM. Since it is written in C, it has been ported to numerous other systems such as the 8-bit Ataris and a number of embedded processors such as the Hitachi H8S.

Take a look at http://c64.cc65.org/. It is a good old C64 working as a web server. It runs the uIP TCP/IP stack, which is written in C and is really tiny; the code is around 4k large and it uses some 200 bytes of RAM.

You don't notice this until you actually try: after a few years of Perl programming, it's hard to put those dollar signs at the end, and even harder to leave off the semi-colons. :-(

...and it's even harder to use two-letter variable names.

I assume you meat U$ and PW$ (or DIM PW$,7 - see getpwnam(3) man page!)... not lame long names like LOGIN$ and PASSWORD$, those weren't there until DOS and QBasic.

Well, I suppose I will use cc64 and raw 6502 assembler for my microcomputing needs. Commodore basic was one of the most hideous programming environments Microsoft has ever produced =)

in practice, most people don't write their programs in 6502 assembler.

(ICK! The language is called assembly, not assembler. Would you like it if I called the C++ language "compiler"?)

That's because most people don't develop for C=64, Apple II, or NES. I still write NES software in assembly because I haven't yet taken the time to get CC65 working and get a C library written. But handcoded assembly does give you the tightest code if you know what you're doing with respect to the pipeline (6502 has one short pipeline so it's easier here).