Видео

LOL. That program was only meant as a reminder of concepts you had already covered, specifically the use of string$ in the display card procedure. The rest of it was just a framework I put together to show it off. Hence the usage warning in the first line. I thought I had added enough comments to explain the overall function of some of the more convoluted code. For example the code at 300 to 385 was a convoluted example of how the correct value for the DDR could be automatically calculated given the desired number of input pins. In a more normal situation, where the pin functions don't need to change, it would be replaced by a single PUT(PC_DDR) assignment with the manually calculated value. Looking at that listing line 390 is commented out so after all that work it looks like I don't use the calculated value anyway. I think I intended to put the single line assignment in line 395 but never got around to calculating it and then forgot about it. It also looks like I was getting tired an got my input and output references mixed up. Since I never tested it on the hardware I never spotted the error(s). Sorry. Incidentally at 11:40 the reason the pin functions are defaulted to all inputs is that was an error. It was supposed to be outputs since that is what you would get if you wrote 00 to the PC_DDR. The following lines then flip each of the lower value bits, that you wanted to be inputs, to ones. The resulting value would then be written to the DDR. So for 4 outputs and 4 inputs PC_DDR would be set to &0F. If you still intend to treat the code as a tutorial I'll elaborate further. The first thing to remember is that it was written without testing against actual hardware so it has to simulate input signals. That results in the need for things such as defaulting the data read in to a value of 1 (line 898) which you questioned at 18:05 (hence the following REM comment); and using the GET in the main loop (line 936) to allow you to step through each bit manually so that you could see the effect instead of it all happening at once. Incidentally the reason I called the variable DAT_button instead of DATA_button is that you can't start a variable name with a 'reserved word' (DATA being an actual command). It took me a while to track down that error :) Secondly the overall concept is based directly on the Arduino code you started off trying to covert. To recap/restate it goes like this... Everything that happens is based on changes to the values read in on the input pins. The program therefore spends MOST of its time in a loop, reading those input pins and waiting for the next change. This can be more easily visualized as a 'State Machine' in which the code remains stuck in each state until the inputs change to the correct value for it to perform the next action and then go back to waiting for the inputs to change to the correct values needed for the code to proceed to the next state. State 0 - Initialise everything When powered on, initialise the DDR etc to set the pin functions as desired, as well as a card counter if wanted. Then proceed to state 1 State 1 - Wait for a card The code goes into an 'infinite' loop, repeated calling the 'read input pin values' routine/procedure, waiting for changes in the input pin values. Since the card reader will default to being empty (no card inserted) both contacts will be made and the inputs will read 0 (ground/0 volts). The code therefore continually loops until a card is inserted and breaks the contacts allowing them to be pulled high. Once this happens the code advances to the next state. State 2 - Initialise card variables Once a card has been detected, Initialise any variables needed for each card. e.g. the total value counter, the bit counter. Then proceed to state 3 State 3 - Wait for a clock pulse to start This is the point you start at when using your manual keys since neither of them are pressed when you begin. (As if a card has just been inserted.) The code goes into another 'read the inputs' loop, waiting for the clock pin to go low, signifying a hole in the card (or a key press) has been detected. When this happens it advances to the next state. State 4 - Wait for a clock pulse to end Now that a clock signal has been detected we need to wait for the data signal to become valid. Since this will happen some time after the clock signal we 'could' do this by waiting a specific time 'if' we knew exactly how fast the card was being scanned. However, because the card is being swiped manually we don't know how long it will need to become valid, but we do know that it will be valid when the clock pulse ends, so we only need to read the data input pin at the same time as the clock pin and keep a copy of the value it was at before the clock input goes high again (clock key released). So the code goes into another 'read the inputs' loop, saving the value of the data pin each time through and repeating until the clock pin goes high, when it moves on to the next state. State 5 - Update display Now we have the data value for the current bit we can store it in an array or add its value directly into a subtotal value since we know its value will be the power of two value for the current bit position (128 for bit7 (msb) … 1 for bit0 (lsb)). Update the display with running totals if desired. Increment the bit counter. If all 8 bits have been read goto state 6 otherwise repeat from state 3 for the next bit. State 6 - Finish with current card Display final results. Add value to any record of previous cards if you are keeping such a list. Implement a delay if the user needs to monitor it. Then go to state 1 to get the next card. Since the reader relies on a physical mechanism for detecting signal contacts it should incorporate protection against contact bounce. If the data being read contains errors then it may be necessary to add a very short delay (centi-seconds) each time the pins are read in order to allow time for the voltage changes to stabilize. I'm still working on the 2x2 character display routine. I do have a working version with limited character data if you wanted me to send that to you. I hope this comment helps and doesn't include any more errors :)

