GPIO access with GForth on Raspberry Pi

[Christof Eberspaecher]

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

[Anton Ertl]

Christof Eberspaecher <chwe...@gmail.com> writes:
>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?

Bernd Paysan implemented words for GPIO access on Raspi3, Raspi4, and
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

[none albert]

In article <ca1bcf8a-624e-46e0...@googlegroups.com>,

An alternative is ciforth
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

[Zbig]

> 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 the
bounds of typed sentence, not only with Backspace; „history”...) would be
nice add-on.

[Christof Eberspaecher]

Thank you, Anton!
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....
Christof

[minf...@arcor.de]

Mind that a Pi4 is a power hog eating in the range of 2 amps(!) at 5 V.

[Anton Ertl]

Christof Eberspaecher <chwe...@gmail.com> writes:
>Unfortunately I want to use a Raspi2. Well, perhaps some excuse to buy a Raspi4, when they might be available again....

There are some offers
<https://geizhals.at/raspberry-pi-4-modell-b-a2081132.html>, although
many are relatively expensive. Availability and prices for the Raspi
400 (Raspi4 in a keyboard) seems to be better.

Another alternative is to enhance gpios.fs to work on the Raspi2

[none albert]

In article <4bd2d1c3-e160-4bb5...@googlegroups.com>,

Zbig <zbigni...@gmail.com> wrote:
>> 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.

You can define
: EKEY KEY BEGIN KEY? WHILE 8 LSHIFT KEY OR REPEAT ;
but then have you experimentally find out, what PgUp does
in your environment and add it to your program as per
"Press page down" TYPE EKEY CONSTANT PgDown
An alternative in linux is to run
infocmp -l -c
and analyse the key definitions and add them to you program.
This adds a whopping 216 words to lina, all but doubling it in size.
Note that this must be done runtime, if you switch to a
a real console window, the output of `` infocmp -l -c ''
is different. The definitions of PgUp etc. cannot be built
in your program.

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

This is actually available.
You can start your lina with
rlwrap lina
and you have comfortable line editing and history, while at
the same time retaining cut-and-paste capability from terminals.

Note that the Windows version of ciforth has these factilities
available, courtesy Bill Gates.

[dxforth]

The official powerpack looks absurdly small for 3A. Wouldn't want that blowing up
and taking out everything connected (user included).

[Christof Eberspaecher]

Thank you, Albert!
WANT seems to work after 1 LOAD, but says: ... not present but wanted. (Oh yes.)
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]

> You can define
> : EKEY KEY BEGIN KEY? WHILE 8 LSHIFT KEY OR REPEAT ;

Thanks.

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

[Zbig]

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

[Marcel Hendrix]

FORTH> ekey h. $00012200 ok ( keypad )
FORTH> ekey h. $00002200 ok ( just PgDn )
FORTH> ekey h. $00012200 ok ( cursorblock )

-marcel

[Zbig]

> > > : 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. $00012200 ok ( keypad )
> FORTH> ekey h. $00002200 ok ( just PgDn )
> FORTH> ekey h. $00012200 ok ( cursorblock )

Well in lina it doesn't work. 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
„hijacks” 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.

[Christof Eberspaecher]

By chance I now found, that you can still install wiringPi:

#Bullseye branch system use the following command:
git clone https://github.com/WiringPi/WiringPi
cd WiringPi
./build
gpio -v
# Run gpio -v and version 2.60 will appear. If it does not appear, it means that there is an installation error

This worked.
So I can now do some experiments. :-)
Thanks to all!

[S Jack]

On Tuesday, July 5, 2022 at 4:29:45 PM UTC-5, Zbig wrote:
> 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.

Haven't played with control keys of late but being hosted by linux on
chomebook I would expect to deal with both linux and hterm to get what
key codes forth will see.
Anyway for a quick test I defined arrowup as a forth word to dump
TIB (I accept whitespace.) The arrowup moves the cursor up
when I define the word and when I execute it. As seen, it arrives
just as the escape sequence for cursor up.

