BasicX 2.10 Compiler Bug?

Started by mdrapal2000 December 22, 2003
Seems that there was a bug introduced in the later version of the
2.10 compiler on the NetMedia site. Specifically, for those who try
to use a Ram Sandwich and enable *both* extended RAM and I/o, the
compiler will complain that there is more than 528 bytes of memory
used to hold static data (well duh, extended RAM almost always looks
like that). If you enable just extended RAM, the compile works, but
the buttons cause the code to go nuts (because this uses extended
I/O). I think that this bug was introduced when the Chip Menu page
was enhanced to allow the larger EEPROM - seems that the version
before handled this properly. Another pointer to the same problem,
I think, is that if you set the Extended RAM and IO box, Press OK,
and then come back to the dialog, it isn't remembered like the
others are. Maybe this is the reason that the compiler is acting as
if extended RAM is turned off?

BTW, I tried to download the Beta 2 version from the Netmedia site,
to see if maybe this had been fixed in the beta version.
Unfortunately, the ZIP file is corrupt (bad CRC), so I couldn't tell.

Myron Drapal



From: mdrapal2000 <>

> Seems that there was a bug introduced in the later
> version of the 2.10 compiler on the NetMedia site.
> Specifically, for those who try to use a Ram
> Sandwich and enable *both* extended RAM and I/o
[...]

OK, we'll look at this.

> I think that this bug was introduced when the Chip
> Menu page was enhanced to allow the larger EEPROM
> - seems that the version before handled this
> properly. [...]

In other words, V2.0 handled this properly? Or are you referring
to a previous beta test version of the compiler?

> BTW, I tried to download the Beta 2 version from
> the Netmedia site, to see if maybe this had been
> fixed in the beta version. Unfortunately, the ZIP
> file is corrupt (bad CRC), so I couldn't tell.

Well, we normally make previous compiler releases available, but
not beta test versions. I'm surprised this is still on our site.

-- Frank Manning
-- NetMedia, Inc.



Frank,

Thanks for your quick response to this. I'm sure that you are
probably on Christmas break (or will be shortly), so you don't
need "just one more bug" right at this momoent ;)...

Anyway, when I wrote "previous versions of the compiler", I was
alluding to the (maybe pre-release) of the 2.10 compilers, before
the addition of the support for the larger than 32K eeprom. At the
time that I was using them, they were (most probably) on your beta
site, as it seems that this project would not have ever compiled
under the older 2.0 compiler. I happen to have the older install
for the 2.0 compiler and tried that one last night (just for grins),
and got a syntax error immediately (something about passing strings
as arguments to functions - I think that this is one of the
enhancements in the 2.10 compiler, so this is what makes me think
that this wouldn't have ever been compiled under the 2.0 compiler).
I think I may spend a little time with it this week and see if I can
force it to compile under the 2.0 compiler, just to see if I can get
it running again, but I would be willing to test any fixes you might
find for this as all of my other projects use the 2.10 compiler.

BTW, thanks again for your quick reply. I am really impressed with
the NetMedia products. I've tried a few others and have stuck with
the BasicX line simply because it does what it says it does. Any
problems that I have had almost always been of my own making ;).
And this includes the SitePlayer product - I just completed adding a
SitePlayer to my BasicX Sprinkler System (yea, it's overkill, but
it's way cool...).

Myron Drapal --- In , "Frank Manning" <fmanning@n...> wrote:
> From: mdrapal2000 <drapal@h...>
>
> > Seems that there was a bug introduced in the later
> > version of the 2.10 compiler on the NetMedia site.
> > Specifically, for those who try to use a Ram
> > Sandwich and enable *both* extended RAM and I/o
> [...]
>
> OK, we'll look at this.
>
> > I think that this bug was introduced when the Chip
> > Menu page was enhanced to allow the larger EEPROM
> > - seems that the version before handled this
> > properly. [...]
>
> In other words, V2.0 handled this properly? Or are you referring
> to a previous beta test version of the compiler?
>
> > BTW, I tried to download the Beta 2 version from
> > the Netmedia site, to see if maybe this had been
> > fixed in the beta version. Unfortunately, the ZIP
> > file is corrupt (bad CRC), so I couldn't tell.
>
> Well, we normally make previous compiler releases available, but
> not beta test versions. I'm surprised this is still on our site.
>
> -- Frank Manning
> -- NetMedia, Inc.





Frank,

Do you have any updates on this? Not that I want to seem "pushy",
but I haven't been able to come up with a work-around for this
problem yet. Just a quick status update? Thanks.

Myron Drapal --- In , "mdrapal2000" <drapal@h...> wrote:
> Frank,
>
> Thanks for your quick response to this. I'm sure that you are
> probably on Christmas break (or will be shortly), so you don't
> need "just one more bug" right at this momoent ;)...
>
> Anyway, when I wrote "previous versions of the compiler", I was
> alluding to the (maybe pre-release) of the 2.10 compilers, before
> the addition of the support for the larger than 32K eeprom. At
the
> time that I was using them, they were (most probably) on your beta
> site, as it seems that this project would not have ever compiled
> under the older 2.0 compiler. I happen to have the older install
> for the 2.0 compiler and tried that one last night (just for
grins),
> and got a syntax error immediately (something about passing
strings
> as arguments to functions - I think that this is one of the
> enhancements in the 2.10 compiler, so this is what makes me think
> that this wouldn't have ever been compiled under the 2.0
compiler).
> I think I may spend a little time with it this week and see if I
can
> force it to compile under the 2.0 compiler, just to see if I can
get
> it running again, but I would be willing to test any fixes you
might
> find for this as all of my other projects use the 2.10 compiler.
>
> BTW, thanks again for your quick reply. I am really impressed
with
> the NetMedia products. I've tried a few others and have stuck
with
> the BasicX line simply because it does what it says it does. Any
> problems that I have had almost always been of my own making ;).
> And this includes the SitePlayer product - I just completed adding
a
> SitePlayer to my BasicX Sprinkler System (yea, it's overkill, but
> it's way cool...).
>
> Myron Drapal
> drapal@h...
>
> --- In , "Frank Manning" <fmanning@n...>
wrote:
> > From: mdrapal2000 <drapal@h...>
> >
> > > Seems that there was a bug introduced in the later
> > > version of the 2.10 compiler on the NetMedia site.
> > > Specifically, for those who try to use a Ram
> > > Sandwich and enable *both* extended RAM and I/o
> > [...]
> >
> > OK, we'll look at this.
> >
> > > I think that this bug was introduced when the Chip
> > > Menu page was enhanced to allow the larger EEPROM
> > > - seems that the version before handled this
> > > properly. [...]
> >
> > In other words, V2.0 handled this properly? Or are you referring
> > to a previous beta test version of the compiler?
> >
> > > BTW, I tried to download the Beta 2 version from
> > > the Netmedia site, to see if maybe this had been
> > > fixed in the beta version. Unfortunately, the ZIP
> > > file is corrupt (bad CRC), so I couldn't tell.
> >
> > Well, we normally make previous compiler releases available, but
> > not beta test versions. I'm surprised this is still on our site.
> >
> > -- Frank Manning
> > -- NetMedia, Inc.




From: mdrapal2000 <>

>>>> Specifically, for those who try to use a Ram
>>>> Sandwich and enable *both* extended RAM and I/o
>
> Do you have any updates on this? Not that I
> want to seem "pushy", but I haven't been able
> to come up with a work-around for this problem
> yet. Just a quick status update? Thanks.

We're still looking at this. As a workaround, what happens if you
click on the "External RAM" checkbox rather than "Extended I/O and
RAM"?

In the past I've done that to get access to both the external RAM
and extended I/O.

-- Frank Manning
-- NetMedia, Inc.


From: mdrapal2000 <>
Sent: Sunday, December 21, 2003 9:36 PM

Sorry about the delay in responding.

> Seems that there was a bug introduced in the later
> version of the 2.10 compiler on the NetMedia site.
> Specifically, for those who try to use a Ram Sandwich
> and enable *both* extended RAM and I/o, the compiler
> will complain that there is more than 528 bytes of
> memory
> [...]
> Another pointer to the same problem, I think, is that
> if you set the Extended RAM and IO box, Press OK,
> and then come back to the dialog, it isn't remembered
> like the others are. [...]

This checkbox actually should not be there -- all you need to do
is check "External RAM". That should be enough to also enable
extended I/O.

This should enable all the relevant I/O pins -- the 16
address/data lines (21..28 plus 32..39), plus these control lines:

Pin Description

2 Selects high or low RAM
3 XIO chip select
16 RAM/XIO write enable
17 RAM/XIO read enable

All 20 pins should be functional if you check the External RAM
box.

-- Frank Manning
-- NetMedia, Inc.



Frank,

Well, I went back and tried this again, and it failed again. I was
about ready to give up on this, then I went back to the LCDDriver
example from the RamSandwich examples, and it worked (not any real
surprise though, since it really doesn't exercise the RamSandwich at
all). But looking at the Chip options, I noticed that they were
defaulted differently - specifically, pin 3 was forced high, and pin
15 was forced low. I went back to my project, selected External Ram
and forced these pins to the same states and Voila! - it works! I
guess that in the older version of the compiler that I had where
this worked must have defaulted these pins to their correct state
based on the selection of the "External Ram and I/O" selection,
while the latest compiler, since it no longer supports this
selection explicitly, doesn't know to do this. Anyway, now I'm back
to finding my bugs ;()... Thanks for your help with this.

Myron Drapal --- In , "Frank Manning" <fmanning@n...> wrote:
> From: mdrapal2000 <drapal@h...>
> Sent: Sunday, December 21, 2003 9:36 PM
>
> Sorry about the delay in responding.
>
> > Seems that there was a bug introduced in the later
> > version of the 2.10 compiler on the NetMedia site.
> > Specifically, for those who try to use a Ram Sandwich
> > and enable *both* extended RAM and I/o, the compiler
> > will complain that there is more than 528 bytes of
> > memory
> > [...]
> > Another pointer to the same problem, I think, is that
> > if you set the Extended RAM and IO box, Press OK,
> > and then come back to the dialog, it isn't remembered
> > like the others are. [...]
>
> This checkbox actually should not be there -- all you need to do
> is check "External RAM". That should be enough to also enable
> extended I/O.
>
> This should enable all the relevant I/O pins -- the 16
> address/data lines (21..28 plus 32..39), plus these control lines:
>
> Pin Description
>
> 2 Selects high or low RAM
> 3 XIO chip select
> 16 RAM/XIO write enable
> 17 RAM/XIO read enable
>
> All 20 pins should be functional if you check the External RAM
> box.
>
> -- Frank Manning
> -- NetMedia, Inc.




From: mdrapal2000 <>

> Well, I went back and tried this again, and it failed
> again. I was about ready to give up on this, then I
> went back to the LCDDriver example from the
> RamSandwich examples, and it worked (not any real
> surprise though, since it really doesn't exercise
> the RamSandwich at all).

The LCDDriver itself doesn't need much RAM, so it doesn't need the
additional memory in the RAMSandwich, but I'm not sure the LCD
itself will work without the RAMSandwich.

> But looking at the Chip options, I noticed that
> they were defaulted differently - specifically,
> pin 3 was forced high, and pin 15 was forced low.

Yes, pin 3 needs to be high for the RAMSandwich to work.

I believe pin 15 is required only to control the contrast on the
LCD. The pin is in PWM mode, controlled by Timer1 (which also uses
pin 29 for PWM control of the LCD brightness).

So I think you're free to use pin 15 for other purposes -- that
is, it's not required for either extended I/O or extended RAM.

Pin 3 is a different story.

> I went back to my project, selected External Ram
> and forced these pins to the same states and
> Voila! - it works!

Excellent -- glad to hear it.

> I guess that in the older version of the compiler
> that I had where this worked must have defaulted
> these pins to their correct state based on the
> selection of the "External Ram and I/O" selection,
> while the latest compiler, since it no longer
> supports this selection explicitly, doesn't know
> to do this.

Well, I'll have to double check this. Pin 3 has always needed to
be high to enable the RAMSandwich, even in old versions of the
compiler.

> Anyway, now I'm back to finding my bugs ;()... Thanks
> for your help with this.

You're welcome -- glad to hear it's working now.

-- Frank Manning
-- NetMedia, Inc.