Whats the quickest way to set bits?


Closed Thread
Results 1 to 34 of 34
  1. #1
    Join Date
    May 2004
    Posts
    81

    Default Whats the quickest way to set bits?

    I am trying to create a bargraph display. It has 16 segments. My routine uses a calculation of an upper bound limit for what the display should be reading and a lower bound limit.

    Code:
    GraphDivider = (GraphMax - GraphMin)  / 16
    GraphVal = (X / GraphDivider)
    Everything to do with this graph is using word variables.

    So lets say my graph top value is 100, and my graph lower value is 0, and X = 50:
    (100 - 0) / 16 = 100 / 16 = 6.25
    50 / 6.25 = 8

    Thats exactly the result I expect to get. Now, to display the number 8 on the graph (having the first 8 LED's lit, the binary number I would have to send would be %0000000011111111

    Is there a way to tell pic basic to set the first 8 bits on? Looking through the documentation I see I can set bit 8 with DCD=7 but that will leave all other bits at 0

  2. #2
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    How is the display connected to the MCU? How are you sending data to it.
    Dave
    Always wear safety glasses while programming.

  3. #3
    Join Date
    May 2004
    Posts
    81


    Did you find this post helpful? Yes | No

    Default

    Using an alegro A6276, so the pic shifts the data out. The displays thems selfs are working fine. I was just wondering if there was a quicker way to set all bits up to a certain bit number on with out having to use a look up table.

  4. #4
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default

    <strike>GraphVal = $FFFF >> ((X * 16) / (GraphMax - GraphMin))</strike>

    GraphVal = $FFFF >> (((X - GraphMin) * 16) / (GraphMax - GraphMin))
    <br>
    <br>
    Last edited by Darrel Taylor; - 23rd October 2010 at 03:22. Reason: oops
    DT

  5. #5
    Join Date
    May 2004
    Posts
    81


    Did you find this post helpful? Yes | No

    Default

    DOH!

    I knew there was something I wasnt thinking of...

    The key was right shifting the $FFFF. If anyone else is following this, here is the final formula I came up with and it works perfectly.

    GraphVal = $FFFF >> (16 - (X / ((GraphMax - GraphMin) / 16)))

    This is for auto guages so the scale of the graph can swing. For instance, a fuel level gauge might read 0 to 16 galons, where a water temp guage might read 180° - 290°, so it was important to note that the bottom number might change as well as the top.
    Last edited by bearpawz; - 23rd October 2010 at 04:16. Reason: It works now...

  6. #6
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default

    And probably something I wasn't thinking of too.
    That might go backwards, and need to be inverted.

    GraphVal = $FFFF >> (16-(((X - GraphMin) * 16) / (GraphMax - GraphMin)))

    I'll test it and see.

    Doh, you beat me to it.
    Oops again.
    DT

  7. #7
    Join Date
    May 2004
    Posts
    81


    Did you find this post helpful? Yes | No

    Default

    Uh Oh. Ok, it work flawlessly until you start working with a very tight scale. An example is the volt meter. It usually displays information from 8V to 18V with the guages I am replacing. Unfortunatly, based on the formula there ends up being too small of a number to even light one LED. (or at least its not lighting anything up). I passed in a value of 13 for my test data. This is a valid number between 8 and 18. However, when you start using the formula (the one I came up with) here is what happens:

    GraphVal = (16 - (X / ((GraphMax - GraphMin) / 16)))

    GraphVal = (16-(13/((18 - 8)/16)))

    GraphVal = (16-(13/(10/16)))

    GraphVal= (16-(13/.625)

    GraphVal = 16-20

    GraphVal = -4!


    Sorry, Ive never been horribly great at actual math. Now what? lol.

  8. #8
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    You will not be getting a value volts at the ADC. You will have something between 0 and 255 or 0 and 1023. 8 or 10 bits.

    So maybe we should start there.
    Dave
    Always wear safety glasses while programming.

  9. #9
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    What about this for you ADC in
    http://www.picbasic.co.uk/forum/content.php?r=249
    Oversample to get you 16bit rez. Then you are done.

    Or am I missing something.
    Dave
    Always wear safety glasses while programming.

  10. #10
    Join Date
    May 2004
    Posts
    81


    Did you find this post helpful? Yes | No

    Default

    Not even worried about that part right now. What will be monitoring the actual car will be a whole other system. At the moment just need to know how to get the displays to display correctly.

  11. #11
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default

    Try the last formula I gave in post #6

    Testing here, making animation to prove it.
    It works.
    DT

  12. #12
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default

    <object id='stUkhdQ01IR1FYSF9cWVxcU1Nc' width='425' height='344' type='application/x-shockwave-flash' data='http://www.screentoaster.com/swf/STPlayer.swf' codebase='http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=9,0,115,0'><param name='movie' value='http://www.screentoaster.com/swf/STPlayer.swf'/><param name='allowFullScreen' value='true'/><param name='allowScriptAccess' value='always'/><param name='flashvars' value='video=stUkhdQ01IR1FYSF9cWVxcU1Nc'/></object>

    Code:
    DEFINE OSC 4
    
    ;----[USART Settings]-------------------------------------------------------
    DEFINE HSER_RCSTA 90h    ' Enable serial port & continuous receive
    DEFINE HSER_TXSTA 24h    ' Enable transmit, BRGH = 1
    DEFINE HSER_SPBRG 25     ' 9600 Baud @ 4MHz, 0.16%
    DEFINE HSER_CLROERR 1    ' Clear overflow automatically
    
    ;----[LCD Settings]---------------------------------------------------------
    DEFINE LCD_DREG PORTA     ' LCD data port 
    DEFINE LCD_DBIT 4         ' LCD data starting bit 0 or 4 
    DEFINE LCD_RSREG PORTA    ' LCD register select port 
    DEFINE LCD_RSBIT 2        ' LCD register select bit 
    DEFINE LCD_EREG PORTA     ' LCD enable port 
    DEFINE LCD_EBIT 3         ' LCD enable bit 
    DEFINE LCD_BITS 4         ' LCD bus size 4 or 8 
    DEFINE LCD_LINES 2        ' Number lines on LCD 
    DEFINE LCD_COMMANDUS 2000 ' Command delay time in us 
    DEFINE LCD_DATAUS 50      ' Data delay time in us 
    
    ;----[A/D Settings]---------------------------------------------------------
    DEFINE ADC_BITS 10        ' ADCIN resolution  (Bits)
    DEFINE ADC_CLOCK 1        ' ADC clock source  (Fosc/8)
    DEFINE ADC_SAMPLEUS 11    ' ADC sampling time (uSec)
    
    ;----[Variables]------------------------------------------------------------
    GraphMAX   VAR WORD
    GraphMIN   VAR WORD
    GraphVal   VAR WORD
    X          VAR WORD
    ADval      VAR WORD
    Xmax       VAR WORD
    Xmin       VAR WORD
    char       VAR BYTE
    OverRange  VAR BIT
    UnderRange VAR BIT
    
    ;----[Aliases]--------------------------------------------------------------
    RCIF       VAR PIR1.5
    OverPin    VAR PORTC.5
    UnderPin   VAR PORTC.4
    
    ;----[Default Values]-------------------------------------------------------
    GraphMAX   = 100
    GraphMIN   = 0
    Xmax    = 100
    Xmin      = 0
    
    ;----[Initialize]-----------------------------------------------------------
    PORTB = 0
    TRISB = 0
    PORTD = 0
    TRISD = 0
    ANSEL = %00000001
    ANSELH = 0
    ADCON1.7 = 1
    PAUSE 250 : LCDOUT $FE,1 : PAUSE 250 : LCDOUT $FE,1
    GOSUB ShowMenu
    GOSUB ShowLimits
    OverRange = 0
    UnderRange = 0
    
    ;----[Main Program Loop]----------------------------------------------------
    Main:
        IF RCIF THEN GOSUB Terminal
        GOSUB GetAD
        GOSUB ShowGraph
        GOSUB CheckOverUnder
    GOTO Main
    
    ;----[Get and Scale Analog Reading]-----------------------------------------
    GetAD:
        ADCIN 0, ADval
        X = ADval * (Xmax - Xmin)
        X = DIV32 1023 + Xmin
        LCDOUT $FE,$80, "AD=",DEC ADval, "    "
        LCDOUT $FE,$8B, "X=",DEC X, "    "
    RETURN
    
    ;----[Show the BarGraph]----------------------------------------------------
    ShowGraph:
        IF X > GraphMAX THEN
            OverRange = 1
        ELSE
            OverRange = 0
        ENDIF
        IF X < GraphMIN THEN
            UnderRange = 1
        ELSE
            UnderRange = 0
        ENDIF
        X = (X MIN GraphMAX) MAX GraphMIN
        
        ;-- This is the formula being tested ---------------------
        GraphVal = $FFFF >> (16-(((X - GraphMIN) * 16) / (GraphMAX - GraphMIN)))
        
        PORTD = GraphVal & $FF
        PORTB = GraphVal >> 8
    RETURN
    
    ;----[Show Menu for Terminal]-----------------------------------------------
    ShowMenu:
        HSEROUT ["MENU: 1=GraphMAX, 2=GraphMIN, 3=Xmax, 4=Xmin :"]
    RETURN
    
    ;----[Handle the RS232 Terminal]--------------------------------------------
    Terminal:
        HSERIN [char]
        SELECT CASE char
          CASE "1" : HSEROUT [13,10,"Enter the GraphMAX: "]
                     HSERIN  [DEC GraphMAX]
          CASE "2" : HSEROUT [13,10,"Enter the GraphMIN: "]
                     HSERIN  [DEC GraphMIN]
          CASE "3" : HSEROUT [13,10,"Enter the Xmax: "]
                     HSERIN  [DEC Xmax] 
          CASE "4" : HSEROUT [13,10,"Enter the Xmin: "]
                     HSERIN  [DEC Xmin]
          CASE ELSE : HSEROUT [7]
        END SELECT
    
    ;----[Show Limits]----------------------------------------------------------
    ShowLimits:
        LCDOUT $FE,$C0,"    GRAPH    X      "
        LCDOUT $FE,$94,"MAX:                "
        LCDOUT $FE,$D4,"MIN:                "
        LCDOUT $FE,$99,DEC GraphMAX
        LCDOUT $FE,$D9,DEC GraphMIN
        LCDOUT $FE,$A1,DEC Xmax
        LCDOUT $FE,$E1,DEC Xmin
    
    RETURN
    
    ;----[Look for Over and Under Range]----------------------------------------
    BlinkSpeed  CON 50
    BlinkCount  VAR WORD
    
    CheckOverUnder:
        BlinkCount = BlinkCount + 1
        IF BlinkCount = BlinkSpeed THEN
            BlinkCount = 0
            IF OverRange THEN
                TOGGLE OverPin
            ELSE
                LOW OverPin
            ENDIF
            IF UnderRange THEN
                TOGGLE UnderPin
            ELSE
                LOW UnderPin
            ENDIF
        ENDIF
    RETURN
    
    This post has been promoted to a bar graph wiki page, located here: http://www.picbasic.co.uk/forum/cont...ge-min-and-max
    Last edited by ScaleRobotics; - 23rd October 2010 at 18:33. Reason: Added promotion tag
    DT

  13. #13
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    Wow!!!!!
    That is cooool!!!!!!!
    Dave
    Always wear safety glasses while programming.

  14. #14
    Join Date
    May 2008
    Location
    Italy
    Posts
    825


    Did you find this post helpful? Yes | No

    Default

    Assuming you have to measure max 18 volts, then you will need a resistor devider by 4 which will yield 4,5 volts to the ADC input. Assuming you will use a 10 bits convertion then:

    45000/1024 = 44 (rounded)

    Your 16 leds graphs = $FFFF >>( 16- ((ADC * 44 * 16)/45000))

    Cheers

    Al.
    All progress began with an idea

  15. #15
    Join Date
    May 2004
    Posts
    81


    Did you find this post helpful? Yes | No

    Default

    thanks daryl, it does in fact work. I got tired last night and gave up on it and I think we were cross posting some how. Now all I have to do is tackle communications and Im done with this part of the project.

    Btw: Whats that cool little program your using in your video?

  16. #16
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default

    Yeah, it was kind of late.
    But like I said, I needed the practice.

    The simulator is Proteus VSM from Labcenter Electronics.
    Definately the coolest program I've ever had.
    DT

  17. #17
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107


    Did you find this post helpful? Yes | No

    Default

    Darrel,

    I'm thinking of buying Proteus VSM. I know I should ask Labcenter, but since you use it with PBP, could I ask you a few questions?

    All my schematic capture is in Altium (formerly Protel). Do you know if Proteus will import other formats? Altium will export in Orcad 8 format and a few others.

    If I write a program in PBP, I assume that I have to feed Proteus the .ASM file in for the simulation. Is that true? I can't imagine that it would show me the PBP line it was executing during an animation. Just how easy is it to use in conjunction with PBP?
    Charles Linquist

  18. #18
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default

    I don't think it can import files from any other programs.
    There's nothing in the menu's, but I don't know if there are any external conversion programs.

    With PBP 2.60A, you can work directly with your PBP code and it will single step through the program as it's simulating. The internal editor is terrible, but you can use MCS as an external editor. It doesn't use MCS to single step, but it's easier to write stuff.

    You can also integrate it with MPLAB, and it will single step using the MPLAB IDE and watch variables, have breakpoints etc, but it reduces the screen space for the simulation.

    For me, it's easier to compile programs like I always do with MCS, and just run the .HEX file in Proteus like I would on real hardware. No single stepping that way, but I don't need to single step anymore anyhow.

    There's a demo version available.
    It's doesn't let you create your own schematics, but there are a bunch of samples that you can write your own PBP code for. It's kind of like buying several development boards. You can't change the hardware, but you can write programs to run on them. And they're free.

    I've saved so much money since I got it.
    I don't buy chips and parts and breadboards and LCD's etc. anymore.
    All my breadboards and electronics stuff are still in boxes after the move to Colorado. Just don't need them anymore.
    DT

  19. #19
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107


    Did you find this post helpful? Yes | No

    Default

    I have so many unique situations that I don't know if Proteus would help. I have an unlimited number of development boards, but what is hard for me is simulation. I'm using all the pins of an '8723 (and in some cases, 2 8723's "lashed" together). I have so many combinations of digital, analog, and serial data that testing is becoming very, very time consuming.

    And I have to deal with a lot of external hardware. Like I2C. And I almost always control fans using a PID control loop using the PICs CCP registers to send 158Khz PWM out to a "buck" converter, which is filtered to give pure DC to the fans. I watch the fan tachometers and use that feedback to control the PWM. I have an algorithm that automatically sets up the coefficients for any fan (big or small) that I hook to it. But it seems like I'm always tuning that algorithm.

    I also need to process a lot of serial data - often SNMP packets that have to do a large amount of parsing. I use Lantronix XPorts or MatchPorts to do the network "heavy lifting" but long packets still come in over the USART or SPI port. The ability to inject long strings into those ports and watch the execution of the parser would be priceless. Right now, I capture network packets with WireShark and go through long lists, byte-by-byte.
    Since I'm dealing with external devices, a lot of things are time-critical as well.
    The whole test process takes far too long.

    I can't imagine that Proteus could do all of what's needed, but if it could help me with even part of what I'm doing, it would be money well spent. What do you think?
    Charles Linquist

  20. #20
    Join Date
    Mar 2009
    Posts
    653


    Did you find this post helpful? Yes | No

    Default

    This bargraph generator looks like it could be useful!

    I watched the video, but I wasn't able to work outwhat all the user input was for - what I'd like a bargraph generator to do is react to an incoming analog signal.

    Ideally with just 5 leds... up until, now, I've been using a dedicated bar graph IC ( - warning turn your PC sound down), but the problem with that IC is that it's a one trick pony...therefore I was thinking of using a PIC to do the bar graph - becuase this would allow corny LED patterns like Knight rider etc!...so I was pondering how to do this just a couple of days ago...this thread is very convenient!

  21. #21
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default

    Charles,

    I think you're out of luck on the fan part, it does have a fan motor but you have to measure RPM from the commutator current pulses. There's no direct RPM output.

    It has the 8720 and 8722, but not the 8723 ... yet. Every new version (about every other month) has more chips and stuff.
    You can run multiple chips simultaneously.

    It doesn't have an XPort, but you can interface to an external COM port, so it could use a real XPort.

    It has I2C and SPI debuggers that allow you to send anything you want to either the master or the slave. It will definitely be useful for that part.

    But overall, I think you'll be better off sticking with hardware for such a large project, especially because simulating lots of analog circuitry slows it down considerably. It would probably take an 8 or 16 core computer to simulate your whole circuit anywhere near real-time.
    DT

  22. #22
    Join Date
    Feb 2006
    Location
    Gilroy, CA
    Posts
    1,530


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by HankMcSpank View Post
    I was thinking of using a PIC to do the bar graph - becuase this would allow corny LED patterns like Knight rider etc!...
    For Knight Rider bargraph, check out post number three on the MIBAM thread here: http://www.picbasic.co.uk/forum/showthread.php?t=10564
    http://www.scalerobotics.com

  23. #23
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

    Default

    Charles, download the current issue of Embedded Systems Design here. You can also subscribe to the print version which is available for free to professionals.



    It will give you a good idea of what is happening in terms of tools (hardware and software) and techniques that are used in current embedded systems design and development.

  24. #24
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107


    Did you find this post helpful? Yes | No

    Unhappy

    I keep threatening to change compilers (to C18, for example) or make a bigger move to ARM chips, but it seems like I never have time to make the switch.

    Also, I have so many thousands (truly!) of PICs in military applications that it is really hard to change. In some cases, it took a year to get the hardware qualified but we now have enough of a 'track record' with the hardware and sw that we can get products qualified "by example". If I changed chips, I would have to start over.

    I guess I'll have to keep doing it the hard way for a bit longer.

    And one more thing - anyone who thinks that PBP is somehow not as good as 'C' can be told that it is running in an awful lot of very, very critical military applications. When written correctly, PBP is bulletproof.
    Charles Linquist

  25. #25
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by Charles Linquis View Post
    ....And one more thing - anyone who thinks that PBP is somehow not as good as 'C' can be told that it is running in an awful lot of very, very critical military applications. When written correctly, PBP is bulletproof.
    Hey, if it works for you and your customers are happy, go for it.

  26. #26
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107


    Did you find this post helpful? Yes | No

    Default

    But I will still have to make the change sooner or later. That is, unless we can get Darrel to add functions, procedures, better string handling and a few other features to the next version of PBP!
    Charles Linquist

  27. #27
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

    Default

    Charles, it is not about you saying that something is bulletproof or whether C (or other language) is better/worse than PBP (or anything else). It is about how easy/difficult it is to ensure (from a maintenance/validation standpoint) that the application/system is correct and how you can validate/test that is so.

    From the software perspective, you have discovered that as an application becomes more complex, it gets increasingly difficult to maintain (make changes, additions or corrections). As you have mentioned, languages having structured elements (such as functions, procedures, local and global variables, etc.) go a long way in making it so. Also, features such as pointers, structures, members and unions are very useful when dealing with complex data structures. These features are available in languages such as C.

    As for hardware, having the ability to do some form of in-circuit hardware debugging is extremely useful. The ability to single step through the firmware (at the source and/or debug level), set breakpoints, inspect memory and register values, change values on-the-fly, tracing, etc. can give you a view of what your system is actually doing that is difficult to impossible otherwise.

  28. #28
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107


    Did you find this post helpful? Yes | No

    Default

    I only made the 'bulletproof' comment because although I write mostly in PBP, I have hired people that knew only 'C'. At first, they were totally convinced that a program written in BASIC was either very slow in execution, or lacked a lot of functionality, or was a "toy" for some other reason.

    After a couple of months, they realized their opinions were wrong. All of them learned PBP at least to some extent.

    I was trying to give a "pep talk" to all the other PBP coders out there.

    My heartburn with PBP is that it is difficult to write reusable code, and also the lack of easy debugging.
    Charles Linquist

  29. #29
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

    Default

    Charles, if I (and even more importantly, my customers) are convinced that we have a serious (non-toy in your words), commercial grade MCU development toolchain that is considered bulletproof, I would not bother looking for anything else.

  30. #30
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    It all comes down to who is banging on the keyboard.

    I write crappy code no matter what language I use. I imagine folks like Darrel and Bruce write great code no matter what language they use.

    I also bet that Darrel and Bruce can write in Basic and blow even a good "C" coder out of the water.

    So if you like B, C, or what ever... use it. What is good for one is not necessarily good for another.
    Dave
    Always wear safety glasses while programming.

  31. #31
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

    Default

    Sorry Dave, coding ability (or lack thereof) isn't the issue here.

  32. #32
    Join Date
    Nov 2003
    Location
    Wellton, U.S.A.
    Posts
    5,924


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by rmteo View Post
    Sorry Dave, coding ability (or lack thereof) isn't the issue here.
    Darn, wrong again...
    But I coulda swore it was the code that made these things work like we want them to.

    Oh well, back to the drawing board.
    Dave
    Always wear safety glasses while programming.

  33. #33
    Join Date
    Feb 2006
    Location
    Gilroy, CA
    Posts
    1,530


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by rmteo View Post
    Charles, if I (and even more importantly, my customers) are convinced that we have a serious (non-toy in your words), commercial grade MCU development toolchain that is considered bulletproof, I would not bother looking for anything else.
    Carefull rmteo,

    One of your customers might see that you spend an awfull lot of time on this toy compiler forum, and wonder if you are really programming their equipment with the bulletproof C. Sure you try to convert others here to the dark side on a regular basis, but is that just to disquise the fact you really like PicBasic better?
    http://www.scalerobotics.com

  34. #34
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by scalerobotics View Post
    Carefull rmteo,

    One of your customers might see that you spend an awfull lot of time on this toy compiler forum, and wonder if you are really programming their equipment with the bulletproof C. Sure you try to convert others here to the dark side on a regular basis, but is that just to disquise the fact you really like PicBasic better?
    Actually my customers don't give a hoot as to what I like - they only care about what they want. And as long as I give them what they want (on the terms and conditions we have mutually agreed upon) they really don't care what I do with my time - even if I decide to spend it on a toy compiler (your words) forum.

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts