Hi,
the actual raspberry os does no longer support wiringPi, which was a way to access GPIO under GForth as described here: https://forums.raspberrypi.com/viewtopic.php?t=207597
Is there now another (easy) way?
Hi,
the actual raspberry os does no longer support wiringPi, which was a way to access GPIO under GForth as described here:
https://forums.raspberrypi.com/viewtopic.php?t=207597
Is there now another (easy) way?
Thanks in advance! Christof
An alternative is ciforth
lina.html on my site below.
Christof Eberspaecher <chwe...@gmail.com> writes:Thank you, Anton!
Hi,Bernd Paysan implemented words for GPIO access on Raspi3, Raspi4, and
the actual raspberry os does no longer support wiringPi, which was a way to access GPIO under GForth as described here: https://forums.raspberrypi.com/viewtopic.php?t=207597
Is there now another (easy) way?
Odroid C2 and N2(+) last year, and from what he wrote
http://git.savannah.gnu.org/cgit/gforth.git/tree/arch/arm64/gpios.fs
It's included with the current Gforth snapshot
http://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth.tar.xz
in
arch/arm64/gpios.fs
If you know German, you can find an Article about it in
https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d2021-02.pdf
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html
Anton Ertl schrieb am Dienstag, 5. Juli 2022 um 18:26:01 UTC+2:
Christof Eberspaecher <chwe...@gmail.com> writes:
Hi,Bernd Paysan implemented words for GPIO access on Raspi3, Raspi4, and Odroid C2 and N2(+) last year, and from what he wrote
the actual raspberry os does no longer support wiringPi, which was a way to access GPIO under GForth as described here: https://forums.raspberrypi.com/viewtopic.php?t=207597
Is there now another (easy) way?
http://git.savannah.gnu.org/cgit/gforth.git/tree/arch/arm64/gpios.fs
It's included with the current Gforth snapshot
http://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth.tar.xz
in
arch/arm64/gpios.fs
If you know German, you can find an Article about it in
https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d2021-02.pdf
- antonThank you, Anton!
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html New standard: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html
Yes, I speak German. Unfortunately I want to use a Raspi2. Well, perhaps some excuse to buy a Raspi4, when they might be available again....
Unfortunately I want to use a Raspi2. Well, perhaps some excuse to buy a Raspi4, when they might be available again....
Christof Eberspaecher schrieb am Mittwoch, 6. Juli 2022 um 08:01:48 UTC+2:
Anton Ertl schrieb am Dienstag, 5. Juli 2022 um 18:26:01 UTC+2:
Christof Eberspaecher <chwe...@gmail.com> writes:Thank you, Anton!
Hi,Bernd Paysan implemented words for GPIO access on Raspi3, Raspi4, and
the actual raspberry os does no longer support wiringPi, which was a way to access GPIO under GForth as described here: https://forums.raspberrypi.com/viewtopic.php?t=207597
Is there now another (easy) way?
Odroid C2 and N2(+) last year, and from what he wrote
http://git.savannah.gnu.org/cgit/gforth.git/tree/arch/arm64/gpios.fs
It's included with the current Gforth snapshot
http://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth.tar.xz
in
arch/arm64/gpios.fs
If you know German, you can find an Article about it in
https://wiki.forth-ev.de/lib/exe/fetch.php/vd-archiv:4d2021-02.pdf
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html >> > New standard: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html
Yes, I speak German. Unfortunately I want to use a Raspi2. Well, perhaps some excuse to buy a Raspi4, when they might be available again....
Mind that a Pi4 is a power hog eating in the range of 2 amps(!) at 5 V.
In article <ca1bcf8a-624e-46e0...@googlegroups.com>,Thank you, Albert!
Christof Eberspaecher <chwe...@gmail.com> wrote:
Hi,An alternative is ciforth
the actual raspberry os does no longer support wiringPi, which was a way to access GPIO under GForth as described here:
https://forums.raspberrypi.com/viewtopic.php?t=207597
Is there now another (easy) way?
Thanks in advance! Christof
lina.html on my site below.
WANT set-function gpio-on
18 CONSTANT #LED
_output #LED set-function
#LED gpio-on
#LED gpio-off
Tested on raspberry 1, 32 bit version.
Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
An alternative is ciforth
lina.html on my site below.
It wouldn't hurt to add the word like EKEY, allowing recognition of keys
like Home/End, PgUp/Dn, F-keys, cursor etc.
Also a little more comfortable command line (moving around within theThis is actually available.
bounds of typed sentence, not only with Backspace; „history”...) would be >nice add-on.
You can define
: EKEY KEY BEGIN KEY? WHILE 8 LSHIFT KEY OR REPEAT ;
Also a little more comfortable command line (moving around within the >bounds of typed sentence, not only with Backspace; „history”...) would beThis is actually available.
nice add-on.
You can start your lina with
rlwrap lina
You can define
: EKEY KEY BEGIN KEY? WHILE 8 LSHIFT KEY OR REPEAT ;
You can defineBut this solution isn't general; for example: it doesn't work in case of key-combination Shift-PgDn.
: EKEY KEY BEGIN KEY? WHILE 8 LSHIFT KEY OR REPEAT ;
FORTH> ekey h. $00012200 ok ( keypad ): EKEY KEY BEGIN KEY? WHILE 8 LSHIFT KEY OR REPEAT ;But this solution isn't general; for example: it doesn't work in case of key-combination Shift-PgDn.
FORTH> ekey h. $00002200 ok ( just PgDn )
FORTH> ekey h. $00012200 ok ( cursorblock )
Hi,
the actual raspberry os does no longer support wiringPi, which was a way to access GPIO under GForth as described here: https://forums.raspberrypi.com/viewtopic.php?t=207597
Is there now another (easy) way?
Thanks in advance! Christof
It wouldn't hurt to add the word like EKEY, allowing recognition of keys like Home/End, PgUp/Dn, F-keys, cursor etc.
Also a little more comfortable command line (moving around within the
bounds of typed sentence, not only with Backspace; „history”...) would be
nice add-on.
Even more interesting: it doesn't work
in Gforth either; neither the above definition, nor Gforth's own EKEY
don't detect Shift-PgDn key combination. I wonder what can be so
special about this? Maybe Linux' scrollback buffer somehow so strongly >=E2=80=9Ehijacks=E2=80=9D this one, that it's difficult to handle by Forth?
Still I probably didn't try every key combination possible, so maybe
there is also a problem with some other key combination. So far
I detected problem with both Shift-PgDn and Shift-PgUp.
You can define
: EKEY KEY BEGIN KEY? WHILE 8 LSHIFT KEY OR REPEAT ;
But this solution isn't general; for example: it doesn't work in case of >key-combination Shift-PgDn.
You can define
: EKEY KEY BEGIN KEY? WHILE 8 LSHIFT KEY OR REPEAT ;
Thanks.
would beAlso a little more comfortable command line (moving around within the
bounds of typed sentence, not only with Backspace; „history”...)
nice add-on.This is actually available.
You can start your lina with
rlwrap lina
I know „rlwrap” since long time — it's very useful — but lina
often crashes
badly when used with rlwrap, for example if I accidentally make a typo
(most of the time it doesn't, but you'll never know, when suddenly you're
out of Forth in such case).
Since lina is on GPL2, it wouldn't hurt to employ „readline” directly.
none albert schrieb am Dienstag, 5. Juli 2022 um 20:55:45 UTC+2:
In article <ca1bcf8a-624e-46e0...@googlegroups.com>,way to access GPIO under GForth as described here:
Christof Eberspaecher <chwe...@gmail.com> wrote:
Hi,
the actual raspberry os does no longer support wiringPi, which was a
WANT seems to work after 1 LOAD, but says: ... not present but wanted. (Oh yes.)https://forums.raspberrypi.com/viewtopic.php?t=207597An alternative is ciforth
Is there now another (easy) way?
Thanks in advance! Christof
lina.html on my site below.
WANT set-function gpio-on
18 CONSTANT #LED
_output #LED set-function
#LED gpio-on
#LED gpio-off
Tested on raspberry 1, 32 bit version.
Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst >Thank you, Albert!
I did not find the docu for gpio.
The source seems to be in screen 146 for raspi1 but I was not able to
get it to work.
I am astonished, that you can just @ and ! in linux? I got a >"Speicherzugriffsfehler" crash even with sudo.
Christof
Zbig <zbigniew2011@gmail.com> writes:
Even more interesting: it doesn't work
in Gforth either; neither the above definition, nor Gforth's own EKEY
don't detect Shift-PgDn key combination. I wonder what can be so
special about this? Maybe Linux' scrollback buffer somehow so strongly >>=E2=80=9Ehijacks=E2=80=9D this one, that it's difficult to handle by Forth?
I tried it with Gforth running in an xterm, and the xterm (probably
other terminal emulators as well) does not pass Shift-PgDn on to
gforth, because it uses it for its own scrolling purposes. You can
probably configure xterm to pass Shift-PgDn on to the application, but
does Gforth's EKEY know the escape sequence for that?
Still I probably didn't try every key combination possible, so maybe
there is also a problem with some other key combination. So far
I detected problem with both Shift-PgDn and Shift-PgUp.
Shift-Up and Shift-Down are also captured for scrolling, and Ctrl-S
Ctrl-Q for flow control, and (I think) the shell captures Ctrl-C for >interrupt and Ctrl-Z for stopping the process.
- anton
I can't believe anybody commented on this, without mentionning
what the environment is, e.g. TERM=xterm-256color
In article <3d1b59d5-8ed3-4c5b-a217-6a9db036126cn@googlegroups.com>,
Christof Eberspaecher <chwebersp@gmail.com> wrote:
none albert schrieb am Dienstag, 5. Juli 2022 um 20:55:45 UTC+2:(Oh yes.)
In article <ca1bcf8a-624e-46e0...@googlegroups.com>,way to access GPIO under GForth as described here:
Christof Eberspaecher <chwe...@gmail.com> wrote:
Hi,
the actual raspberry os does no longer support wiringPi, which was a
Thank you, Albert!https://forums.raspberrypi.com/viewtopic.php?t=207597An alternative is ciforth
Is there now another (easy) way?
Thanks in advance! Christof
lina.html on my site below.
WANT set-function gpio-on
18 CONSTANT #LED
_output #LED set-function
#LED gpio-on
#LED gpio-off
Tested on raspberry 1, 32 bit version.
Groetjes Albert
WANT seems to work after 1 LOAD, but says: ... not present but wanted.
I did not find the docu for gpio.
The source seems to be in screen 146 for raspi1 but I was not able to
get it to work.
I am astonished, that you can just @ and ! in linux? I got a >>"Speicherzugriffsfehler" crash even with sudo.
Christof
You can io with @ and !. That is memory mapped io.
Mostly however you must use C@ and C!.
On a 64 bit system you have to occasionally use L@ and L!
(32 bit io).
I added gpio for a demonstration of led display, I admit that
the library is poorly documented.
Can you send the whole log via e-mail ?
Groetjes Albert
From what I see lina expects its „forth.lab” file in current directory. >Wouldn't it be somewhat better idea to make it search for this file
current directory first, and if not found there — then to try lina
binary's installation directory?
Why I raised this question: I copied lina binary to my „~/bin” to have
it in my „path”. But there's no advantage of doing this, if one's still >„directory-dependent” in such circumstances.
What I mean is that in „~/bin” I could keep default „forth.lab”, having
still ability to override this (in case of any need) with local copy, if present
in current dir. More flexibility.
Apparently you haven't read the documentation, not even the
READMElina.txt.
- lina is directly usable after unpacking
- follow the instruction in READMElina.txt for system wide installation,
Apparently you haven't read the documentation, not even the
READMElina.txt.
I feel a misunderstanding. You are not supposed to edit the block
file, normally. The ./lab is a storage for library code
and a normal user is not allowed to modify the installed library.
(Other users would not like this!)
If you see gforth code you see
require <facility.fs>
In ciforth that sort of stuff is tucked into .lab.
You don't expect to modify <facility.fs> in gforth, do you?
(And other users may object to your changes, and you need
root privileges to do that, a huge red flag.)
In article <f9aa24e0-6b0d-4ce0-81f8-665cfb01cac0n@googlegroups.com>,
Zbig <zbigniew2011@gmail.com> wrote:
From what I see lina expects its „forth.lab” file in current directory. >>Wouldn't it be somewhat better idea to make it search for this fileif present
current directory first, and if not found there — then to try lina >>binary's installation directory?
Why I raised this question: I copied lina binary to my „~/bin” to have >>it in my „path”. But there's no advantage of doing this, if one's still >>„directory-dependent” in such circumstances.
What I mean is that in „~/bin” I could keep default „forth.lab”, having
still ability to override this (in case of any need) with local copy,
in current dir. More flexibility.
Apparently you haven't read the documentation, not even the
READMElina.txt.
- lina is directly usable after unpacking
- follow the instruction in READMElina.txt for system wide installation,
or e.g. in a personal bin directory.
In short lina expects nothing regards the library file.
The absolute path of the library file is burned into the executable
during installation.
Groetjes Albert--
Apparently you haven't read the documentation, not even the
READMElina.txt.
- lina is directly usable after unpacking
- follow the instruction in READMElina.txt for system wide installation,
So you mean there's a need for that "special" way of installation?
I was trying to use the "-l" option, as the chapter "4.9.2 Private libraries" >says, but it doesn't work, unfortunately.
OK, will try to install it differently.
By chance I now found, that you can still install wiringPi:
Apparently you haven't read the documentation, not even the
READMElina.txt.
Unfortunately, the given procedure seems to be working only for 32-bit version.
-- I modified line 28 in Makefile (I mean lina-master.zip archive from github)
to ln -sf lina64.cfg lina.cfg;
-- lina version 64-bit has been created
-- as root I typed:
* ./lina64 -g 60 lina64+
* ./lina64+ -i /usr/bin/lina64 /usr/lib/forth.lab
* ln -s /usr/bin/lina64 /usr/bin/lina
* chmod 755 /usr/bin/lina64
* chmod 644 /usr/lib/forth.lab
Unfortunately, any attempt to run it looks like this:
AMDX86 ciforth Segmentation fault
...fortunately, however, 32-bit binary works in my system.
Unfortunately, it's interested only in that system-wide "forth.lab":
execve("/usr/bin/lina", ["lina", "-e"], [/* 61 vars */]) = 0 >open("/usr/lib/forth.lab", O_RDONLY) = 3
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
As I wrote: the "alias" solution somehow doesn't work.
BTW: reading ci86.lina.pdf (stopped at "Assembler" at the moment)
I was treating it as kind of "Reference Guide", so I thought I don't
need to search little README-type small *.txt files scattered
"here and there" in addition, assuming the manual contains complete >information.
I tried it with Gforth running in an xterm, and the xterm (probably
other terminal emulators as well) does not pass Shift-PgDn on to gforth, because it uses it for its own scrolling purposes. You can probably configure xterm to pass Shift-PgDn on to the application, but does
Gforth's EKEY know the escape sequence for that?
I have modified the installation in behalf of Debian and
botched the normal installation. You have found a real defect.
The installation defect warrants a new release.
I filed it as an issue, with a work around.
Sometimes you need a push.I have modified the installation in behalf of Debian and
botched the normal installation. You have found a real defect.
The installation defect warrants a new release.
I filed it as an issue, with a work around.
Glad I could be of any help.
I tried also mina under FreeDOS -- unfortunately, with my usual
configuration it crashed badly JEMMEX (EMS/XMS memory manager).
So i tried to run it on the system without any drivers at all; it
still refused to cooperate, reporting "Runtime error 200 at 0963:2850".
So i tried to run it on the system without any drivers at all; itIt run splendidly on MSDOS 6.22.
still refused to cooperate, reporting "Runtime error 200 at 0963:2850".
So i tried to run it on the system without any drivers at all; itIt run splendidly on MSDOS 6.22.
still refused to cooperate, reporting "Runtime error 200 at 0963:2850".
Was it slower or faster machine? I did my tries on DX2/66.
Was it slower or faster machine? I did my tries on DX2/66.That looks like the Borland Pascal bug. It required a fast cpu (Pentium
or better) to manifest.
Was it slower or faster machine? I did my tries on DX2/66.That looks like the Borland Pascal bug. It required a fast cpu (Pentium
or better) to manifest.
So it looks like that interrupt has been requested even before the cell contents...or maybe rather it has been copied to CPU's "prefetch queue" before self-modification
has been modified?
Was it slower or faster machine? I did my tries on DX2/66.That looks like the Borland Pascal bug. It required a fast cpu (Pentium
or better) to manifest.
From what I see Mina binary has at 284Eh (exactly just before 2850h) "INT 00".
(From "DOS Interrupts": "INT 00 - internal - DIVIDE ERROR")
It is the place described in the source as "RQBIOS: INT(0) ; request number to be overwritten".
Since that part is described as "self modifying code" the conclusion is, that >the self-modification doesn't go exactly as well in different circumstances.
BTW there are sequences like:
XCHG AX,SI
XCHG AX,SI
What's the purpose of that swapping ”back and forth”?
So i tried to run it on the system without any drivers at all; itIt run splendidly on MSDOS 6.22.
still refused to cooperate, reporting "Runtime error 200 at 0963:2850".
Was it slower or faster machine? I did my tries on DX2/66.
In article <a44a8393-58e4-4326-963d-885cd5a79debn@googlegroups.com>,
Zbig <zbigniew2011@gmail.com> wrote:
Was it slower or faster machine? I did my tries on DX2/66.That looks like the Borland Pascal bug. It required a fast cpu (Pentium
or better) to manifest.
From what I see Mina binary has at 284Eh (exactly just before 2850h) "INT 00".
(From "DOS Interrupts": "INT 00 - internal - DIVIDE ERROR")
It is the place described in the source as "RQBIOS: INT(0) ; request number to be overwritten".
Since that part is described as "self modifying code" the conclusion is, that >>the self-modification doesn't go exactly as well in different circumstances.
That conclusion is correct. The bug is not in mina, but in the msdos emulator that not allows this modification.
BIOSO is used two times. The purpose of BIOSO to call the bios with high level code. You can replace the bios calls with assembler code, and then
the self modifying code vanishes.
The library code that uses BIOSO will no longer work.
That conclusion is correct. The bug is not in mina, but in the msdos emulator
that not allows this modification.
BIOSO is used two times. The purpose of BIOSO to call the bios with high level code. You can replace the bios calls with assembler code, and then the self modifying code vanishes.As DX-Forth uses the same scheme (self-modify an 'INT 0') it should also
The library code that uses BIOSO will no longer work.
fail assuming that's the cause. To rule out MINA, I would patch INT 00h to INT 66h (unused interrupt). AFAIK 'Runtime error 200 at' is a Borland code and message.
Since that part is described as "self modifying code" the conclusion is, thatthat not allows this modification.
the self-modification doesn't go exactly as well in different circumstances. That conclusion is correct. The bug is not in mina, but in the msdos emulator
Since that part is described as "self modifying code" the conclusion is, thatThat conclusion is correct. The bug is not in mina, but in the msdos emulator
the self-modification doesn't go exactly as well in different circumstances.
that not allows this modification.
Well maybe it cannot be called „a bug” in strict sense, still it is non-reliable code:
„For Intel486(TM) processors, a write to an instruction in the cache will modify
it in both the cache and memory, but if the instruction was prefetched before the write, the old version of the instruction could be the one executed.”
( https://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/pentium4_hh/events4/self-modifying_code_clear.htm )
So it's confirmed 100%. Creating self-modifying code for the processors higher
than 386 seems to be risky business, unfortunately.
Since that part is described as "self modifying code" the conclusion is, thatThat conclusion is correct. The bug is not in mina, but in the msdos emulator
the self-modification doesn't go exactly as well in different circumstances.
that not allows this modification.
Well maybe it cannot be called „a bug” in strict sense, still it is non-reliable code:
„For Intel486(TM) processors, a write to an instruction in the cache will modify
it in both the cache and memory, but if the instruction was prefetched before
the write, the old version of the instruction could be the one executed.”
( https://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/pentium4_hh/events4/self-modifying_code_clear.htm )
So it's confirmed 100%. Creating self-modifying code for the processors higherBut what is the official position? All I could find was:
than 386 seems to be risky business, unfortunately.
IA-32 Intel® Architecture Software Developer’s Manual Volume 3:
On 25/07/2022 07:07, Zbig wrote:
So it's confirmed 100%. Creating self-modifying code for the processors higher
than 386 seems to be risky business, unfortunately.
IA-32 Intel® Architecture Software Developer’s Manual Volume 3:
To write self-modifying code and ensure that it is compliant with current
and future versions of the IA-32 architecture, one of the following two
coding options must be chosen:
(* OPTION 1 *)
Store modified code (as data) into code segment;
Jump to new code or an intermediate location;
Execute new code;
(* OPTION 2 *)
Store modified code (as data) into code segment;
Execute a serializing instruction; (* For example, CPUID instruction *)
Execute new code;
(The use of one of these options is not required for programs intended
to run on the Pentium or Intel486 processors, but are recommended to
insure compatibility with the Pentium 4, Intel Xeon, and P6 family
processors.)
Risky? You just follow the rules, and it works.So it's confirmed 100%. Creating self-modifying code for the processors higher
than 386 seems to be risky business, unfortunately.
Risky? You just follow the rules, and it works.So it's confirmed 100%. Creating self-modifying code for the processors higher
than 386 seems to be risky business, unfortunately.
Oh, I don't know. Most of the time it works — but then one finds
the case when it doesn't, and then there are controversies: „no,
it's not the code; it's bad emulator” or the like.
From what I see the technique is better to be avoided, unless it is
„really really” needed for some particular reason.
...
IA-32 Intel® Architecture Software Developer’s Manual Volume 3:
To write self-modifying code and ensure that it is compliant with current >> and future versions of the IA-32 architecture, one of the following two
coding options must be chosen:
(* OPTION 1 *)
Store modified code (as data) into code segment;
Jump to new code or an intermediate location;
Execute new code;
That's the rule I stated above.
(* OPTION 2 *)
Store modified code (as data) into code segment;
Execute a serializing instruction; (* For example, CPUID instruction *)
Execute new code;
Note that CPUID only exists on the Pentium and later CPUs. I wonder
what that rule is about? Who would use a slow serializing instruction (typically 10+ cycles) instead of a fast jump and make their program
less portable at the same time?
(The use of one of these options is not required for programs intended
to run on the Pentium or Intel486 processors, but are recommended to
insure compatibility with the Pentium 4, Intel Xeon, and P6 family
processors.)
I am absolutely certain that the jump rule is needed for the 486 and
earlier CPUs. I don't know if it's needed for the more recent CPUs
mentioned above.
What steps did you take to rule out MINA as the cause of your error?
Does it happen with DX-Forth? I used self-modifying code which you
can test with:
s" foobar$" drop 'DX ! 9 doscall
From what I see the technique is better to be avoided, unless it is „really really” needed for some particular reason.Such as when there's no single 'INT' instruction.
[...]
As DX-Forth uses the same scheme (self-modify an 'INT 0') it should also
fail assuming that's the cause. To rule out MINA, I would patch INT 00h to >> INT 66h (unused interrupt). AFAIK 'Runtime error 200 at' is a Borland code >> and message.
So I did it, changing "INT 00" to "INT 66". While with "INT 00" it spits out "Divide error" under debug (but then I'm able to continue), in case of "INT 66"
the machine is hung up.
Of course DXForth works as usual (no problems).
From the above it certainly looks like MINA isn't modifying the 'INT 00' instr
- but why if the DX-Forth DOSCALL test I posted works? I'll compare the codes
to see if I can spot something. It doesn't make sense that SMC should work on
DX-Forth but not on MINA when run on the same machine/setup.
OK, so I made the test you've posted and yes, it works like this:
s" foobar$" drop 'DX ! 9 doscall foobar ok
: test begin $30 doscall key? until key drop ;
It proves nothing if it works but a fail would be interesting.
You are using FreeDOS - can you boot a genuine MS-DOS?
: test begin $30 doscall key? until key drop ;
It proves nothing if it works but a fail would be interesting.
It seems to be working OK. Waited some time and ended the
loop with keypress.
You are using FreeDOS - can you boot a genuine MS-DOS?
Not on that particular 486 — too much hassle with such „transition”. But honestly: reliable code should work on either one, not „only for
MS-DOS (tm)". FreeDOS isn't an emulator — and I already wrote, that
exactly under emulator (which uses FreeDOS files, BTW) Mina — rather surprisingly, in such situation — works correctly?
On 26/07/2022 19:26, Anton Ertl wrote:
...
IA-32 Intel® Architecture Software Developer’s Manual Volume 3:
To write self-modifying code and ensure that it is compliant with current >>> and future versions of the IA-32 architecture, one of the following two >>> coding options must be chosen:
(* OPTION 1 *)
Store modified code (as data) into code segment;
Jump to new code or an intermediate location;
Execute new code;
That's the rule I stated above.
(* OPTION 2 *)
Store modified code (as data) into code segment;
Execute a serializing instruction; (* For example, CPUID instruction *) >>> Execute new code;
Note that CPUID only exists on the Pentium and later CPUs. I wonder
what that rule is about? Who would use a slow serializing instruction
(typically 10+ cycles) instead of a fast jump and make their program
less portable at the same time?
(The use of one of these options is not required for programs intended
to run on the Pentium or Intel486 processors, but are recommended to
insure compatibility with the Pentium 4, Intel Xeon, and P6 family
processors.)
I am absolutely certain that the jump rule is needed for the 486 and
earlier CPUs. I don't know if it's needed for the more recent CPUs
mentioned above.
I've no experience but assuming so I would at least expect to see it
stated in the docs for the 486. At the time the 486 was created, DOS programs were still widely used and for Intel to release a CPU that
was incompatible would be 'A courageous decision, Minister'.
If you are able re-assemble MINA, try inserting a JMP per Intel:
MOV BYTE [RQBIOS+1],AL ; Patch the code.
JMP XXX
XXX: POP DX
p.s. Change that so the interval between modify and execute exceeds 32 bytes.
p.s. Change that so the interval between modify and execute exceeds 32 bytes.
Indeed after insertion of 32 NOPs — which along with following few instructions
gave a little more than 32 bytes — it started to work. But when I was trying to fix
that with two shorter jumps „back and forth” — no way.
I'll simply replace that SMC with „ordinary” code.
Indeed after insertion of 32 NOPs — which along with following few instructionsGoogling I got the impression a JMP to the next instruction should have worked.
gave a little more than 32 bytes — it started to work. But when I was trying to fix
that with two shorter jumps „back and forth” — no way.
Did you use a 3-byte JMP instr? As both BIOSO and BIOSN self-modify, both need
patching.
If the JMP's don't work it would be possible to split the routines and satisfy
the 32-byte distance requirement without the need for padding.
I'll simply replace that SMC with „ordinary” code.It rather defeats the purpose. I wouldn't do it to DX-Forth. A programmer is expected to solve problems - not run away from them :)
Indeed after insertion of 32 NOPs — which along with following few instructionsGoogling I got the impression a JMP to the next instruction should have worked.
gave a little more than 32 bytes — it started to work. But when I was trying to fix
that with two shorter jumps „back and forth” — no way.
Did you use a 3-byte JMP instr? As both BIOSO and BIOSN self-modify, both need
patching.
Indeed NASM optimized these jumps to 2-byte instruction — so I changed it to be
both 'JMP LONG' explicitly. Unfortunately, it didn't change much; mina breaks as
before.
If the JMP's don't work it would be possible to split the routines and satisfy
the 32-byte distance requirement without the need for padding.
Probably. Even very likely.
I'll simply replace that SMC with „ordinary” code.It rather defeats the purpose. I wouldn't do it to DX-Forth. A programmer is >> expected to solve problems - not run away from them :)
Actually I'm not sure is it worth the effort.
From what I see the most important is „DOS dispatcher” INT 21h, and just a few more, like: INT 10, 11, 12, 13, 15, 16, 19, 1A, 20, 33 (h). That makes eleven interrupts together. So for such handful it's possible to handle the problem
using kind of table, being 100% sure nothing will break in case the program will be
run on another, even different processor, that maybe will behave some slighthly different
way. If there was need to use, say, 60 different interrupts or so — well, that would be
quite different story. But if there's no need — maybe it would be practical to follow the
advice from „Thinking Forth”, I mean: „Generality usually involves complexity. Don't
generalize your solution any more than will be required; instead, keep it changeable”.
I'll simply replace that SMC with „ordinary” code.
As for SMC failing on later CPUs I would have expected
to see reports of same. I ran MINA on a Pentium without issue. Without evidence
to the contrary I would treat 486 as a special case. No point crippling software
because Intel gave birth to one bastard. Similarly the idea SMC is the devil's
work to be avoided at any cost.
So yes, maybe „one bastard” — still it's the quite ubiquitous one (if we mean that now
„retro” gear). Really a pity I don't have any AMD 486 for comparison.
On the other hand: it's good to know, that unmodified Mina (or just that short procedure)
can be used for testing CPUs regarding potential SMC (un)reliability.
MOV BYTE [RQBIOS+1],AL ; Patch the code.
JMP XXX
XXX: POP DX
Otherwise any backwards JMP should do it.
Otherwise any backwards JMP should do it.
Two days ago I changed that code following way:
POP AX ; Function code
; Once we are more acknowledgeable, put segment overwrite here.
JMP XXX1 ; senseless jump to make self-modifying code work on 486 YYY1: MOV BYTE [RQBIOS+1],AL ; Patch the code.
POP DX
POP CX
POP BX
POP AX
PUSH SI ; Save Forth registers. NEEDED?
PUSH BP
; XCHG SI,AX ; Save AX in (already free) SI
; XCHG SI,AX
RQBIOS: INT(0) ; Request number to be overwritten.
PUSHF ; Save status into DI
POP DI
; XCHG SI,AX ; Save AX in (still free) SI
; XCHG SI,AX
POP BP ; Restore Forth registers. NEEDED?
POP SI
PUSH AX
PUSH BX
PUSH CX
PUSH DX
PUSH DI ; i.e. flags
JMP SHORT ZZZ1
XXX1: JMP YYY1 ; senseless return
ZZZ1: JMP NEXT
; SELF MODIFYING CODE ENDS HERE! YOU HAVE BEEN WARNED!
So, as you can see there are even two jumps — forth and back — and this wasn't of any help.
That's why I became somewhat cautious with SMC.
JMP XXX1 ; senseless jump to make self-modifying code work on 486
[..]
XXX1: JMP YYY1 ; senseless return
Are you saying the following patch (applied to both BIOSO and BIOSN) doesn't work?
MOV BYTE [RQBIOS+1],AL ; Patch the code.
JMP XXX
NOP
XXX: POP DX
Are you saying the following patch (applied to both BIOSO and BIOSN) doesn't >> work?
MOV BYTE [RQBIOS+1],AL ; Patch the code.
JMP XXX
NOP
XXX: POP DX
Yep, that works. Thanks.
Great! Can you confirm:
1) Changing JMP XXX to JMP SHORT XXX it still works
2) Deleting the NOP causes it to fail
Great! Can you confirm:
[...]
2) Deleting the NOP causes it to fail
When I commented-out the NOPs, it... still works.
Hi,
the actual raspberry os does no longer support wiringPi, which was a way to access GPIO under GForth as described here: https://forums.raspberrypi.com/viewtopic.php?t=207597
Is there now another (easy) way?
Thanks in advance! Christof
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 60:18:18 |
| Calls: | 6,915 |
| Calls today: | 5 |
| Files: | 12,379 |
| Messages: | 5,431,244 |