Survey: A 65C02-based PC

[kc5tja]

GARTHWILSON wrote:

> The programmer's text editor I use a lot offers hot keys and F keys, mouse menus, and tool bars.

But when you need to do something with the editor, you always do it the same way, every time. That's the point.

Quote:

I always keep the tool bars turned off. It also offes infinite combinations of windowing and tiling, repositioning and resizing.

How often do you actually use this though? By the sounds of your response, not very often. Yeah, it can do it, but is it useful to you? If so, how useful?

I used to be all for windowing interfaces. I currently find them a hinderance of the highest order. Newbies do too; just watch anyone trying to learn how to use MacOS or Windows for the first time.

Quote:

My PC-board CAD does not offer the tool bars, which is fine with me. Neither one has the dumb little pictures (icons) that are meaningless without text below them to tell you what they are.

I'll agree that icons have been violently abused over the years; however, "dumb little pictures" can come in handy when used appropriately, and they don't even need descriptive text underneath them.

Quote:

Discussing my endless Windoze frustrations here might be off-topic. My point for any designers of 65K hardware or OS would be to encourage the objectives I've mentioned earlier, to avoid putting the user in a cage, regardless of how cute or flowery the cage is.

Read Jef Raskin's book, "The Humane Interface." You'll come to realize that the inventor of the MacOS GUI itself is spot on in his assessment that GUIs today (including MacOS') are not the simple, user-friendly environments they used to be. He acknowledges that the WIMP concept was right in the short-term, but wrong in the long-term, because it does not foster habituation (or worse, development of bad habits), and programs which have a whole multitude of ways to accomplish goal X is demonstrably harder for new users to grok. He offers solutions that new UIs should implement, whether textual OR graphical.

To bring this discussion somewhat back on topic, consider the whole idea of user configurability. It sounds really nice to be able to arrange your settings according to your preferences. Screen colors, text fonts, etc. are all candidates for configuration. But that peachy-keen, homey feeling you get from user configuration very quickly disappears as soon as you get a number of technical support phone calls. I've been on the receiving end of technical support phone calls when I worked for two ISPs. While our software wasn't configurable (it was Dial-Up Networking -- not much you can do for that), the fact that each user had a different desktop arrangement, different color settings, etc. all made technical support a minimum of twice as difficult (and thus, expensive for us). "Double click on My Computer, then go to Dial-Up Networking." "What do you mean by My Computer?" "You should have an icon on your desktop that looks like a computer, and reads `My Computer' underneath it." "No, I don't have that." "Sir? Are you sure? All Windows installations comes with it." "Nope. Don't have it." (Turns out this user was using an alternative shell which didn't use the normal desktop icon system, and so, nothing was standard from a technical support point of view. This person literally had to bring his computer in before we knew what the heck was going on.) Even users who DO have the stock Windows 95 desktop would very often rename My Computer, Network Neighborhood, or Dial-Up Networking to something "Cute"(tm) because they thought ... well, it was cute. Well, imagine my frustration when I found out that one of our customer's My Computer was renamed to "Fido's Home" (I'm not kidding), because she named the computer after her dog. It only took three tech support phone calls from her to remember that she renamed it.

The 65-based PC must, in my opinion, take these things into consideration. One of the overwhelming reasons for the popularity of both the Apple-II and the Commodore 64 was its sheer simplicity. Plug it in, turn it on, and go. No fussing about with DIP switches, no fussing about with plug-in cards, no fussing about with anything. People even put up with the abysmal speeds of Commodore's serial peripheral bus because it was so utterly convenient, even despite the wide availability of IEEE-488 interfaces available for the 64 and cheap mods for the 1541 and 1571 drives.

I'm not saying that you should close off the whole system architecture of the PC, for fear that the user will somehow manage to end the world as we know it. But I am saying that we need more integration than even today's "integrated" PCs offer. Integrated, sane video hardware (VGA just doesn't cut it, sorry), sane audio interfaces with reasonable capability (must our audio cards really support studio-grade DSP? We got along fine for decades without it!), sane I/O and auto-configuration systems, etc. These things can all be included lock, stock, and barrel without sacrificing the ability to add peripherals. It also establishes the minimum baseline system, and helps ensure a completely usable system right out of the box. The PC, to this day, still can't make this claim, since you always have to populate it with some compatible video card (not all cards are compatible with Linux or BSD, for example, and even Windows drivers can get horrifically confused with the wide array of seemingly compatible hardware out there now). Audio compatibility is still a major issue. I have a SoundBlaster Live! in my box, and my roommate has a SoundBlaster Audigy with all the bells and whistles. You'd think that we can run similar drivers, but the answer to that is a resounding no. I have a digital camera that uses USB, along with an 802.11b network that also uses USB. I have to have two UHCI drivers installed in my Linux system because one doesn't like to talk with the 802.11b driver. Yet, ironically, the two UHCI drivers seem to live perfectly fine with each other. Go figure.

In short, I'm sick of the headaches of modern PC environments. I spend no less than an hour and a half, all total, per day, just managing the computer, and not producing useful, productive work. That's anywhere between 12.5% to 33% of my computer use schedule, depending on the circumstances. 1% I can see, 5% is maybe tolerable. 12.5% is inexcusable. When my network goes down, that figure increases. When I have to reconfigure my audio settings because one program won't work with 16-bit sound, and another program will not work with 8-bit sound, that figure increases. It's annoying. Damn annoying. Infuriating, in fact.

If this 65-based PC is actually produced, it must ensure that these frustrations don't happen. Otherwise, it's just another non-x96 PC wanna-be. Consider: all non-x86 PCs out there (even modern Macs) all use AT or ATX-motherboards and chipsets. There's something wrong with this picture...

[esarintulo]

Hi Daryl,
with what everyone wants to see on your (his/her) "SBC" (that stands for Single-or is it Simple- Board Computer,right ?) you will end with what we call in French "une usine à gaz" (gas-works) !!!
It seems to me that the real power behind such a board would be the "intelligence" put on it and that everyone should be able to choose the kind of "intelligence" he/she wants.
So my suggestion would be to come with a bus FIRST (the ASK family's one was not that bad), supported by some kind of universal (and cheap,and easy to find) connectors : the Din 41612 2*32 pins seems a good candidate (can be extended to 96 pins - 3*32 if necessary).The obvious choice for the board would then be the 160 by 100 mm so called EuropaBoard as protoboards are very easy to find.
I would like to find on that board,beside the 65816,supports for 28 pins Eproms (or eeroms or flashroms or ....) and supports for 28pins Srams with decoding as versatile as possible.6551, along with some 6522/6532/6526, is a must too so any DOS or Windoze terminal could be used.A minimal monitor permitting RS232 link,bytes and bits manipulation,file transfer, is also mandatory.
With all that ,everyone would be able to focus on the "intelligence" he /she wants to bring on board (and start programming ...) and think of and build all those marvellous boards he/she would see hooked on the bus.
Yes,the Microtan is a good example of what could be done : on a clear bus,one can expand forever.......
Have fun.I will,anyhow....

René.

[8BIT]

Thanks Rene, and to all of you who have responded.

It is clear that we all have our own ideas on what would be the perfect computer.

For me, I would include a 65816 and a 16550 serial UART (or a dual UART) for faster serial speeds and some kind of simple boot hardware to allow an OS (user selectable) to be loaded into RAM. Yes, I want the entire memory map to be RAM, to allow the processor to run a full speed after the bootup sequence.

From there, I'd have an expansion bus capable of addressing the full memory map, with I/O decoding and interrupt handling for the I/O hardware.

From there, each user could add what he/she wants in terms of I/O devices and software.

For I/O, I would want to work on video, keyboard, sound, permanent data storage, and standard I/O interfaces such as serial, parallel, USB, Ethernet, IDE, PCMCIA, etc.

Now, I just have to find the time, money, and more time to make it all come true.......

Daryl

[dilettante]

Hi, Johnny-come-lately here,

Wow, and I thought the religious wars would be over whether the machine ought to be CBMish or Appleish!

Here are my two cents worth.

I think I'd prefer to see some sort of basic reference design for a modern "core" 65xx circuit. Along with this could be another reference design for the important basic higher-level I/O section (video, hard drive I/O, USB, Ethernet, what have you).

The SBC crowd could simply implement these on one board, the backplane crowd should come to an agreement on a backplane, then implement the core on one card, but be able to implement the I/O functions as a second card or several cards. The SBC may have to accept some design efficiency tradeoffs to be 100% compatible with the multi-board computer's minimal configuration, yet be open enough to permit MBCs to add new I/O cards down the road.

The Memory-I/O map ought to be identical for both because we'd want to avoid fancy memory controllers or dynamically-loading OSs as work-arounds for address-space differences.

I feel that the primary storage ought to be flash myself, preferably SmartMedia but I could live with CF if I had to. I haven't scoped out the practicality of this, but here are my thoughts:

Boot ROM: just enough smarts to POST then load and boot an OS kernel from (internal) removeable flash written in existing flash formats (basically similar to MS-DOS formatted drives).

Kernel: Standard I/O supporting some small agreed-upon set of I/O, probably most of the reference basic I/O devices. Some way to natively add "driver" logic for additional devices after booting.

CLI: User interface(s) - here the fun begins. Anything you want at this point. Basic interpreter, DOS or Amiga style CLI, full GUI, whatever. Here is where uniqueness can begin. You can have yer BASIC, yer Forth, yer Oberon.

The software work above the Kernel is gonna go slow, and is very different in character from the hardware, boot, and Kernel work. I'll bet we see a tinyForth and a tinyBasic come as second horses to a fancy MLM. Probably a basic MLM in early boot ROMs anyway.

Using an internal flash drive as a personality module would not only be cool and flexible, these are readily available and inexpensive in some good sizes: 128MB for SmartMedia, larger for CF. The full set of goodies could be booted up off these things w/o any disk access at all. "Builds" could be done using PCs until things get mature.

I might go so far as to suggest that Hard Drives be optional add-ons, not even supported fully in the kernel (though the flash I/O routines could largely be recycled maybe - they're quite similar at an important level if we choose to support MS FAT style drive formats). I think USB and Ethernet are musts, and some people want video but I could live w/o it. I'd want to put the thing on my network and get to it from my PCs. Probably use an HTTP/HTML interface like routers and printers and other appliances do, though fully programmable.

If one CLI (plus whatever) gets popular and alternatives die out, we've lost nothing. Upgrades are cheap and easy, plus you can slap in an old version if need be 10 years from now, then put the 2013 version back in when done.

[kc5tja]

dilettante wrote:

Wow, and I thought the religious wars would be over whether the machine ought to be CBMish or Appleish!

The problem is that the CBM machines are built quite similarly to the Apple machines. It is, in fact, Atari who innovated different bus architectures with the 65xx series, and that is a model to study, if not aspire to, in my opinion. (Note: The Amiga was designed by none other than Jay Minor, the father of too many Atari platforms to list here. One familiar with the Atari 800-series, IIRC, will immediately appreciate the Amiga's bus architecture and I/O chipset capabilities.)

Quote:

The Memory-I/O map ought to be identical for both because we'd want to avoid fancy memory controllers or dynamically-loading OSs as work-arounds for address-space differences.

Dynamic loading isn't hard to do. As usual, the Amiga demonstrates its viability with the use of dynamically loaded libraries, using a statically linked binary execution format, in a single-address-space environment. Even today, the people you mention something like this to will tell you, "That's not possible."

Still, supporting a binary format that takes dynamic linking into account would make things simpler and faster at run-time, due to the lack of run-time "stubs." But, alas, I have to admit, I do still prefer AmigaOS's method of load-time static linking over most DLL implementations. I feel I have greater control.

For that matter, why distinguish between an application and a library at all? The only difference I can think of is that an application has ONE entry point, while a library has multiple. But having only one entry point is merely a degenerate case of having many; hence, there is no concrete difference between the two.

Quote:

I feel that the primary storage ought to be flash myself, preferably SmartMedia but I could live with CF if I had to. I haven't scoped out the practicality of this, but here are my thoughts:

SmartMedia isn't going away, as a few here have feared. I found a USB-bus SM drive in Radio Shack a while ago for a mere $20. That's the same basic price point as *internal* floppy disk drives, suggesting an internal SM drive would be even cheaper than its floppy cousin. Also, while media prices for smart media isn't as cheap as floppies, the cost per MB of storage is still quite a bit cheaper than floppy storage.

The 65-series platform will need a USB host controller of some kind. This is the one missing piece. It should support, at a minimum, 1.5Mbps and 12Mbps throughputs (e.g., USB 1.1). Once this is taken care of, a large number of I/O-related problems will be solved.

Quote:

Boot ROM: just enough smarts to POST then load and boot an OS kernel from (internal) removeable flash written in existing flash formats (basically similar to MS-DOS formatted drives).

Usability studies seem to suggest that POSTing takes too long for most users. People want instant-on access to their computers. Hence, while I agree that POST functionality should be in the boot ROM, it should not always run. The best way to handle this would be to run POST only if a certain key (combination) on the keyboard is pressed during booting.

For example, it takes my PC over 2 minutes to boot into Linux; just under half that time is spent in BIOS doing RAM test and bus enumeration. It's silly, because PCI bus enumeration, USB bus enumeration, and detection of devices on the various I/O ports should take at most a few milliseconds.

By the way, an approach similar to what you proposed above was used on the Atari ST. It booted from a small, fixed ROM, but its GEM desktop environment was loaded from a ROM-disk. This kept the cost of the ROM system low, as 16-bit wide ROMs that were fast enough for the 68000 were not available back in the mid-80s. The kernel was loaded into a "write-protected" region of RAM, to make the RAM behave exactly like ROM.

The 16-bit ROM width isn't an issue for our purposes, but bus speed certainly is. Therefore, booting the operating system off a ROM-disk makes a lot of sense. A primitive form of memory management, while not strictly necessary, would be highly desirable to prevent rogue software from overwriting the kernel image once loaded into memory.

Quote:

Kernel: Standard I/O supporting some small agreed-upon set of I/O, probably most of the reference basic I/O devices. Some way to natively add "driver" logic for additional devices after booting.

I personally like the concept of an exokernel myself; the kernel provides zero resource policy, but provides only protection of resources. Applications are then free to implement whatever I/O or resource policies they desire. "Operating systems" as we currently know them are implemented as shared libraries (this isn't too far from the truth either; by definition, an OS is a shared base of software which all applications link to at load-time or run-time). The performance of the system is, unlike microkernels, equal or superior to traditional monolithic kernel designs, as applications ultimately have (near) register-level access to resources.

The nice thing about exokernels is they make good on the promise of running software from multiple "operating systems" (which microkernels have, to date, not been able to deliver transparently). Thus, "installing an OS" is as simple as copying the relavent libraries into the appropriate place in the filesystem. The only requirement is that the variety of operating systems share at least one common filesystem (so that they know how to access their respective libraries).

Quote:

Using an internal flash drive as a personality module would not only be cool and flexible, these are readily available and inexpensive in some good sizes: 128MB for SmartMedia, larger for CF. The full set of goodies could be booted up off these things w/o any disk access at all. "Builds" could be done using PCs until things get mature.

I recommend using USB devices, because they're available, they're cheap, and they all use a consistent device driver model. That is, a USB floppy driver will/should work with *any* USB storage device, CF and SM included.

Quote:

I might go so far as to suggest that Hard Drives be optional add-ons, not even supported fully in the kernel (though the flash I/O routines could largely be recycled maybe - they're quite similar at an important level if we choose to support MS FAT style drive formats).

Compact Flash is IDE; there is *zero* difference. If you support CF, you'll inherently also support harddrives. SmartMedia is different, however. But if you use USB storage devices, you have ONE driver for all these, as they ALL use the SCSI command-set.

Also, PLEASE remember that the storage device and the filesystem used on it are two completely different issues. There is nothing in FAT that is inherently "harddrive specific" (in fact, it's designed *specifically* for use on floppy drives); likewise, there is nothing in compact flash that mandates the use of FAT. I've used Linux's ext2fs filesystem on CompactFlash and SmartMedia several times, with complete success.

People seem to think that FAT is required because of the illusion that PC BIOS won't boot with anything else. This is NOT TRUE. BIOS boots the system by loading only the first 512 byte block on the media, and branching to that code. If that code is designed to use, say, Amiga OFS instead of FAT, then it'll boot using OFS.

Quote:

I think USB and Ethernet are musts, and some people want video but I could live w/o it. I'd want to put the thing on my network and get to it from my PCs. Probably use an HTTP/HTML interface like routers and printers and other appliances do, though fully programmable.

The original purpose of the 65-series computer is to serve as a decent replacement for the PC: low power, quiet, and user-friendly with minimum of configuration muss and fuss. Consequently, to be a replacement of the PC, then it must have video support.

Trying to use a computer purely from an HTTP interface has failed on more than one attempt. Protocols such as PC Anywhere and the open-source VNC will probably be more to your liking. If not, you might want to research distributed windowing systems, such as Berlin or X11.

[dilettante]

Excellent points, all well taken.

Quote:

The original purpose of the 65-series computer is to serve as a decent replacement for the PC: low power, quiet, and user-friendly with minimum of configuration muss and fuss. Consequently, to be a replacement of the PC, then it must have video support.

Given that premise, I've probably wasted everyone's time by posting in this thread. After seeing the hobby almost from its beginning (started drooling over hardware in magazines and at local club meetings in 1974) I came to the conclusion that the "wars" were over and sold my Amiga 2000 and bought a 486 PC around '93. Apple and Linux notwithstanding, the consumer/office PC market belongs to Wintel for now. I can't see a 65XX or 65XXX machine coming close to competing with even handheld devices in that market. The hardware/software arms race is tough to catch up with.

Feel free to carry on the good fight (glad to see it) but from where I stand life is too short.

[GARTHWILSON]

kc5tja, or anyone familiar with USB's innards, maybe you could give us kind of a primer or tutorial on the subject.  Obviously several are interested.  Some questions I might have are:

1)  Will we be dependent on here-today-gone-tomorrow chip sets?  Or can it be done with parts that will hang around several times as long as it takes us to complete a project on hobbyist time (sometimes even years)?

2)  If we implement the original (slower) USB spec, will all future USB devices made for faster spec.s be downward compatible, or will hardware and software have to be updated to accommodate a new extension to the spec in a couple of years?

3)  How much code space and how much hardware might be involved in implementing it?  (I'm thinking about the investment in time, hardware space on a board, amount of memory required, and lastly, dollar cost.)

The editor of one of the trade magazines practically said recently in an editorial that "RS-232 is dead!" and then got bombarded with a ton of E-mail from readers saying this was not true at all, except maybe in portions of the consumer PC market.  One of them, Ivan Baggett, the president of Bagotronix, Inc., gave several reasons.  Here's part of his letter:

• • "We also make custom OEM products that are not listed on our website.  These control products are used in industrial automation for high-pressure air compressors, photographic film processing, and traffic control.  In each product, there is at least one RS-232 port for interfacing to other control systems or PCs.  In each case, the added cost and complexity of a USB port would be prohibitive.  USB is not an easy thing to add to an embedded system, for these reasons:
    
    1) There are very few general-purpose embedded microcontrollers with built-in USB capability.  Therefore, USB is typically added as a separate chip, increasing the cost.
    
    2) USB protocol adds a lot of code to an embedded device.  In many cases, it would mean using a microcontroller with more memory, further increasing unit costs.  Also development time would be increased.
    
    3) USB nodes are either hosts or devices.  They are not peers.  This means that USB devices (embedded systems) can only talk to a USB host (PC), but not each other.  Therefore USB is useless as a peer-to-peer link.  There is a new industry effort to overcome this limitation of USB, it's called USB-On-The-Go.  But USBOTG is very complex to code, and requires a USBOTG controller, which is only available from one company so far.  Contrast this to RS-232, which can be used between any two units without regard for host/device issues.
    
    The consequence of (3) is that any embedded system that is required to interface to both embedded systems and some new PCs would require both RS-232 and USB ports.  This would add cost, complexity, and size.  Given the constraints that embedded designers like me face, it's obvious which port must be eliminated from the embedded device—it's USB.
    
    RS-232 is trivial for a PC manufacturer to support, but USB is quite a burden for embedded systems to support.  In the cutthroat world of PCs, they will eliminate anything they can to save money.  This is the real motivation for the disappearance of the RS-232 port from PCs.  The embedded computing world does not need to be dictated to by the bean counters of the PC world."

[ end of quote ]

Obviously he's coming at from a perspective other than that of the home- or office-type PC market, but he definitely mentions things that are of interest to me in my work.  That's not to say I think USB should get lost, but rather that both have their place and RS-232 isn't going away.

In any case, I am interested in how USB might be implemented in a 6502 system where 10K of code space for implementing it is not acceptable.  Without knowing, I doubt that it would be that much, but how much would it take?  Is it reasonable for a 6502 hobbyist to tackle?  Perhaps someone could write up such a primer and Mike could post it on this website.  I'm working on some other primers that will go up this year.

Quote:

the consumer/office PC market belongs to Wintel for now.

and it will remain that way if people let themselves be conquered.  Although I don't like it, I use two Pentium machines because my business demands it— the software selection for my work on other machines is generally weak, and in some cases, non-existent.  For example, a programmable logic manufacturer may provide development software only for Windoze.

Quote:

I can't see a 65XX or 65XXX machine coming close to competing with even handheld devices in that market. The hardware/software arms race is tough to catch up with.

Although we would like to see market-viable alternatives, I'm not sure any of us are expecting it to come from a 65-family machine.  It would be nice to be able to replace some of the PCs' functions however with a 65-family machine.  These functions might include programmers' text editors, assemblers, compilers, and even some internet use, but probably would not extend into things like very complex CAD.

Garth

[Edit, many years later:]

Quote:

SmartMedia isn't going away, as a few here have feared.

SmartMedia memory cards are no longer manufactured as of around 2006 (according to Wikipedia).

Quote:

The 65-series platform will need a USB host controller of some kind. This is the one missing piece.

The MAX3421 might do the job.  It's an SPI-interfaced USB peripheral/host controller IC.

[kc5tja]

GARTHWILSON wrote:

1) Will we be dependent on here-today-gone-tomorrow chip sets? Or can it be done with parts that will hang around several times as long as it takes us to complete a project on hobbyist time (sometimes even years)?

Currently, all are here-today-gone-tomorrow solutions because not a *single* USB host controller "chip" exists -- they're always implemented as a component on a motherboard chipset. Hence, if we were to support USB, we'd have to make our own (e.g., via an FPGA or some such).

Quote:

2) If we imlement the original (slower) USB spec, will all future USB devices made for faster spec.s be downward compatible, or will hardware and software have to be updated to accommodate a new extension to the spec in a couple of years?

I can't answer this, but I know that, at least, USB 2.0 devices are partially supported under USB 1.1. Those devices which *require* the higher throughput of USB 2.0, of course, will not work under the USB 1.1 bus. Those that *support* it, but can work nonetheless with 1.1, then yes, it'll work.

Quote:

3) How much code space and how much hardware might be involved in implementing it? (I'm thinking about the investment in time, hardware space on a board, amount of memory required, and lastly, dollar cost.)

Again, I can't really answer this question.

As far as hardware, I'm not at all sure. However, for software, I'm guessing around 6 to 12KB of code would need to be dedicated to bandwidth allocation, and queueing of packets.

Remember that USB is a special-purpose networking protocol, and so it'll have requirements very similar to, say, Ethernet, as far as code space requirements.

But again, the interest in USB is not for embedded device control. It has never been, and it never will be. I would love to see the concept of a serial loop bus be re-introduced, but that'll never happen if we want cheap, off-the-shelf peripherals for this computer. Keyboards, mice, and flash/SmartMedia readers/writers make the investment worthwhile alone, to say nothing of wireless Ethernet adaptors.

Quote:

In each case, the added cost and complexity of a USB port would be prohibitive. USB is not an easy thing to add to an embedded system, for these reasons:

1) There are very few general-purpose embedded microcontrollers with built-in USB capability. Therefore, USB is typically added as a separate chip, increasing the cost.

2) USB protocol adds a lot of code to an embedded device. In many cases, it would mean using a microcontroller with more memory, further increasing unit costs. Also development time would be increased.

3) USB nodes are either hosts or devices. They are not peers. This means that USB devices (embedded systems) can only talk to a USB host (PC), but not each other. Therefore USB is useless as a peer-to-peer link. There is a new industry effort to overcome this limitation of USB, it's called USB-On-The-Go. But USBOTG is very complex to code, and requires a USBOTG controller, which is only available from one company so far. Constrast this to RS-232, which can be used between any two units without regard for host/device issues.

