I am porting a little BASIC program to the Apple IIc, using the AppleWin emulator to test it. AppleWin does not have a IIc mode so I'm using the IIe-enhanced mode (the program uses the MouseText font).
I need to generate a "clicking" sound and thus I've inserted this instruction:
S=PEEK(-16336)
This instruction is accepted and works in AppleWin.
But when I typed the program in the real IIc, I got a "syntax error" on the above instruction.
I'm assuming the IIc does not accept a negative value for PEEK, because otherwise it's plain BASIC.
Is it so? How can I replace that instruction on the IIc to generate a "click" noise?
Thanks
You should be able to use
S=PEEK(49200)
This corresponds to address $C030 which is the speaker soft switch.
Thanks! It does seem to work in the emulated IIe; I'll try it ASAP on the IIc and post back the results.
Short generic answer - 64K = 1024 * 64 = 65536. You can get the positive value by adding 65536 to the negative representation. To get the negative value, subtract 65536 from the positive value. The calculators in Windows and MacOS both have a programmer mode where you can see the bit patterns are equivalent. So 65536 + -16336 =49200. Note, the calculator will also show the hexadecimal $C030 value.
The slightly longer, more generic answer is people tend to follow familiar patterns. It turns out that the original Apple ][ and ][ Plus computers used Integer BASIC which preceded AppleSoft floating point BASIC. INT Basic used two's compliment 16 bit integers. Without going into all the binary representation, the 64K values available in 16 bits were balanced around zero. Thus providing a range of values -32K to +32K (more or less). Actually -32767 through +32768 because zero is "in the middle". Unsigned integers (like memory addresses) have a range of 0 through 64K or 0 to 65536. In order to shrink the code to use less memory, INT BASIC used negative numbers to produce the exact bit pattern needed for unsigned integer memory addresses. This avoided the coded needed to convert 2's compliment to unsigned integers. Afterall, the bit patterns were the same and geeks were smart enough to adjust so the machine need not. Later Applesoft versions supported numbers larger than 32K but the habit was already developed for many and perpetuated. In practice, PEEKS and POKESs tended to migrate toward positive values over time. But, CALL statements seemed to always use negative values for any location above 32K.
For most people I knew, the famous Beagle Bros Peeks, Pokes & Calls chart was the beginning of a journey of discovery into all things "secret" inside the machine language ROM code. It would have answered your question and might be of interest to you as you run up against other issues. You find it at http://beagle.applearchives.com/the_posters/poster_2.html and other places.
Now I'm curious. I agree with your choice of Enhanced //e on the emulator to mimic the //c. I will need pull out a //c this weekend and test it, but I would have expected your code to work with either positive or negative on a "newer" //c. If I get the same failure you did, I will read the ROM code to see what is actually happening. Perhaps you got a control character or something else in the line of code that threw the syntax error? There are several versions of the //c ROM, although I don't recall there being any differences related to the problem you describe. The ROM version of your //c should be at $FBBF hex or 64447 decimal. What do you get with
PRINT PEEK(64447)
Thanks for the insight! I've just come on the scene so I have a lot to learn, I will start from the Beagle Bros then.
As soon as I can (I don't have the IIc at home) I will try that command. I don't think I made a syntax error myself (or at least I hope so!), I entered the line three times just to be sure; but my IIc does have an Italian keyboard layout (QZERTY) and that did cause some typing issue. I'll try again and quadruple check.
The //c works fine with that PEEK to make a clicking sound. I have several old programs I've typed in on my //c from an old Compute! book that use that to make a ticking sound.
This program uses it to make a ticking sound while the computer is "thinking":
2100 FOR PAUSE = 1 TO 30:SOUND = PEEK ( - 16336): FOR TIME = 1 TO 60: NEXT TIME,PAUSE
This one has a timer, and when the timer starts getting low, it makes a ticking sound:
2380 IF TICS < = 5 THEN FOR L = 1 TO 2:SOUND = PEEK ( - 16336): NEXT L
There's nothong wrong with your command. Try it again.
I apologise. There was, indeed, a syntax error on the line that contains the PEEK instruction. I got a little lost with the weird keyboard layout. So I stand corrected, PEEK(-16336) does work on my IIc.
At least I've learned something.
While we are at it: I am booting the machine from the original Utility Disk, which is booting ProDOS version 1.0.3. When the disk boots, the display goes from 40 to 80 columns, but when I get to the command prompt the usual "]" is replaced by "é". If I press the little "keypad" key next to the 80/40 column switch key on the top of the keyboard, the "é" prompt changes to the normal "]" and everything that appears on the screen changes to match a US QWERTY layout, so for example "ò" becomes "|" and so on. When I release the key, I'm back to the "é". Apparently, there is some codepage weirdness going on. I guess I'll have to figure out how to either apply the localized codepage to the system (and get the normal "]" prompt, among other things) or to permanently change it to US if need be.
Also, is it normal that when I press the backspace key I get a solid box instead of deleting the character left of the cursor?
All of that is normal. The "keyboard" switch changes both the keyboard layout (via the MAP ROM) as well as the character generator. You might want to check out the ROMXc.
You can change either or both of these behaviors with custom ROMs (or the MAP configurator board from JD Micro).