Hi All!

I'd like to pose a question to everyone.

How many people would be interested in building a modern 65C02-based PC, complete with Video, keyboard, sound, floppy disk, hard disk, and serial & parallel ports? Include, of course, an OS capable of driving all of the hardware.

It has been suggested to me that there are quite a few folks out there who would like to get back a simple computer such as the Apple ][ & Commodore 64.

Here are my thoughts on such a computer:

There are two paths: Custom Hardware or readily available PC peripherals.

Processor: 65C816 with 128K RAM (expandable)
Video: 1) NTSC/PAL Composite Video, or 2) VGA using PC Hardware
Sound: 8/16 bit Soundblaster Compatable PC card
Keyboard: PC AT keyboard
Floppy: 1.44MB PC compatible Floppy Drive
hard Disk: IDE hard Drives
Serial: dual 16550 for faster speeds
parallel: Standard 8 bit PC Parallel port compatible (for printers)

Operating System:
A simple DOS capable of storage to both the Hard disk and floppy.
Languages such as assembly, BASIC, Forth available from Disk.

Thats my two cents... What do YOU think?

Daryl
http://65c02.tripod.com/

About time. Too many people seem to avoid the 65816 in favor of the 6502.



VGA signalling is easier to do than composite video, especially when color is involved. I'd suspect it'd take less hardware to accomplish VGA signalling than color composite.

That being said, it's also true that digitized composite video is pretty easy to implement as well, at least monochrome.

Personally, though, I'm in favor of VGA. I see no long-term future for NTSC signalling.



PC *card*, or the use of the same chip as the card? The former seems to be a dead-end solution, unless you're intending to go PCI, and that's a bit on the expensive side, I think. ISA is a dead-end solution -- none of my computer stores have ISA cards any more.

I think a slightly superior solution would actually be to dedicate a USB hub solely for the purpose of driving USB speakers.

Alternatively, and I think the best solution, is the creation of a plain dumb set of DMA channels for audio (e.g., Amiga and early Macintosh do this).



Several things here.

1. The parallel ports are implemented largely by 6522 VIA chips as is. That being said, they can readily handle EPP devices as well. Are you also thinking of supporting ECP port operation as well? If so, then having a 6522 for the parallel port wouldn't be sufficient; perhaps a PIC chip configured to act as a parallel port can function as the bus master for the ECP operation.

2. IrDA has been largely ignored for desktop machines. Why? I'd love to *NOT* have to use my cradle for my Palm Pilot when syncing with my PalmOS device. Imagine how nice it'd be to place an IrDA printer next to the computer, and forego the rats nest behind the computer?

3. Perhaps we should be the first to create a USB 1.1 hub interface for the 6502/816. USB devices are plentiful and varied (e.g., such a bus will give us near instant access to everything from printers to storage devices to scanners to webcams, and more), and the hardware requirements looks awfully simple. Architecturally, the hub looks to be similar in scope to a network device and bus master. Definitely not something that could easily be implemented in discrete logic, but perhaps in a FPGA or two...



I'd rather Forth be in ROM, so that the system isn't utterly useless without a host operating system. But that being said, perhaps it's best to stick with a simple boot-time kernel, and have Forth in a bootable ROM-disk, which is accessed only if higher priority storage devices don't respond with bootable partitions. I seem to recall that the Atari ST platform used a similar system to boot GEM with.

IMHO, have BASIC in ROM, and a simple OS, but allow boot from disk as well.

65C816, yes. How about the 20 MHz model I hear is used in the C1? :þ

(shudders at the thought of BASIC...)

This is the type of thing that starts religious wars, unfortunately. Unfortunately, BASIC is pretty universally accepted in the software development community as one of the worst possible programming languages you can teach someone. IMO, I'd rather the ROM space be devoted to the kernel and have a bootable language environment before having a ROMed implementation of BASIC.

But, if you guys do decide on using BASIC, PLEASE make it a structured BASIC, complete with support for user-defined types and other things.

