How much RAM is there in an 08M2 really ?

Buzby

Senior Member
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/showthread.php?20694-Portable-Magic-Morse-Decoder-MK2&p=198608&viewfull=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:

techElder

Well-known member
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.
 

hippy

Technical Support
Staff member
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

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.

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.
 

AllyCat

Senior Member
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.
 

hippy

Technical Support
Staff member
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.
 

Buzby

Senior Member
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
 

Technical

Technical Support
Staff member
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.
 

AllyCat

Senior Member
Hi,

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.
 

Buzby

Senior Member
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
 

srnet

Senior Member
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.
 

BESQUEUT

Senior Member
Sorry Technical, but I disagree.

The simulator should replicate the chip as close as practically possible, warts and all.
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")
 

Technical

Technical Support
Staff member
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:
[COLOR=Navy]#ifdef [/COLOR][COLOR=Blue]_08M2
SYMBOL [/COLOR][COLOR=Black]buffstart [/COLOR][COLOR=DarkCyan]= [/COLOR][COLOR=Navy]$58        [/COLOR][COLOR=Green]'setup 40 character buffer, 20character display[/COLOR]
[COLOR=Blue]SYMBOL [/COLOR][COLOR=Black]buffend [/COLOR][COLOR=DarkCyan]= [/COLOR][COLOR=Navy]$7F
#else[/COLOR]
[COLOR=Blue]SYMBOL [/COLOR][COLOR=Black]buffstart [/COLOR][COLOR=DarkCyan]= [/COLOR][COLOR=Navy]$D8        [/COLOR][COLOR=Green]'setup 40 character buffer, 20character display[/COLOR]
[COLOR=Blue]SYMBOL [/COLOR][COLOR=Black]buffend [/COLOR][COLOR=DarkCyan]= [/COLOR][COLOR=Navy]$FF
#endif[/COLOR]
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:
[COLOR=Navy]#ifdef [/COLOR][COLOR=Blue]simulating[/COLOR]
[COLOR=Black]address [/COLOR][COLOR=DarkCyan]= [/COLOR][COLOR=Black]address [/COLOR][COLOR=DarkCyan]& [/COLOR][COLOR=Navy]127
#endif[/COLOR]
There is never any reason for a stack underflow/overflow. Programs that attempt it can always be refactored to not need it.
 

premelec

Senior Member
@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... ]
 

Buzby

Senior Member
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
 

inglewoodpete

Senior Member
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?
 

BESQUEUT

Senior Member
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...
 

lbenson

Senior Member
is bptr in the 08M2 a 7- or 8-bit variable?
The following indicates that it is 7 bits (output is "127 127"):
Code:
#picaxe 08M2

bptr = $ffff
w0 = bptr
sertxd(#bptr," ",#w0,cr,lf)
For "#picaxe 14M2" (or 18M2 or 20M2) the output is "511 511".

For 20x2 it is "127 127", for 28X2 and 40X2 it is "255 255".
 
Top