Reply by George Neuner January 23, 20112011-01-23
On Sat, 22 Jan 2011 21:58:46 -0500, George Neuner
<gneuner2@comcast.net> wrote:

>I never saw the BBC machine. DeSmet (Aztec) C for the Apple was full >ANSI in its final incarnations.
Oops! Aztec C was Manx, not DeSmet. Sorry for the confusion. George
Reply by George Neuner January 22, 20112011-01-22
On Wed, 19 Jan 2011 19:16:34 -0800 (PST), toby
<toby@telegraphics.com.au> wrote:

>On Dec 28 2010, 5:02&#4294967295;am, David Brown ><da...@westcontrol.removethisbit.com> wrote: >> On 28/12/2010 03:35, George Neuner wrote: >> >> > There are freely available native and cross development tools >> > targeting both the 6502 and 65816: C and Pascal compilers, Forths, and >> > a whole selection of assemblers and disassemblers. >> >> There were a range of programming languages available for the BBC >> Masters, including Pascal, C, Forth and Logo, running native on the >> 6502. &#4294967295;I don't remember whether the Pascal was a full compiler > >The C certainly wasn't full C. I think the Pascal was a subset (no >recursion, iirc?) To get full blown languages you needed a Tube system >- my school had a nice Z80 CP/M Tube BBC clone with an integrated >colour screen.
I never saw the BBC machine. DeSmet (Aztec) C for the Apple was full ANSI in its final incarnations.
>> > Freely available from Apple are the APW 65816 assembler and C compiler >> > (you needs a //gs to run these) and the corresponding MPW 65816 cross >> > development tools for the Macintosh. > >I never saw these. Where would you get them today? (Apple recently >pulled their FTP site which formerly hosted MPW, but not these tools, >unless they were in a directory apart from the main distribution.)
The //gs system software is available free here: http://support.apple.com/kb/TA48312?viewlocale=en_US The APW tools seem to have disappeared from Apple's site - they were there in December 2010 when I made the previous post. They APW tools were based on ByteWorks ORCA tools which are still available. An early version of APW is available free from: http://www.byteworks.org/Byte_Works/cpw.html The ORCA environment and compilers are available for $$$ (though reasonable) from http://store.syndicomm.com/ I originally found the APW stuff googling 65816 developer tools, so it's possible they are mirrored somewhere ... but I can't find them again just now. There are free 65816 C and Pascal compilers. You can get the ByteWorks C and Pascal GS/OS and //gs toolbox interfaces from Syndicomm and cobble together a developer system.
>> > There is a proprietary MPW Pascal compiler for the 65816 but, AFAIK, >> > it isn't available free. &#4294967295;TML Pascal (//gs) is available free. > >I used TML Pascal in the 1980s for Macintosh. Nice environment but >Lightspeed (later THINK then Symantec) Pascal and Lightspeed C >eventually killed off the competition :)
APW didn't have an APDA sanctioned Pascal. ORCA/Pascal was the plug-in Pascal for APW. Overall ORCA was a better compiler, but TML's integrated debugger made it a nicer development environment. TML (now Complete Pascal) for //gs is available here: http://www.cirruscomms.com.au/~mike_stephens/apple2/TML_Pascal/index.html George
Reply by Quadibloc January 21, 20112011-01-21
On Jan 19, 11:41=A0am, timcaff...@aol.com (Tim McCaffrey) wrote:

> My big disappointment was their personal computer (TI-99?), they wrote an > interpreter that was used to implement an interpreter for Basic, and they > didn't provide peek/poke or machine language function calls, so you were > *forced* to use the slow basic interpreter for everything.
Yes, this was ridiculous. They didn't want to have to cut prices on the 990 "minis", and they therefore didn't have an ethos of providing maximum performance at minimum cost. John Savard
Reply by Quadibloc January 21, 20112011-01-21
On Jan 18, 10:44=A0pm, Rocky <robertg...@gmail.com> wrote:

> The 990/9 was made in 1973. Later when the 9900 chip was available the > made the 990/4 using it.
Even though I programmed the 990/4, I don't recall ever even seeing a magazine advertisement for the 990/9. I had no idea that such a machine existed, although I knew of at least one of the 960 or the 980 as incompatible antecedents to the 990. John Savard
Reply by toby January 19, 20112011-01-19
On Dec 28 2010, 5:02=A0am, David Brown
<da...@westcontrol.removethisbit.com> wrote:
> On 28/12/2010 03:35, George Neuner wrote: > > > > > > > On Sat, 25 Dec 2010 19:39:30 -0800 (PST), larwe<zwsdot...@gmail.com> > > wrote: > > >> On Dec 25, 9:45 pm, George Neuner<gneun...@comcast.net> =A0wrote: > > >>> I have no idea whether 6502 compatible chips are in demand for any > >>> purpose. > >>> Even so, I wouldn't bother with the 6502, but rather I would implemen=
t
> >>> the 65816 (or the 65802 if you need 6502 pin compatibility). =A0The > > >> At least until a year or two ago, Sunplus had a range of chips that > >> were 6502 core with some restrictions (IIRC no Y register and maybe a > >> couple of other oddities). Winbond and a couple of others also use > >> 6502 or 65816 cores in their toy chips. > > > There are a number of second sources for 6502's, but they aren't all > > the same chip ... several manufacturers (incompatibly) extended the > > original instruction set to add unconditional branching and a variety > > of bit manipulation instructions. =A0Some of the extended variants have > > instruction sets that conflict with the official 65c02 instruction > > set. > > I think Rockwell made an enhanced version of the 6502 for the later BBC > micros (the BBC Master). > > > > > > > I hadn't heard about variants missing an index register ... that would > > effectively cripple the chip regardless of which register was missing. > > The "indexed indirect" (pointer table) address mode depends on X and > > "indirect indexed" (pointer+offset) mode depends on Y. =A0You can work > > around lacking either of these, but the code would be both larger and > > slower. > > > AFAIK, Western Design Center is the only source for 65816. > > >> I guess it depends on whether > >> you already have proprietary dev tools (for compiling proprietary > >> languages, building audio projects, assembling LCD data, etc) that > >> target 6502. > > > There are freely available native and cross development tools > > targeting both the 6502 and 65816: C and Pascal compilers, Forths, and > > a whole selection of assemblers and disassemblers. > > There were a range of programming languages available for the BBC > Masters, including Pascal, C, Forth and Logo, running native on the > 6502. =A0I don't remember whether the Pascal was a full compiler
The C certainly wasn't full C. I think the Pascal was a subset (no recursion, iirc?) To get full blown languages you needed a Tube system - my school had a nice Z80 CP/M Tube BBC clone with an integrated colour screen.
> or used > P-Code. =A0And Acorn's Basic was always viewed as one of the best Basic > variants around, and had a built-in assembler.
It was excellent; I used it for years (and heavily exercised that assembler).
> > Of course, native BBC Micro software is perhaps not the most useful > starting point for cross development... > > > > > Freely available from Apple are the APW 65816 assembler and C compiler > > (you needs a //gs to run these) and the corresponding MPW 65816 cross > > development tools for the Macintosh.
I never saw these. Where would you get them today? (Apple recently pulled their FTP site which formerly hosted MPW, but not these tools, unless they were in a directory apart from the main distribution.)
> > > There is a proprietary MPW Pascal compiler for the 65816 but, AFAIK, > > it isn't available free. =A0TML Pascal (//gs) is available free.
I used TML Pascal in the 1980s for Macintosh. Nice environment but Lightspeed (later THINK then Symantec) Pascal and Lightspeed C eventually killed off the competition :)
> > > George
Reply by toby January 19, 20112011-01-19
On Jan 2, 12:23=A0pm, k...@kymhorsell.com wrote:
> In comp.arch n...@cam.ac.uk wrote: > > ...> diagnostics, but some of the degradation is fundamental. =A0Where > > timing problems were rare and obscure, now they are common and > > ubiquitous. > > > Even 40 years ago, it was EXTREMELY rare to have to cancel a whole > > project because of a failure mode IN PRODUCTION EQUIPMENT which > > couldn't be located or even reduced to a tolerable level, but > > nowadays it is merely unusual. =A0In a few decades, it may even > > become common. > > ... > > There is something to this. :) > ... > Just a couple years back I worked on an embedded system to provide simul =
data,
> SMS and multi-channel voice over a 3g network. Not only was the wireless > module quirky (I am being charitable) with at least 50% of its > executive summary functionality undocumented and maybe > not-entirely-thought-out, but the large multinational responsible seemed > uncooperative in getting our product past a prototype stage. > ... > The development of consumer-level products is largely a matter > of stage magic. Provided the end user (or even your supervisor :) > doesn't know exactly what your gadget is doing, it can *appear* to work f=
ine.
> As in the music hall, a bit of misdirection in the form > of =A0a "simplified explanation" or 2, a few flashing leds, > and a couple of potted "information messages" can convince observers > the product is not only doing its job but miraculously exceeding design s=
pecs.
> > Just -- *please* -- don't look behind the curtain. >
Do you think this low investment in quality is due to the ever- shortening product life cycles? And that business model tends more and more to encouraging turnover/upgrades? This also seems to explain why consumer product user interfaces (e.g. cellphones) are so awful and getting worse.
> -- > Generally, an empty answer. Try again. > =A0 -- John Stafford <n...@droffats.net>, 08 Dec 2010 10:16:59 -0600
Reply by Tim McCaffrey January 19, 20112011-01-19
In article <f8e8136e-a857-46b8-b3ed-3cb1e267a715@m7g2000vbn.googlegroups.com>, 
gnuarm@gmail.com says...
> >On Jan 18, 4:11=A0pm, Quadibloc <jsav...@ecn.ab.ca> wrote: >> On Dec 24 2010, 1:06=A0pm, D Yuniskis <not.going.to...@seen.com> wrote: >> >> > Then TI came along suffering some major hallucinations with their >> > 99xx(x)'s... =A0:-/ =A0(clean idea but technology went a different >> > way). >> >> Well, they simply adopted a desperate strategy to make a 16-bit >> processor with a general-register architecture possible with the >> minimum number of transistors on the chip itself. As soon as more >> transistors on the chip would become possible, _of course_ that would >> no longer be needed. >> >> John Savard > >TI making the TMS9900 family had nothing to do with "desperation". It >was simply an LSI version of the TI-990 minicomputer, much like the >LSI-11 being DEC's chip level implementation of their PDP-11 >minicomputer. > >The reason the TI computers didn't have internal registers was because >at the time it was conceived, CPU speed was limited by the speed of >memory and when TI started making memory chips to replace slow >magnetic core memory, it only made sense to utilize main memory based >workspaces rather than a tiny register set on the CPU chip. What >diminished the utility of this approach was not the number of >transistors, but the speeds that ultimately were obtained that could >not be duplicated going off chip. That is the same reason why CPU >makers ultimately started incorporating cache memory on the CPU die >rather than using off chip fast, static RAM. Before it became viable >to include the cache on the CPU die, they made CPU modules that >included RAM chips along with a CPU packaged to minimize the speed >penalty of going between chips. But ultimately this was a major >limiting factor in CPU clock rates and had to go. >
[snip] I remember an announcment from TI stating that later 990 Minis actually cached the registers on chip (when you changed the workspace register it did a writeback of "dirty" registers). Their claim was that the result was just as fast as the typical on-chip registers, but they got to maintain backward compatibility. My big disappointment was their personal computer (TI-99?), they wrote an interpreter that was used to implement an interpreter for Basic, and they didn't provide peek/poke or machine language function calls, so you were *forced* to use the slow basic interpreter for everything. The design of the 9900 was very elegant in many respects (the I/O was pretty neat as well, at least it had a low pin count even if it wasn't very fast). They just didn't want to make the leap to 32 or 64 bits with it. When they introduced the TI 99000 you could almost here the collective Doh! throughout the industry. - Tim
Reply by Rocky January 19, 20112011-01-19
On Jan 19, 7:24=A0am, Quadibloc <jsav...@ecn.ab.ca> wrote:
> On Jan 18, 5:18=A0pm, rickman <gnu...@gmail.com> wrote: > > > TI making the TMS9900 family had nothing to do with "desperation". =A0I=
t
> > was simply an LSI version of the TI-990 minicomputer, > > Huh? > > The 9900 came first. > > Then they built the 990/4 which was powered by a 9900. > > Later on, they built a souped-up LSI version, the 990/10, and even > later another version came out with a floating-point capability that > wasn't made available at first. > > John Savard
The 990/9 was made in 1973. Later when the 9900 chip was available the made the 990/4 using it. See http://www.cozx.com/~dpitts/ti990.html
Reply by Quadibloc January 19, 20112011-01-19
On Jan 18, 5:18=A0pm, rickman <gnu...@gmail.com> wrote:

