Affordable PCB Layout Software ???

The only case I know of like that was software that used undocumented op codes in the early 6510 CPU. That isn't Mos Technology, Commodore or Microsoft's fault. It was the programmer who used codes the 6510 manual told you not to use.

The Commode 128 was successful enough to spawned the 128D, and the never marketed 256 version that was being manufactured when they were shut down and liquidated.

BTW, Microsoft wrote the BASIC versions used in most Commodore computers.

--
http://improve-usenet.org/index.html

aioe.org, Goggle Groups, and Web TV users must request to be white
listed, or I will not see your messages.

If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm


There are two kinds of people on this earth:
The crazy, and the insane.
The first sign of insanity is denying that you\'re crazy.

Actually, it was you who missed the point. I was pointing that vista is dog slow on the fastest hardware and you pointed out that linux is bloated as well. I mentioned that linux works just fine on hardware

1/4th as fast as current machines, and you pulled out bullshit story about adobe being bloated.

Maybe on a 200mhz P1, it is too bloated to run. Compare that to vista that is too bloated to run worth a shit on a 6ghz 2gb machine.

You're just argueing for the sake of argueing. Kplonk>

The 6510 (and the 8502 used in the C128) supported the same undocumented opcodes during its lifetime. The only real compatibility issue I'm aware of involved an undocumented way to play samples on the sound chip, which no longer worked with newer revisions of that chip.

With the exception of the Amiga line, all Commodore computers used the Microsoft BASIC interpreter, just like many other home computers.

