I really didn't want a conceptual debate either. I just wanted to understand what I thought was BasicX's approach. I am just more of a hardware person and obviously BasicX attracts software people more that the other products due to its sophistication. In particular, I purchased the BX-24 without concerning myself very much about the software. What caught my fancy was the claim for more speed and more instructions. At times I am rushed and when I re-read the tone of my writing I am disappointed with it. I will try to slow down, re-read more before sending, and be more patient. > > I have to respectfully disagree with you. I really didn't want to debate > this subject because it doesn't contribute one iota to using and > understand BasicX. There are plenty of other fora to debate the relative > merits of programming languages and computer architectures. The fact > that your arguments are technically inaccurate is also somewhat > frustrating. I think Tony made some excellent points as well. >

--- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote: > I. too, must disagree, Kramer. > > The whole point of a high level language like basic is to insulate > you from the internals of the hardware. I do understand and appreciate the whole idea of a 'high level language'. It seems though that the microcontroller took what was once Basic and re-invented it into a subset that was focused on controlling pins rather than the manipulation of data or a visual image on a screen via a key board. Once that occured, the RISC seems to be attached as a part of the 'new Basic concept'. I can appreciate that you want to keep the integrity and versatility of BasicX as a high level language and may even think that it should be portable to other processors. Why not the 8051, the PIC and or the SX-Ubicom? I know I have left out a few, but why not all of them? I suspect it is easier to dream of that to muster the resources to do. In any event, I didn't want to drag you fellows into a purely conceptual conversation. I just really wanted to understand why the BX-24, BX-35, and BX-01 are special and capable of unique tasks among the crowd. At times I am very busy with my English teaching duties and my writing suffers. Please forgive the tone if it seems to be too pedantic. My intentions are to try to constructively contribute to discovering more of what BasicX and its related hardware can do. Obviously I am not as far along in the programing as many of you. And it seems that is one of its major appeals - a more sophisticated programing structure that Parallax's PBasic [which has only one dimensional arrays and limited math]. I worked on my BX-35 board today and it is coming along nicely. It is actually smaller than I first mentioned. About 80mm by 64mm at this stage. The ON/OFF switch seems hugely out of place ;-).

G. Kramer Herzog wrote: > > This group is about BasicX and not AVR. I suggest you ask your > question > > on the AVR-Chat group. The answer to your question doesn't make any > > difference, does it? > > > > Mike > > I suppose that I haven't made myself clear. I have to respectfully disagree with you. I really didn't want to debate this subject because it doesn't contribute one iota to using and understand BasicX. There are plenty of other fora to debate the relative merits of programming languages and computer architectures. The fact that your arguments are technically inaccurate is also somewhat frustrating. I think Tony made some excellent points as well. > BasicX is written solely to operate two distinct Amtel AVR chips. > > In is not a portable language that moves from platform to platform > and it both depends on and conceptually originates from the AVR > capabilities. The BASIC language like most 3GLs is VERY portable to other platforms. This is one reason why BASIC has endured for over 25 years. The system library functions are not part of the language per se and do not necessarily port to other platforms as they reflect the capabilities of the underlying hardware. > The whole concept of BASIC languages on RISC microcontrollers seems > particularly related to the Harvard Architecture and the RISC > offering the learner the kind of environment where it becomes easier > to learn the hardware and eventually the assembly language. What has BASIC got to do with computer architectures? The compiler takes care of any differences. Even more so as the BasicX compiler converts a program to an intermediate stack based language which is then interpreted by a virtual machine inside the Atmel RISC chip. I count that as 3 layers of abstraction above the hardware. You may want to read the Atmel paper which should answer all your questions on AVR RISC versus CISC: http://www.compass-lab.com/pdf/AVR_RISC.pdf > Also, I assume that some of us eventually might move into Assembly > language programing if we have enough time and develop a keener > understanding of what the distinct and unusual properties of a > product [the AVR] are. You may chose to do this but as Tony rightly points out most of what you need to do can be done in C. In fact without the 10 to 100x productivity brought by 3GLs we wouldn't have the computer applications of today. Very few companies still use assembly language programming even those people writing device drivers. > Please forgive me, if you don't agree. But, I really find the BX-01 > to be a quite unique and puzzling chip. Unlike the BasicAtom, the > BasicStamp, the PICs, or any other of the 24pin DIP microcontrollers > with somewhat similar Basic language support. I'm not sure why you find the BX-01 puzzling. It does reflect some of the hardware features of the 8515. Obviously NetMedia thought that these would be useful to some people otherwise why bother creating it in the first place? I think the BX-01 was the first chip but ultimately the BX-24/35 was more successful partly because of the range of features of the underlying chip. > Nonetheless, I still am working on understanding the BX-01 as it > seems to be mostly ignored and yet very useful. You must admit that > you have set aside the BX-01,too. I didn't set aside the BX-01. I looked at the features of the various chips against what I wanted to do and decided that the BX-35 most suitable. Other people have different criteria and so may choose something else. > And, you cannot fully understand features such as Capture or Analogue > to Digital without opening the hood and looking at the hardware. Really? I have never had to read the Atmel hardware datasheet to understand how to use a BasicX system library function. The documentation could be better, of course, but GetADC is almost self-explanatory. Mike

