​ ​ ​ ​ How much RAM is there in an 08M2 really ?
Page 1 of 3 1 2 3 LastLast
Results 1 to 10 of 21

Thread: How much RAM is there in an 08M2 really ?

  1. #1
    Senior Member
    Join Date
    Feb 2009
    Location
    Cheshire, England
    Posts
    2,361
    Blog Entries
    4

    Default How much RAM is there in an 08M2 really ?

    Code:
    #picaxe 08M2
    
    for b0 = 10 to 255
    	poke b0, b0
    	peek b0, b1
    	sertxd ("W  ", #b0, " R ", #b1, cr, lf )
    next
    If you run this code in the simulator of PE6 it will crash after trying to write byte 128.

    If you use PE5 simulator it doesn't crash, and appears to write and read up to byte 255.

    I discovered this after downloaded the Magic Morse ( http://www.picaxeforum.co.uk/showthr...l=1#post198608 ).

    The 'ClearBuffer' routine in Magic Morse crashes as soon as it tries to write byte 192, which makes sense, as according to the M2 document ( http://www.picaxe.com/docs/picaxem2.pdf ) the RAM on the 08M2 only goes up to byte 127.

    It's not really a problem for me, as I'll be using an X2, but what exactly happens in a real 08M2 when it pokes beyond 127 ?

    There appear to be quite a few 08M2 Magic Morse projects constructed using 08M2, and they all appear to be working, but how ?.

    Maybe it's real magic

    Cheers,

    Buzby
    Last edited by Buzby; 17-12-2016 at 19:50.

  2. #2
    Senior Member
    Join Date
    Feb 2010
    Location
    Don't Mess With My Texas!
    Posts
    2,172

    Default

    I know you're serious, but after 127 is where the smoke is stored. You are smoke writing after that. Try using an RGB value to see if you can release some magenta colored smoke.
    - Tex
    __________________________________________________ _______________________
    "Truth lies dormant in our future history." ― Tex Clodhopper LXV
    “Confidence is ignorance. If you're feeling cocky, it's because there's something you don't know.” ― Eoin Colfer, Artemis Fowl

  3. #3
    Technical Support
    Join Date
    Jan 1970
    Location
    Bath,UK
    Posts
    6,397
    Blog Entries
    1

    Default

    128 bytes http://www.picaxe.com/BASIC-Commands/Variables/peek/

    PE6 doesn't crash, it stops the simulation with an 'invalid RAM address' simulation warning. Which is correct.

    In a real chip the address will be 'and 127', so any value above 127 will be mapped back down to 0-127.
    PICAXE Technical Support

  4. #4
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    23,630

    Default

    Quote Originally Posted by Buzby View Post
    What exactly happens in a real 08M2 when it pokes beyond 127 ?
    There are 128 bytes of RAM in an 08M2 with PEEK and POKE addresses $00 to $7F.

    When PEEK or POKE is used with an address greater than 127 ($7F), the address is masked with $7F and that is the address used. Hence address $80 will reference address $00, etc.

    One has be careful coding RAM analysis programs as the code can easily affect any variables used in the analysis without that being obvious.

    The program below clears all potential RAM from address 0 up to 1023. It then writes a $FF to address 0. Finally it scans through RAM noting where $FF has been found. On the 08M2 this shows the $FF at addresses 0, 128, 256, 384 etc, $0000, $0080, $0100, $0180, etc. Mask those addresses with $7F and they all reference address $00 which is where the only $FF was placed.

    The s_w1 and s_w2 variables are available for use on both M2 and X2 devices and are not part of the RAM area, so are safe to use in RAM testing programs without any side effects.

    Code:
    For s_w1 = 0 To 1023
      Poke s_w1, 0
    Next
    
    Poke 0, $FF
    
    For s_w1 = 0 To 1023
      Peek s_w1, s_w2
      If s_w2 <> 0 Then
        SerTxd( #s_w1, CR, LF )
      End If
    Next

    Quote Originally Posted by Buzby View Post
    If you use PE5 simulator it doesn't crash, and appears to write and read up to byte 255.
    Just one of the reasons we recommend people use PE6.

    Quote Originally Posted by Buzby View Post
    There appear to be quite a few 08M2 Magic Morse projects constructed using 08M2, and they all appear to be working, but how ?
    Could just be luck or good fortune that they work, or appear to work when they don't.

  5. #5
    Senior Member
    Join Date
    Feb 2012
    Location
    London
    Posts
    2,626

    Default

    Hi,

    Ah, technical and hippy have beaten me to the answer. Initially I "confused" myself by using @bptr to write and read the RAM. But bptr is itself masked as a 7-bit counter so can give misleading results. This is the test code I then used, which "appears" to work on the first pass, but the second pass reveals the problem.

    Code:
    #picaxe 08m2
    #no_data
    
    sertxd(cr,lf,"starting ")
    for s_w1 = 0 to 255
    poke s_w1,s_w1
    peek s_w1,s_w2
    sertxd(#s_w2," ")
    pause 100
    next
    sertxd(cr,lf,"reading ")
    for s_w1 = 0 to 255
    peek s_w1,s_w2
    sertxd(#s_w2," ")
    pause 100
    next
    sertxd(" done")
    There can be a similar problem with "fake" memory cards (SDHC, etc.). They can appear to work until you try to use them past their half or quarter capacity boundaries, but then you find your earlier data has "vanished" or become corrupted.

    Cheers, Alan.

  6. #6
    Technical Support
    Join Date
    Jan 1970
    Location
    UK
    Posts
    23,630

    Default

    Quote Originally Posted by AllyCat View Post
    There can be a similar problem with "fake" memory cards (SDHC, etc.). They can appear to work until you try to use them past their half or quarter capacity boundaries, but then you find your earlier data has "vanished" or become corrupted.
    Yes, it's exactly like that. If one only ever used a part of a card which did not physically exist, never used the parts which were being corrupted, it would appear to be working correctly and have as much memory as was being accessed.

    That may be what is happening for those programs which do that on an 08M2. If they access memory from 255 ($FF) down to 192 ($C0), that would really be 127 ($7F) down to 64 ($40). If memory at $40 to $7F is not otherwise used it will still work.

    It could be the code was originally written for a PICAXE with 256 bytes, and the fact the 08M2 has only 128 was never noticed when the code was ported over and tested.

  7. #7
    Senior Member
    Join Date
    Feb 2009
    Location
    Cheshire, England
    Posts
    2,361
    Blog Entries
    4

    Default

    Hi

    It's a question then as to whether PE6 simulation should crash at byte 128 ( it stops running, not just a warning, I call that a crash ), or should it do the '& $FF' as a real chip does ?.

    If the simulator executed a 'Break' instead of a 'Stop' when it finds a boundary error, then the dialog box could ask 'Stop or Continue'.

    Cheers,

    Buzby

  8. #8
    Technical Support
    Join Date
    Jan 1970
    Location
    Bath,UK
    Posts
    6,397
    Blog Entries
    1

    Default

    It is not a crash (software mistake) PE6 deliberately stops the simulator with an appropriate warning (intentionally programmed behaviour). Would you ever have noticed this issue in the BASIC program if the simulator did not do this?....

    Accessing a memory address out of range is a coding mistake by the end user, and so should be stopped and the end user program corrected.
    PICAXE Technical Support

  9. #9
    Senior Member
    Join Date
    Feb 2012
    Location
    London
    Posts
    2,626

    Default

    Hi,

    Quote Originally Posted by Buzby View Post
    If the simulator executed a 'Break' instead of a 'Stop' when it finds a boundary error, then the dialog box could ask 'Stop or Continue'.
    +1 . There was a similar comment in a thread a few days ago (I don't recall the exact context). Certainly I would prefer to receive a "warning" but then the simulation to continue (as best it can). Sometimes the PE's (or Rev Ed's) view of an "illegal" operation is not the same as mine.

    However, it probably wouldn't be of much use if PE continued to "warn" every time that an "illegal" access occurred (e.g. a break), which might be all that the PE6 architecture can achieve. (PS: but Technical implies that it is entirely intentional).

    Cheers, Alan.

  10. #10
    Senior Member
    Join Date
    Feb 2009
    Location
    Cheshire, England
    Posts
    2,361
    Blog Entries
    4

    Default

    Sorry Technical, but I disagree.

    The simulator should replicate the chip as close as practically possible, warts and all.

    If code passes a syntax check then it should run as per the chip, and if the chip doesn't boundary check so be it.
    ( It could be that the user deliberately wants to use a quirk of the chip, like the 6502 jump indirect instruction back in the day. )

    Far better if the simulator flags the situation, but continues running.

    Would you ever have noticed this issue in the BASIC program if the simulator did not do this?....
    Er, yes.

    Well, to be more precise, if I'd written the code the bug wouldn't be there.

    Cheers,

    Buzby

Bookmarks

Posting Permissions

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