I just saw a tweet from Robin @ 8-Bit Show And Tell concerning a bug in Commodore BASIC that existed in the PET, C64 and VIC-20.
VAL() takes a string and converts it in to a floating point numerical variable. The value of “1E39” is a number in scientific notation, and this appears to cause a problem.
In Microsoft BASIC, the notation “1E39” represents the number 1 multiplied by 10 raised to the power of 39. This is also known as scientific notation, where the “E” indicates the exponent to which the base (10 in this case) is raised. So, “1E39” is equal to 1 * 10^39, which is an extremely large number:
I was in the middle of writing more on my CoCo Base-64 encoding series and stumbled upon some weirdness with the DATA command. Consider this silly program:
0 REM baddata.bas
10 READ A$:IF A$="" THEN END
15 PRINT A$;:GOTO 10
20 DATA ":"
30 DATA HELLO
40 DATA ""
This will print:
:HELLO
I know I could just have done DATA “:HELLO” but stay with me on this..
If you try to combine lines like this:
0 REM baddata.bas
10 READ A$:IF A$="" THEN END
15 PRINT A$;:GOTO 10
20 DATA ":":DATA HELLO
40 DATA ""
…you get this:
Color BASIC DATA quirk.
When I get a moment, I’ll have to look at the ROM disassembly and see what is going on.
In C, “#ifdef” or “#if defined()” are used to hide or include portions of code only if certain conditions are met. For example, my recent *ALL RAM* BBS experiment contains code for using the SD card library as well as the Ethernet library. I used #ifdef around specific blocks of code so I could compile versions with or without either of those libraries. But all is not well in Arduino land. Consider this following, simple example:
In this example, I did not want the fileReadln() function to be included unless I had defined FOO. But, compiling this produces:
ifdef:15: error: ‘File’ was not declared in this scope
ifdef:15: error: expected primary-expression before ‘char’
ifdef:15: error: expected primary-expression before ‘count’
ifdef:15: error: initializer expression list treated as compound expression
Unhelpful. And after wasting some time on this, I started a topic in the Arduino.cc forums to ask if others were experiencing the same thing. And they were. A helpful post from parajew pointed me to this site which helped explain the problem, and offered a workaround:
http://www.a-control.de/arduino-fehler/?lang=en
The pre-processor does some stuff behind the scenes, creating prototypes and including header files where needed, and it just does it wrong. The A-Control site figured out a simple workaround, which I trimmed a bit to just adding this at the top of my scripts:
// BOF preprocessor bug prevent - insert me on top of your arduino-code
// From: http://www.a-control.de/arduino-fehler/?lang=en
#if 1
__asm volatile ("nop");
#endif
…and now either of my examples will compile as intended. Thank you, parajew and A-Control! I can now move on to my next problem…