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

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

  1. #11
    Senior Member
    Join Date
    Feb 2011
    Location
    Cardiff,UK
    Posts
    4,175

    Default

    As I am the person who wrote the code way back then, I recall it was not a 'coding mistake' at all, but deliberate as I was also running the code on an X2 as well.

    So a deliberate bit of coding that used a known feature of the M2.

    I agree with Buzby, the simulator should replicate as close as possible the known behaviour of the actual chip, its not a simulator if it does not.
    Picaxe in Space is now Silent (but probably still running)
    http://www.50dollarsat.info/

  2. #12
    Senior Member
    Join Date
    Jan 1970
    Location
    Colorado USA
    Posts
    2,947

    Default

    @Buzby - link in post one not working - please modify... tks

  3. #13
    Senior Member
    Join Date
    Feb 2009
    Location
    Cheshire, England
    Posts
    2,310
    Blog Entries
    4

    Default

    Quote Originally Posted by premelec View Post
    @Buzby - link in post one not working - please modify... tks
    Done. Not quite sure why the link didn't work before. http://www.picaxeforum.co.uk/showthr...l=1#post198608

    It's clever code, and when I've integrated into my current experiment ( which should be ready in a day or two, and it's a cracker ! ) I shall give all thanks to the author.

    Cheers,

    Buzby

  4. #14
    Senior Member
    Join Date
    Sep 2011
    Location
    Montpellier (FRANCE)
    Posts
    2,631

    Default

    Quote Originally Posted by Buzby View Post
    Sorry Technical, but I disagree.

    The simulator should replicate the chip as close as practically possible, warts and all.
    Quote Originally Posted by srnet View Post
    I agree with Buzby, the simulator should replicate as close as possible the known behaviour of the actual chip, its not a simulator if it does not.
    +1
    Same thing for return without gosub...
    At least, this can be a program option ("replicate chip" or "stop with warning")
    There are 10 types of people in the world: those who understand binary, and those who don't.

  5. #15
    Technical Support
    Join Date
    Jan 1970
    Location
    Bath,UK
    Posts
    6,357
    Blog Entries
    1

    Default

    Any code that causes confusion or question in the future for others should be avoided, even if it 'works'.

    Better coding would be something along the lines of this, which would never show any simulator message.

    Code:
    #ifdef _08M2
    SYMBOL buffstart = $58        'setup 40 character buffer, 20character display
    SYMBOL buffend = $7F
    #else
    SYMBOL buffstart = $D8        'setup 40 character buffer, 20character display
    SYMBOL buffend = $FF
    #endif
    There are only a couple of times the simulator intentionally stops, peek/poke invalid RAM or stack over/under flow. In 99% of cases where this occurs it is due to a coding error that the end user didn't even know about, and so the stop is beneficial as it forces a rethink/refactor to resolve the issue, rather than the end-user 'muddling on' with poorly written code and ignoring error messages. It was deliberate and considered design choice when moving from PE5 and PE6 to do this, not just an accidental 'crash' as been implied above.

    Experienced programmers can always bypass the warning if they want to, using something like

    Code:
    #ifdef simulating
    address = address & 127
    #endif
    There is never any reason for a stack underflow/overflow. Programs that attempt it can always be refactored to not need it.
    PICAXE Technical Support

  6. #16
    Senior Member
    Join Date
    Sep 2011
    Location
    Montpellier (FRANCE)
    Posts
    2,631

    Default

    Quote Originally Posted by Technical View Post
    In 99% of cases where this occurs it is due to a coding error that the end user didn't even know about,
    How did you measure that ?
    Why is it not possible to have an option for the remaining 1% ?
    There are 10 types of people in the world: those who understand binary, and those who don't.

  7. #17
    Senior Member
    Join Date
    Jan 1970
    Location
    Colorado USA
    Posts
    2,947

    Default

    @Buzby - thanks... as a lover of Morse for over 65 years i still copy by ear but am interested in how to read various fists... I was inspired to review several youtube videos on using various keying apparatus [as well as Morse readers which got me to looking at youtube] and surprised at the manual off timing that was being portrayed as good sending... but still was 'readable'. Old folk like me tend to rest on dashes... ;-0 And my practical observation of Morse information transfer is that you can get a lot of information into inaccurate timing - a simple example being a half dot indicating operator recognition of error ... [BTW there are some incredible fast manual sending displays on youtube... ]

  8. #18
    Senior Member
    Join Date
    Feb 2009
    Location
    Cheshire, England
    Posts
    2,310
    Blog Entries
    4

    Default

    There are only a couple of times the simulator intentionally stops, peek/poke invalid RAM or stack over/under flow. In 99% of cases where this occurs it is due to a coding error that the end user didn't even know about, and so the stop is beneficial as it forces a rethink/refactor to resolve the issue, rather than the end-user 'muddling on' with poorly written code and ignoring error messages. It was deliberate and considered design choice when moving from PE5 and PE6 to do this, not just an accidental 'crash' as been implied above.
    The simulator stops, but the real chip doesn't. It's a fault, albeit intentionally, in PE.

    My suggestion, which addresses both views, is that the simulator should have a 'message' window, where anything PE doesn't like is shown in "BIG RED LETTERS"

    I agree, 99% of the time a boundary excursion or an over-pushed stack is a novice coding error, but what about the 1% of us who know what we are doing ?

    Cheers,

    Buzby

  9. #19
    Senior Member
    Join Date
    Jan 1970
    Location
    Perth, Western Australia
    Posts
    4,251

    Default

    Quote Originally Posted by Buzby View Post
    My suggestion, which addresses both views, is that the simulator should have a 'message' window, where anything PE doesn't like is shown in "BIG RED LETTERS"

    I agree, 99% of the time a boundary excursion or an over-pushed stack is a novice coding error, but what about the 1% of us who know what we are doing ?
    My thoughts, FWIW. I rarely use the simulator, preferring the real thing.

    Perhaps are better solution would be to have two selectable modes of simulator operation: 1) Stop on error (diagnostic mode) and 2) Stumble over errors (like the real chip). Similar to other versions of basic (Eg Behave like "On error goto 0" or "On error resume next").

    One question, which I could check myself: is bptr in the 08M2 a 7- or 8-bit variable?

  10. #20
    Senior Member
    Join Date
    Sep 2011
    Location
    Montpellier (FRANCE)
    Posts
    2,631

    Default

    Quote Originally Posted by inglewoodpete View Post
    Perhaps are better solution would be to have two selectable modes of simulator operation: 1) Stop on error (diagnostic mode) and 2) Stumble over errors (like the real chip). Similar to other versions of basic (Eg Behave like "On error goto 0" or "On error resume next").
    +1 for that...
    There are 10 types of people in the world: those who understand binary, and those who don't.

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
  •