GPIO access with GForth on Raspberry Pi

443 views
Skip to first unread message

Christof Eberspaecher

unread,
Jul 5, 2022, 9:51:24 AMJul 5
to
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

unread,
Jul 5, 2022, 12:26:01 PMJul 5
to
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

unread,
Jul 5, 2022, 2:55:45 PMJul 5
to
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

unread,
Jul 5, 2022, 5:29:45 PMJul 5
to
> 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

unread,
Jul 6, 2022, 2:01:48 AMJul 6
to
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

unread,
Jul 6, 2022, 2:43:01 AMJul 6
to
Mind that a Pi4 is a power hog eating in the range of 2 amps(!) at 5 V.

Anton Ertl

unread,
Jul 6, 2022, 3:55:50 AMJul 6
to
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

unread,
Jul 6, 2022, 4:16:01 AMJul 6
to
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

unread,
Jul 6, 2022, 4:19:09 AMJul 6
to
The official powerpack looks absurdly small for 3A. Wouldn't want that blowing up
and taking out everything connected (user included).

Christof Eberspaecher

unread,
Jul 6, 2022, 4:20:50 AMJul 6
to
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

unread,
Jul 6, 2022, 4:39:26 AMJul 6
to
> 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

unread,
Jul 6, 2022, 5:53:08 AMJul 6
to
> 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

unread,
Jul 6, 2022, 8:51:55 AMJul 6
to
FORTH> ekey h. $00012200 ok ( keypad )
FORTH> ekey h. $00002200 ok ( just PgDn )
FORTH> ekey h. $00012200 ok ( cursorblock )

-marcel

Zbig

unread,
Jul 6, 2022, 9:31:49 AMJul 6
to
> > > : 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

unread,
Jul 6, 2022, 11:21:46 AMJul 6
to
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

unread,
Jul 6, 2022, 12:30:40 PMJul 6
to
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

unread,
Jul 6, 2022, 1:49:56 PMJul 6
to
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

unread,
Jul 7, 2022, 8:01:42 AMJul 7
to
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

unread,
Jul 7, 2022, 8:12:00 AMJul 7
to
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

unread,
Jul 7, 2022, 8:16:55 AMJul 7
to
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

unread,
Jul 7, 2022, 8:28:01 AMJul 7
to
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

unread,
Jul 7, 2022, 3:42:21 PMJul 7
to
> 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

unread,
Jul 8, 2022, 5:59:33 AMJul 8
to
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

unread,
Jul 8, 2022, 10:12:17 AMJul 8
to
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

unread,
Jul 8, 2022, 3:30:43 PMJul 8
to
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

unread,
Jul 8, 2022, 3:56:08 PMJul 8
to
> 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

unread,
Jul 8, 2022, 5:17:56 PMJul 8
to
> 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

unread,
Jul 8, 2022, 7:39:44 PMJul 8
to
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

unread,
Jul 9, 2022, 10:19:36 AMJul 9
to
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

unread,
Jul 9, 2022, 10:47:37 AMJul 9
to
> 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

unread,
Jul 9, 2022, 11:40:50 AMJul 9
to
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

unread,
Jul 10, 2022, 4:39:25 AMJul 10
to
> 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

unread,
Jul 10, 2022, 7:44:12 AMJul 10
to
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

unread,
Jul 10, 2022, 7:03:18 PMJul 10
to
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

unread,
Jul 11, 2022, 7:31:09 AMJul 11
to
> 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

unread,
Jul 11, 2022, 7:58:18 AMJul 11
to
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

unread,
Jul 16, 2022, 6:01:40 PMJul 16
to
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

unread,
Jul 17, 2022, 6:53:54 AMJul 17
to
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

unread,
Jul 17, 2022, 9:32:42 AMJul 17
to
> >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

unread,
Jul 17, 2022, 12:15:50 PMJul 17
to
That looks like the Borland Pascal bug. It required a fast cpu (Pentium
or better) to manifest.

Zbig

unread,
Jul 17, 2022, 1:57:02 PMJul 17
to
> > 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

unread,
Jul 17, 2022, 2:09:14 PMJul 17
to
> > 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

unread,
Jul 17, 2022, 2:19:02 PMJul 17
to
> 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

unread,
Jul 17, 2022, 3:46:11 PMJul 17
to
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

unread,
Jul 17, 2022, 4:07:11 PMJul 17
to
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

unread,
Jul 17, 2022, 10:01:26 PMJul 17
to
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

unread,
Jul 17, 2022, 10:19:54 PMJul 17
to
> > 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

unread,
Jul 24, 2022, 5:07:27 PMJul 24
to
> >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

unread,
Jul 24, 2022, 5:10:33 PMJul 24
to
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

unread,
Jul 25, 2022, 2:42:47 AMJul 25
to
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

unread,
Jul 25, 2022, 4:50:06 AMJul 25
to
> >> >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

unread,
Jul 26, 2022, 5:48:52 AMJul 26
to
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

unread,
Jul 26, 2022, 6:56:25 AMJul 26
to
> >> 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

unread,
Jul 26, 2022, 8:06:04 AMJul 26
to
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

unread,
Jul 26, 2022, 8:24:23 AMJul 26
to
> 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

unread,
Jul 26, 2022, 8:37:53 AMJul 26
to
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

unread,
Jul 26, 2022, 10:10:53 AMJul 26
to
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

unread,
Jul 26, 2022, 10:38:50 AMJul 26
to
> 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

unread,
Jul 26, 2022, 10:42:17 AMJul 26
to
OK, so I made the test you've posted and yes, it works like this:
s" foobar$" drop 'DX ! 9 doscall foobar ok

dxforth

unread,
Jul 26, 2022, 11:49:07 AMJul 26
to
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

unread,
Jul 26, 2022, 12:03:24 PMJul 26
to
> : 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

unread,
Jul 26, 2022, 11:56:26 PMJul 26
to
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