I'm not sure that a simple delay works as a valid debounce mechanism since the code has already changed state and could have been in response to an erroneous signal spike. A delay after that would just postpone the effect of the error. Hence one possible reason you read the occasional 0 bit. That first card also has 9 clock bits so it would read an extra bit (0) between scans.

Just seen the Sine Lab channel also did an earlier more descriptive video on I/O ports - How does I/O on microcontrollers work? - Beyond Arduino #1

The eZ80F92/93 chips are microcontrollers, since they have Flash memory, Ram, timers and various ports on a single chip. The difference with respect to other microcontrollers is that the eZ80F92/93 chips also include the data bus, the data bus and the address bus, in addition to some CPU control lines, which allows the expansion of its internal memory, connecting external memories with a limit of 16 MB, as well as allowing more input/output ports to be mapped. Kind regards.

Nicely done

Did you see my latest reply on here? I also seem to have posted a follow up to it on my community channel page :D

One thing you need to understand is that PC_DR is NOT a memory location. Although it is allocated an address it is not a simple write/read storage circuit, it is a multifunctional input/output port under control of the PC_DDR. When you read from it, if any of the 8 bits are designated as an input pin, you will read the voltage level on that pin. If the pin is not connected to a specific voltage (i.e. floating) the value read will effectively be random depending on the electric fields in their vicinity, which can change as wires etc are moved in relation to each other. If you try reading from a pin designated as an output (why would you ever want to that anyway?) you will probably get a default value as shown in the data specs. When you write to the port, any bits designated as outputs will be set to the high or low value specified by the corresponding bit in the value you wrote. This voltage can be used to turn on, or off, low current circuits like LED displays or transistors that could control higher power circuits. Writing to pins that are designated as inputs will be ignored.

thanks for your feedback and testing

This looks like a dialect of BBC BASIC... Though not running on RISC OS... Possibly Brandy or one of Richard Russel's variants... The giveaways here are MODE (flashes up for a moment when he loads the second program.) and the use of "%" to signify integer variables... Also the use of PROC/DEF PROC, IIRC QBasic defined SUBs, rather than PROCs...

This link will be very helpful and useful to you, regarding logic gates. Kind regards. ruclips.net/video/pVor4boxogA/видео.html

267: not 'before the clock is released' but 'when it is released.'

Answers to questions ... line 230 : any time you use GET(PC_DR) you will get a snapshot of the voltages connected to each input pin. Since you have pull-ups on pc0 and pc1 the two least significant bits will be 1 (high) unless you press a button in which case the corresponding pin will go low(0). The remaining 6 most significant bits will default to a high but because they are 'floating' they might occasionally go low. If you had a loop reading in the value (portc_in_raw) and then print out the binary representation you will probably see them occasionally flicker, especially if you touch the GPIO pins. line 240: anything ANDed with 0 will give a 0 output. Anding the input with 00000011 will set the top 6 bits to 0 and the bottom 2 bits to whatever value they were at when the port was read in. line 266: YES! you only store the data value (and the move onto the next array element) when the clock pin goes from pressed to not pressed.