frogd
ELF32X86_64 Frog Version 1.0d
tib 2@ adump ;
cr cr :
ok
1B[A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ok
bye :)

[Anton Ertl]

Zbig <zbigni...@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.

[none albert]

In article <fe3ce592-f65b-4b9c...@googlegroups.com>,

I suspect that rlwrap is safer than lina, and that the crashes are
warranted.
lina is not a c-program, calling readline() is not straightforward.
Even if I implemented it, it means that I sell my soul to the c-people
and comply. All input/output , and the whole testing system has to be
rewritten.
Honestly, were I forced to do that, I would abandon ciforth for gforth
in eye blink.

[none albert]

In article <25533fa7-d592-42c5...@googlegroups.com>,

This is a simple solution.

I can't believe anybody commented on this, without mentionning
what the environment is, e.g. TERM=xterm-256color

Under these circumstances I can write a glorious editor with the
information provided with
infocmp -l -c

[none albert]

In article <2022Jul...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Zbig <zbigni...@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.

Bottom line, if you want to use special keys -- in case you want
to write you own editor -- , you have to disable these special
keys in the editor, no surprise there.
You're doubly special. You have to take into account the special
keys of your windows system, and special keys are probably
terminal dependant.
So if you gui intercepts shift-page-down, you can as well sit
on the roof (a Dutch expression).

>
>- anton

[none albert]

In article <3d1b59d5-8ed3-4c5b...@googlegroups.com>,

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 ?

[Zbig]

> I can't believe anybody commented on this, without mentionning
> what the environment is, e.g. TERM=xterm-256color

TERM="xterm"

OK, I'll examine it further.

[none albert]

In article <nnd$14ef56f1$51a862bc@47e2c85bbc07e978>,

