Forums

Mac and BX-24

Started by tsprap April 9, 2005
I have asked some people this question before in a PM. There might be
someone who knows the answer but my guess is that we would need to trace
the RX/TX/DTR protocol. We know that the host uses DTR to signal to the
BasicX runtime that it wants to transmit or receive something. Also the
download to the runtime involves 2 parts:
- download into the Atmel EEPROM of the initial port settings - there
are 8 bytes of interest here
- download into the SPI EEPROM of the BasicX program

My guess is that the structure is a command code followed by a
bytestream. Verify probably reads the EEPROM back out. There are other
commands for resetting and halting the BasicX runtime as well.

It would certainly be a benefit to the community for someone to figure
out the precise protocol and document it. I don't have the resources to
do it. We could even add it to my series of articles on the internals of
the BasicX platform :)

Mike
http://home.austin.rr.com/perks/basicx/Articles/

>
> Good point. Your right, my comment was based more on one persons
> comments. My
> choice in words could have been better. I have no problem with a
> company choosing to
> support one platform or another. They need to do what is right for
> their business,
> absolutely. My point is that it may make good business sense to
> provide some type of
> support for alternative (non Windows) operating systems. The community
> of people who
> use linux, and develop tool for linux, are also the same group of
> people who could and
> would be interested in products like this. Especially if there basic
> support or an open
> framework to access the hardware. If you think solely in terms of
> market share then and
> only look at those numbers, then you are missing a large part of the
> "likely" group of
> product users. Windows has a huge installed base, and massive market
> share. But look at
> it in terms of percentage of population. DIY users who use linux would
> be more attracted
> to projects like this than the average home/business windows user.
> This is just the nature
> of the population of users right now. Whether or not it makes business
> sense is something
> a business needs to weigh. Personally, if the cool things that can be
> done with these
> things was better known to a wider group of more likely customers,
> growth would be
> inevitable. As a consumer we weigh value differently. For me, as a
> multi platform user, I
> hold great value in products that give me the freedom to choose where
> and how I use it.
> The openness and accessibility of the NetMedia products is very cool.
> The diy nature of
> their products is a perfect example of niche product that doen't have
> to be so niche. Make
> the hardware accessible on other platforms, the word will get out,
> NetMedia will sell more
> product and the community will grow. I am excited to be building with
> these again.
>
> Is there documentation on how the serial interface is accessed?
> Protocol, compiling, etc... I
> have not taken the time to look in a long while, but if it is, I will
> see if I can put something
> together. For the community, and the users of non windows os'es > --- In basicx@basi..., "Tom Becker" <gtbecker@r...> wrote:
> > > ... at least the community seems more open...
> >
> > Is that due to one person's comment?
> >
> > Is there some fault in a manufacturer choosing which platforms to
> > support? If you operated a business, would the following typical
> > headline entice you to invest in tools for Macs?
> >
> > "Apple Could Grow Global PC Market Share To 5% In 2005"
> > http://www.forbes.com/markets/2005/03/18/0318automarketscan10.html
> >
> >
> > Tom
> >
> >
> >
> > Tom Becker
> > --... ...--
> > GTBecker@R... www.RighTime.com
> > The RighTime Clock Company, Inc., Cape Coral, Florida USA
> > +1239 540 5700 > *>.




I had an exchange with Chris yesterday that convinced me that you can
program a BX-24 using the avr-gcc tooset native on a mac or *nix box by
attaching an SPI programmer to the SPI pins of the BX-24. For example,
I have a $30 avr-isp programmer, and I think it shouldn't be too hard
to hook it up to a BX. Haven't tried it yet, but I will soon. That's
halfway there.

The other half is for someone to wrap the tokenizer in a *nix engine,
then link it to uisp. I was very excited to see the tokenizer
released, even. I would like to see this happen, because frankly, I
like the basicx environment better than I do the avr-gcc,

But for those mac users who want to program AVRs native, there are a
ton of pages on how to do it. I just added another for newbies
yesterday.

