Survey: A 65C02-based PC

[kc5tja]

usotsuki wrote:

Then again, look at DOS 3.3/ProDOS.

What about it?

Quote:

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

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.

Quote:

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

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.

Quote:

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...

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.

[GARTHWILSON]

Quote:

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.

That's good to hear!

Quote:

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?

Absolutely.  I think they lie awake at night trying to devise ways to make their software less and less efficient and more and more frustrating.  Forth, OTOH, makes extremely thrifty use of memory, using sometimes as little as 8K or 12K for the interpreter, compiler, assembler, editor, zero-overhead Forth interrupt service, and the rest of the kernel, still allowing you total freedom to make your own structures, operators, data types, defining words, etc., unlike BASIC or even C.  It's a very becoming OS, programming environment, and language for the 6502 with its 256-byte native stack and its many indexed and indirect ZP addressing modes.

As much as I have come to favor Forth however, I will not say "This is it."  I don't think it's necessary to commit to one OS for this computer, and I think others should be allowed to use whatever OS they want, or even no OS at all.

The issue of EPROMs and their speed limitations has been raised, along with the idea to boot at a slower clock speed from EPROM and copy its contents to RAM before paging it out and kicking the clock speed up.  This also does away with the old how-much-ROM-versus-how-much-RAM conflict, and since even the interrupt vectors will be in RAM, it lets your program change those on the fly and eliminate a level of indirection depending on what possible interrupt sources are set up.

But another way to do it, affording yet another advantage, is to have the OS get loaded into RAM from a sub-postage-stamp-sized serial EEPROM module plugged into a 4-conductor connector at the edge of the board.  [Edit, 14 years later: See the I2C-6 I²C connector standard, and the SPI-10 SPI connector standard, both hobbyist-friendly, for tiny modules.]  32Kx8 24256 EEPROMs in 8-pin DIP have been available for a few years.  There's also a 64Kx8 24512 in 8-pin DIP, although I haven't seen them yet in distributor catalogs used by hobbyists.  (Atmel has an 8Mx8 serial Flash but it's in SMT only, much bigger than an 8-pin DIP, and it's about $40.)  [Edit, many years later:  This will of course keep advancing; but the 26VF064 offers 8Mx8 flash in an SO-8 package for $2-$3.]  [Edit, 7/28/22:  I now offer a tiny I2C-6 EEPROM module on the front page of my site.  There's a link to the data sheet there.]

The loading takes place before the processor is let out of RST or its BE (bus enable) pin is brought true.  These serial EEPROMs are easy for the user to program, don't need any special programming voltages, and they keep their data for something like 100 years.  OTOH, UV EPROMs, even in the dark, can lose it in as little as 10 years.  They're also not practical to change for different applications.  You could have different modules for BASIC, Forth, Oberon, or just BIOS—whatever you like.  There's no need to argue over what ROM-resident OS will be onboard.  If the module just has a BIOS, it might load the OS from a disc or other medium.

If the CPU board is in something like a card cage, having the tiny serial EEPROM module plug into the front of the board means you can change it without pulling board out of the cage.  You can also change it without powering down the whole computer.  The computer will just bring the clock and data lines low and cut the power to it when it's done reading it.  An LED at the connector tells when the power is down and it's safe to plug in or unplug the module.  In a card cage, space at the front edge is in high demand for various connectors, LED annunciators, etc., and this tiny EEPROM module takes very little of that space.  I'll be sending Mike some pictures of my projects to post soon and you can see the simplicity and small size of this module.  [Edit, many years later:  You can see this tiny EEPROM module on the front page of my site.]

Garth

[usotsuki]

kc5tja wrote:

Quote:

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

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.

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

kc5tja wrote:

Quote:

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

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.

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

kc5tja wrote:

Quote:

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...

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.

I think you have a point there...

[kc5tja]

usotsuki wrote:

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

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.

Quote:

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

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

Quote:

Quote:

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.

I think you have a point there...

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."

[GARTHWILSON]

Quote:

Quote:

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

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

It's no problem in Forth—in fact, your binary naturally becomes part of the language itself.  How I've wished BASIC could do this, complete with all the parameter-passing and so on, even error-checking if applicable!  Some BASICs can be expanded by the user using assembly language to add statements, functions, and operators, but it's not easy.  C64 BASIC doesn't even have functions to do a bit-by-bit OR or AND on two input numbers to give one output number.  [Edit: Corrected below.]  In Forth it would only take a minute to add them; but on the C64 this was a big pain when I was trying to show our then-13-year-old son how to do some model railroad control functions using an I/O expansion board I made for him.

The key to making a flexible computer that will meet many people's needs does not lie in trying to make it do everything, because we won't be able to anticipate everything.  The key is in making it such that the user holds the keys to expanding it into all the fields we never dreamed of.

Garth

[kc5tja]

GARTHWILSON wrote:

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

It's no problem in Forth-- in fact, your binary naturally becomes part of the language itself.

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.

Quote:

C64 BASIC doesn't even have functions to do a bit-by-bit OR or AND on two input numbers to give one output number.

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.

Quote:

The key is in making it such that the user holds the keys to expanding it into all the fields we never dreamed of.

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

[Tancor]

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

[GARTHWILSON]

Quote:

Quote:

C64 BASIC doesn't even have functions to do a bit-by-bit OR or AND on two input numbers to give one output number.

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.

You're right.  Darn.  I wasn't looking in the right manual.  This other one made it look like it was only for true/false logic, such that 00010000B OR 00000001B would yield "true" (all bits set), because at least one input number was non-zero.  I was wondering how they could have omitted something so basic as a bitwise OR.  I guess I better go try it now.

In any case, my point was that trying to anticipate every need in the design process is not enough.  The user must be given the tools to do his own expansion.  And although Forth fits the bill so well for the programming end and I like my Forth with a gillion already-resident features, I'm still not sure it would be right to tell everyone they must have Forth (or Lee's really nice EhBASIC, or any other given language or OS for that matter) in the computer, with no choice from one use to the next.