none) (albert <albert@cherry.> wrote:
>In article <3d1b59d5-8ed3-4c5b...@googlegroups.com>,
>Christof Eberspaecher <chwe...@gmail.com> wrote:
>>none albert schrieb am Dienstag, 5. Juli 2022 um 20:55:45 UTC+2:
>>> In article <ca1bcf8a-624e-46e0...@googlegroups.com>,
>>> Christof Eberspaecher <chwe...@gmail.com> wrote:
>>> >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.
>>>
>>> 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

>>Thank you, Albert!
>>WANT seems to work after 1 LOAD, but says: ... not present but wanted.
>(Oh yes.)
>>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

I've analysed it. There was nothing wrong with the code per
se, but the conditional compilation system prevented it
from being loaded (defect in ?RP1).
You can download version 5.4.1 from lina.html on my site below.

I tested it with the control of an 2x16 display (1602)
on a raspberry pi 1. (32 bit arm7)

-------- 8< ---------------- 8< ----------
\ $Id: lcd1602.frt,v 1.2 2019/04/16 12:48:02 albert Exp albert $
\ Copyright (2012): Albert van der Horst {by GNU Public License}

\ HCC Forth gg: Egel project 12 for the Raspberry pi.
\ After the 8051 and MSP430 implementations of Willem Ouwerkerk.

\ This is a driver for the 1602A display : 16 by 2 char's.
\ The following is a direct connection to the raspberry pi 1 revision 1

\ descr color 1602 pi name gpio#
\ ground black 1 2
\ Vdd red 2 6
\ RS brown 4 3 SDA 0 (pi 1 rev. 1)
\ RW orange 5 5 SCL 1 (pi 1 rev. 1)
\ E grey 6 7 GPCLK0 4
\
\ DB4 yellow 11 15 GPIO 22
\ DB5 green 12 16 GPIO 23
\ DB6 blue 13 18 GPIO 24
\ DB7 purple 14 22 GPIO 25
\
\

WANT BOUNDS
WANT gpio-on set-function _on
DECIMAL
0 CONSTANT RS \ brown 4 3 SDA
1 CONSTANT RW \ orange 5 5 SCL
4 CONSTANT EN \ grey 6 7 GPCLK0

22 CONSTANT DB4 \ yellow 11 15
23 CONSTANT DB5 \ green 12 16
24 CONSTANT DB6 \ blue 13 18
25 CONSTANT DB7 \ purple 14 22

\ Display variables
16 CONSTANT c/l
VARIABLE cursor
HEX
0F DB4 LSHIFT CONSTANT DB4-7

\ Set all bit used to output. Tell
: init
_output RS set-function _output EN set-function
_output RW set-function
DB4 4 + DB4 DO _output I set-function LOOP
RW gpio-off \ Always write
;

: command-mode RS gpio-off ;
: char-mode RS gpio-on ;

: enable-pulse EN gpio-on 1 MS EN gpio-off 1 MS ;

\ Output nibble .
: nibble>lcd DB4 LSHIFT DUP _on P! INVERT DB4-7 AND _off P!
enable-pulse ;
\ Output nibble . Alternative implementation.
\ : nibble>lcd' DB4-7 _off BIS DB4 LSHIFT _on BIS
\ enable-pulse ;
\ Send byte to LCD
\ Depending on mode it is interpreted as a char or a command.
\ This assumes 4 bits mode!
: lcd-byte DUP 4 RSHIFT nibble>lcd nibble>lcd ;

\ Send instruction .
: lcd-instr command-mode lcd-byte ;

\ Make LCD clean and set cursor in upper left corner.
: lcd-page 1 lcd-instr 0 cursor ! 2 MS ;

\ After calling this it should be possible to send char's to the display
: lcd-setup
init \ Basic io interpretation
3 0 DO 03 lcd-instr 5 MS LOOP \ And set 8 bits interface mode
02 lcd-instr \ Finally set 4 bits interface mode.
28 lcd-instr \ 4 bit interf. 2 lines, 5*7 bits char.
08 lcd-instr lcd-page \ Display cursor, empty screen
06 lcd-instr \ Display direction from left to right
0C lcd-instr \ Display on & cursor on
;

\ Type sc to the display.
: lcd-type char-mode DUP cursor +!
BOUNDS ?DO I C@ lcd-byte LOOP ;

: lcd-emit ( char -- ) DSP@ 1 lcd-type DROP ;
: lcd-space ( -- ) BL lcd-emit ;
: lcd-spaces ( u -- ) 0 ?DO lcd-space LOOP ;

\ Like `CR but for lcd.
: lcd-cr
c/l cursor @ < IF \ Cursor at line 2 ?
80 lcd-instr 0 cursor ! \ Yes, to line 1
ELSE
C0 lcd-instr c/l cursor ! \ No, to line 2
THEN ;

: demo1 ( -- )
lcd-setup
" Hi Forth" lcd-type lcd-cr \ Test LCD
" users..." lcd-type ;

: demo2 ( -- )
lcd-setup
"arm ciforth lina" lcd-type lcd-cr \ Test LCD
"Egel A.D. MMXIX" lcd-type ;
DECIMAL
-------- 8< ---------------- 8< ----------

You are not obliged to use _on and _off that allows to
turn several io-bits on and off at the same time.

You can get by with
_output _input set-function gpio-on gpio-off
that can serve as a model that applies widely, I think.

You can use set-function to set a port to e.g. analogue
to digital conversion. That requires consulting the manual,
but it should be straightforward.

[Zbig]

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.

[none albert]

In article <f9aa24e0-6b0d-4ce0...@googlegroups.com>,

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.

[Zbig]

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

[Zbig]

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

[Zbig]

Reading the chapter "8.1 BLOCKS" I didn't find the explanation how
to create fresh blocks file for my own screens. Actually the chapter
doesn't contain any 1-2-3 explanation "in order to create..." etc. -- it's
just a (part of) glossary.
I can see, for example, that some kind of initialization is required ("8.1.8 BLOCK-INIT").
From what I see, BLOCK-INIT wants "n" on the stack. What is "n", actually? In the
spartan description that follows I read: "The handle ‘BLOCK-HANDLE’ can be used
to access it, with access code ‘n’ (2 for read and write)". So is it the same "n", as for
BLOCK-HANDLE -- or is it something different?
I didn't read the whole "Glossary" yet, but it seems there isn't any example for
any of the words listed.
Should I guess how BLOCK-INIT works? Or is it described in some another README,
not directly in manual?

OK, I typed "2 BLOCK-INIT" (having no better idea at the moment). But the attempt to
access any block is failed:
2 BLOCK-INIT
OK
1 LIST
SCR # 1 1 LIST ? ciforth ERROR # 8
OK
In the paragraph "8.1.5 BLOCK-EXIT" I read: "A block file must have been opened by BLOCK-INIT".
The problem is. that the paragraph "8.1.8 BLOCK-INIT" doesn't explain, how to do this. I mean
creating new, "empty" file in "local" sub-dir, not using system-wide "forth.lab, where I haven't (as
"user", not root) write access.

I believe for you -- the creator -- all these things are obvious, and my questions probably seem
stupid to you. Well you may want to try to recommend lina to another user -- quite new to it -- and
then to ask him/her to create fresh file for new screens. I wonder how much time it can take to
him/her to figure it out, when (for the reasons unknown to me) it's not that obvious like simple
"use blocks.fb" in Gforth, for example. Why it can't be that straightforward?

[none albert]

In article <nnd$367bbc52$41479f07@76caef605e674857>,

none) (albert <albert@cherry.> wrote:
>In article <f9aa24e0-6b0d-4ce0...@googlegroups.com>,
>Zbig <zbigni...@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 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,
>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.

It is far easier than you think.
After unpacking in the directory
./lina -e
System wide installation :
sudo ./lina -i /usr/bin/lina /usr/bin/forth.lab

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.)

[Zbig]

> 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.)

I feel a misunderstanding here; the above is not an answer to my question.

OK, never mind; probably I should pause further tries with lina until
its manual is complete.

[none albert]

In article <f19f8f7f-c370-41b7...@googlegroups.com>,

The documentation about options triggers a misunderstanding, I will have to
change it. You have read more of the documentation then most users,
I must say. Sorry, that I assumed that you have not read any doc's.

Now:
ciforth is a primitive system, and can interpret just one option on the
command line.
If the first argument is not starting with '-' ciforth ...

Must be:
ciforth is a primitive system, and can interpret just one option on the
command line. Moreover it can interpret options only if it is
properly installed in the first place.
If the first argument is not starting with '-' ciforth ...

Note:
Implementation note: -x triggers the code `` ^X LOAD '' loading screen 24.

[Zbig]

> By chance I now found, that you can still install wiringPi:

Also this may be interesting for you:
"EuroTcl 2017: Using GPIOs of Raspberry Pi in pure Tcl - my way (Uli Ender)"
https://www.youtube.com/watch?v=pLDXUtRARlA

[none albert]

In article <7c42c89d-fef6-474a...@googlegroups.com>,

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.

Furthermore the compiler factory is 6 years behind and I have
updated this weekend.
https://github.com/albertvanderhorst/ciforth/~

[Bernd Paysan]

Am Wed, 06 Jul 2022 17:35:35 GMT schrieb Anton Ertl:

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

If it's \e[5;2~ and \e[6;2~ as expected (adding the modifier with
';'<number+1>), Gforth will know.

In the Linux console, which doesn't support scrolling for some time now,
it doesn't encode the shift key, as well, so you get a normal PgUp or PgDn
instead.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o id: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
https://bernd-paysan.de/

[Zbig]

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

[none albert]

In article <ff8e35d6-9d35-45c0...@googlegroups.com>,

Sometimes you need a push.

You are a brave person. Using the compiler factory is intimidating.

Normally to get an idea of you like ciforth, one would download
one of the packages that are ready-made for a particular operating
system selecting 32/64 size.

See
https://github.com/albertvanderhorst/ciforth/releases/tag/CVS_REL-5-4-0

In those versions the aforementioned defect is fixed.

[Zbig]

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".

[none albert]

In article <447abdd8-624a-4a96...@googlegroups.com>,

It run splendidly on MSDOS 6.22.
The only conclusion is that FreeDOS did a bad job emulating MSDOS,
for what you tell me.

[Zbig]

> >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".
> It run splendidly on MSDOS 6.22.

Was it slower or faster machine? I did my tries on DX2/66.

[dxforth]

That looks like the Borland Pascal bug. It required a fast cpu (Pentium
or better) to manifest.

[Zbig]

> > 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”?

[Zbig]

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

It has indeed something to do with how the more modern (at the time mina
has been created) processors work.
When I ran mina within "debug", it reported that error 200, but I noticed it
managed to modify interrupt number to "INT 21h". Then next attempt (still
under debug) with "g 0100", and... it works.
So it looks like that interrupt has been requested even before the cell contents
has been modified?

[Zbig]

> So it looks like that interrupt has been requested even before the cell contents
> has been modified?

...or maybe rather it has been copied to CPU's "prefetch queue" before self-modification
has been done?

[none albert]

In article <4eebed60-e0ac-4271...@googlegroups.com>,

MSDOS runs on 8088 typically. If the processor has a so called
"real mode", such as 80386, MSDOS can run in this mode.

In an amd 64 ubuntu the following works:
[That is an emulator, no real mode on AMD 64 bits.]

wine mina -e

And then
REQUIRE SIEVE
10 SIEVE

...
or
REQUIRE EDITOR
219 EDIT

A screen editor that knows single key wordstar commands.
See documentation.

[none albert]

In article <a44a8393-58e4-4326...@googlegroups.com>,

Zbig <zbigni...@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.

>
>BTW there are sequences like:
>
>XCHG AX,SI
>XCHG AX,SI
>
>What's the purpose of that swapping ”back and forth”?

That is an artefact of the code generation from a generic source.
The same generic source generates AMD 64 code and more relevant
a 32 bit real mode mina32.
If it bothers you, you can remove the code and use nasm to
generate a new compiler. That is exactly the reason, why I
provide you with this source.

[dxforth]

On 18/07/2022 06:07, albert wrote:
> In article <a44a8393-58e4-4326...@googlegroups.com>,
> Zbig <zbigni...@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.

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.

[Zbig]

> > That conclusion is correct. The bug is not in mina, but in the msdos emulator
> > that not allows this modification.

FreeDOS ISN'T an emulator; FreeDOS is independently created DOS.

Besides: I made another attempt, and this time under emulator run under
Linux' control (DOSemu). And... the emulator ran mina with no problems!
And... that emulator uses as DOS "layer"... FreeDOS files!

> > 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.
> 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).

[Zbig]

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

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.

[Zbig]

See also: https://news.ycombinator.com/item?id=29564458

„Wasted many hours of my young life trying to figure out why my
self-modifying assembler program worked perfect in the debugger
but not without it.”

[dxforth]

But what is the official position? All I could find was:

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.)

[Zbig]

> >> >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.
> >
> > 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.
> But what is the official position? All I could find was:
>
> IA-32 Intel® Architecture Software Developer’s Manual Volume 3:

Not sure about „official position”; I've found statements of the programmers
who experienced that problem. They confirmed my initial suspicion.

It seems, that self-modifying code:
— can be considered safe on older processors (and I mean „quite old”)
— may work as intended, or may not — on newer processors
— always makes slower the procedure it's applied to

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>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.

Risky? You just follow the rules, and it works.

And that's already with the 8086 and 8088: They have an instruction
perfetch buffer of 6 and 4 bytes, respectively, so if you change an
instruction that has already been prefetched, you will not see the
effect of the change right away. I expect that the prefetch buffers
grew over the generations (e.g., the 486 would prefetch one cache line
(16 bytes) at a time). But the prefetching was straight ahead up to
and including the 486, and when a jump was taken, the prefetching
started from scratch. So they announced the rule that you had to take
a jump between the modification and the execution.

The Pentium added branch prediction and an instruction cache that is
separate from the data cache, both of which mean that the jump rule
would no longer work without extra hardware effort. Because backwards
compatibility is so important, they spent the extra hardware effort,
so the jump rule is still sufficient. I suspect that Pentium and
later CPUs are actually closer to the ideal of self-modifying code as
you would imagine it working from the specifications of the
instructions than the earlier CPUs, but I have not tested this.

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

- 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

[Zbig]

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

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.

[dxforth]

On 26/07/2022 20:56, Zbig wrote:
>> >> 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.
>
> 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.

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.

[Zbig]

> What steps did you take to rule out MINA as the cause of your error?

But I wrote everything in this thread already. What more can I say?

> Does it happen with DX-Forth? I used self-modifying code which you
> can test with:
>
> s" foobar$" drop 'DX ! 9 doscall

No, I hadn't such problem with DXForth. But — considering that Mina
example — can we be sure it won't happen in the future, and in case
of every possible x86 clone?

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

But is it really the situation that begs for self-modifying code?
— one doesn't usually use that many different DOS/BIOS software interrupts
— these interrupts usually require variable number of arguments anyway
— having quite nice interface to ML — like exactly in DXForth — allows to
do request for interrupt in elegant way without resorting to self-modifying code

[dxforth]

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'.

[dxforth]

On 18/07/2022 12:19, Zbig wrote:
> [...]

>> 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).

It appears INT 66 needs to be initialized first, hence the crash. I got the
same when I called it directly using $66 INTCALL.

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.

[Zbig]

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

I DIDN'T use the test you've posted. You asked a question, whether I had any such
problems with DXForth — so I responded I didn't have any so far.

[Zbig]

OK, so I made the test you've posted and yes, it works like this:
s" foobar$" drop 'DX ! 9 doscall foobar ok

[dxforth]

On 27/07/2022 00:42, Zbig wrote:
> OK, so I made the test you've posted and yes, it works like this:
> s" foobar$" drop 'DX ! 9 doscall foobar ok

So it successfully modified INT 00h to INT 21h and performed DOS Fn9 -
'Write String to STDout'.

Try this:

: 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?

[Zbig]

> : 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?

[dxforth]

Running FreeDOS under an emulator is introducing another variable -
not ruling out FreeDOS. If the claim is MINA's code is unreliable
then one has to prove it. Since only you can reproduce the fault
it's left to you to pin-point where the defect is.

I compared MINA BIOSO vs. DX-Forth INTCALL. Not a lot of difference
other than the latter's code is larger as it can use any 8086 register
as parameter.

There are 23 instructions in DX-Forth between modifying and executing
INT 00, vs. 8 instructions for MINA. Neither uses a JMP between modify
and execute as suggested by Intel for later generation cpu's.

DX-Forth has extra code to handle a MS-DOS 2 bug:

mov cs:fssav,sp
intc1: int 0 ; NOTE: self-modifying code
cli
mov ss,cs:cseg1 ; restore SS:SP
mov sp,cs:fssav ; for DOS 2.x
sti

I don't understand the purpose of the XCHG instr's in MINA:

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

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

[dxforth]

Well, it appears Intel did. From the 486DX2 manual:

3. The prefetch queue has been increased from 16
bytes to 32 bytes. A jump always needs to exe cute
after modifying code to guarantee correct execution
of the new instruction.

http://www.s100computers.com/My%20System%20Pages/80486%20Board/Intel486_DX2_Microprocessor_Data_Book_Jul92.pdf

[dxforth]

On 27/07/2022 13:56, dxforth wrote:
>
> 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.

[Zbig]

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

[dxforth]

On 27/07/2022 23:28, Zbig wrote:
>> 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.

Googling I got the impression a JMP to the next instruction should have worked.
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 :)

[Zbig]

> > 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.
> Googling I got the impression a JMP to the next instruction should have worked.
> 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 believe that of course it can be handled, since I fixed it primitive way by adding NOPs —
still there remains an apprehension of kind: „...until next time” (in different conditions).

[dxforth]

On 28/07/2022 05:24, Zbig wrote:
>> > 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.
>> Googling I got the impression a JMP to the next instruction should have worked.
>> 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.

This should do it.

RQBIOS: INT(0) ; Request number to be overwritten.

...
JMP NEXT
;
RQBIOSN: INT(0) ; Request number to be overwritten.
...
JMP NEXT

; *************
; * BIOSO *
; *************
;
N_BIOSO:
DW 5
DB "BIOSO"
BIOSO:
...

MOV BYTE [RQBIOS+1],AL ; Patch the code.

...
XCHG SI,AX
JMP RQBIOS

; *************
; * BIOSN *
; *************
;
N_BIOSN:
DW 5
DB "BIOSN"
BIOSN:
...
MOV BYTE [RQBIOSN+1],AL ; Patch the code.
...
XCHG SI,AX
JMP RQBIOSN

>> > 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”.

Nice try. I'd try a backwards JMP. If beaten, I'd go for 32-byte separation
and a JMP (see above). 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.

[dxforth]

On 27/07/2022 23:28, Zbig wrote:
>

> I'll simply replace that SMC with „ordinary” code.

It's possible to simulate an INT n instruction. How foolproof it is, I don't know.

pop bx ; INT#
sub ax,ax ; get vector
mov es,ax
shl bx,1
shl bx,1
mov ax,es:[bx]
mov ivec,ax
mov ax,es:[bx+2]
mov ivec+2,ax
...
pushf ; execute it
cli
call dword ptr [ivec]
...


ivec dw 0,0

[Zbig]

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

I tried Mina on AthlonXP — and yes, it works (I mean unmodified, original binary).
The CPU I tried it with:

processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(TM) XP 3000+
stepping : 0
cpu MHz : 2100.201
cache size : 512 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall
bugs : fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass
bogomips : 4202.41
clflush size : 32
cache_alignment : 32
address sizes : 34 bits physical, 32 bits virtual
power management: ts

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.

[dxforth]

On 29/07/2022 05:06, Zbig wrote:
>
> 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.

It may be worth chasing down an AMD 486 manual. From an earlier i486 manual
(not DX2) it explains:

"The prefetch unit is flushed whenever the next instruction needed is not
in numerical sequence with the previous instruction - for example, during
jumps, task switches, exceptions, and interrupts."

So the JMP can be to anywhere *but* the next sequential instruction? That
may explain why:

> MOV BYTE [RQBIOS+1],AL ; Patch the code.

> JMP XXX
> XXX: POP DX

didn't work. You may like to try:

JMP XXX
NOP
XXX:

to see whether it flushes the prefetch queue. Otherwise any backwards JMP
should do it.

[Zbig]

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

[Zbig]

Oh, I forgot — that was „the first version”. I changed then the lines:

> JMP XXX1 ; senseless jump to make self-modifying code work on 486

> [..]

> XXX1: JMP YYY1 ; senseless return

...to both contain JMP LONG. No effect.

[dxforth]

I wouldn't expect the above to work as there's no JMP between modification
and execution.

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

[Zbig]

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

[dxforth]

Great! Can you confirm:

1) Changing JMP XXX to JMP SHORT XXX it still works
2) Deleting the NOP causes it to fail

[Zbig]

> Great! Can you confirm:
>
> 1) Changing JMP XXX to JMP SHORT XXX it still works

NASM earlier already optimized these JMPs to be „short”,
so this made no difference (same opcode, I made sure).

> 2) Deleting the NOP causes it to fail

When I commented-out the NOPs, it... still works.

[dxforth]

On 30/07/2022 22:18, Zbig wrote:
>> Great! Can you confirm:
>>
>> [...]

>
>> 2) Deleting the NOP causes it to fail
>
> When I commented-out the NOPs, it... still works.

Ok - so the NOP is superfluous and a JMP to the next sequential instruction
works i.e. is sufficient to flush the CPU prefetch. Solved!

[Stephen Pelc]

On 5 Jul 2022 at 15:51:22 CEST, "Christof Eberspaecher" <chwe...@gmail.com>
wrote:

> 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

VFX Forth for ARM Linux includes port access code for Raspberry PI. See
Examples/Lin32/rpi-gpio.fth

Stephen
--
Stephen Pelc, ste...@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612,
+34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads