(sorry for my pour english)
in the past, we assested to many way for conduct a 6502 based machine.
starting from a simple asm monitor like in the kim, proceding with languages like basic or forth, and than with something like a dos.

in our days, the role of a cli is secondary (but powershell...brrrr!) because we use a gui (also in linux bash is loosing positions)

what i'm asking to myself, and maybe someone is interested, if in our days is it possible to project a good environment for to drive a 6502 o.s. without reinventing the wheel or copying a pre-existent solution.

because there must be a way for inputing orders, we need a kind of language.
it's nice that this language can be more complex that few directive, like in c64 dos drive or apple prodos.
rexx, like in amiga, or bash as in linux are complex languages, maybe too complex for a 6502 project, where the use of memory must be conservative.

i found in the 6502.org site some good example of o.s. and my post is only for explore all direction.

any ideas?

Unfortunately, the quality of the English will make understanding somewhat difficult. Please bear with us if we don't seem to understand.



I encourage you to reconsider this position. The GUI has not dominated the CLI for even moderately advanced users. This includes on MacOS X installations. A cursory search of MacOS X tips shows a plethora of blog articles detailing the usage of the CLI.

Also, remember too that not all CLIs are the same. Much of the CLI syntax used in Windows and Unix systems are arcane, optimized for rapid writing of one-off scripts by system administrators under heavy pressure from technical support and senior management, but not for user comprehension at all.

Contrast this with Tripos (and, by extension, AmigaDOS), where command names use real, honest-to-goodness words, and have real, honest-to-goodness parsers to interpret command-line options.



Here is where my understanding breaks down. I really don't know what you're asking here.

Here's my attempt to guess based on context: as far as I can tell, you are asking if it's possible to evolve from a CLI-based environment to a GUI-based environment without discarding old software?

The answer is yes -- there are three ways to accomplish this that I know of:

* Rewrite the CLI so that it, itself, is a GUI application. This is the approach that AmigaOS took, and with stellar results (refer to the Amiga ROM Kernel manual, Libraries and Devices, and read up on the "console.device" component).

* Write your CLI commands so that their business logic sits in a shared library. That way, the CLI 'command' is just a program that links against the library, parses CLI options, and then passes all the dirty work off to the library. Then, the GUI version of the same program does the same thing -- presenting a window or dialog box with the relevant options, then passing everything off to the library to do the dirty work.

* Write your CLI commands so that its input and output are concurrently machine- and human-readable. Many Linux tools are written this way. Numerous CD-burners, for example, don't actually touch the SCSI interface at all -- they launch a program called "cdrecord", which is a command-line tool whose output is (more-or-less) easily intercepted by another program and translated into a GUI display in real-time.

Indeed, the jump from CLI to GUI is actually somewhat small as long as good user interface guidelines are supported for both the GUI and the CLI application environments. Jumping from a single-tasking to a multi-tasking operating system, however, is a substantially more disruptive change.

With all this being said, however, be aware that you're making a change for a reason: it's foolish not to write software which exploits the new features you've worked so hard to make possible.



Not necessarily, IF you're willing to precompile your scripts first. This is the approach that Python takes:

Step 1. When launching your script's interpreter, check to see if it needs to be recompiled into bytecode first. If so, perform the compilation.

Step 2. Then, just interpret the bytecode.

The pre-compilation step is totally transparent to the user, except for the length of time it might take (particularly on slower CPUs or I/O subsystems).

Did you find anything in particular unsatisfactory before?

If you want BASIC, Lee's EhBASIC looks outstanding, far better than other 6502 BASICs I've seen.

I believe André Fachat has written a Pascal compiler for 6502. I can't say I know anything about it.

Forth works very well on 6502 and even much more so on the 65816, and is extremely memory-efficient. The performance is good for a higher-level language, and if that's still not enough, it allows you to quickly write short, speed-critical portions in assembly. It really has the ultimate in extensibility. It had the tools to do object-oriented programming long before it was called that. Its interactiveness is better than any other language I know of. It easily does multitasking even on a 6502. You can service interrupts in high-level Forth without overhead. Development is extremely fast and results in fewer bugs. The original Forth implementations were were stand-alone systems that included functions normally performed by separate OSs, editors, compilers, assemblers, debuggers, and other utilities; and although now it's common for it to be run on top of a separate OS, you can still do as many or as few of these functions as you want in your 6502 computer.

The biggest problem with it I suppose is lack of commercial support, since anyone can get under the hood and easily extend the compiler, especially for a processor as simple as the 6502, and there aren't any black boxes in Forth. A software vendor can't say, "You need our latest version because it will do this and that," because you will just respond, "Good idea!" and go implement it quickly yourself on your own Forth, and not buy anything from him. As a result, the 6502/816 Forths floating around tend to be ones that are developed by individuals for their own use and may not be organized in a way that is clear for someone new to pick it up and run with it. If I were selling hardware, I would definitely put my Forth on it so you would have something running immediately. It would be extremely well documented, and basically Forth-83 with a ton of extensions, many from ANS Forth and common usage.

When I was first getting into Forth in 1990, I liked it but had my reservations, thinking there were various things that it couldn't do well, or even at all. As I gained experience with it, I began to see that it was not only able, but afforded very, very elegant solutions that did not initially meet the eye. Managers sometimes don't like it because it gives the programmer complete freedom, which interestingly tends to make good programmers better, and make bad ones worse.

Wally Daniels (on this forum) typed the Fig-Forth source code into his computer and got it working, and made it available on this website. It's a pretty basic one though. I've been wanting to make my own much more complete 6502 Forth available to everyone, but it will take time to do so. Wally Daniels is also using my 65816 Forth and actually has more experience with it than I do. The source code files for that one could stand some clean-up too, to make it suitable for wider distribution.