Well, again, USB isn't for embedded control. It was designed first and foremost for general purpose desktop users in mind.

Quote:

RS-232 is trivial for a PC manufacturer to support, but USB is quite a burden for embedded systems to support. In the cutthroat world of PCs, they will eliminate anything they can to save money. This is the real motivation for the disappearance of the RS-232 port from PCs. The embedded computing world does not need to be dictated to by the bean counters of the PC world."

This is a fallacy if I've ever heard one. The USB hardware is substantially more involved than the RS-232 hardware. The cost of an RS-232 port is mere pennies, even cheaper in volume production. USB implementations require bus mastering (since it's DMA driven), and limited hardware support for the serial protocol (this can be averted), and high-speed shift registers for (de)serialization. RS-232 can be implemented with a set of 10-bit shift registers and a down-counter (this is how the Amiga implemented it; it handled 1.536Mbps too!!).

The reason for eliminating the RS-232 port is two-fold:

1. Eliminating the RS-232 ports from a PC gives the perception of "progress," and forces the user to have to utilize USB devices. This benefits the USB community by (artificially?) creating an economy of scale.

2. There just plain isn't enough room on many small-sized PCs (e.g., micro-ATX boards) for RS-232 ports. USB ports are smaller, better shielded, and hot-swappable.

The tradeoff comes in the user's ease of use and configuration, and its hot-swappability (a feature which I use quite often with my digital camera, BTW).