I. too, must disagree, Kramer. The whole point of a high level language like basic is to insulate you from the internals of the hardware. This basic running on the little uC is extremely similar to other versions running on very different hardware. Unless you decide to interact with hardware registers, you would never know what you are running on (except for memory limitations) Learning BasicX in no way prepares you for Assembly Language, other than teaching you logic and stuff. However, I think that ASM has a more limited application than you seem to indicate. Getting down to the level of ASM is not necessary for most of us. I _do_ find that the strong typing required my BasicX is very similar to C. As a matter of fact, I can port my basic code to C VERY easily. C is much easier to maintain than ASM. These days, I think most stuff is being written in a higher level language, like C, then there may be hand-coded ASM routines for the bottlenecks For instance, I started the design of a rally computer in BAsicX, mostly to see if it could be done, and to see what the constrains were. Once I got it working in a simple manner, and had the external hardware somewhat functional, I could choose the AVR hardware to get down to some real horsepower. I ended up with an ATMega128. Now I am testing some new hardware (realtime clock and precision oscillator) on the BX, and once I get the hardware and interface algorithm, I will re-write it in C for the AVR. (I am considering a Ramtron combined RTC, and 32KB Ferroelectric RAM). Using the BX allows me to do the basic stuff and get it working easily and smoothly before I rip up my development board with the ARV hardware, LCD displays, switches, etc. I really like the BX for its simplicity and INSULATION from the hardware. -Tony --- In basicx@basi..., "G. Kramer Herzog" <hwanghetw@y...> wrote: > > > This group is about BasicX and not AVR. I suggest you ask your > question > > on the AVR-Chat group. The answer to your question doesn't make any > > difference, does it? > > > > Mike > > I suppose that I haven't made myself clear. > > BasicX is written solely to operate two distinct Amtel AVR chips. > > In is not a portable language that moves from platform to platform > and it both depends on and conceptually originates from the AVR > capabilities. > > The whole concept of BASIC languages on RISC microcontrollers seems > particularly related to the Harvard Architecture and the RISC > offering the learner the kind of environment where it becomes easier > to learn the hardware and eventually the assembly language. > > Both BasicX and the AVR seem to explore the boundaries more than > their competators. > > Also, I assume that some of us eventually might move into Assembly > language programing if we have enough time and develop a keener > understanding of what the distinct and unusual properties of a > product [the AVR] are. > > Please forgive me, if you don't agree. But, I really find the BX- 01 > to be a quite unique and puzzling chip. Unlike the BasicAtom, the > BasicStamp, the PICs, or any other of the 24pin DIP microcontrollers > with somewhat similar Basic language support. > > I enjoy your contributions to identifying the 'BasicX way of > programing'. It seems that is a quite powerful and easily integrated > software [uses Visual Basic to some extent, so you can create GUI in > the Windows environment to interface with the BX-01, BX-35, or BX- 24]. > > Nonetheless, I still am working on understanding the BX-01 as it > seems to be mostly ignored and yet very useful. You must admit that > you have set aside the BX-01,too. The larger instruction set and the > multiplexed data and addressing are certainly used in BasicX in the > BX-01. > > And, you cannot fully understand features such as Capture or Analogue > to Digital without opening the hood and looking at the hardware.

--- In basicx@basi..., "G. Kramer Herzog" <hwanghetw@y...> wrote: > [BasicX] is not a portable language that moves from platform to > platform and it both depends on and conceptually originates > from the AVR capabilities. This assertion is incorrect, in my opinion. The BasicX language itself has nothing to do directly with the hardware on which it is implemented. The language would be no different if the virtual machine were re-targeted to an MCU with a von Neumann architecture, e.g. 68HC01, or if it were re-targeted to your x86-based PC or even the PIC. Some aspects of the System Library routines are specific to the AVR microcontrollers and might need to be changed if a different MCU were targeted. However, I cannot see anything in the System Library routines that remotely suggests that they are implemented on a RISC- based architecture. The only hint of Harvard architecture is that there are different functions for accessing RAM and EEPROM. That distinction would probably not be necessary for an underlying von Neumann architecture. > The whole concept of BASIC languages on RISC microcontrollers > seems particularly related to the Harvard Architecture and the > RISC offering the learner the kind of environment where it > becomes easier to learn the hardware and eventually the assembly > language. I don't see the connection at all. Your assertion is somewhat akin to suggesting that driving a car that has diesel engine will make it easier to become an expert diesel mechanic. The driving experience is not much different whether the vehicle is a gasser, a diesel or a hybrid. The casual user may not even notice a difference. On the other hand, an experienced mechanic or engineer might. Don