Good going. You seem to have grasped the concept of the bitwise AND, although I'm not sure you've grasped the use of it in masking out specific bits. The diagram you were looking at showed how the AND gate worked using two switches in series and you started talking about using your two keypad switches in their place. That would not do what you want, it would only output 1 when both keys are pressed, when what you need is to monitor them separately, hence the need for bit masking. When you read in port C you get an 8 bit value. You are only interested in the two least significant bits. Using the AND command will perform a comparison of each bit in the value with the corresponding bit in the mask, equivalent to using 8 individual And gates, one per bit. Using a 0 in the mask will always result in that bit being 0 in the output. Using a 1 will leave that bit unchanged leaving it as a 0 or a 1 in the ouput. AND 3 will therefor give you the state of the two least significant bits resulting in a value between 0 and 3 (000000 00 ... 000000 11 in binary). Using AND 1 will then give you the value of the least significant bit (pc0=clock) and AND 2 will give you the value of the next significant bit (pc1=data). Once you have isolated the two individual pin states (as done in the start of PROCDisplayTest) you can then use them to update data$(k) with the state of the data pin when the clock state changes from pressed to not pressed. Another point to consider is how you are going to eventually convert the string array characters into a numeric value once you've read in 8 bits. Remember that when you scan a card you will get the most significant bit value in first so if your input loop goes from 0 to 7 you will have stored bit 7 in data(0) and bit 0 in data(7).

Hey Luis, glad you liked it. That little dot was a glitch, a leftover bit from when you had previously played the game. Also, the initial view is different the first time you play. I need to do better cleaning up between games. Also, I need to add your score to the exit screen, as it was lost at that point!

10:15 If you think about what your loop is doing and when I'm sure you can work out what is happening. You should go back to the conversion of the Arduino program to see what you need to do inside which loop in order to only read each successive input once. You can then output your bit values however you want and then use your byte(j) array to generate the outputt value totals. Incidentally you don't need a clock_byte array since it will always read 'not pressed' at the point you read the data button state since its release it what signals that the data is ready to be read. Instead you need a data_byte(j) array. Good choice of the Math and Science channel for tutorials. It took a while to find out that the video you were referring to was the first in the playlist for Engineering Circuits Analysis (DC)- Vol 1. It definitely look like a good place to start and looks like the following lessons will cover more basics that you WILL need. You should follow up by checking out the corresponding lessons in your Electronics for Inventors text book.

Amateur hour right here, most professional embedded systems development is done in C, C++, or assembly language. I suppose this is OK to teach to children who want to get into electronics... like the Propeller and Parallax stuff.

Your flickering is caused by the CLS in PROCDisplayTest. Get rid of it and the delay loops but be aware you will need to modify some of the other PRINT lines in order to erase the ends of longer strings when overwriting them with shorter strings. When you DIM a variable it reserves memory for it to use. You only want to do this once, at the start of the program. Putting the DIM in a loop would try to reserve more memory each time through so it isn't allowed hence the BAD DIM error. Your final error in line 317 is caused by adding the print byte$(0) onto the same line as the IF command. Trying to perform multiple actions on the result of an IF statement can be non-intuitive and is best avoided, keep them as simple as possible or use multi line blocks. In this case I suspect that when the result of the test is true it performs the action specified after the THEN 'byte$(0)=0' and then goes to the *next line*. If it fails it does all the actions specified after the ELSE 'byte$(0)=1:PRINT etc' . The simplest way to fix this is to move the print onto the next line.