As long as that mini-registry follows some standard conventions (e.g., knows how to separate "program" settings from "user" settings -- in many early programs, there weren't individual user settings since it was assumed that one PC = one user, and this causes network deployment to fail), that sounds workable. However, you still need a centralized location to, e.g., register COM servers, DLLs, etc. so that one program can *find* another program in the first place without knowing its exact name and path, etc.

Windows uninstallers are *supposed* to remove their registry entries when you tell them to remove the programs, but it is true that many install/uninstall routines are written and tested very, very poorly. (I've seen a few where even changing the default installation path causes some parts of the program to end up where you want them and others to end up in the original default path, the result of which is that the program doesn't work at all. And heck, there are some expensive programs like PADS PCB and ORCAD that to this day either won't let you or very much suggest against installing them in "c:\\program files\\whatever" because of the SPACE IN THE PATH NAME. How can you possibly respect a software development company that in 2008 hasn't gotten around to supporting a feature of the file system introduced back in 1995? Sheesh. ORCAD also tries very hard to prevent you from having a space in the name of your design files, although with a bit of trickery you can force it to let you do so. But again... what a piece of junk...)

Definitely something of a pinnacle of 8-bit computers, the 128D.

The Apple IIGS certainly wasn't bad either, although of course that was already a mixed 16/8-bit CPU.

Lynx is actually still kept alive by folks who use it in embedded systems such as routers -- since occasionally you'd really, really like to get to a simple in-house data-collection web site or whatever, and don't need the fancy graphics. I installed it on an Asus WL-HDD NAS box earlier this year just for fun, and it worked better even with "regular" web sites than I would have guessed.

I'm usually more interested in tiny web servers sitting on embedded system that I connect to from a desktop web browser.

Sorry, but some production runs of the 6510 didn't support all the undocumented op codes. i had a friend who was into graphics, and his

6510 died. I had to try over a dozen chips to find one that worked with that program. Everything else we tried ran on all the other 6510 chips. I repaired hundreds of c-64 & C128/128D computers at the component level.

They had different levels though. When they went from the PET seers, to the Vic-20, they scaled it way down. The c-64 was a little better, but the C128/D was a lot better.

--
http://improve-usenet.org/index.html

aioe.org, Goggle Groups, and Web TV users must request to be white
listed, or I will not see your messages.

If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm


There are two kinds of people on this earth:
The crazy, and the insane.
The first sign of insanity is denying that you\'re crazy.

Commodore developed their C-256 based on the Western Design Center

65816 16 bit CPU, but it was never on the market.

--
http://improve-usenet.org/index.html

aioe.org, Goggle Groups, and Web TV users must request to be white
listed, or I will not see your messages.

If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm


There are two kinds of people on this earth:
The crazy, and the insane.
The first sign of insanity is denying that you\'re crazy.

You claimed that only Microsoft produces inefficient software, and that all other companies use OO programming (why should I care as a user?) and produce more efficient software. If that were true that would be nice, I would only have to avoid Microsoft and I get good quality and efficient software. Unfortunately the reality isn't that simple, and Microsoft far from the only sinner.

When confronted with counter examples, your argument is that bloat isn't a problem (except apparently when it is from Microsoft). Funny comming from someone posting in in an embedded newsgroup, where in a typcial embedded project every penny counts and throwing more powerful hardware isn't often an option.

Anyway when I replace my desktop machine (which is already much more powerful than your '1.4mhz laptop') with a machine that has at least twice the processing power, I expect it to be at least as responsive as the machine it replaces, not slower. I guess I'm funny that way.

The equivalent of putting your fingers in your ears and shouting 'nah, nah, I can't hear you'. Very mature.

For an example a little closer to the group's topic - Code Worrier for the Freescale 6805 devices was something like a 600 MB download, and 1 GB install, for a compiler for a device with a couple of KB code space.

such

for

I've occasionally found lynx useful from machines that I only have ssh access to. Text-based utilities are very useful for remote administration.

Hmmm...this the first time I heard of this (used to be in the c64 scene). Especially demo's relied heavily on undocumented features, but nevertheless there were few compatibility issues.

That would be the C65, the few hundred remaining units are nowadays a collectors item which sell for over $1000 on eBay.

The latest PET had BASIC 4.0. The VIC-20 and the C64 used BASIC 2.0, can't think of anything in the C64 BASIC that the VIC-20 didn't have. Interesting background information about why which basic was chosen for a certain computer and why the C128, unlike earlier models, displayed the Microsoft copyright message can be found in the book "On the Edge - the spectacular rise and fall of Commodore".

(comp.sys.cbm would be a better place to discuss this)

that

I only found two out of over 100 6510 that would run his program. he contacted the software company abut it, and they admitted that it was written on a developer's pre production computer, but that they would not give him the current version, or even a discount, so RObert disassembled the software and re wrote the bad parts to work on any

6510.

Try running Basic programs written for the PET on either. They were stripped down so their business software won't run on the cheaper 'home' models.

I used to visit there, but there was very little traffic that wasn't cross posted from British Sinclair users. It had more trolls than regulars, so I gave up.

--
http://improve-usenet.org/index.html

aioe.org, Goggle Groups, and Web TV users must request to be white
listed, or I will not see your messages.

If you have broadband, your ISP may have a NNTP news server included in
your account: http://www.usenettools.net/ISP.htm


There are two kinds of people on this earth:
The crazy, and the insane.
The first sign of insanity is denying that you\'re crazy.

The sise of the IDE has little to do with the size of the code space on the target. The size of the compiler also has little to do with the processor code space.

Mark Borgerson

that

Like I said; the PET had BASIC 4.0 where the VIC-20 and C64 had BASIC

2.0. The most important difference between the two is that BASIC 4.0 (PET) had disk commands. The advantage of BASIC 2.0 was that it could fit with the kernal in just 16 KByte. The VIC-20 and C64 were designed (in very short time) to be as cheap as possible, cutting corners where possible.

It's more a function of the quality of the libraries. It goes back to the old "hello world" test, looking at the generated code to see how much irrelevent bullshit gets included.

One programmer's irrelevant bullshit is another's initialization code.

I expect that most embedded programmers will know that

printf("hello world");

will produce a different result from

puts("hello world");

Of course the result will also depend on whether the program has to run on bare silicon or can take advantage of a bios or more complet OS. I generally start with bare silicon, so I'm not surprised when the program has to link in serial port drivers, initialization code, etc. etc.

For a system like the 6805, I would probably consider the 'beans' to be example code and extract only the essence. Codewarrior was probably a better system back when it was only generating code for the M68K systems or systems of equivalent register complexity.

I've never been a big fan of 'one size fits all' tool vendors. That's why I use tool sets from IAR for the Atmel ARM chips, Codewarrior for the M68K, Imagecraft for the MSP430 and GCC for an ARM-Linux system. (The latter was not my choice, though). I've also used Keil for the

8051 series---but I'm not sure I'd pick them for an ARM compiler vendor.

Mark Borgerson

There is an annual Sinclair/Commodore flame war, but for the rest it's mostly relevant stuff in my experience.