2500AD C compiler for 6502

Supplying and support your own SW tools would increase costs. Relying on

The costs that I imagine Sunplus worries about would come from requests for chip data, prototyping boards and general hardware/software integration support. These requests would be encouraged as tools and information about their chips became more widely known. I think they and their reps believe they already know every potential customer, and any new inquiries would almost certainly be a waste of effort for them. Also. there's a increasing tendency for design to follow manufacturing over to southern China, so strategically it may not be wise to increase investment in supporting developers elsewhere.

Jim McGinnis' responses on this subject fit with my understanding of Sunplus. If you read their datasheets, you'd see why they are afraid of letting everyone read them--the datasheets create almost as many questions as they answer.

Just to be sure no one gets the wrong idea, the cc65 owner is in the right here. Sunplus considers their datasheets confidential, strange as that may seem. cc65 cannot incorporate Sunplus support without Sunplus' permission.

- Wallace

Last I checked (this was ~14 months ago), Sunplus had a very odd way of compiling code. They use an off-the-shelf 6502 assembler trained not to use certain registers that aren't implemented in certain of their cutdown cores, and then they run a utility over the object code to backpatch some of the opcodes and perform retrospective address fixups.

Sunplus supplies the toy market. Support is nonexistent in this market. Incomprehensible, unreliable and guaranteeably buggy tools are the norm. Generally it doesn't matter because you just give your rep wave files and a flowchart and some $0.05-per-week laborer in the code mines of China figures out how to get it 80% working, which is good enough.

Because the workflow with these parts - and the vendor accountability

- is just not in the same league as what most cae'ers would expect. By way of example as to just how different these parts are from mainstream microcontrollers: There is no testing and no functional guarantee. Typically they supply a 1% overage to cover defectives. So your Happy Meal toy doesn't work, and you give it back to the McWorker and he gives you a replacement.

Code for these parts is supported by libraries supplied by the chip vendor, supporting CELP, MIDI playback, etc etc - various functionality which the chip vendors keep very secret. They don't want to outsource that functionality, and they want minimal in-house development costs, so they use, by-and-large, in-house tools.

It is *normal practice* in this industry segment for parts to be supported only by proprietary tools. In this day and age, a large percentage of toy micros are either 6502s or 65C816s under the hood, but that's virtually useless information.

Interesting. I think I'll stay out of that segment of the industry.

Remember the TI99? Some companies like to demonstrate their incompetence so that there's no question about their abilities...

I can't imagine anyone being able to enforce a copyright of instruction mnemonics. This is akin to trying to enforce a copyright of the Latin alphabet. [Maybe that's a way to get rid of all the superfulous "E"s in English words -- I'll just copyright the letter E and refuse to allow anyone to use it!]

Oh yeah... I forgot about that little detail. Thanks for reminding me...

Once the Sunplus parts pass your own functional test, are they as reliable as any other maker's (given the same level of firmware design)?

I wonder if anyone really knows, since most Sunplus 8-bit parts wind up in toys. Unlike the average 8-yr-old, the end user of this product will notice if the part resets frequently or something worse...

Thanks, Wallace

By my book, that means what these guys produce is not actually a (general-purpose) microprocessor or -controller, but rather a special-purpose part which will be essentially useless to anybody but the narrowly defined target audience, and IMHO not worthy of mention in this newsgroup.

As police men on crime scene watch would put it: "Move on, everybody, nothing to see here --- just move on".

I don't know about that... I would think a 8-bit microcontroller that costs less than a quarter--or even a dime--would be of interest to lots of developers, even if you do have to use proprietary tools.

At any rate, I thank everyone who's contributed to this thread. I know it helps me, and evidently there are at least two other Sunplus developers out there.

- Wallace

Hello Wallace,

In general, with a very small sample size... I'd say yes, Sunplus is as reliable as Winbond, or EMC, or King Billion, or Realtek, or... However, reliability is really not a design parameter for these parts :) Note that the intended functionality of these uCs is to spend most of their lives asleep, to respond briefly to an interrupt, and then to re-snooze.

Maybe they miss every ten-thousandth interrupt, reliably. There's no way of knowing, because the 3yo target user just bashes the button for the 10,001th time and the toy works again.

Maybe the core will overheat and explode if run continuously in a tight loop for 37 minutes at Vbatt=4.0V. There's no way of knowing, because the 3yo target user can't keep the thing running at 100% duty for that long.

Issues like ESD sensitivity, timing, boundary conditions of Rosc or other clock input, you're just so completely on your own. Even when the datasheet says something on one of these topics, it can be utter fantasy and you'll never get a response from the manufacturer beyond "Ah, yes, we know there is mispring in datasheet".

On most of these toy parts, you can't even do a power-on firmware checksum (and looky here, memory reliability isn't characterized - fancy that!).

If I was designing anything non-trivial, I would *not* want to use one of these toy chips, no matter who the manufacturer. If nothing else, you can be sure that the support structure for any non-speaking-toy application is nonexistent. And God knows, it's hard enough to get semi-acceptable support on the intended application set.

A couple of vendors - Elan is the only one that comes immediately to mind - do support using some of their parts in "microcontrolling" type non-toy applications. But that is still the road less traveled, IMHO. I'd certainly never consider doing anything critical with one of those parts derived from the toy line.

I agree. That is also pretty much exactly what they will tell you, if you ask them.

:) It can be fun to work in, but it hardly encourages best practices. Because the functionality of a toy isn't often well-defined (the box tells you generalities only), the rule of thumb is "make sure that it does SOMETHING when the user plays with it - ANYTHING is better than nothing". So for instance in a toy with some communication system (e.g. IR remote control) you should make it respond - somehow - to spurious codes - regardless of the actual play pattern.

There are scams just waiting to happen in that industry (I'm surprised I never heard of one). The sale contract for these parts often says explicitly that Company XYZ made these parts using the customer-supplied object code and their normal production process, but that they performed no testing or other Q/C feedback. I.e. they fed your recipe into the oven, and out came dice, so they cut them and packed them and here you are - take it or leave it, no money back.

So they could ship you a thousand of someone else's part instead of your part, or chips with a 99% defect rate, and you'd have no real recourse. In theory you could sue in China - good luck on that route!

Ah, but suppose that the only way to get the information about how to generate code for these parts was to sign an NDA that says you can't disclose any of this information or make tools that use it, or do anything except buy chips and burn "I love you, Mommy!" into them?

Hmm, that certainly gives me pause. I'm familiar with the poor documentation and general lack of information. Unquantified ESD behavior is a little scary.

I'll check with Spectrum Rep to see what other non-toy applications are using Sunplus' low-end chips. (I know they have USB host controllers and other more advanced parts, too.)

Thanks, Wallace

Most of these parts will be chip-on-board, and since wire bonding has a relatively high failure rate, I'm not sure how effective it is to test prior to bonding. My own experience is that Sunplus's parts did not have an unusually high failure rate, although it specs are pretty fuzzy so you need to be conservative in interpreting them

There are some exceptions. My former employer, Voice Signal Technologies, sold Sunplus speech recognition libraries independently from Sunplus.

You can use any 6502 tools -- and there were lot of them in the Apple II days -- to develop for the 6502-like chips, albeit with some effort to remap opcodes if needed. The 2500AD toolset is more or less the standard for Sunplus, however. I think they are the only commercially supported 6502 tools still out there, and support does help when you're on a tight schedule. I haven't heard of any 65C816 clones - do you know who makes those?

Winbond's more recent parts (the top-of-the-line BandDirector things) have that core, or so they told us. Also, there is a video game ASIC from Sunplus that contains an '816. That is the part used in that "Atari 2600 games in an Atari joystick" toy product.

There was one other vendor that told us about '816s, I think it might have been Sonix. Not sure on that one, though.

--

-- Lewin A.R.W. Edwards

Always a possibility, but then I would have expected the statement to have reflected that condition. At the very least, it would be beneficial to potential users of the part to know if the vendor is making such unconventional demands. If it were me, I would look for a different part, even at greater expense, rather than take the risks that attach to using parts from a vendor with that attitude.

TANSTAAFL. You gets what you pays for. Cheap price implies that something was sacrificed; in this case, quality control and standardization.