Quote:

Obviously he's coming at from a perspective other than that of the home- or office-type PC market, but he definitely mentions things that are of interest to me in my work. That's not to say I think USB should get lost, but rather that both have their place and RS-232 isn't going away.

However, you'll never, ever find a CompactFlash or SmartMedia drive for RS-232. For USB, however, they're everywhere, and darn cheap to boot.

Quote:

In any case, I am interested in how USB might be implemented in a 6502 system where 10K of code space for implementing it is not acceptable.

Unless you're one slick coder, it can't. Don't bother trying. I was going under the assumption that we were planning for the 65816-based PC.

Quote:

Without knowing, I doubt that it would be that much, but how much would it take? Is it reasonable for a 6502 hobbyist to tackle? Perhaps someone could write up such a primer and Mike could post it on this website. I'm working on some other primers that will go up this year.

I think it's quite possible to tackle by a hobbiest. The limiting factor is the host controller required by the protocol. You either need dedicated hardware, or a dedicated CPU handling the bit-banging requirements of USB that can tackle 12Mbps throughputs. That won't happen with a 65xx(x) series CPU.

I don't know anything about low-level USB implementation requirements, however; someday, I'll have to find out, as I'd like to use my digital camera from within my native Forth environment (if/when I ever get that done. ).

[kc5tja]