For that matter, if your'e going to go that far, I strongly suggest using Oberon instead of BASIC anyway (whether in ROM or loaded post-boot into RAM). Having roots in Modula-2, Oberon is a simple, systems-level programming language similar in scope to C, but is much, much, much easier for beginners to get. The source code looks much prettier than C as well, which makes code maintenance significantly more tolerable. It's also a completely type-safe language.

It's also garbage collected, which makes the user's memory management significantly easier. Having experience with Oberon, I can easily say that it rivals Python or BASIC in ease of managing memory.

Advantages:
Super-easy to use for the beginner and advanced, alike.

It's modular. The "operating system" can be expressed as a set of Oberon modules, which are loaded on an as-needed basis.

It's compiled. The Oberon compiler is usually a one-pass compiler, making for super-fast compilations, that rival those of Forth's.

It's type-safe. The beginner might be inundated with type errors at first, but the results are well worth it. Array bounds checking, NIL pointer derefencing checks, etc. are all generated by the compiler to prevent irreparable damage to the run-time environment. Oberon's type-checking extends to the module interface, where an IMPORTed module is checked for type safety against the program's requirements before any code is executed.

Although compiled, Oberon's modularity and support for module-level introspection makes an interactive environment easy to implement. In fact, The Oberon System 3 environment is written in Oberon, and like Smalltalk, presents a consistent, all-Oberon environment.

The disadvantage:
It's more complex to implement than Forth is.

The run-time environment requires a memory allocator and a garbage collector.

Interfacing to other, non-type-safe languages like C and Forth might be more difficult. (But then why would you want to when Oberon compiles to native machine code anyway?)

How about C in ROM? :þ

First, why would you want to subject anyone to the sheer terror that is C?

Second, Oberon is a smaller, simpler language than C anyway.

Finally, I don't think we'll have enough ROM space for any of our ideas anyway, so the only viable alternative is either a really crummy version of BASIC or Forth. I vote for the latter, while distributing Basic, C, and/or Oberon on secondary storage.

Also, why are we talking about floppies anyway? Floppies are a dead technology. Go with compact flash and/or SmartMedia instead. They're smaller than floppies, about as fast, and holds hundreds of megabytes.

No brainer, if you ask me.

For small, simple, and easy to program, I'd go for Lua - http://www.lua.org has the details.

Here's something to consider: If we want to use a fast 65816, we will have a problem with implementing a large size of ROM since the access speed of ROM is generally slower than RAM. My thinking was to implement a boot loader in ROM with the system clocked down to load the basic OS into RAM and then clock up to full speed. That leaves us with keeping any languages on our data storage media.



I agree. I know Ross Archer is working on a compact flash interface. I'm sure others may be doing so as well. The good thing about floppy support is the ability to easily transfer files between our system and a PC, at least until we can get a PPP and TCP/IP stack going so we can access the internet directly.

As far as programming languages go, we all have our OWN favorites. That's another reason to load them from our storage media, that way we can each load our own preferred language.

Daryl
[/quote]

Jeri Ellsworth developed something similar called the CommodoreOne (http://c64upgra.de/c-one/) which looks interesting..

Yes, this is the rationale behind my reasoning. It's just that I don't want the machine to be TOTALLY useless in the event that there is no bootable volume. I'm thinking along the lines of OpenFirmware here, though maybe not going quite as far.

You know, I really like this BBS's quoting mechanism. I *really* wish normal e-mail had a system like it!

Digital LCD monitors are getting cheaper. Why not just go that route? Rich Dreher has come up with a compact flash card that goes in an Apple 2e or 2GS. It works pretty slick.

And VGA LCD monitors are even cheaper yet. Because this computer isn't going to be a volume production item (at least compared to a normal PC), it's important that costs be kept to a minimum. I'm all for using pure digital technology where applicable, but analog VGA's overall system prices are quite compelling.

As for Compact Flash, I'm in total agreement. I see no future for floppies, and while CF media is more expensive (why?! They're using the same technology as SmartMedia!), the circuitry to interface to it is dead simple. http://www.6502.org has a few IDE interface schematics in their mini-projects section. Strongly recommended, considering it gives you free access to not only CF, but also larger capacity harddrives as well!