> This group is about BasicX and not AVR. I suggest you ask your question > on the AVR-Chat group. The answer to your question doesn't make any > difference, does it? > > Mike I suppose that I haven't made myself clear. BasicX is written solely to operate two distinct Amtel AVR chips. In is not a portable language that moves from platform to platform and it both depends on and conceptually originates from the AVR capabilities. The whole concept of BASIC languages on RISC microcontrollers seems particularly related to the Harvard Architecture and the RISC offering the learner the kind of environment where it becomes easier to learn the hardware and eventually the assembly language. Both BasicX and the AVR seem to explore the boundaries more than their competators. Also, I assume that some of us eventually might move into Assembly language programing if we have enough time and develop a keener understanding of what the distinct and unusual properties of a product [the AVR] are. Please forgive me, if you don't agree. But, I really find the BX-01 to be a quite unique and puzzling chip. Unlike the BasicAtom, the BasicStamp, the PICs, or any other of the 24pin DIP microcontrollers with somewhat similar Basic language support. I enjoy your contributions to identifying the 'BasicX way of programing'. It seems that is a quite powerful and easily integrated software [uses Visual Basic to some extent, so you can create GUI in the Windows environment to interface with the BX-01, BX-35, or BX-24]. Nonetheless, I still am working on understanding the BX-01 as it seems to be mostly ignored and yet very useful. You must admit that you have set aside the BX-01,too. The larger instruction set and the multiplexed data and addressing are certainly used in BasicX in the BX-01. And, you cannot fully understand features such as Capture or Analogue to Digital without opening the hood and looking at the hardware.

Well, I sort of agree that this is a little off topic for BASICX issues, but it does apply to our hardware even if we BasicX users do not DIRECTLY see the underlying structures. THese structures do affect what the BasicX designers were able to do, and I suspect that the true RISC chips were inadequate. So, we can thank our lucky stars that the AVRs exist because it allows the BasicX type of chips to exist. As for whether AVRs are truely RISC, well, what are the advantages of RISC? 1) 8 bit instructions, 2) all instructions executing in 1 or 2 clock cycles, preferably 1. These goals are nearly always met with the AVR arcitecture. So, as far as the functions go, the AVRs are very RISC-like. But within these constraints, the AVR designers gave us some more powerful commands to work with. A definite advantage. What's not to like about more program and data memory? More speed would be good too! As long as the CPU efficiency is maintained.... -Tony --- In basicx@basi..., "G. Kramer Herzog" <hwanghetw@y...> wrote: > I look at the documentation for the BX-01 and then I go to Amtel's > site for more hardward information and I just seem to get a bit > confused. > > First of all, Amtel does define the BasicX microprocessors as reduced > instruction set [RISC]. The whole idea was to eliminate the > complexity of Assembly language encoding. > > But Amtel's AVR RISC has 100 or so instructions [where as Microchip's > PIC has about 30 and so does SX-Ubicom]. > > So, why do they claim to have RISC? > > Then we get into the memory architecture of Harvard versus VonNeuman. > PIC and SX-UBicom are clearly Harvard, but the BX-01 appears to be > using a system of addressing that is quite similar to VonNeuman. > Granted that maybe you cannot easily mix program and data in RAM, but > you certainly have a lot more RAM to play with that the other Harvard > chips. > > In sum, I really am struggling to come to terms with how the Amtel > AVR thinks of itself in terms of usefulness. It is somewhere between > the two more typical solutions. Is it special because of this or > just an big complex machine?

G. Kramer Herzog wrote: > In sum, I really am struggling to come to terms with how the Amtel > AVR thinks of itself in terms of usefulness. It is somewhere between > the two more typical solutions. Is it special because of this or > just an big complex machine? > This group is about BasicX and not AVR. I suggest you ask your question on the AVR-Chat group. The answer to your question doesn't make any difference, does it? Mike

I look at the documentation for the BX-01 and then I go to Amtel's site for more hardward information and I just seem to get a bit confused. First of all, Amtel does define the BasicX microprocessors as reduced instruction set [RISC]. The whole idea was to eliminate the complexity of Assembly language encoding. But Amtel's AVR RISC has 100 or so instructions [where as Microchip's PIC has about 30 and so does SX-Ubicom]. So, why do they claim to have RISC? Then we get into the memory architecture of Harvard versus VonNeuman. PIC and SX-UBicom are clearly Harvard, but the BX-01 appears to be using a system of addressing that is quite similar to VonNeuman. Granted that maybe you cannot easily mix program and data in RAM, but you certainly have a lot more RAM to play with that the other Harvard chips. In sum, I really am struggling to come to terms with how the Amtel AVR thinks of itself in terms of usefulness. It is somewhere between the two more typical solutions. Is it special because of this or just an big complex machine?