dilettante wrote:

Given that premise, I've probably wasted everyone's time by posting in this thread.

I don't think so. But remember that what we're describing is a hobby machine, although Garth has interest of using it for his workbench machine (he already has a custom-built 6502 box that he's looking to replace with an upgraded architecture).

Quote:

After seeing the hobby almost from its beginning (started drooling over hardware in magazines and at local club meetings in 1974) I came to the conclusion that the "wars" were over and sold my Amiga 2000 and bought a 486 PC around '93. Apple and Linux notwithstanding, the consumer/office PC market belongs to Wintel for now.

I agree that the 65xx(x) architecture won't conquer the desktop again anytime soon, if at all. But my "quiet" (compared to the other computers I have here) PC sounds like the inside of a 747 jet, and emits all sorts of RF noise, making my ham radio hobby less pleasing. Moreover, it draws the equivalent of three 100W lightbulbs in power. A 65x-based PC will not run Windows or Linux, which is fine because it's a hobby machine anyway. But it can run all the important software a user is willing to write or download from someone else, such as e-mail clients, web browsers, and text editors/word processors.

You might not realize it, but the Commodore 64/128 "industry" is alive and well, and is now entirely user-supported.

Quote:

I can't see a 65XX or 65XXX machine coming close to competing with even handheld devices in that market. The hardware/software arms race is tough to catch up with.

A 16MHz 65816 will give a 16MHz Dragonball CPU a dire run for its money. Beyond that, however, the ARM owns the '816, and the MIPS is better still.

Quote:

Feel free to carry on the good fight (glad to see it) but from where I stand life is too short.

Life is too short not to try new things. I, too, grew up with the early 8-bits, moved to the Amiga (although I still have mine, it isn't used often anymore), and now am with the x86-based PC architecture. Moving to the PC early on was nice, but it's since gotten very boring, and very monotonous what with Microsoft running my life and all. I'd like a refreshing change from that.

[cas]

Hi,

we're a group of 6502 ATARI hobbists that work on an USB device for the ATARI 8Bit, so I like to share some of our USB experience so far.

Today, after 6 Month of development (4 Mon Hardware and 2 Mon Software so far) we're able to send packets between the ATARI and an Linux PC over USB, but nor full communication. The development enviroment is FORTH, the drivers will be translated in optimised assembler when proven in the interactive FORTH enviroment.

GARTHWILSON wrote:

kc5tja, or anyone familiar with USB's innards, maybe you could give us kind of a primer or tutorial on the subject. Obviously several are interested. Some questions I might have are:

1) Will we be dependent on here-today-gone-tomorrow chip sets? Or can it be done with parts that will hang around several times as long as it takes us to complete a project on hobbyist time (sometimes even years)?

Yes, it seems so. We use the National Semiconductor USBN9602 USB Controller. This is a node controller, not a host controller, but we try to bend this thing to allow 1-to-1 USB-Node communication. But this has to be proven in the future development.

I know people who have the source for FPGA USB Controller if needed.

Quote:

2) If we imlement the original (slower) USB spec, will all future USB devices made for faster spec.s be downward compatible, or will hardware and software have to be updated to accommodate a new extension to the spec in a couple of years?

New USB-Hardware is free to support the older or only the newer specs. I think that devices that need throughput will stop supporting USB 1.1 in the future , so yes, USB is not a solution for ever....

Quote:

3) How much code space and how much hardware might be involved in implementing it? (I'm thinking about the investment in time, hardware space on a board, amount of memory required, and lastly, dollar cost.)

I plan for 2-3 K 6502 Code for a generic driver (Mouse, Keyboard). For Ethernet or Storage you need also to implement higher levels like FAT Filesystem or TCP/IP which can get bloated big.

So if you format the Storage with a low-level filesystem like ATARI DOS 2.x, the drivers on the 6502 will be small. All we need then is a FS-driver for the PC world, but having all the emulators, writing a new FS-driver for, say Linux, is not a big issue. Its easier to get the PC reading the Home-Compter FS that the other way round.

Hardwarecosts so far are 50 Euro per Unit, so it's not really cheap.

And yes, I would like to see a new, effordable 6502/65816 computer!

Carsten Strotmann

[kc5tja]

cas wrote:

Today, after 6 Month of development (4 Mon Hardware and 2 Mon Software so far) we're able to send packets between the ATARI and an Linux PC over USB, but nor full communication. The development enviroment is FORTH, the drivers will be translated in optimised assembler when proven in the interactive FORTH enviroment.

Would you be able to post the Forth code for this? I'd be interested in viewing the Forth sources when they're complete.

Quote:

I know people who have the source for FPGA USB Controller if needed.

I was envisioning that FPGAs would be used pretty much for all custom logic in the computer, including video and audio, SmartMedia interface, basic I/O ports, etc. I think it'd be best to also include the USB interface in the FPGA category as well.

The nice thing about this is, if we make the FPGAs load from EEPROM, it'd be possible to hot-fix "hardware bugs."

Quote:

I plan for 2-3 K 6502 Code for a generic driver (Mouse, Keyboard). For Ethernet or Storage you need also to implement higher levels like FAT Filesystem or TCP/IP which can get bloated big.

FAT is utterly trivial to implement. Remember that the original PCs shipped with only 64K to 128K of RAM installed; DOS 1.x had to be loaded into a portion of that RAM. VFAT32 is only marginally more sophisticated. I wouldn't bother with VFAT16 -- it's a waste.

Quote:

So if you format the Storage with a low-level filesystem like ATARI DOS 2.x, the drivers on the 6502 will be small.

I'm willing to bet that FAT is as simple as AtariDOS, and all the while, you gain the benefits of supporting subdirectories. Are there any sites that document AtariDOS (seeing as how Commodore's filesystem is quite well documented on the Internet, there should be comparable docs for AtariDOS as well) that you recommend as a starting point?