Some (untested) hints and tips to finish conversion... Replace all digitalRead(clock) with GET(PC_DR)AND1 Replace all digitalRead(data) with (GET(PC_DR)AND2)/2 Replace all Serial.print(value) with a standard PRINT command. 40..62 -> Not needed for Agon. Replace with PC_DDR & PC_DR assignments as per other GPIO test programs 100 -> Not needed for Agon 110..120 -> PUT(PC_DDR) -> set pin function to inputs (hardware pull-ups needed) 130,140 -> Not needed for Agon 200 REPEAT :REM loop forever 210 Initialise counter 220 Wait until clock pin=1 (card insertion breaks contact -> begin scan) 230 allow contacts to settle 240 loop for each of 8 bits 250 wait for clock pin to go low (start of clock pulse so datapin not ready) 260 allow contacts to settle 270 wait for clock pin to go high (end of clock pulse so datapin now readable) 280 allow contacts to settle 290 double the subtotal value -> left shifting promotes the bits to the next significant position. 300 add in the current bit value using the OR operation. (The bit read is inverted since contact is 0 when made and 1 when not) i.e. data_byte = (data_byte OR (NOT(GET(PC_DR)AND2)/2)) 315 show progress (value of current data bit, inverted to show desired reading) i.e. PRINT (NOT(GET(PC_DR)AND2)/2) 320 next/end bit loop 330 wait for clock pin to go low (card removal restores contact) 340 allow contacts to settle 350,360,370 delete unneeded REM lines 355,365 print total value of card. 380 UNTIL 0 : REM loop for next card

I'm liking the look of mode 20. I guess I need to update my set up now. Thanks for sharing the update news. Good job on understanding the points I made in our chat. Everybody needs to learn things for the first time when they haven't come across the knowledge before. You are doing a pretty good job considering you aren't getting formal tuition. Here's hoping you can continue to progress and more importantly continue to enjoy your journey.

4:30 You listed and fixed GPIO.BAS instead of gpio_card.bas then at 6:30 you overwrite it by saving the modified gpio_card.bas with the wrong name :(

So, about your serial connection. I assume you are sending the data over the USB power cable? This I take it means you are powering your Agon from the PC? If so then I think you should mention that not all USB cables are equal. A lot of cheap cables used as power leads don't meet the full specification and don't include the data lines. So be aware. As for the program ... Prefixing the binary value with a % symbol is just a habit I picked up from other languages. It is just an indicator like the & for hex values. Unfortunately BBC BASIC doesn't recognise it. :( The use of the hash symbol is purely a temporary indicator for non-printing ASCII codes. It stands out more than the normal dot used in file/memory dump outputs. As I mentioned in our chat I am currently working on a 2x2 sized character display so that example was simply a placeholder for visual effect. When you get round to looking at the code you will see plenty of comments explaining changes you need to make in order to use it with your hardware. The comments also suggest how the card representation could be improved by using VDU drawing commands. I look forward to seeing your implementation.

BASIC ❤

maby can do somthing like this 5 CLS 10 DIM list(20) 20 index = 0 30 REPEAT 40 key$ = INKEY$(0) 50 REM press A to Added 1 Press b to Added 2 50 IF key$ = "a" THEN index = index +1:list(index)= 1:PRINT TAB(1,4); "Added 1 to list " 90 IF key$ = "b" THEN index = index +1:list(index)= 2:PRINT TAB(1,4); "Added 2 to list" 150 FOR i = 0 TO 20 160 PRINT TAB(i-1,1);list(i) 165 NEXT 170 UNTIL FALSE

The program was only meant to illustrate the comparisons between readings when using pull-ups and pull-downs. It was not intended to be interactive, but after our little chat today and the ideas in this video, expect an updated version soon. :D

21:52 All voltage measurements are the difference between 2 points. That is why you have 2 leads on the meter. To measure the 3.3 you have compare it to a 0v reference. If you connect the black lead to 0v (ground) it will be the reference to which the red lead is compared. No 0v reference means nothing to compare to so no readings. 24:00 You got the LED to light because you had a complete circuit, from 3.3 to ground via the resistor and LED. You then disconnect the LED from ground so no current is flowing, the LED does not light and you measure 1.63 (basically a floating voltage). 39:50 When you connect the red lead to the side of the resistor connected to pin34 it should always read about 3.3 volts. If you connect it to the other side of the resistor, that is, the side connected to the port pin (e.g. 17 or 18) it should read about 3.3 when the button is open but almost 0v when the button is pressed.

What you are doing is just like a joystick input, so check out what is done for those.

In my limited experience, pullup seem to be a little more common, but I'm not sure why. It's slightly counterintuitive, but it's not too hard to get used to a pin going to zero when a button is pressed.

Well just to confirm that while your diagram is not the best way to lay out the connections the way you showed it would be an acceptable way from an electrical perspective. Although you seemed unsure through most of the video I didn’t spot any mistakes in what you said. I’ll try and message you on Facebook tomorrow with more detailed comments.

Thanks for the video! It's possible on the Agon because they have special commands for triangle rendering. So I can upload a list of polygons from the CPU to the graphics chip and instruct it to render them. I also used some extra capabilities of the agon where you upload buffered commands once and instruction it once per frame, so that you don't call the draw polygon each per triangle. The long loading will upload the series of buffer commands for 1800 frames once. What I found not easy on the Agon is that I can't easily update the screen pixels to do full software rendering with the CPU. Like, there is no direct access to a video buffer like other home computers, but rather you have to write in a bitmap in memory and upload it every time. So not easy to do plasma effects and rotozoomers or other like I used on Amstrad CPC. A 64x64 poststamp screen maybe gives me 20-25fps just by uploading. My dreams of using the much faster ez80 to do cool big software rendering effects are crashed :) The hardware works like that, CPU slow serial connection to the VDP. You are supposed to upload either bitmaps or buffer commands and other data once at init, then with few instructions tell them how to display. Maybe I could make some cool demo effects with that different perspective on how to work with it. But I see there are also updates on the firmware all the time, sometimes they break things, sometimes they add new things, I think someone added affine mapping to be able to stretch the bitmap in hardware for texture mapping. I think there are few demos where people try their engines. Maybe a wolfenstein engine will be more possible now. It's been so long though I didn't do anything new and didn't update my firmware. I don't know when I'll be back on Agon, maybe I could try to port my CPC wolfenstein engine (which runs only 6-9fps on the CPC and I abandoned it long, but on ez80 there will be some improvement for sure).

MOSI, CS, SCK and MISO are for SPI connections. CSL and SDA are for i2c connections (ie, nunchuck, or the real time clock module). CTS and RTS are related to the UART1 along with TCD and RXD, but less often used. These are duplicated on the UEXT io bus connector.

keep going and make it fully working :) ! Great project!