http://stage.itp.tsoa.nyu.edu/~tigoe/pcomp/vendor/archives/001081.shtml On Apr 14, 2005, at 8:25 PM, Mike Perks wrote:

>
> I have asked some people this question before in a PM. There might be
> someone who knows the answer but my guess is that we would need to
> trace
> the RX/TX/DTR protocol. We know that the host uses DTR to signal to the
> BasicX runtime that it wants to transmit or receive something. Also the
> download to the runtime involves 2 parts:
> - download into the Atmel EEPROM of the initial port settings - there
> are 8 bytes of interest here
> - download into the SPI EEPROM of the BasicX program
>
> My guess is that the structure is a command code followed by a
> bytestream. Verify probably reads the EEPROM back out. There are other
> commands for resetting and halting the BasicX runtime as well.
>
> It would certainly be a benefit to the community for someone to figure
> out the precise protocol and document it. I don't have the resources to
> do it. We could even add it to my series of articles on the internals
> of
> the BasicX platform :)
>
> Mike
> http://home.austin.rr.com/perks/basicx/Articles/
>
>>
>> Good point. Your right, my comment was based more on one persons
>> comments. My
>> choice in words could have been better. I have no problem with a
>> company choosing to
>> support one platform or another. They need to do what is right for
>> their business,
>> absolutely. My point is that it may make good business sense to
>> provide some type of
>> support for alternative (non Windows) operating systems. The community
>> of people who
>> use linux, and develop tool for linux, are also the same group of
>> people who could and
>> would be interested in products like this. Especially if there basic
>> support or an open
>> framework to access the hardware. If you think solely in terms of
>> market share then and
>> only look at those numbers, then you are missing a large part of the
>> "likely" group of
>> product users. Windows has a huge installed base, and massive market
>> share. But look at
>> it in terms of percentage of population. DIY users who use linux would
>> be more attracted
>> to projects like this than the average home/business windows user.
>> This is just the nature
>> of the population of users right now. Whether or not it makes business
>> sense is something
>> a business needs to weigh. Personally, if the cool things that can be
>> done with these
>> things was better known to a wider group of more likely customers,
>> growth would be
>> inevitable. As a consumer we weigh value differently. For me, as a
>> multi platform user, I
>> hold great value in products that give me the freedom to choose where
>> and how I use it.
>> The openness and accessibility of the NetMedia products is very cool.
>> The diy nature of
>> their products is a perfect example of niche product that doen't have
>> to be so niche. Make
>> the hardware accessible on other platforms, the word will get out,
>> NetMedia will sell more
>> product and the community will grow. I am excited to be building with
>> these again.
>>
>> Is there documentation on how the serial interface is accessed?
>> Protocol, compiling, etc... I
>> have not taken the time to look in a long while, but if it is, I will
>> see if I can put something
>> together. For the community, and the users of non windows os'es
>>
>>
>> --- In basicx@basi..., "Tom Becker" <gtbecker@r...> wrote:
>>>> ... at least the community seems more open...
>>>
>>> Is that due to one person's comment?
>>>
>>> Is there some fault in a manufacturer choosing which platforms to
>>> support? If you operated a business, would the following typical
>>> headline entice you to invest in tools for Macs?
>>>
>>> "Apple Could Grow Global PC Market Share To 5% In 2005"
>>> http://www.forbes.com/markets/2005/03/18/0318automarketscan10.html
>>>
>>>
>>> Tom
>>>
>>>
>>>
>>> Tom Becker
>>> --... ...--
>>> GTBecker@R... www.RighTime.com
>>> The RighTime Clock Company, Inc., Cape Coral, Florida USA
>>> +1239 540 5700
>>
>>
>>
>>
>> ----------------------------------
>> --
>> *>.
>>
> >
>
> Yahoo! Groups Links
--
Tom Igoe


Thanks! I'll give it a try and report back. On Apr 15, 2005, at 10:36 AM, Mike Perks wrote:

>
> Tom,
>
> Just to clarify here. Chris is suggesting that you can take a BXB file
> and download into the SPI EEPROM on the BX-24. Writing to the chip
> EEPROM is not going to help - this is where Chris may have
> misunderstood
> what you were asking. I'm not aware that the AVR ISP programmer has
> this
> capability and you might need a different piece of hardware to do this.
> Here is a link to a programmer that you may be able to use to program
> the SPI EEPROM
> (http://www.artek.it/it/scheda_it.cfm?" target="_blank" rel="nofollow">http://www.artek.it/index.cfm?http://www.artek.it/it/scheda_it.cfm?
> s_prodotto(4l
> and http://www.lancos.com/e2p/si-prog-v2_2.pdf ). I think you also need
> to temporaily attach to pin 1 on the EEPROM for the SPI CS signal.
>
> Mike
>
>> I had an exchange with Chris yesterday that convinced me that you can
>> program a BX-24 using the avr-gcc tooset native on a mac or *nix box
>> by
>> attaching an SPI programmer to the SPI pins of the BX-24. For
>> example,
>> I have a $30 avr-isp programmer, and I think it shouldn't be too hard
>> to hook it up to a BX. Haven't tried it yet, but I will soon. That's
>> halfway there.
>>
>> The other half is for someone to wrap the tokenizer in a *nix engine,
>> then link it to uisp. I was very excited to see the tokenizer
>> released, even. I would like to see this happen, because frankly, I
>> like the basicx environment better than I do the avr-gcc,
>>
>> But for those mac users who want to program AVRs native, there are a
>> ton of pages on how to do it. I just added another for newbies
>> yesterday.
>>
>> http://stage.itp.tsoa.nyu.edu/~tigoe/pcomp/vendor/archives/
>> 001081.shtml
>> <http://stage.itp.tsoa.nyu.edu/%7Etigoe/pcomp/vendor/archives/
>> 001081.shtml>
>>
>>
>>
>>
>>
>> On Apr 14, 2005, at 8:25 PM, Mike Perks wrote:
>>
>>>
>>> I have asked some people this question before in a PM. There might be
>>> someone who knows the answer but my guess is that we would need to
>>> trace
>>> the RX/TX/DTR protocol. We know that the host uses DTR to signal to
>>> the
>>> BasicX runtime that it wants to transmit or receive something. Also
>>> the
>>> download to the runtime involves 2 parts:
>>> - download into the Atmel EEPROM of the initial port settings - there
>>> are 8 bytes of interest here
>>> - download into the SPI EEPROM of the BasicX program
>>>
>>> My guess is that the structure is a command code followed by a
>>> bytestream. Verify probably reads the EEPROM back out. There are
>>> other
>>> commands for resetting and halting the BasicX runtime as well.
>>>
>>> It would certainly be a benefit to the community for someone to
>>> figure
>>> out the precise protocol and document it. I don't have the resources
>>> to
>>> do it. We could even add it to my series of articles on the internals
>>> of
>>> the BasicX platform :)
>>>
>>> Mike
>>> http://home.austin.rr.com/perks/basicx/Articles/
>>>
>>>>
>>>> Good point. Your right, my comment was based more on one persons
>>>> comments. My
>>>> choice in words could have been better. I have no problem with a
>>>> company choosing to
>>>> support one platform or another. They need to do what is right for
>>>> their business,
>>>> absolutely. My point is that it may make good business sense to
>>>> provide some type of
>>>> support for alternative (non Windows) operating systems. The
>>>> community
>>>> of people who
>>>> use linux, and develop tool for linux, are also the same group of
>>>> people who could and
>>>> would be interested in products like this. Especially if there basic
>>>> support or an open
>>>> framework to access the hardware. If you think solely in terms of
>>>> market share then and
>>>> only look at those numbers, then you are missing a large part of the
>>>> "likely" group of
>>>> product users. Windows has a huge installed base, and massive market
>>>> share. But look at
>>>> it in terms of percentage of population. DIY users who use linux
>>>> would
>>>> be more attracted
>>>> to projects like this than the average home/business windows user.
>>>> This is just the nature
>>>> of the population of users right now. Whether or not it makes
>>>> business
>>>> sense is something
>>>> a business needs to weigh. Personally, if the cool things that can
>>>> be
>>>> done with these
>>>> things was better known to a wider group of more likely customers,
>>>> growth would be
>>>> inevitable. As a consumer we weigh value differently. For me, as a
>>>> multi platform user, I
>>>> hold great value in products that give me the freedom to choose
>>>> where
>>>> and how I use it.
>>>> The openness and accessibility of the NetMedia products is very
>>>> cool.
>>>> The diy nature of
>>>> their products is a perfect example of niche product that doen't
>>>> have
>>>> to be so niche. Make
>>>> the hardware accessible on other platforms, the word will get out,
>>>> NetMedia will sell more
>>>> product and the community will grow. I am excited to be building
>>>> with
>>>> these again.
>>>>
>>>> Is there documentation on how the serial interface is accessed?
>>>> Protocol, compiling, etc... I
>>>> have not taken the time to look in a long while, but if it is, I
>>>> will
>>>> see if I can put something
>>>> together. For the community, and the users of non windows os'es
>>>>
>>>>
>>>> --- In basicx@basi..., "Tom Becker" <gtbecker@r...> wrote:
>>>>>> ... at least the community seems more open...
>>>>>
>>>>> Is that due to one person's comment?
>>>>>
>>>>> Is there some fault in a manufacturer choosing which platforms to
>>>>> support? If you operated a business, would the following typical
>>>>> headline entice you to invest in tools for Macs?
>>>>>
>>>>> "Apple Could Grow Global PC Market Share To 5% In 2005"
>>>>> http://www.forbes.com/markets/2005/03/18/0318automarketscan10.html
>>>>>
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>>
>>>>> Tom Becker
>>>>> --... ...--
>>>>> GTBecker@R... www.RighTime.com
>>>>> The RighTime Clock Company, Inc., Cape Coral, Florida USA
>>>>> +1239 540 5700
>>>>
>>> > Yahoo! Groups Links
--
Tom Igoe



--- In basicx@basi..., Mike Perks <basicx@a...> wrote:
> Just to clarify here. Chris is suggesting that you can take a BXB
> file and download into the SPI EEPROM on the BX-24. Writing to the
> chip EEPROM is not going to help - this is where Chris may have
> misunderstood what you were asking.

Be aware, too, that if you rely on the "Chip Dialog" to configure your
I/O ports (a bad idea, in my opinion) the .bxb file does not constitute
the entire program. If you do all of your port/pin configuration in
BasicX code (using PutPin() or Register.DDRC, etc.) then the .bxb file
contains everything that is necessary.

> I think you also need to temporaily attach to pin 1 on the EEPROM
> for the SPI CS signal.

The CS signal for the SPI EEPROM appears on the 7th hole (beside pin 1)
of the set of terminals that run along the end of the BX-24.

Don


> ... the "Chip Dialog" to configure your I/O ports...
> ... port/pin configuration [] using PutPin()...

I'd hoped these served different purposes. Shouldn't the Project/Chip
settings be in effect while the machine is in reset, before code
execution?

There's nothing like a big motor suddenly receiving 100% reverse when
the machine's Reset button is pressed. One of the functions I put in an
output GAL was to put the pin signals in a safe state when in reset; it
would be very useful, I think, if that state could be predefined in the
IDE. Tom
Tom Becker
--... ...--
GTBecker@GTBe... www.RighTime.com
The RighTime Clock Company, Inc., Cape Coral, Florida USA
+1239 540 5700


Tom,

Just to clarify here. Chris is suggesting that you can take a BXB file
and download into the SPI EEPROM on the BX-24. Writing to the chip
EEPROM is not going to help - this is where Chris may have misunderstood
what you were asking. I'm not aware that the AVR ISP programmer has this
capability and you might need a different piece of hardware to do this.
Here is a link to a programmer that you may be able to use to program
the SPI EEPROM
(http://www.artek.it/it/scheda_it.cfm?s_prodotto(4l" target="_blank" rel="nofollow">http://www.artek.it/index.cfm?http://www.artek.it/it/scheda_it.cfm?s_prodotto(4l
and http://www.lancos.com/e2p/si-prog-v2_2.pdf ). I think you also need
to temporaily attach to pin 1 on the EEPROM for the SPI CS signal.

Mike

> I had an exchange with Chris yesterday that convinced me that you can
> program a BX-24 using the avr-gcc tooset native on a mac or *nix box by
> attaching an SPI programmer to the SPI pins of the BX-24. For example,
> I have a $30 avr-isp programmer, and I think it shouldn't be too hard
> to hook it up to a BX. Haven't tried it yet, but I will soon. That's
> halfway there.
>
> The other half is for someone to wrap the tokenizer in a *nix engine,
> then link it to uisp. I was very excited to see the tokenizer
> released, even. I would like to see this happen, because frankly, I
> like the basicx environment better than I do the avr-gcc,
>
> But for those mac users who want to program AVRs native, there are a
> ton of pages on how to do it. I just added another for newbies
> yesterday.
>
> http://stage.itp.tsoa.nyu.edu/~tigoe/pcomp/vendor/archives/001081.shtml
> <http://stage.itp.tsoa.nyu.edu/%7Etigoe/pcomp/vendor/archives/001081.shtml > On Apr 14, 2005, at 8:25 PM, Mike Perks wrote:
>
> >
> > I have asked some people this question before in a PM. There might be
> > someone who knows the answer but my guess is that we would need to
> > trace
> > the RX/TX/DTR protocol. We know that the host uses DTR to signal to the
> > BasicX runtime that it wants to transmit or receive something. Also the
> > download to the runtime involves 2 parts:
> > - download into the Atmel EEPROM of the initial port settings - there
> > are 8 bytes of interest here
> > - download into the SPI EEPROM of the BasicX program
> >
> > My guess is that the structure is a command code followed by a
> > bytestream. Verify probably reads the EEPROM back out. There are other
> > commands for resetting and halting the BasicX runtime as well.
> >
> > It would certainly be a benefit to the community for someone to figure
> > out the precise protocol and document it. I don't have the resources to
> > do it. We could even add it to my series of articles on the internals
> > of
> > the BasicX platform :)
> >
> > Mike
> > http://home.austin.rr.com/perks/basicx/Articles/
> >
> >>
> >> Good point. Your right, my comment was based more on one persons
> >> comments. My
> >> choice in words could have been better. I have no problem with a
> >> company choosing to
> >> support one platform or another. They need to do what is right for
> >> their business,
> >> absolutely. My point is that it may make good business sense to
> >> provide some type of
> >> support for alternative (non Windows) operating systems. The community
> >> of people who
> >> use linux, and develop tool for linux, are also the same group of
> >> people who could and
> >> would be interested in products like this. Especially if there basic
> >> support or an open
> >> framework to access the hardware. If you think solely in terms of
> >> market share then and
> >> only look at those numbers, then you are missing a large part of the
> >> "likely" group of
> >> product users. Windows has a huge installed base, and massive market
> >> share. But look at
> >> it in terms of percentage of population. DIY users who use linux would
> >> be more attracted
> >> to projects like this than the average home/business windows user.
> >> This is just the nature
> >> of the population of users right now. Whether or not it makes business
> >> sense is something
> >> a business needs to weigh. Personally, if the cool things that can be
> >> done with these
> >> things was better known to a wider group of more likely customers,
> >> growth would be
> >> inevitable. As a consumer we weigh value differently. For me, as a
> >> multi platform user, I
> >> hold great value in products that give me the freedom to choose where
> >> and how I use it.
> >> The openness and accessibility of the NetMedia products is very cool.
> >> The diy nature of
> >> their products is a perfect example of niche product that doen't have
> >> to be so niche. Make
> >> the hardware accessible on other platforms, the word will get out,
> >> NetMedia will sell more
> >> product and the community will grow. I am excited to be building with
> >> these again.
> >>
> >> Is there documentation on how the serial interface is accessed?
> >> Protocol, compiling, etc... I
> >> have not taken the time to look in a long while, but if it is, I will
> >> see if I can put something
> >> together. For the community, and the users of non windows os'es
> >>
> >>
> >> --- In basicx@basi..., "Tom Becker" <gtbecker@r...> wrote:
> >>>> ... at least the community seems more open...
> >>>
> >>> Is that due to one person's comment?
> >>>
> >>> Is there some fault in a manufacturer choosing which platforms to
> >>> support? If you operated a business, would the following typical
> >>> headline entice you to invest in tools for Macs?
> >>>
> >>> "Apple Could Grow Global PC Market Share To 5% In 2005"
> >>> http://www.forbes.com/markets/2005/03/18/0318automarketscan10.html
> >>>
> >>>
> >>> Tom
> >>>
> >>>
> >>>
> >>> Tom Becker
> >>> --... ...--
> >>> GTBecker@R... www.RighTime.com
> >>> The RighTime Clock Company, Inc., Cape Coral, Florida USA
> >>> +1239 540 5700
> >>
> >>



--- In basicx@basi..., "Tom Becker" <gtbecker@r...> wrote:
> > ... the "Chip Dialog" to configure your I/O ports...
> > ... port/pin configuration [] using PutPin()...
>
> I'd hoped these served different purposes. Shouldn't the
> Project/Chip settings be in effect while the machine is in reset,
> before code execution?

That's not how it works. The AVR is documented as setting all of its
I/O pins to input mode (no pullups) when it is reset. Then it reads
the reads the address at zero (in its Flash memory) and begins
executing there. In the case of the BX-24, that code is the virtual
machine. Although undocumented, I suppose that the VM might read
values in the "system" part of Persistent memory (internal EEPROM)
and configure the I/O ports using the data found there. That still
doesn't address the time between reset and when the VM finally gets
around to configuring the ports.

You need to design your interface hardware so that nothing bad
happens when all of the I/O pins float. For the most part, that
means that all output pins should have external pullups and be active
low. That way, they'll be forced inactive during the reset period.

Just to be clear, my point was that if you rely on the Chip Dialog
for I/O configuration you must remember that the "object code" for
your program is actually in two pieces: the .bxb file and the .prf
file. If you were to give someone just the .bxb file to download,
your program probably won't work correctly.

That's why I strongly suggest that you not rely on the Chip Dialog.
Besides, it's better to have the information right there in the
source file documenting the I/O configuration. For example,

Register.DDRA = bx0011_1111
Register.PORTA = bx0011_0000
Register.DDRC = bx0011_0000
Register.PORTC = bx1111_0000

This also avoids the problem of inadvertently modifying the settings
in the Chip Dialog (or losing the .prf file in a disk crash [do you
save that file in backups?]) and then trying to figure out why your
program no longer works like it should.

Don


Tom Becker wrote:

> > ... the "Chip Dialog" to configure your I/O ports...
> > ... port/pin configuration [] using PutPin()...
>
> I'd hoped these served different purposes. Shouldn't the Project/Chip
> settings be in effect while the machine is in reset, before code
> execution?
>
> There's nothing like a big motor suddenly receiving 100% reverse when
> the machine's Reset button is pressed. One of the functions I put in an
> output GAL was to put the pin signals in a safe state when in reset; it
> would be very useful, I think, if that state could be predefined in the
> IDE.

Last week I experienced this very problem with my motors. Luckily they
are not that powerful. When I first started experimenting with motors I
was using my BX-35 based development board. The PWM output pins just
happen to also be wired to active low push buttons and DIP switches. I
prefer that to avoid needing to flip input values - that is pressing a
button results in a 1.

Anyhow when I wanted to get more mobile I shifted to a BX-24 on a
breadboard. The first time I pressed reset luckily the wheels were
upside down. There was a kick of 100% PWM on one of the outputs. After
checking my code, it took me a few minutes to figure out why - no
pulldown resistors on the inputs to the H-Bridge controller. If you
check my schematic I recently posted you will see a 10K resistor SIL
array (RN1) for just the purpose of tying these chip output to ground.

Don is exactly right in his description about how BasicX loads the I/O
registers from EEPROM sometime after initialization. In fact this is one
of the things I'm going to describe further in the forthcoming part 6 of
my articles about the internals of BasicX. As a taster the initial
values of the port regsiters are held in low EEPROM memory where DDRD is
address 0, PORTD is address 1 and so on up to PORTA at address 10. You
will note that this is the same order as the port registers in the Atmel
chip and that PIND is missing as it is not required. Don and I
conjecture that during BasicX initialization, there is a block copy of
these 11 bytes into the corresponding port registers starting at RAM
address 49. The EEPROM memory is initialized during program download
from the data in the PRF file. It really a shame that NetMedia didn't do
this at the beginning of a BXB file instead.

I also completely agree with Don with his best practices both from a
hardware and a software point of view. Take control of these ports
yourself to make sure nothing inadvertant happens.

Mike
http://home.austin.rr.com/perks/basicx/Articles/




I went ahead and downloaded the BasicX tockenizer and noticed that
they are Visual Basic files. I know there is a Visaul Basic-->Real
Basic project converter. Real Basic is cross compatable so i was
thinking you could covert it to Mac? correct me if i'm wrong --- In basicx@basi..., "borngraphics" <borngraphics@y...>
wrote:
>
> Umm, there is a great attitude. I have just started working with
the BasicX and Basic
> Stamps again after a couple of years of doing other projects. One
of my main problems
> has always been no native mac support for the program uploaders.
The mac is a very
> viable platform, very well suited for this sort of application. I
was originally working on a
> realbasic app for the mac, and the stamps. Now with the Parallax
PBASIC Tokenizer
> Library and macbs2 it is very easy to program those. NetMedia, from
what I have seen has
> no support for any *nix system. A simple downloader is not to
complicated, and if I can
> find the time I will see if I can put one together. The goal would
be to write one *nix
> compatible serial downloader, even if you have to use the os x
terminal and a great text
> editor like TextWrangler / BBEdit, it would be a start.
>
> VNC is not a real option for me, because I do a lot of this from a
PowerBook. Virtual PC is a
> ridiculous option because of the bloated over head that has to run
for essentially a text
> editor and serial connection. Ouch.. To lump a request for basic
mac support with C64,
> TRS-80, etc... is foolish. Integrating control of a stamp, with
things such as shell scripting,
> and applescript become pretty awesome once we have a quick and
dirty way to natively
> upload to the BasicX...
>
> tsprap, look at the stamps again, and brainstems by acroname. You
will find osx support
> there. Even if not native to the company, at least the community
seems more open.
>
> --- In basicx@basi..., "James R. Parish" <homer@j...> wrote:
> > And while they are at it they could make versions for the C64,
ATARI800,
> > TRS-80 and TI99...
> >
> > -----Original Message-----
> > From: tsprap [mailto:tsprap@y...]
> > Sent: Saturday, April 09, 2005 8:00 PM
> > To: basicx@basi...
> > Subject: [BasicX] Mac and BX-24
> >
> >
> >
> > This is just a sugestion. I'm mainly a Mac user and don't like
> > switching between Mac & PC to program the BasicX. Couldn't
NetMedia
> > make a Mac version of their editor/downloader? I would make my
own, but
> > i'm a novice in progrmaing C/C++, Java, or RealBasic on a
computer.
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links



I assume you mean the bxTokenizer.zip on the NetMedia website. If you
read the source code you will quickly discover that all it does is call
APIs in a DLL named bxcomp141.dll that is part of a Windows install of
BasicX. This is the real problem and means that you need a Windows
emulator on the MAC. If you know how to call a Windows DLL in a MAC
environment then you can simply rewrite the front end in your favorite
language (Basic, C, Java etc).

BTW This also means we could replace the clunky Windows GUI and Editor
with something better. Just needs a little bit of work :)

Mike

>
> I went ahead and downloaded the BasicX tockenizer and noticed that
> they are Visual Basic files. I know there is a Visaul Basic-->Real
> Basic project converter. Real Basic is cross compatable so i was
> thinking you could covert it to Mac? correct me if i'm wrong
>