[cas]

kc5tja wrote:

Would you be able to post the Forth code for this? I'd be interested in viewing the Forth sources when they're complete.

You can find the latest information and sources on this project at http://www.strotmann.de/twiki/bin/view/APG/UsbDDkD

Quote:

The nice thing about this is, if we make the FPGAs load from EEPROM, it'd be possible to hot-fix "hardware bugs."

Regarding hot-fixing, do you know Tiny-Open-Firmware (http://www.tinyboot.com/)? Its a FORTH system especially for Firmware on limited small systems.

Quote:

Quote:

I plan for 2-3 K 6502 Code for a generic driver (Mouse, Keyboard). For Ethernet or Storage you need also to implement higher levels like FAT Filesystem or TCP/IP which can get bloated big.

FAT is utterly trivial to implement. Remember that the original PCs shipped with only 64K to 128K of RAM installed; DOS 1.x had to be loaded into a portion of that RAM. VFAT32 is only marginally more sophisticated. I wouldn't bother with VFAT16 -- it's a waste.

If so, FAT should not be the problem

Quote:

Quote:

So if you format the Storage with a low-level filesystem like ATARI DOS 2.x, the drivers on the 6502 will be small.

I'm willing to bet that FAT is as simple as AtariDOS, and all the while, you gain the benefits of supporting subdirectories. Are there any sites that document AtariDOS (seeing as how Commodore's filesystem is quite well documented on the Internet, there should be comparable docs for AtariDOS as well) that you recommend as a starting point?