Quote:

2) I like the idea of putting a bunch into ROM to make life easier

I favor making the ROM to be in something like one of the tiny modules I described using an 8-pin serial EEPROM DIP that can be changed from the front as easily as a floppy in a disc drive—much easier than opening the case to change 28-pin EPROMs even if they're in ZIF sockets.

Quote:

3) Modular would be nice - I'd love it if it could be where things like the video adapter would be a separate card - I don't mind assigned slots, but this way if...

Not only modular, but I would favor a passive backplane.  Some of us will want the physical portability to take just the CPU board with some I/O into some embedded application and want it to work without the extra space required for a disc drive, or even a PCMCIA card for that matter.  I would encourage a mechanical form factor that is an established standard that won't go away quickly like the here-today-gone-tomorrow stuff we see in the fast-moving PC market.  Established industrial standards should qualify.  VME bus and STD-32 aren't going anywhere for a long time.  (STD, by the way, stands for "simple-to-design", not "standard".)  We don't have to stick to their electrical and timing specs, only take advantage of the fact that prototyping boards and connectors will still be available for decades.  A 3U VME bus card is 100mm wide and usually 160mm long, and has 96 pins on its connector.  STD is just slightly bigger.  STD80 (the original 8-bit STD standard) has 56 contacts on the board-edge connector (not really enough for my ideas) and STD32 (the compatible 32-bit STD standard) has twice as many in the same space.  Using one of these would allow the main CPU board to be put in a card cage, or in a desktop computer case, or even in a small case that can be tossed into the attache case, the latter having just a small LCD and keypad for user interface.  The board can be put into embedded applications as well.  The 96 pins of the connector used by VME bus are in three rows of 32, and it all fits into holes in a standard .1" grid, both for the board and for the backplane—nice for wire-wrapping on the same boards that accept IC sockets.  If everyone finds the 3-row connectors used by VME to be too expensive, the same idea could be carried out with dual-row right-angle pin headers and sockets that are dirt cheap.  That would still give at least 64 pins—maybe enough (just barely).  There are smaller, cuter board form factors like Vector's C64 expansion boards with the 44-contact board-edge connector, but I think they'd be too limiting; and not being established industrial standards, they're already getting hard to find.

In the past, many on the forums have wanted to have the microprocessor bus itself be brought out to and edge connector for other boards to be connected to it.  This really puts a lid on maximum operating speed for several reasons.  Putting a lot of things on the bus will present a lot of capacitive bus loading.  The arrangement also generally requires that everything out on other boards connected into the same buses be able to run as fast as you want the processor.  Then you also have to take into account transmission-line effects and excessive inductive reactances that crop up with fast rise and fall times on connections that are more than a few inches long.  In the 1MHz days of the Apple II, you could get away with a huge circuit board with more huge boards plugged into it, with the processor's own address and data buses, phase 2, R/W\, etc, going everywhere.  Not anymore, unless you still want to use 1MHz parts.  Keep the processor's own bus confined to a small area, and make the ad-infinitum expansion happen through I/O ports, like VIAs.  This kind of board can be made to work with future higher speeds.  Who knows— Instead of being limited to 16 or 20MHz, maybe WDC's next manufacturing run will be good for 32MHz+ (although I'm sure it would have to be in PLCC or QFP, since I'm sure there's no way to get the DIPs to work that fast, at least until they re-arrange the pinout and put a couple of pairs of power and ground pins in the middle).  Maybe we'll be using 6ns memories by then.

Quote:

4) Easy-to-obtain chips

Absolutely, and long-time stability will be important for a project like this.  A few things look like they'll be around for decades more, like 5V 74HCxx logic.  In spite of all the new low-voltage stuff on the market for cell phones and pagers, 5V is not going away, and in fact a lot of the newer low-voltage products are specifically being designed today to be able to interface to 5V logic if the need arises.  WDC's parts are spec'ed down to  1.2V, but the highest speed comes at the 5V they're primarily designed for.

This would be a computer that hobbyists will be wanting to do their own work on, whether assembly, modification, repair after an experiment goes terribly wrong, or whatever, and much of the parts list will probably always be available in thru-hole parts (not just surface-mount).

Garth

[kc5tja]

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.

[leeeeee]

kc5tja wrote:

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

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.

[kc5tja]

leeeeee wrote:

kc5tja wrote:

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

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

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.

[usotsuki]

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) ? :þ

[kc5tja]

usotsuki wrote:

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.

[mdpenny]

kc5tja wrote:

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.

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

[mdpenny]

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