Here we go ... 2:20 Although you have connected the pin3 alligator clip to the resistor lead I'm glad to see it is on the correct side and doesn't go through it, so the value is irrelevant in this configuration, thus ensuring the keypad common will be at 0 volts. 5:24 Unfortunately an empty loop does not give a specific execution time. If you want an accurate time you should use TIME or INKEY(x) or a similar method. Try this simple program to measure the delay given by the chosen loop count. 10 t=TIME 20 FOR i=0 TO 6000:NEXT i 30 PRINT "That took "; TIME - t; " Centi-seconds" 40 GOTO 10 07:45 Nice job tidying up the code. I am a little surprised that you left out the print_byte procedure for printing some binary values. 19:50 PC_DR is not a normal variable, when set as input the value reflects the voltages on the GPIO pins you cannot store any other value there. Using PUT(PC_DR) sets the GPIO pins to the selected value only if they have been configured as outputs using the DDR. I don't know what the default direction is without checking the manual, but even if they did default to outputs the very next command on line 30 sets them all to inputs a tiny fraction of a second later which would turn off all the outputs. If you still had the LEDs connected you might see them flash for the briefest period but I doubt it. 21:42 You can't use the ? operator to read the GPIO pins. They are connected via the VDP which handles all the I/O for the AGON hence the need to use the GET and PUT functions. Using ?PC_DR actually reads address &94 in the main BBC memory map (&400094 in Agon memory). 22:05 The ! operator reads the 4 bytes starting at &94 as a 32 bit value. 24:48 Again you are checking 2 different memory locations, main memory vs I/O memory. Since the values of the bits read in represent the voltages connected to the GPIO pins, 0 for 0 volts (Ground) and 1 for a +ve voltage (3.3v), these representations are fixed in hardware and cannot be changed. If you want to change the representation so that you get a 1 when the button is pressed you have two options. Firstly you could invert the hardware so that you connect the keypad common to 3.3v instead of ground and use pull-DOWN resistors to hold the input pins low until a button is pressed. Alternatively you could simply invert the value in software e.g. 150 portc_in_raw=GET(PC_DR) EOR &FF Either way you will need to swap the keystate$ assignments in lines 170 and 190 back to there original values. Since the original Arduino code used 0volts to signify a contact (by a button or through a hole) you will see that it doesn't matter so whether you used contactvalue=0 or you used contactvalue=1 then whichever polarity you chose to use, the rest of the code would be the same E.G. (first thoughts outline : use at your own risk) REM Set register values etc. as current program data_value=0 FOR bit_counter= 7 TO 0 STEP -1 REPEAT PROCreadpins UNTIL CLOCK_button_pressed=TRUE REM assumes the data contact (if any) is made before the clock contact IF DATA_button_pressed=TRUE THEN data_value = data_value +2^bit_counter PRINT "Bit# ";bit_counter," SubTotal = ";data_value REPEAT PROCreadpins UNTIL CLOCK_button_pressed=FALSE NEXT bit_counter PRINT "Total value = ";data_value DEF PROCreadpins portc_in GET(PC_DR) AND 3 IF (portc_in AND 1) =contactvalue THEN CLOCK_button_pressed=TRUE ELSE CLOCK_button_pressed=FALSE IF (portc_in AND 2)/2=contactvalue THEN DATA_button_pressed=TRUE ELSE DATA_button_pressed=FALSE ENDPROC