I used ATARI DOS only as an example. I think all DOS systems for Homecomputers are somewhat similar in complexity. ATARI DOS is not really a masterpiece or a good template for new development. Anyway, it is well documented (including 6502 Source) in the book "Inside ATARI DOS", online at http://www.atariarchives.org/iad/

Best regards

Carsten

[Memblers]

I'm fairly inexperienced with hardware stuff. I hope you don't mind me jumping in here. I find the idea of a 65xx-based PC to be quite interesting. Especially if it could have good sound capabilities, for synthesis and/or digital mixing.

kc5tja wrote:

I was envisioning that FPGAs would be used pretty much for all custom logic in the computer, including video and audio, SmartMedia interface, basic I/O ports, etc. I think it'd be best to also include the USB interface in the FPGA category as well.

That sounds good. So, this FPGA would be configurable by running code on the machine? Would that make it possible for a user to do something like create a register that could do specific tasks that usually requires hundreds of CPU cycles to accomplish?

Reminds me of a website I visited once, of some company that had developed an FPGA add-on for (I think it was) an x86 PC. It had software that would read the source code to a program and automatically configure the FPGA to handle the parts that it does best. Probably only useful for extreme number-crunching or something, but it sounded interesting anyways.

I don't know much about FPGAs, myself.. but I've seen some really impressive things done with them. I'm not sure how I would convert something I would think of as assembly source code to pure logic. Am I "jumping in the deep end" by thinking of it that way?

