What about it?



So have I, and that's precisely why I never want to see it again. I strongly value modular languages over the relative unstructuredness of BASIC. BUT, if that's what people want on their systems, then a good quality, structured BASIC can be written for it, though editing the program will be tedius with line numbers and it would otherwise run rather slow.



SHELL isn't needed if BASIC is also the shell. It's served by LOAD and RUN. Some BASICs do have a command called "CHAIN" which combines those two. I otherwise see absolutely nothing to be ashamed of with these commands. Commodore's version 4.0, 7.0, and 10.0 implementations of BASIC (found on PETs and on the 128) all had commands very similar to these. The Commodore 128 even had an auto-boot feature that would automatically boot a disk upon system reset/power-up, much like most "DOSes" have today.



No, I disagree. There are certain basic operations that you can do to a file, as an object. It pretty much boils down to a factoring between directory operations, and file operations. Directory operations involves things like COPY, KILL, LOCK, etc. because they affect files (and even sub-directories if supported) globally. Other, per-file, operations are your traditional OPEN, CLOSE, READ/WRITE, etc. After all, what really is a directory? It's a container for "things." It neither knows nor cares what those things actually are -- they could be files, OR they could be other directories. In the case of a Unix filesystem, they could also hold references to device drivers, sockets, pipes, and more.

It's best to separate the functionality of the "file" from the functionality of the "directory." A good, object-oriented analysis can yield a nice, clean, orthogonal system interface with plenty of room to grow in the future. Otherwise, you'll end up with ad hoc solutions to problems that are really non-problems. In the end, you end up with bandaid on top of bandaid on top of bandaid, and consuming more memory and resources than if a proper analysis has been performed at the start.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

What about something with a built-in text editor, like QBasic?

What about running a binary program? Sure, there's BRUN, but it might be nice to run it with parameters.

I think you have a point there...

Most of the BASICs I've used have had built-in text editors. The Commodore 64 has a built-in full-screen editor that is marginally useful, but not nearly as feature complete as I'd like. Considering that it fits in 12K of ROM space along with the BASIC interpretter itself, this can be forgiven.

The next BASIC I've used was AmigaBASIC, written by Microsoft. BTW, AmigaBASIC is the great ancestor of VisualBASIC and all subsequent versions of Microsoft BASICs after 1987. It was the first to introduce relatively high level of structure, but it didn't offer user-defined types, nor did it offer any form of encapsulation at all.

Next came AtariST BASIC. I won't go there. That was a definite step backwards. It was so bad, that a commercial replacement called GFA-BASIC was released that was light-years more advanced than anything even Microsoft had produced. However, I've never used it, so I can't comment.

Then I used VisualBASIC under Windows. At first, this environment proved to be quite ... disgusting. It was slow, it was buggy, it was often times more trouble than it was worth. Over time, of course, it got a lot better. Currently, VB is rather useful, including SOME capabilities of object oriented programming languages (specifically, the most often used ones), a whole lot more structure to it than AmigaBASIC ever had, a really ugly syntax for user-defined types (but at least it supports it), etc.

Still, despite this evolution, I would spend the time instead with Oberon instead of BASIC. Oberon is a language created by Niklaus Wirth (and thus, inherits many traits from Pascal and Modula-2), designed specifically to be clean, simple, elegant, and relatively efficient. It was built specifically to compete squarely with C and C++ in the systems programming arena. Yet, it's syntax is simple and general enough to be useful for all kinds of applications development. Its dynamic module loading and compiling features blurs the distinction of loading and running an application. It's one-pass compiler is blindingly fast. Not as fast as Forth's, but it is definitely so fast that there's virtually no need to store intermediate object files when running a program. And it's a *VERY* strongly typed language (if you thought Pascal was strongly typed, you ain't seen nuthin' yet!).

The syntax of Oberon is sufficiently close to Python and BASIC that if you know one, you'll be very much at home with the others.



You're right, I'd completely forgotten about this.



While I have a point, I admit that I veered somewhat off topic. That being said, let me additionally say that Oberon-1's type system is structured enough to allow this kind of factoring in the code. Oberon-2's is even better, supporting what it calls "Type Bound Procedures," which is a mathematically correct term for what C++ calls "Virtual Functions."

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

It's possible to do with BASIC as well, but you'd have to update the parser's token table to reference the new command. It would also be relatively unnatural too -- suppose the new program is best expressed as a function, for example...

EhBASIC uses a neat-o CALL mechanism that works reasonably well enough for this type of expansion, but again, it's not seamless.



Yes it does. In fact, that's all it has. Like Forth, it represents TRUE with all bits set, and FALSE with all bits clear.

Otherwise, statements like POKE 1, PEEK(1) OR 32 wouldn't work.



And the only way to do that is to use a simple, consistent, orthogonal, and well documented interface specification.

My $0.02

1) I think the computer would be a great idea - I still use my old Apple comps (I have a rather large collection, long story). I still like the idea of a certain level of control and simplicity.

2) I like the idea of putting a bunch into ROM to make life easier - at least a CLI, basic interpreter and assembler entry (similar to what the Apple had for programming - for those that don't know - apple actually did have a small assembler hard coded in rom - I don't remember where it was in ROM off hand any more, but I do still have my assembly programming books that have the call ##:)

3) Modular would be nice - I'd love it if it could be where things like the video adapter would be a seperate card - I don't mind assigned slots, but this way if someone wanted to build their own seperate type of video card (RGB, composite, VGA, whatever) it would be possible - as long as they have similar interfacing for basic text output - advanced stuff could be handled custom.

