1. poke2 (2)
- Posted by r.schr at t-online.de
Sep 14, 2001
Hi hardware freaks,
what i really want to know: a piece of Euphoria code which has the same
impact on the hardware as the following piece of C code:
/***** Begin of C-Code *****/
int *ip; /* address of 16-bit word */
ip = 0x200000; /* starting address of hardware memory */
*ip = 0xABCD; /* writing 16-bit word at address 0x200000 */
/***** End of C-Code *****/
Thanks, Rolf
2. Re: poke2 (2)
----- Original Message -----
From: <r.schr at t-online.de>
To: "EUforum" <EUforum at topica.com>
Subject: poke2 (2)
> Hi hardware freaks,
>
> what i really want to know: a piece of Euphoria code which has the same
> impact on the hardware as the following piece of C code:
>
> /***** Begin of C-Code *****/
>
> int *ip; /* address of 16-bit word */
>
> ip = 0x200000; /* starting address of hardware memory */
> *ip = 0xABCD; /* writing 16-bit word at address 0x200000 */
>
> /***** End of C-Code *****/
>
> Thanks, Rolf
You could try this...
integer INTEL
atom a
atom ip
-- See what sort of "endian" chip this is
a = allocate(4)
poke4(a, 1)
INTEL = peek(a)
free(a)
ip = #200000
if INTEL then
poke(ip, {#CD, #AB})
else
poke(ip, {#AB, #CD})
end if
----
Derek
3. Re: poke2 (2)
<lots of people have been writing...>
One situation I've encountered when poking values into memory locations
which are essential to operating some bit of hardware is with hardware
timers. Imagine there are two adjacent memory locations called timer+0 and
timer+1. They both hold a single unsigned 8 bit value. Together they
represent an unsigned 16 bit value. The timer+0 location contains the
least significant byte and timer+1 holds the most most significant byte.
The hardware decrements this 16 bit value fifty times a second. When both
timer+0 and timer+1 reach zero a trappable software interrupt is generated.
If anyone is interested I'm relating this stuff from programming a 6502
with, I think, a 6522 VIA (versatile interface adaptor) but it was a while
ago - don't quote me 
Now then timer+0 (the least significant byte of the combined 16 bit value)
transitions from 0 to 255 the hardware has to decrement the value in
timer+1. Here is the issue looming. When you set the timer with two
instructions like:
poke into timer+0 the least significant byte
poke into timer+1 the most significant bye
you have to consider the possibility (remote but possible) that after a
value has been poked into timer+0 the processor could be interrupted to
decrement the timer. If the value poked into timer+0 is zero then this
changes to 255. When program execution resumes the the poke into timer+1
takes place we have an incorrect value in the timer. The whole point of
using such hardware timers is to get precision and now the precision has
just been lost.
In many many test cases this scenario never happens but once the system is
running live after two years then BAM it happens. If your writing code to
operate a device that monitors a patients heart beat or even administers a
does of a drug via a drip then this stuff becomes _really_ important.
So you have to get clever when setting and even reading timer values. Most
approaches are based on a stick 255 in timer+0 and 255 in timer+1. Then
immediately do it again and then set your true values. When reading a
timer you do it twice and check for an anomaly.
By the way the best software anti-piracy protection method I ever saw was
based on a hardware timer but I'll save that for another day.
If anyone got this far then thanks for reading :-]
Regards,
FP.