This looks like the old QBasic program

@LearnAgon I am a little concerned that you are using my code from my recently added video in my channel @TELSBENCH. This 'here' is titled as 'ForLoop study session' but that is not the basis of the code which is intended to inform users how to use GPIO on Agon Light. I would prefer it if you do not use my code as a substantive part of your videos. Although the code is under the MIT license, this does not seem to me to be fair play that you are winning views off my work. If you want to learn how my code works, and then create something unique on your own effort, but have questions, you could always post a question on my channel and I will be happy to answer it. Peace.

Also try adding the following. You should have enough knowledge now to understand how it works. 85 portc_in_raw = GET(PC_DR) 90 portc_in = portc_in_raw AND 3 115 END 155 P. :P. :P. 156 P. "Port C pins raw status = "; PROCshow_binary_byte(portc_in_raw) 157 P. "Port C pins C0/C1 status = "; PROCshow_binary_byte(portc_in) 200 DEF PROCshow_binary_byte(byte) 210 FOR bit = 7 TO 0 STEP -1 220 IF byte AND 2^bit P."1"; ELSE P."0"; 230 N. 240 P. 250 E.

Just a quick thought about the simplest way to make the program more usable ... copy line 40 to line 85 (PROCDisplayTest) and then restore lines 90,94 and 96 to their state before you made it only monitor a single pin.

Aww... the whole purpose of the code was to allow you to monitor both keys and you ended by removing the second key. If you had named line 98 as data instead of clock (as per the original code) you might have been able to see that you had got it working correctly but it was just scrolling too fast to see it clearly. See my comment to part 1 of the video for some suggested improvements.