4) Easy to obtain chips

just my humble thoughts

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I'm in need of a job, badly. How many people would be interested in purchasing a kit if I were to design a simple 65C816-based PC or SBC with documentation? What target price range would you expect to pay for such a kit? If you wouldn't purchase a kit, would you purchase a pre-built unit? If so, for how much?

I'm just doing some minor research into some possibilities at the present time. Thanks for your time.

Want to make some suggestions then? I'm always open to ideas from users (or potential users).

Either e-mail me directly or post in the EhBASIC forum.

Go on, you know you want to. 8^)=

Lee.

NOTE -- copied to EhBASIC forum as well, since it does have relavence there as well.

Not particularly; the suggestions I'd make would make the language much less portable, since the language would then subsume the role of a command shell as well. It's best to let a more seamless system interface be part of the user's specific installation/port of EhBASIC. This way, EhBASIC is still appealing to those who wish to run a traditional CP/M-type or Unix-type shell environment.

It would involve, for example, creating two new types of variables: command references and function references. A command variable is invoked in a manner similar to PRINT, while a function variable is invoked similarly to USR(). The code to which they point to cannot be changed by normal BASIC functionality; instead, new operators must be added to ensure type agreement and extraction (e.g., myCmd = CMDPTR(49152) sets myCmd to point to $C000. Now you can say myCmd a,b,c or whatever. Saying myCmd = 49152 would either give an error, or change the type of myCmd to integer -- not something you want to have happen. To print the current address of myCmd, you'd need something like PRINT CMDADR(myCmd) or some such. For functions, it'd be like: myFunc = FNPTR(49152):z = myFunc(a,b,c):PRINT FNADR(myFunc)).

Then it would involve making use of the aforementioned system, internally, to implement the command syntax. If a command would normally produce a syntax error because it wasn't found as an intrinsic of the language (or a pre-existing command variable), the BASIC would have to scan the command-path of the interpretter on disk to find the command with the appropriate name. If found, it'd have to load it into memory, and assign a command variable to point to it automatically. Then it'd invoke the command using the normal command variable conventions. The same would be true for functions as well.

I don't think people would want to wait for the interpretter to get through scanning the disk every time an unrecognized command appeared (particularly annoying on machines with only a single floppy disk drive).

As you can see, this is a non-trivial change, and while it is quite possible to do (and is perhaps even useful for systems equipped with fast secondary storage; a harddrive or flash ROM access on a syntax error wouldn't be nearly as bad as a floppy access), I'm not sure I'd want this to be part of your core EhBASIC system.

How about a command like "AUTOSHELL ON" or "AUTOSHELL OFF" and then allow manual execution of external commands by a "SHELL" command (BASICA 2 style) ? :þ

That would work, I suppose.

BTW, moving this specific discussion (re: EhBASIC) to the EhBASIC forum.

OK, here's my £0.02-worth...

It appears diferent people want different things from this computer. Some want a 65(C)02-based system, some want a 65(C)816 system. Some want "traditional" I/O - serial, parallel, FDD, IDE - whilst some want "newer" I/O - IrDA, USB, Flash ROM-stuff. Some want some-variant-of-BASIC, some C, some FORTH, some Oberon, you name it _somebody_ wants it.

There's always _one_ way to do it - anyone know of/remember the Microtan?

The basic module could be designed as a potential SBC - a single 160-by-100mm Eurocard-sized PCB, with 65(C)02 CPU, clock & reset circuitry, along with space/sockets for (say) 8KB EPROM, 8KB SRAM, 6522 and 6850, along with connectors - some sort of connector for the 6522 I/O, and a 9 or 25 connector for a serial port.

These latter components could all be optional; instead of the onboard EPROM/SRAM/VIA/ACIA, set a link/jumper differently, and this onboard stuff is disabled, with all the 6502 lines going via an (optional) Eurocard connector. The board could then be plugged into a suitable expansion cage, to which could be added a "support" board (address decoding, some I/O, OS/boot EPROM), RAM board, ROM board (for BASIC, C, FORTH, ...), I/O board (serial/parallel/FDD/IDE or IrDA/USB/Flash ROM).

Also, if someone wants a 65(C)816 CPU, such a board could be designed - if people are familiar with the Acorn/BBC Micro, these machines have a port on them marked "Tube" - this port allowed for a CPU board to be connected to the BBC Micro; the BBC Micro would then handle the I/O-end of things - keyboard, screen, floppies - whilst the extra CPU would handle the user's programs. Acorn ended up producing a (fast) 6502 unit, a Z80 unit (for CP/M), a NS32016 unit, and (for the BBC Master only), an 80186 unit (for DOS+).

As long as there's some sort of agreed standards (memory maps, ROM-content-format, Eurocard connector pinouts, etc.), different boards could be designed for different purposes and uploaded to 6502.org, leaving people to choose which bits they actually want.

Any good?

--Martin

_________________
Martin Penny

.sig in beta - full release to follow.

Hmm. Re-reading some of the earlier articles shows I was beaten to the general idea, but my suggestion still stands.

(Drat - should read things more carefully before opening my mouth...)

--Martin

_________________
Martin Penny

.sig in beta - full release to follow.