[kc5tja]

Memblers wrote:

That sounds good. So, this FPGA would be configurable by running code on the machine? Would that make it possible for a user to do something like create a register that could do specific tasks that usually requires hundreds of CPU cycles to accomplish?

Yes, you would include a piece of software which loads a large table of bytes into the FPGA chip, and that would reprogram the FPGA's internal logic.

Quote:

I don't know much about FPGAs, myself.. but I've seen some really impressive things done with them. I'm not sure how I would convert something I would think of as assembly source code to pure logic. Am I "jumping in the deep end" by thinking of it that way?

FPGA information is very hard to come by. The manufacturers generally do not want to release programming information for their chips without expensive licenses, which is why you so rarely see open source tools for working with FPGAs (and even then, it's usually only for simulation).

You generally would not convert assembly language into a logic circuit unless you really needed the speed it offered. Even though an FPGA is programmable, it is not programmable in the same sense a microprocessor is -- an FPGA is still a specialized device.

The use of FPGAs in my idea was to dedicate, for example, one FPGA for use as a video chip, one for use as an audio chip, etc. Their programming would be relatively fixed -- but in the event some special capability was needed, or in the event a "hardware bug" was discovered, implementing the appropriate logic to upgrade or fix the circuits could be done at boot-time, or even while the machine is running.

[Memblers]

Have you seen this?

http://www.xgamestation.com/

It sounds a lot like what was being discussed in this thread. It uses an FPGA for video, and it optionally supports a 65816.