Firstly, your diagram looks ok just unfinished. You will need a second pull up between 3.3 and pin 18 (and similarly for any other pins you want to use as inputs. You almost got the program in correctly. Sorry I got the IS/is NOT assignments the wrong way round but you were fixing that as video ended. You will will probably also spot your error in line 98 which should have changed from clock to data. Obviously you could rename them as anything you want, pins 17 and 18 or C0 and C1 for example. I could suggest you move the timing loop into the repeat loop and add a blank line between each time through the loop, or even print the two lines on the same lines like the original program did for the single value but I guess you will sort those type of tweaks in part 2 of the video Finally for this part, congratulations you seem to have worked out the purpose of the bitwise operations. When you read in the port data register you get 8 bits (255 by default in this case). Using the AND 3 sets the top 6 bits to 0 because we aren't interested in them so we will be left with a value of 0 to 3. Viewing them in binary is definitely the way to go.

Everything that involves "input signals" through the GPIO ports necessarily requires a predefined polarity. Otherwise, the reading of these inputs will always be incorrect (knowing their real state), due to the electrical noise that is induced through the wiring, altering the states of the bits (0 or 1) simply by touching the wiring. This is why it is necessary to use pull up or pull down resistors, depending on each case. Kind regards. P.S. I left you my answer to your question in the respective channel on discord.

Did you mange to find the links in my earlier comment or do you want me to send them via Facebook?

For a good explanation of pull up concepts, check out the AddOhms channel videos for episodes #15 and #25 (numbers 5 and 9 in his Electronics Basics playlist) ...

can aslo do for example other 4 pins next to port c at right side

Connect the Pullup between the input pin and 3.3v. leaving your input pin also connected to the switch going to ground then the switch is depressed. This has the effect of ensuring a known level 3.3v is presented to the input pin when the switch is not depressed. Search for Wiki Pullup Resistor

On the good side you seem to have sussed the bit pattern concept. Congratulations. Next step is to read whichever input you are interested in. Try this (unchecked code)... REPEAT portc_in = GET (PC_DR) AND 3 IF (portc_in AND 1) =1 THEN keystate$="IS" ELSE keystate$="is NOT" PRINT "Clock key "; keystate$;" pressed." IF (portc_in AND 2) =2 THEN keystate$="IS" ELSE keystate$="is NOT" PRINT "Data key "; keystate$;" pressed." UNTIL 0 :REM bored=TRUE

You have the button lead connected to the 3.3v side of the resistor instead of the pin 17 side. when you press the button you are connecting ground directly to 3.3v That is BAD! Don't do it!! It needs to be on the pin17 side of th resistor.

33:40 think in binary. 3 = 0011 AND 5 = 0101 gives 0001 = 1 The bit mask selects which bits are to be considered in the output value. If the mask is 5 (0101) then only bits 2 and 0 of the value (0011) are considered ... 0*2^2=0 + 1*2^0=1.

Sorry about the +ve. It and -ve are common/general shorthand for positive and negative. The bit pattern used to mask the ANDed values, don't have to be in hex. It doesn't matter whether a value is shown in Octal, Decimal, Hex or any other representation since it is stored in binary and therefore they are all the same. v AND 255 is exactly the same as v AND &FF. It is common to use Hex to represent bit mask values as it is easier to visualise the binary bit patterns being used. Unfortunately using floating input pins for radio reception would not be a simple project. Although it may be possible using some fancy Fourier Transform mathematical processing the frequency range would be very limited unless you added significant pre-processing hardware. If you are seriously interested try researching 'Software Defined Radio' :D

Mike is Correct. This is correct. There should be a pullup resistor to +3.3v of say 10k for example. The document refers to this in open drain/source mode. So get add a pullup for each key

The operation value AND bit pattern returns the state of any bits in value that correspond to any bits in the bit mask pattern that are set to 1. If you GET PC_DR you get an 8bit value where each bit corresponds to the matching port C pins pc7 to pc0. Since you are only interested in the value of 1 pin you use a bitwise AND operation to mask out the bit that you are interested in and ignore the rest. AND &01 masks out the least significant bit which corresponds to PC0 and ignores the other pins. Try this example 10 FOR v=0 TO 15 20 PRINT v;”=“; v AND &08; “+”; v AND &04; “+”; v AND &02; “+”; v AND &01 30 NEXTv

10:20 That is interesting. Not sure why you get a zero when trying to read the DDR. Possibly because it is a write only register. You should check the manual for details but I don’t think it is a problem.