> TI making the TMS9900 family had nothing to do with "desperation". =A0It > was simply an LSI version of the TI-990 minicomputer,
Huh? The 9900 came first. Then they built the 990/4 which was powered by a 9900. Later on, they built a souped-up LSI version, the 990/10, and even later another version came out with a floating-point capability that wasn't made available at first. John Savard
Reply by rickman January 18, 20112011-01-18
On Jan 18, 4:11=A0pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
> On Dec 24 2010, 1:06=A0pm, D Yuniskis <not.going.to...@seen.com> wrote: > > > Then TI came along suffering some major hallucinations with their > > 99xx(x)'s... =A0:-/ =A0(clean idea but technology went a different > > way). > > Well, they simply adopted a desperate strategy to make a 16-bit > processor with a general-register architecture possible with the > minimum number of transistors on the chip itself. As soon as more > transistors on the chip would become possible, _of course_ that would > no longer be needed. > > John Savard
TI making the TMS9900 family had nothing to do with "desperation". It was simply an LSI version of the TI-990 minicomputer, much like the LSI-11 being DEC's chip level implementation of their PDP-11 minicomputer. The reason the TI computers didn't have internal registers was because at the time it was conceived, CPU speed was limited by the speed of memory and when TI started making memory chips to replace slow magnetic core memory, it only made sense to utilize main memory based workspaces rather than a tiny register set on the CPU chip. What diminished the utility of this approach was not the number of transistors, but the speeds that ultimately were obtained that could not be duplicated going off chip. That is the same reason why CPU makers ultimately started incorporating cache memory on the CPU die rather than using off chip fast, static RAM. Before it became viable to include the cache on the CPU die, they made CPU modules that included RAM chips along with a CPU packaged to minimize the speed penalty of going between chips. But ultimately this was a major limiting factor in CPU clock rates and had to go. Now we find that the only real speed limiting factor is the software. Today's CPUs run DOS so fast that a user can't fully utilize the capabilities. As for memory, who would ever need more than 640 KB anyway? That is why the GUI was invented. It makes the computer more easily used by the masses, but more importantly it sucks up all available CPU speed and memory capacity to continue to create demand for ever faster CPUs which are sold along with... new software!!! Good thing food vendors haven't figured out this approach to sales... oh, wait, they have... "Can I Super-Size that for you sir?" Rick