I think that a system with a command line interface OS should be used, languages should be left to the individual and loaded from disk or add-on cartridge. One of these modern serial ROM's could be used to load languages into RAM on startup.

Another possibility is to make the CLI operate in a graphics mode, then it
would be easy to port the OS into a grahpic operating environment. Why walk in the legacy of that huge unmentionable software company.

WARNING: Potentially controversial opinion essay follows...



A few points:

1. Implementing a CLI is, in fact, following in the footsteps of two unmentionable companies: AT&T (Unix) and Microsoft (DOS). Of course, other platforms have had CLIs as well, such as the Amiga (inspired by VMS's shell environment, but implemented almost directly like a Unix clone).

2. A command-line interface must interpret user input. Hence, it itself is a language.

Most CLIs are not Turing complete. To make a Turing complete shell interface, in fact, requires resources that are often in excess of a normal language, specifically because the syntax of the language must work around syntax that is incredibly irregular. BASH, for example, consumes 511400 bytes on my x86 Linux box. On a RISC architecture, multiply that value AT LEAST by two. This value, of course, does not include the host OS resources that it relies upon. Moreover, very little of that code is Linux-specific. The last time I saw a version of BASH for DOS, it consumed over 400K, and *required* a 32-bit DPMI handler to be installed to run it.

Yet, Pygmy Forth on my system consumes only 16KB of 16-bit code (if we were to scale it up to 32-bit, it'd be 32KB), and can invoke external programs just like BASH can, though with additional syntax (e.g., " QEDIT myFile.txt" SYSTEM instead of just QEDIT myFile.txt). But the neat thing comes when I have to pass parameters to commands, and have to iterate over whole directories of files, including sub-directories. Neither COMMAND.COM nor BASH have a "NOT" wildcard character (in fact, neither does VMS, but AmigaOS does!), so while I can INCLUDE files based on certain criteria, I can't EXCLUDE them. With Forth, I can, and I can do it in much less space and overhead. Any Lisp user will probably give you similar success stories.

3. In most CLI environments, commands are implemented as subroutines, with grossly unnatural means of passing parameters and an incredibly restrictive method of returning results back. Most CLI commands accept a pure string input, or an array of strings with each element representing one argument. They only return a single integer for a result code. The sheer difficulty in parsing command line arguments cannot be over-appreciated. Just look at the 5 or so "standard" CLI parameter parsing packages available for Linux alone, not counting the ad hoc approaches most commands take. Look at how many exist for MS-DOS. The only two systems I've seen that had only one standard method of processing commands was AmigaOS and VMS, and even AmigaOS didn't really have it until Kickstart 2.0, where they shipped the "standard argument parser" standard with the OS.

With more rational languages, this doesn't exist. The command is implemented, as far as the language is concerned, as a normal language subroutine. Therefore, parameters are passed as normal language parameters (usually on the stack). This maintains proper structure (and, optionally, encapsulation if the environment is object oriented), and is a critical factor in enabling system-wide garbage collection. Moreover, integers are passed as real integers -- no encoding or decoding functionality is needed inside your application. Same thing with floating-point values. And strings are pre-parsed. Wild-cards can be expanded with the aid of an explicit call to an expander function (see the Scheme example below).

Moreover, returning a result is handled the same way as any other language subroutine. In the case of Forth, this is depositing one or more values on the data stack (or other relavent stacks as necessary, such as floating point or string). Note also that Forth and Lisp can return MULTIPLE values (versus the traditional one) of ANY type (versus the traditional integer). This enables commands like (expand) or MATCH-FILES to perform wild-card expansion on demand, rather than as an automatic and implicit function of the shell. I cannot TELL you, as a programmer, how many times I've been bitten by this when trying to use 'grep' to find a pattern involving a dot, an asterisk, or square brackets. I've also written my own commands whose interface really would have been greatly simplified for the user if (s)he could pass "*" to the command without having the shell auto-expand it to a list of files (a list, by the way, whose delineation isn't certain).

This structure also encourages capability-based security systems, which to date, have been demonstrated to be superior to ACL-based security systems in every way. Damage from viruses can be contained much more easily with capability systems. A faulty program can trash only the files it's been given explicit permission to modify by the user. Wide-open e-mail security holes are a thing of the past, while STILL preserving the capabilities (no pun intended) and relative ease of use of packages like Outlook (Express). NONE of this is possible in a traditional, strictly-text based shell environment, specifically because it so harshly breaks encapsulation.

4. This raises another interesting point. You have a language parser and interpreter for the shell itself, and then you have a language parser and interpreter/marshaller for the command line parameters as well. How many more languages do you need to support? Scripting is critical for many people, and that constitutes yet another language. Try as you might to unify the CLI and the script, it can't be done 100%. Even BASH has difficulties in this area, though it rarely presents a problem to the user.

5. I've also very desparately wanted to perform basic arithmetic in the shell as well. By basic arithmetic, I'm talking addition, subtraction, multiplication, and division. Not quite as frequently, I've also wanted to do other algebraic operations, like squares and square-roots, and very rarely, sines and cosines. As it is, neither BASH nor COMMAND.COM permit even simple addition. I have to rely on an external command, usually called expr, to figure this stuff out, but I can't use it to affect filenames, and I can't use it for generic text manipulation. How sad.

Because Forth and Lisp are effectively plug-in based languages, any arbitrary program that is willing to accept the Oberon/Forth/Lisp/whatever ABI, regardless of what language it's actually written in, will be self-consistent with the remainder of the language. Therefore, only ONE interpretter is necessary (Forth also has a built-in compiler, so "scripts" that you write get compiled to a representation that is, if not native code, awfully close to it), for both commands and parameters, and allows easy functional composition between programs without the bizarre and patently arbitrary syntax requirements for things like pipes and file redirection.

But you can't invoke a command as easily in these languages? Sure you can. For example:



The advantages of Forth and Lisp/Scheme is that the shell follows the language's syntax rules precisely, while Oberon and DOS, etc. do not (they need a separate interactive interpreter). Note that Forth isn't strictly garbage collected "as is," but can be made to support explicit garbage collection with relatively little additional code. Also, the structure of the dictionary is highly conducive to frequent space re-use, so even to this day, Forth implementations actually tend NOT to use dynamic memory allocation for most tasks.

The only advantage to the CP/M or Unix derived shell environments that I can see is that it requires less typing on average, and therefore, gives the *false* appearance of being easier to learn. Yet, nearly *ALL* of today's IT professionals grew up on systems that had integrated langauges in them, not shells. *EVERYONE* that I've seen who's grown up on a shell-based environment like the PC has demonstrated measurably inferior computer use capabilities to those who didn't.

In short, the scism between OS and language is demonstrably a false one, and should be eschewed. There is a lot of talk these days of re-unifying the language and the OS, so it's a problem that is recognized widely in the software community. The decision, then, is what language do you choose to implement as the default? I also have to agree, why walk in the legacy of that huge unmentionable software company?

Then again, look at DOS 3.3/ProDOS.

Now I like BASIC because I grew up with it, but for having the same ui as the language you'd have

COPY "source","target"
RENAME "source","target"
LOCK "filename"
UNLOCK "filename"
SHELL "command"
KILL "filename"

etc. ... sure, it's following Ma¢ro$haft (but not entirely - see how 'rename' is implemented vs. "name" in M$-BA$I¢). But then it's not TOO weird...