Edit: I see Samuel posted while I was writing. It took me awhile to realize what "CLI" stood for, which I now assume is "command-line interface" which is sometimes preferable. I guess I didn't realize (or remember) you weren't a native English speaker before this. Keep trying. What other languages do you speak?

While I think a well-equipped Forth environment would make an excellent single-language operating system environment, I don't think it'd serve well for anyone except relative experts. The methods of achieving productivity in Forth prove so foreign to everyone who has even a remote level of experience with typical computer usage that they'd be totally at a loss to figure out even the most basic of operations in Forth. Thankfully, Forth is learnable, and can be managed by mere mortals once they get out of the gutter that is filesystem-based, multi-language operating systems. However, this requires nothing less than the total retooling of the user's mindset.

Most of the features you list in Forth's favor require a degree of excellence in software engineering that your average computer user just isn't going to have. How many people can properly manage block storage on their own? If they want to write new software, will they just wing it, or write proper modules (in the Parnas and Wirth definition of the term) implementing proper ADTs that manage their persistence transparently? Do these people even know what an ADT is? I won't even begin to get into RAM management!

How many people are going to get that the module that they've just written can be re-used in other applications? That people don't write applications in Forth, but rather modules? That an "application" is nothing more than an active driver for otherwise passive modules? That they don't have to manage multiple chunks of block storage per module just because there exists multiple applications installed (a single, large, contiguous region of disk space can suffice for every application you have)? Will they know the reasons why? (The answer: if the module is written so as to store its state in an ISAM or similar database structure, each row in the ADT's table will have a primary key which identifies it uniquely amongst all the others. Each relevant application can query this table for its table using the ADT's set of words. RAM buffers are used for caching to increase performance, although the BLOCK system implements its own caching logic which works very well for most code.)

As you can see, this covers primarily just block storage. There also are common problems with RAM management in Forth too.

I should point out that these alleged "problems" are also features -- like all tools, strengths and weaknesses are one. I personally prefer Forth precisely because of many of these features/problems. However, I'm also a software engineer who has experience with assembly language, AmigaVision, BASIC, C/C++, J, K, Lisp, MODULA-2, Oberon, Rexx, Smalltalk, Scheme, TCL, and more I've since forgotten.

I'm not attempting to dissuade people from learning Forth. I'm simply stating that, due to the horrible state of software engineering documentation with specific reference to Forth, most folks will find the platform opaque (despite its transparency!), hard to use (despite its simplicity!), extremely error-prone (well, yeah, I feel you on that one), and positively user-hostile.

thank you all for your posts.

i retry to explain my thoughts, but:
1) i like cli, in my job i maintain big unix servers
2) i've no problem with modern gui based or not system

i'm trying to image a new system, that isn't not like our beloved ancient micro-something, where the operator can drive all the environment using a very small footprint rom.
my first instinct is to use a well know (and already implemented) language like basic or forth, but this kind of approach in my opinion is not winning because it doesnt gain nothing from the last 30 years of computer history.

it's only a 'let me produce a new simon basic and play a bit'

so, why dont use a unix-like system, with a bash that is itself a language?
ok, that's good and in some way actual, but is it possible to put it in a few kb rom?
maybe and maybe be not: maybe the result is only a pour subset in an heavy rom.

i think that the solution is more complex approach, something that can learn from the embedded world.
for example: the cisco ios (that is quite heavy, yes, but it's only an example) is a declarative language that resolve that specific problem.
also, if i remember well, it exist a specific language for telephony switch.

these are only examples!

i like forth very much (i'm "working" on the 6502 figforth and maybe this weekend i'll post a revive lib6502 version) and maybe can be a kind of solutions (but...mmmhh), let me try:



i prefer a object oriented system, but is it possible to code in few kb?
i'm looking for a native 6502 language, so not a crossdevel system.

i hope that this post is more clear, thank you for your patience.

Well, Bash is a language, just like BASIC.

You can grant BASIC shell-like capability using a special command syntax. The Acorn series of computers did this; any BASIC input line which started with an asterisk (*) was, in effect, a DOS shell command -- an escape to the system program loader.

I don't know if you could redirect program output to BASIC strings or not. Acorn documentation is infamously sparse on the Internet. If you could, that would make for a _really_ powerful combination.

I do know that SwiftForth for Windows and Linux use "$" instead of "*" for shelling out. For example:

I seem to recall that SwiftForth also let you capture command output, but I've never needed to do this in the past, so I cannot confirm my recollection based on experience.



Not really; much of the program bulk of Bash is its parser and process control functionality. Any language (be it a scripting, general purpose programming, or otherwise) will need some kind of lexer at the least (e.g., Forth), or both a lexer AND parser (e.g., BASIC, Pascal, C). If you can minimize these, the rest will probably fit into place on its own.



Keep in mind that "embedded" to Cisco means any PC board equipped with a 60MHz or faster PowerPC RISC processor equipped with tens of megabytes of RAM or more, and with an OS that sits inside megabyte-sized flash ROMs.

That being said, the IOS interface reminds me greatly of the old Citadel BBS interfaces. In both IOS and Citadel cases, the entire command-set of the UI is best defined as a hierarchy of menus. This is why both systems have such excellent help facilities built-in -- they both automatically generate their help output from the compiled-in menu structures.

Also, a recent telecom switch from GE uses Forth, not IOS, as its configuration interface. ;D



It's possible to write object oriented software in any language that you have access to function pointers in. Case in point, much of PC/GEOS is written in object oriented assembly language (most applications are written in an OO style of C). Combined, all of GEOS fits in something like 6 to 8MB of harddrive space, unpacked and fully installed. This includes a full-on GUI, a suite of productivity applications which rivals contemporary office products, a handful of (frankly, boring) games, and Internet access tools.