From Newsgroup: comp.lang.forth

https://www.hackster.io/news/olimex-s-one-euro-rvpc-single-board-computer-goes-up-for-sale-next-week-1cfe4fe2c985

- CH32V003 MCU, 24 MHz, 16KB flash, 2KB ram, and 128B NVRAM
- Uses EC subset of RV32 architecture, so only 16 registers instead
of 32, but this is fine for Forth
- PS/2 keyboard connector
- VGA video connector
- Can apparenty supposedly 800x600 pixels on VGA, not sure how that is
possible with just 2K of ram
- Supposedly available starting next week on olimex.com.

The CH32V003 is or was famous for being the cheapest flash-programmable
MCU at 0.10 USD per part. There are cheaper MCU's like the 3 cent
Padauk which is an 8 bitter, but they are one-time programmable.

Either way, there might not be enough flash and ram to host recent
versions of Mecrisp.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 25/09/2024 4:22 am, Paul Rubin wrote:

https://www.hackster.io/news/olimex-s-one-euro-rvpc-single-board-computer-goes-up-for-sale-next-week-1cfe4fe2c985

- PS/2 keyboard connector

Where can you buy a PS/2 keyboard that's not a piece of junk fit for the bin?

It's a rare USB keyboard today that supports both protocols since PS/2 is rarely
needed and requires legit manufacturers pay a license fee.

I went through this while considering whether to buy the Olimex Agon Lite.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

dxf <dxforth@gmail.com> writes:

Where can you buy a PS/2 keyboard that's not a piece of junk fit for
the bin? It's a rare USB keyboard today that supports both protocols
since PS/2 is rarely needed and requires legit manufacturers pay a
license fee.

I didn't know about this. Are there adapters? And, I'm sure I've got
some PS/2 keyboards kicking around. But I wonder why they chose PS/2 if
there was an issue like this.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 25/09/2024 1:37 pm, Paul Rubin wrote:

dxf <dxforth@gmail.com> writes:

Where can you buy a PS/2 keyboard that's not a piece of junk fit for
the bin? It's a rare USB keyboard today that supports both protocols
since PS/2 is rarely needed and requires legit manufacturers pay a
license fee.

I didn't know about this. Are there adapters?

Physical ones but not ones that convert a USB-only keyboard to PS/2
(not cheaply anyway).

And, I'm sure I've got
some PS/2 keyboards kicking around. But I wonder why they chose PS/2 if there was an issue like this.

Easiest to interface.

There's also an issue with VGA as modern monitors only have HDMI.
VGA to HMDI adapters exist however user reviews suggest they don't
support low resolutions...

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

dxf <dxforth@gmail.com> writes:

There's also an issue with VGA as modern monitors only have HDMI.
VGA to HMDI adapters exist however user reviews suggest they don't
support low resolutions...

Tbh I don't know why they went for the approach of trying to support a
keyboard and screen from that board. It's like they're trying to
replace a VIC-20 or something like that. A serial port (not sure if the
chip has a uart, but they could bit bang it) or USB (same thing) would
be just as good.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 24/09/2024 19:22, Paul Rubin wrote:

https://www.hackster.io/news/olimex-s-one-euro-rvpc-single-board-computer-goes-up-for-sale-next-week-1cfe4fe2c985

Found some code on github following the name in the article:

https://github.com/TurboVega/RVPC/blob/towers-of-hanoi-1/SOFTWARE/Demo-VGA/src/main.c#L288

(forked from Olimex's initial sample repo https://github.com/OLIMEX/RVPC/tree/main/SOFTWARE/Demo-VGA )

Haven't found an 800x600 pixel res variant (though they may be more
talkingh about overall display sync/timings but with wide pixels).

However, can see their general approach - appears to be bit-banging out gpio->vga individual scanlines of a tilemap/charmap display. So vaguely similar to a lot of 8-bit tilemap/charmap display hardware, implemented
in software, on the apparently-fast-enough-to-do-that tiny cpu.

Wwe're not talking a large linear bitmapped framebuffer in the small ram
area, just a smaller tile/char screen area and the current-scanline
buffer in the ram area. The 1-bit bitmap glyph image data itself can
then come from the flash area, much like the "character rom" of an 8-bit.

https://github.com/TurboVega/RVPC/blob/towers-of-hanoi-1/SOFTWARE/Demo-VGA/src/chardefs.h#L2663

That towers of hanoi sample code linked appears to be doing 21x18 8x8
pixel chars display, so in pixel terms that's 168x144, and the byte-per-tile/char display ram area is only 378 bytes.

I suppose adding some control bytes allowing selecting different
tilesets during the display could also give a bit more versatility with
not too much more overhead, as the device has 16384 bytes flash and thus
can hold at least a few different tilesets while still having room for
program code. a 256-character 8x8 1-bit bitmap charset/tileset is 2048
bytes obviously, just like a C64 etc.

Unclear to me ( / far too lazy to work it out) if it's actually fast
enough that it could actually e.g. be pushed all the way to, say 50x38 x
16x16 tiles, but that would then cover a 800x600 pixel res (just over as obviously 600/16=37.5) and still be 1900 bytes for byte-per-tile ram
area (and we need the scanline buffer, another 50 bytes), technically
fitting into the 2048 bytes ram ... though really not leaving room for a
whole lot else at all.

A 256 tile 16x16 1-bit bitmap tileset is 8192 bytes, half the flash.

Perhaps 40x30 16x16 -> 640x480 -> "only" 1200 bytes screen ram could be
made work.

40x30 8x8 -> 320x240, perhaps doubled on output to 640x480
sync/timing-wise for better compat with vga->digital adaptors, might be
a sweeter spot ....if that can be made work.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

I went through this while considering whether to buy the Olimex Agon
Lite.

Indeed Agon requires that. But there is a list
of verified keyboards available: https://docs.google.com/spreadsheets/d/1-6_sz6l-vJW5rFg3M0Y6bwC0hmFS7U6PPNjIZ9plrM8/edit?gid=0#gid=0
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

Paul Rubin <no.email@nospam.invalid> wrote:

https://www.hackster.io/news/olimex-s-one-euro-rvpc-single-board-computer-goes-up-for-sale-next-week-1cfe4fe2c985

- CH32V003 MCU, 24 MHz, 16KB flash, 2KB ram, and 128B NVRAM

^^^^^^
My datasheet for CH32V003 says 48MHz.

- Uses EC subset of RV32 architecture, so only 16 registers instead
of 32, but this is fine for Forth
- PS/2 keyboard connector
- VGA video connector
- Can apparenty supposedly 800x600 pixels on VGA, not sure how that is
possible with just 2K of ram

As noticed it is enough to use buffer for a single scanline. IIUC
DMA channel + SPI peripherial allow sending pixels at half CPU
clock in parallel with normal CPU work (there will be some slowdown
due to bus cycles "stolen" by DMA). With 24MHz CPU clock one would
get 12MHz pixel clock which is IMO too slow for 800x600 resolution.
But with 48MHz CPU clock one gets 24MHz pixel clock which is
bordeline of usable. Of course, with single scanline the scanline
must be filled during horizontal retrace, which may be challenging.
AFAICS this would give about 300-400 clocks which is tight. Using
two scanlines, one which is displayed and second one filled by CPU,
it is possible to do some graphics like sprites.
--
Waldek Hebisch
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

Paul Rubin <no.email@nospam.invalid> wrote:

dxf <dxforth@gmail.com> writes:

There's also an issue with VGA as modern monitors only have HDMI.
VGA to HMDI adapters exist however user reviews suggest they don't
support low resolutions...

Tbh I don't know why they went for the approach of trying to support a keyboard and screen from that board. It's like they're trying to
replace a VIC-20 or something like that. A serial port (not sure if the
chip has a uart, but they could bit bang it) or USB (same thing) would
be just as good.

I think this is mostly publicity stint and a challenge. I do not
know how much they pay for VGA connector, but this may be the most
expensive part in their kit. And PS/2 connector the second most
expensive. Given cost of connectors it would make sense to put
more powerful (and a bit more expensive) processor on the board
(which would no longer be 1 euro board). But with more powerful
processor it would be easier to do something useful, so it would
be less chalenging. Official explanation is that they want to
run video games for kids on it, which explain video part. And
once there is video it is natural to request a keyboard so that
the device is directly programmable. But clearly, at different
level real game is to program this device without using external
"helpers" (like a connected PC).
--
Waldek Hebisch
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

There's also an issue with VGA as modern monitors only have HDMI.
VGA to HMDI adapters exist however user reviews suggest they don't
support low resolutions...

This is just a matter of selecting the proper monitor
for your needs; that's why I use LG featuring three inputs:
DisplayPort / DVI / VGA.

Tbh I don't know why they went for the approach of trying to support a keyboard and screen from that board.

..because without this it wouldn't be any different
to Arduino (or STM32 "pill", or ESP 8266 / 32 etc.). What
would be the sense? Still not enough various "Arduinos"
on the market? We need another, 1001st one?

The aim was to create dirt cheap little computer that
can be used "standalone". VGA output can be done (using
enough computing power) on resistor ladder. HDMI requires
specialized kind of controller (and they require licence
fees, if I'm correct, that's why DisplayPort has been born).
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 29/09/2024 11:30 pm, LIT wrote:

There's also an issue with VGA as modern monitors only have HDMI.
VGA to HMDI adapters exist however user reviews suggest they don't
support low resolutions...

This is just a matter of selecting the proper monitor
for your needs; that's why I use LG featuring three inputs:
DisplayPort / DVI / VGA.

That's also getting harder. Current model LG 22MR410-B has a VGA port
but according to the spec the lowest res is 1024 x 768. The spec for
my 6yr LG says 640 x 480.

It's like the Yamaha "stereo" amp I bought not long ago. No phono input.
To make matters worse the "CD" input was spec'd for 0.5v input. I had to
rig a 6dB pad so the CD volume matched the tuner. Engineers - what engineers?

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

There's also an issue with VGA as modern monitors only have HDMI.
VGA to HMDI adapters exist however user reviews suggest they don't
support low resolutions...

This is just a matter of selecting the proper monitor
for your needs; that's why I use LG featuring three inputs:
DisplayPort / DVI / VGA.

That's also getting harder. Current model LG 22MR410-B has a VGA port
but according to the spec the lowest res is 1024 x 768. The spec for
my 6yr LG says 640 x 480.

I admit for various kind of "retro stuff" I especially
bought older Fujitsu with 4:3 screen and DVI/VGA inputs.

It's like the Yamaha "stereo" amp I bought not long ago. No phono
input.
To make matters worse the "CD" input was spec'd for 0.5v input. I had
to
rig a 6dB pad so the CD volume matched the tuner. Engineers - what engineers?

That's why I prefer "vintage" Akai amp over modern gear. :)
Works like a charm, gives perfect sound — why would I need
anything newer.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

Either way, there might not be enough flash and ram to host recent
versions of Mecrisp.

For just $5 you can get something that'll take it:
https://milkv.io/duo
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

zbigniew2011@gmail.com (LIT) writes:

Either way, there might not be enough flash and ram to host recent
versions of Mecrisp.

For just $5 you can get something that'll take it:
https://milkv.io/duo

That's kind of interesting. Arm and riscv on the same die, like the new
RPi chip? You can also get an RPi Pico 2 for $5 if that helps. I don't
know if Mecrisp has been ported to it, but there is plenty of capacity
(520KB of ram and 4MB of flash).

The Milkv appears to have 64 bit riscv and it runs Linux, wow! I don't
know if Mecrisp can run on that. The Pico 2 is dual core Riscv-32, plus
ARM. I don't remember what risc-v cpu extensions it has.

The RPI Zero series are available now (not in short supply) but
expensive by comparison, $10 to $18 depending.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

https://milkv.io/duo

That's kind of interesting. Arm and riscv on the same die, like the new
RPi chip?

There are numerous videos about it on YT, from
what I see — just search for 'MILKV'.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

zbigniew2011@gmail.com (LIT) writes:

There are numerous videos about it on YT, from what I see — just
search for 'MILKV'.

I looked at the milkv web site a bit more, and it looks nice. I see the
256MB version in the $15 range on aliexpress. The 64MB version is
harder to buy in the US. And, I have no idea how well the software
works on either version.

Also of possible interest:
https://www.aliexpress.us/item/3256807414785972.html

I think I will stick with RPi stuff for now though.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 30/09/2024 12:51 am, LIT wrote:

...
That's why I prefer "vintage" Akai amp over modern gear. :)
Works like a charm, gives perfect sound — why would I need
anything newer.

When it dies for the umpteenth time and better to let it RIP.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

That's why I prefer "vintage" Akai amp over modern gear. :)
Works like a charm, gives perfect sound — why would I need
anything newer.

When it dies for the umpteenth time and better to let it RIP.

But this is an opportunity to do full "restoration": https://www.youtube.com/watch?v=nCkbSklKsuw
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

On 30/09/2024 5:54 pm, LIT wrote:

That's why I prefer "vintage" Akai amp over modern gear. :)
Works like a charm, gives perfect sound — why would I need
anything newer.

When it dies for the umpteenth time and better to let it RIP.

But this is an opportunity to do full "restoration": https://www.youtube.com/watch?v=nCkbSklKsuw

Guess why I took up computing as a hobby.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

Paul Rubin <no.email@nospam.invalid> wrote:

zbigniew2011@gmail.com (LIT) writes:

There are numerous videos about it on YT, from what I see — just
search for 'MILKV'.

I looked at the milkv web site a bit more, and it looks nice. I see the 256MB version in the $15 range on aliexpress. The 64MB version is
harder to buy in the US. And, I have no idea how well the software
works on either version.

I ordered 3 kinds: 64Mb, 256Mb and Milkv-Duo-S (this has 512 Mb).
Linux images fetched from Github boot fine and simple things
work. This is very minimal Linux, on 64Mb board I get:

[root@milkv-duo]~# cat /proc/cpuinfo
processor : 0
hart : 0
isa : rv64imafdvcsu
mmu : sv39

[root@milkv-duo]~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 770048 177105 549526 25% /
devtmpfs 14408 0 14408 0% /dev
tmpfs 14484 0 14484 0% /dev/shm
tmpfs 14484 48 14436 1% /tmp
tmpfs 14484 28 14456 1% /run
/dev/mmcblk0p1 130798 3226 127572 3% /boot
[root@milkv-duo]~# free
total used free shared buff/cache available Mem: 28972 14496 4148 76 10328 11720 Swap: 0 0 0

As you can see Linux take 177Mb of disc space. There is no compiler
(and even no assembler) and available utilities are quite limited. This
is probably intended to be a Python board, Python takes about 75 Mb of
disc space. But 64Mb version may be short on memory for Python. For
example

[root@milkv-duo]~# pip3 list
Killed

Apparently this tried to use 13Mb and triggered oom-kill.
On 64Mb board memory available to Linux is limited as 29Mb
is reserved mainly for media purposes (apparently one needs
to rebuild disc image to change memory allocation).

I my short trial I met two glitches. On Milkv-Duo-S 'poweroff'
instead of turning off the board causes reboot (on 64Mb board
'poweroff' works fine). This is known problem at least for few
months. The second trouble is that they propose to use USB
networking (CDC-NCM). This works fine with one of my desktop
machines, but fails with other. Since in both cases I use the
same Milkv board the trouble seem to be on Linux side (possibly
a security limitation). But they write "it just works". On
Milkv-Duo-S is also tried to connect Ethernet, it worked fine.

It seems that developement for those board is supposed to be done
by cross compilation. There seem to be considerable fragmentation
of Risc-V ecosystem. First, there are many possible subsets. IIUC
'rv64imafd' is supposed to be reasonably sane base and the board
support more: 'rv64imafdvcsu' which IIUC adds compressed instructions,
vestor extention and some systmem (priviledged extention). Provided
Linux uses 'musl'. On desktop machine I fetched Debian cross compiler
for Risc-V, it is based on 'glibc'. ATM I managed to cross-compile
statically linked hello world, after copying to the board it worked
fine (but executable is 491kb). I also cross-assembled assembly
version, this one is 1480b. So, cross-assembling or cross compiling
some Forth should not be very hard.

ATM I am thinking about good use case for 64Mb board. Nice thing
is low power use. When board is "doing nothing" (more precisly
board is blinking the blue LED and I am logged in via USB network)
my USB power meter shows 0 (it is certainly not 0 but almost
surely less than 50mA), with CPU-intensive job on Linux core I see
70mA power draw. So powerwise it is probably competitive with
Cortex-M processors. OTOH main justification for Linux boards
is networking and having real web server. But the 64-Mb board
(and 256-Mb board) needs external Ethernet transformer and
connector, in principle nothing hard, but practically it will
add cost and make it less convenient. I must admit that
Duo-S which has Ethernet connector looks more attractive to
me, despite costing twice as much as 64Mb board.

AFAICS the Risc-V developement tools are extremally bloated.
Source for the Linux image is about 4.5Gb, toolchain sources
about 6.8Gb.
--
Waldek Hebisch
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

I ordered 3 kinds: 64Mb, 256Mb and Milkv-Duo-S (this has 512 Mb).
Linux images fetched from Github boot fine and simple things
work. This is very minimal Linux, on 64Mb board I get:

[root@milkv-duo]~# cat /proc/cpuinfo
processor : 0
hart : 0
isa : rv64imafdvcsu
mmu : sv39

[root@milkv-duo]~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 770048 177105 549526 25% /

This must be the "largest" one, not that 64 MB,
from what I see ("Available 549526" and its
prompt "root@milkv-duo")? Correct?

--
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl wrote:

In article <vesgmb$1i2rq$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

LIT <zbigniew2011@gmail.com> wrote:

I ordered 3 kinds: 64Mb, 256Mb and Milkv-Duo-S (this has 512 Mb).
Linux images fetched from Github boot fine and simple things
work. This is very minimal Linux, on 64Mb board I get:

[root@milkv-duo]~# cat /proc/cpuinfo
processor : 0
hart : 0
isa : rv64imafdvcsu
mmu : sv39

[root@milkv-duo]~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 770048 177105 549526 25% /

This must be the "largest" one, not that 64 MB,
from what I see ("Available 549526" and its
prompt "root@milkv-duo")? Correct?

No. 'df' report "disc" (actually SD-card) space. 'free' reports
RAM:

[root@milkv-duo]~# free
total used free shared buff/cache available
Mem: 28972 14496 4148 76 10328 11720
Swap: 0 0 0

As you can see "total" is about 29Mb with 4Mb free. I put total in
quotes because part of RAM is reserved and in default configuration
there is large hunk reserved for media (camera, TPU, etc).

Concerning prompt, the 64Mb boards runs Linux and by default offers
root login.

--
Waldek Hebisch

For what it is worth.
I have ported the ciforth model (only 64 bits,the 5.4.0 level) onto
linux running on a riscv, taking advantage from earlier Dutch
implementation of noforth for triecky code words (UMD/MOD). http://home.hccnet.nl/a.w.m.van.der.horst/lina.html
As usual, all words are extensively tested, all words are documented.

Thanks, works on Milkv.

Once you have mapped the io space in virtual space and access it
via VMA-IO, you can apply all knowledge gained from the documentation
of the underlying System On a Chip.
For this particular board the printed circuit layout, the schematics
(9 pages) and a full 1000+ page documentation of the SoC (Allwinner
D1) is available. That is why I bought it.

For Milkv there are schematics and chipset documentation (I did not
check how complete it is).
--
Waldek Hebisch
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <vetqgo$1k6sl$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

albert@spenarnc.xs4all.nl wrote:

In article <vesgmb$1i2rq$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

LIT <zbigniew2011@gmail.com> wrote:

I ordered 3 kinds: 64Mb, 256Mb and Milkv-Duo-S (this has 512 Mb).
Linux images fetched from Github boot fine and simple things
work. This is very minimal Linux, on 64Mb board I get:

[root@milkv-duo]~# cat /proc/cpuinfo
processor : 0
hart : 0
isa : rv64imafdvcsu
mmu : sv39

[root@milkv-duo]~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 770048 177105 549526 25% /

This must be the "largest" one, not that 64 MB,
from what I see ("Available 549526" and its
prompt "root@milkv-duo")? Correct?

No. 'df' report "disc" (actually SD-card) space. 'free' reports
RAM:

[root@milkv-duo]~# free
total used free shared

buff/cache available

Mem: 28972 14496 4148 76

10328 11720

Swap: 0 0 0

As you can see "total" is about 29Mb with 4Mb free. I put total in >>>quotes because part of RAM is reserved and in default configuration
there is large hunk reserved for media (camera, TPU, etc).

Concerning prompt, the 64Mb boards runs Linux and by default offers
root login.

--
Waldek Hebisch

For what it is worth.
I have ported the ciforth model (only 64 bits,the 5.4.0 level) onto
linux running on a riscv, taking advantage from earlier Dutch
implementation of noforth for triecky code words (UMD/MOD).
http://home.hccnet.nl/a.w.m.van.der.horst/lina.html
As usual, all words are extensively tested, all words are documented.

Thanks, works on Milkv.

Once you have mapped the io space in virtual space and access it
via VMA-IO, you can apply all knowledge gained from the documentation
of the underlying System On a Chip.
For this particular board the printed circuit layout, the schematics
(9 pages) and a full 1000+ page documentation of the SoC (Allwinner
D1) is available. That is why I bought it.

For Milkv there are schematics and chipset documentation (I did not
check how complete it is).

Could you try if the mapping succeeds?
Start up as root.
Now do
MMAP-IO
and check VMA-IO
It contains the virtual memory address, or possible an error code
-13. The SoC descriptions maps from VMA-IO.
You can also check DEV-MEM that should be 4, normally.
In forth.lab you can see the use of MMAP-IO in relation to
a number of SoC's.
I strive to have working: set-function gpio-on gpio-off gpio-on.
The io-nummers are system dependant.

--
Waldek Hebisch

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl wrote:

In article <vetqgo$1k6sl$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

albert@spenarnc.xs4all.nl wrote:

In article <vesgmb$1i2rq$1@paganini.bofh.team>,

For what it is worth.
I have ported the ciforth model (only 64 bits,the 5.4.0 level) onto
linux running on a riscv, taking advantage from earlier Dutch
implementation of noforth for triecky code words (UMD/MOD).
http://home.hccnet.nl/a.w.m.van.der.horst/lina.html
As usual, all words are extensively tested, all words are documented.

Thanks, works on Milkv.

Once you have mapped the io space in virtual space and access it
via VMA-IO, you can apply all knowledge gained from the documentation
of the underlying System On a Chip.
For this particular board the printed circuit layout, the schematics
(9 pages) and a full 1000+ page documentation of the SoC (Allwinner
D1) is available. That is why I bought it.

For Milkv there are schematics and chipset documentation (I did not
check how complete it is).

Could you try if the mapping succeeds?
Start up as root.
Now do
MMAP-IO
and check VMA-IO
It contains the virtual memory address, or possible an error code
-13. The SoC descriptions maps from VMA-IO.
You can also check DEV-MEM that should be 4, normally.
In forth.lab you can see the use of MMAP-IO in relation to
a number of SoC's.
I strive to have working: set-function gpio-on gpio-off gpio-on.
The io-nummers are system dependant.

I get:

RISCV ciforth beta 2023Mar30
MMAP-IO
OK
HEX
OK
VMA-IO @ .
B2000000 OK
DEV-MEM @ .
3 OK

Datasheet says that device address space starts at 0x01000000
and ends at 0x7FFFFFFF (above is DRAM). There is a command
line utility to do I/O. Sending 0x01000000 to 0x03022000 turns on
blue LED, sending 0x0 truns it off. AFAICS in lina corresponding
address is B2022000. More generally, there are four GPIO devices
(ports). Port 0 is at 0x03020000, port 1 at 0x03021000, port 2 at
0x03022000, port 3 at 0x03023000. Device access should be done in
32-bit units.
--
Waldek Hebisch
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <vf5a40$2fkdi$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
<SNIP>

RISCV ciforth beta 2023Mar30
MMAP-IO
OK
HEX
OK
VMA-IO @ .
B2000000 OK
DEV-MEM @ .
3 OK

Encouraging.

Datasheet says that device address space starts at 0x01000000
and ends at 0x7FFFFFFF (above is DRAM). There is a command
line utility to do I/O. Sending 0x01000000 to 0x03022000 turns on
blue LED, sending 0x0 truns it off. AFAICS in lina corresponding
address is B2022000. More generally, there are four GPIO devices
(ports). Port 0 is at 0x03020000, port 1 at 0x03021000, port 2 at >0x03022000, port 3 at 0x03023000. Device access should be done in
32-bit units.

This suggest that you can do the same from lina using virtual
addresses B302x000 . That is vma-io + 0x0100,0000 (device start) + 2x000.
You probably have to initialize the ports to output in some way
for this to work.

All io must be accessed with 32 bit. lina provides L! L@ for
this. (My conventions is B-W-L-Q ).

--
Waldek Hebisch

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl wrote:

In article <vf5a40$2fkdi$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
<SNIP>

RISCV ciforth beta 2023Mar30
MMAP-IO
OK
HEX
OK
VMA-IO @ .
B2000000 OK
DEV-MEM @ .
3 OK

Encouraging.

Datasheet says that device address space starts at 0x01000000
and ends at 0x7FFFFFFF (above is DRAM). There is a command
line utility to do I/O. Sending 0x01000000 to 0x03022000 turns on
blue LED, sending 0x0 truns it off. AFAICS in lina corresponding
address is B2022000. More generally, there are four GPIO devices
(ports). Port 0 is at 0x03020000, port 1 at 0x03021000, port 2 at >>0x03022000, port 3 at 0x03023000. Device access should be done in
32-bit units.

This suggest that you can do the same from lina using virtual
addresses B302x000 . That is vma-io + 0x0100,0000 (device start) + 2x000.
You probably have to initialize the ports to output in some way
for this to work.

I tried first things like above and got segfaults. AFAICS lina B2000000 corresponds to 0x3000000 in device space, so 0x03022000 corresponds to B2022000. It seems that lina did not map block between 0x1000000
and 0x3000000, in this block that are 'ap_mailbox' and 'ap_system_ctrl',
it is probably not wise to mess with them from user space.

All io must be accessed with 32 bit. lina provides L! L@ for
this. (My conventions is B-W-L-Q ).

1000000 B2022000 L!
OK
0 B2022000 L!
OK

blinks the LED. I tried and 64-bit access works too, but it reads
or writes also the second register, so L! and L@ are simpler to use.

I still need to check which GPIO-s are actually usable, there is
4*32 = 128 logical lines, but the 64-Mb chip has only 68 pins.

There are several control registers deciding what pins do:
PINMUX, RTCSYS_GPIO and control registers for GPIO device.
LED was configured for GPIO output by bundled software, so
it was enough to write to the data port.
--
Waldek Hebisch
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <vf5sit$2gjqb$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

albert@spenarnc.xs4all.nl wrote:

In article <vf5a40$2fkdi$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
<SNIP>

RISCV ciforth beta 2023Mar30
MMAP-IO
OK
HEX
OK
VMA-IO @ .
B2000000 OK
DEV-MEM @ .
3 OK

Encouraging.

Datasheet says that device address space starts at 0x01000000
and ends at 0x7FFFFFFF (above is DRAM). There is a command
line utility to do I/O. Sending 0x01000000 to 0x03022000 turns on
blue LED, sending 0x0 truns it off. AFAICS in lina corresponding
address is B2022000. More generally, there are four GPIO devices >>>(ports). Port 0 is at 0x03020000, port 1 at 0x03021000, port 2 at >>>0x03022000, port 3 at 0x03023000. Device access should be done in
32-bit units.

This suggest that you can do the same from lina using virtual
addresses B302x000 . That is vma-io + 0x0100,0000 (device start) + 2x000.
You probably have to initialize the ports to output in some way
for this to work.

I tried first things like above and got segfaults. AFAICS lina B2000000 >corresponds to 0x3000000 in device space, so 0x03022000 corresponds to >B2022000. It seems that lina did not map block between 0x1000000
and 0x3000000, in this block that are 'ap_mailbox' and 'ap_system_ctrl',
it is probably not wise to mess with them from user space.

Apparently it was wrong to add the 0x0100,0000. vma-io contains the
device start. Then it works.
The addresses below 0x0100,0000 are for chip control, start up,
not so much for peripherals.

All io must be accessed with 32 bit. lina provides L! L@ for
this. (My conventions is B-W-L-Q ).

1000000 B2022000 L!
OK
0 B2022000 L!
OK

blinks the LED. I tried and 64-bit access works too, but it reads
or writes also the second register, so L! and L@ are simpler to use.

I still need to check which GPIO-s are actually usable, there is
4*32 = 128 logical lines, but the 64-Mb chip has only 68 pins.

The board I have DongshanNezha a ball grid with 377 balls.
Io pins are A-G with up to 18 bits per port, a bit irregular but
a lot.
Not bad for less than 30 euro's. 60 pin's readily available to
attach to.
For generating midi (31kbaud serial) I used merely one pin to
play FIG leaf rag on the keyboard.

There are several control registers deciding what pins do:
PINMUX, RTCSYS_GPIO and control registers for GPIO device.
LED was configured for GPIO output by bundled software, so
it was enough to write to the data port.

If you have a detailed electronics layout, it is easy to see
what ports are free to use. It can be a pain to configure the
io. There is an example for the DongshanNezha board in forth.lab.

--
Waldek Hebisch

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl wrote:

In article <vf5sit$2gjqb$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

albert@spenarnc.xs4all.nl wrote:

In article <vf5a40$2fkdi$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
<SNIP>

RISCV ciforth beta 2023Mar30
MMAP-IO
OK
HEX
OK
VMA-IO @ .
B2000000 OK
DEV-MEM @ .
3 OK

Encouraging.

Datasheet says that device address space starts at 0x01000000
and ends at 0x7FFFFFFF (above is DRAM). There is a command
line utility to do I/O. Sending 0x01000000 to 0x03022000 turns on
blue LED, sending 0x0 truns it off. AFAICS in lina corresponding >>>>address is B2022000. More generally, there are four GPIO devices >>>>(ports). Port 0 is at 0x03020000, port 1 at 0x03021000, port 2 at >>>>0x03022000, port 3 at 0x03023000. Device access should be done in >>>>32-bit units.

This suggest that you can do the same from lina using virtual
addresses B302x000 . That is vma-io + 0x0100,0000 (device start) + 2x000. >>> You probably have to initialize the ports to output in some way
for this to work.

I tried first things like above and got segfaults. AFAICS lina B2000000 >>corresponds to 0x3000000 in device space, so 0x03022000 corresponds to >>B2022000. It seems that lina did not map block between 0x1000000
and 0x3000000, in this block that are 'ap_mailbox' and 'ap_system_ctrl',
it is probably not wise to mess with them from user space.

Apparently it was wrong to add the 0x0100,0000. vma-io contains the
device start. Then it works.
The addresses below 0x0100,0000 are for chip control, start up,
not so much for peripherals.

All io must be accessed with 32 bit. lina provides L! L@ for
this. (My conventions is B-W-L-Q ).

1000000 B2022000 L!
OK
0 B2022000 L!
OK

blinks the LED. I tried and 64-bit access works too, but it reads
or writes also the second register, so L! and L@ are simpler to use.

I still need to check which GPIO-s are actually usable, there is
4*32 = 128 logical lines, but the 64-Mb chip has only 68 pins.

The board I have DongshanNezha a ball grid with 377 balls.
Io pins are A-G with up to 18 bits per port, a bit irregular but
a lot.
Not bad for less than 30 euro's. 60 pin's readily available to
attach to.
For generating midi (31kbaud serial) I used merely one pin to
play FIG leaf rag on the keyboard.

There are several control registers deciding what pins do:
PINMUX, RTCSYS_GPIO and control registers for GPIO device.
LED was configured for GPIO output by bundled software, so
it was enough to write to the data port.

If you have a detailed electronics layout, it is easy to see
what ports are free to use. It can be a pain to configure the
io. There is an example for the DongshanNezha board in forth.lab.

Well, chip datasheet, schematics and board description each used
different names for pins, but I worked out which pins are
connected to outside. There is compilcation as some I/O lines
are 1.8V only and some are probably 3.3 tolerant but use 1.8V
signalling. Normal lines are 3.3V, but 3 lines are 1.8V and
connected to level shifters so that on board connector there
3.3V signalling. However "useful" for me is a bit more
complicated. Chip contains bunch of SPI-s, I2C-s, SPI-s,
UART-s and PWM-s. There are 2 SDIO interfaces, camera
interface and ethernet interface. In principle one can use
camera and ethernet lines as GPIO, but it is tricky to
connect to camera lines (camera connector uses small pitch
ribbon) and both camera and ethernet use 1.8V signalling.
So there are electical questions (level shifters and 1.8V
signalling make lines less useful). There is question of
cooperation with Linux: IIUC Linux considers ethernet and
SDIO0 lines as its own (and possibly several other lines).
So there is question which lines can I use without interfering
with Linux. Given that chip contains 3 cores and only one
core runs Linux there should be a way to tell Linux that
some lines/device should be left alone.

Concerning forth.lab, I see there only examples for Raspberry Pi
and Orange Pi, but nothing for Risc-V boards. I fetched
version from 2023Mar30, which looked as only available version
for Risc-V. Assembly code is clearly for Risc-V, but
documentation says Arm or aarch and forth.lab also looks
like one form Arm.
--
Waldek Hebisch
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <vf9n7n$31174$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
<SNIP>

Concerning forth.lab, I see there only examples for Raspberry Pi
and Orange Pi, but nothing for Risc-V boards. I fetched
version from 2023Mar30, which looked as only available version
for Risc-V. Assembly code is clearly for Risc-V, but
documentation says Arm or aarch and forth.lab also looks
like one form Arm.

I checked it, and you are right. Apparently the archive was made
on another host to generate the doc files, and forth.lab was overlooked.
I fix this ASAP, but the risc board has problems with the network.

--
Waldek Hebisch

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

Waldek Hebisch <antispam@fricas.org> wrote:

albert@spenarnc.xs4all.nl wrote:

In article <vf5a40$2fkdi$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
<SNIP>

RISCV ciforth beta 2023Mar30
MMAP-IO
OK
HEX
OK
VMA-IO @ .
B2000000 OK
DEV-MEM @ .
3 OK

Encouraging.

Datasheet says that device address space starts at 0x01000000
and ends at 0x7FFFFFFF (above is DRAM). There is a command
line utility to do I/O. Sending 0x01000000 to 0x03022000 turns on
blue LED, sending 0x0 truns it off. AFAICS in lina corresponding
address is B2022000. More generally, there are four GPIO devices >>>(ports). Port 0 is at 0x03020000, port 1 at 0x03021000, port 2 at >>>0x03022000, port 3 at 0x03023000. Device access should be done in
32-bit units.

This suggest that you can do the same from lina using virtual
addresses B302x000 . That is vma-io + 0x0100,0000 (device start) + 2x000.
You probably have to initialize the ports to output in some way
for this to work.

I tried first things like above and got segfaults. AFAICS lina B2000000 corresponds to 0x3000000 in device space, so 0x03022000 corresponds to B2022000. It seems that lina did not map block between 0x1000000
and 0x3000000, in this block that are 'ap_mailbox' and 'ap_system_ctrl',
it is probably not wise to mess with them from user space.

All io must be accessed with 32 bit. lina provides L! L@ for
this. (My conventions is B-W-L-Q ).

1000000 B2022000 L!
OK
0 B2022000 L!
OK

blinks the LED. I tried and 64-bit access works too, but it reads
or writes also the second register, so L! and L@ are simpler to use.

Milkv Duos have 5 GPIO ports, formally 32-bit but many lines are
not connected to outputs. One port in RTC block and has
base address 0x05021000, the other ports are at 0x03020000 + n*0x1000
where n is port number. Output register is at offset 0, at offset
4 is direction register (setting bit to 1 means that line is an
output). At offset 0x50 is input register. Other registers
deal with interrupts.

ATM I have the following:

HEX
: LBIS DUP L@ ROT OR SWAP L! ;
: LBIC DUP L@ ROT INVERT AND SWAP L! ;
: gpio-base DUP 4 = IF DROP 2001000 ELSE 1000 * THEN VMA-IO @ + 20000 + ;
: bit-data 20 /MOD SWAP 1 SWAP LSHIFT SWAP gpio-base ;
: gpio-on bit-data LBIS ;
: gpio-off bit-data LBIC ;

which outputs bits to data register. To get actual output one
need to set direction register and associate PIN with GPIO function.
There is something more, I tried to hijack Ethernet pins bit I
got no output. Theoretically pins were associated with GPIO
function and lines were set to output, writes changed data
register, but voltage on the pin did not change. OTOH, by
changing UART0 TX pin to GPIO is got output, so there is
something special about Ethernet.

BTW: Chip datasheet talks about ports and pin numbers within
ports, Milkv Duo picture uses pin numbers but there is mixup
with ports. There is command line outility to deal with pins,
it uses different numbering similar to numbering on the board
but not the same. Linux uses still different ping numbering.
Above I use pin number withing port + 32*port number where
ports are numbered from 0.
--
Waldek Hebisch
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <vfhgqc$3sajh$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
<SNIP>

BTW: Chip datasheet talks about ports and pin numbers within
ports, Milkv Duo picture uses pin numbers but there is mixup
with ports. There is command line outility to deal with pins,
it uses different numbering similar to numbering on the board
but not the same. Linux uses still different ping numbering.
Above I use pin number withing port + 32*port number where
ports are numbered from 0.

That is a sensible convention, I use the same.
In my riscv board the output are marked i.e. GD13 that
has assigned the Forth io number (^D-1)*0x20 +13 .
That gets 0x6D .

--
Waldek Hebisch

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <vfhgqc$3sajh$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

Waldek Hebisch <antispam@fricas.org> wrote:

<SNIP>

Milkv Duos have 5 GPIO ports, formally 32-bit but many lines are
not connected to outputs. One port in RTC block and has
base address 0x05021000, the other ports are at 0x03020000 + n*0x1000
where n is port number. Output register is at offset 0, at offset
4 is direction register (setting bit to 1 means that line is an
output). At offset 0x50 is input register. Other registers
deal with interrupts.

ATM I have the following:

HEX
: LBIS DUP L@ ROT OR SWAP L! ;
: LBIC DUP L@ ROT INVERT AND SWAP L! ;

These boards are all 32 bits io. So I lifted the BIS and BIC
from ARM boards into riscv.
So you can use BIS instead of LBIS, BIC instead of LBIC.
Of course they are in assembler, as these low level words must be.

: gpio-base DUP 4 = IF DROP 2001000 ELSE 1000 * THEN VMA-IO @ + 20000 + ;
: bit-data 20 /MOD SWAP 1 SWAP LSHIFT SWAP gpio-base ;
: gpio-on bit-data LBIS ;
: gpio-off bit-data LBIC ;

which outputs bits to data register. To get actual output one
need to set direction register and associate PIN with GPIO function.

I defined set-function by ( fun# gpio#)
and redefine fun# that I always 0 for input , -1 for output.
This make a 1602 driver almost portable except for defining
the port numbers/

--
Waldek Hebisch

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl wrote:

In article <vfhgqc$3sajh$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
<SNIP>

BTW: Chip datasheet talks about ports and pin numbers within
ports, Milkv Duo picture uses pin numbers but there is mixup
with ports. There is command line outility to deal with pins,
it uses different numbering similar to numbering on the board
but not the same. Linux uses still different ping numbering.
Above I use pin number withing port + 32*port number where
ports are numbered from 0.

That is a sensible convention, I use the same.
In my riscv board the output are marked i.e. GD13 that
has assigned the Forth io number (^D-1)*0x20 +13 .
That gets 0x6D .

64 MB Milkv Duo board has marking like GP0, GP1, etc. As I wrote
this does not agree with most other sources. I think 256 MB
version has "the same" marking, but probably slightly different
correspondence with ports and lines withing ports. Milkv
Duo S has different connectors and no marking on the board.
Each has different chip, 64 MB is CV1800B (68 pin QFP, 1 GHz Risc-V +
700MHz Risc-V + 8051), 256 MB is SG2002 (88 pin QFP, 1GHz Arm +
1 GHz Risc-V + 700MHz Risc-V + 8051), Duo-S had 512 MB RAM and
uses SG2000 (205 pin BGA, 1GHz Arm + 1 GHz Risc-V + 700MHz Risc-V +
8051). On 64 MB duo there are some pins that apparently can be
connected to two different ports, reference via "canonical" label
of a pin would exclude such thing.
--
Waldek Hebisch
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

albert@spenarnc.xs4all.nl wrote:

In article <vfhgqc$3sajh$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

which outputs bits to data register. To get actual output one
need to set direction register and associate PIN with GPIO function.

I defined set-function by ( fun# gpio#)
and redefine fun# that I always 0 for input , -1 for output.
This make a 1602 driver almost portable except for defining
the port numbers/

One pin may have several functions, not only GPIO. Do you mean
that you change numbering of functions so that 0 is GPIO input,
-1 is GPIO output and other functions get other numbers?
--
Waldek Hebisch
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <vfjfk9$3v0b0$4@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

albert@spenarnc.xs4all.nl wrote:

In article <vfhgqc$3sajh$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:
<SNIP>

BTW: Chip datasheet talks about ports and pin numbers within
ports, Milkv Duo picture uses pin numbers but there is mixup
with ports. There is command line outility to deal with pins,
it uses different numbering similar to numbering on the board
but not the same. Linux uses still different ping numbering.
Above I use pin number withing port + 32*port number where
ports are numbered from 0.

That is a sensible convention, I use the same.
In my riscv board the output are marked i.e. GD13 that
has assigned the Forth io number (^D-1)*0x20 +13 .
That gets 0x6D .

64 MB Milkv Duo board has marking like GP0, GP1, etc. As I wrote
this does not agree with most other sources. I think 256 MB
version has "the same" marking, but probably slightly different >correspondence with ports and lines withing ports. Milkv
Duo S has different connectors and no marking on the board.
Each has different chip, 64 MB is CV1800B (68 pin QFP, 1 GHz Risc-V +
700MHz Risc-V + 8051), 256 MB is SG2002 (88 pin QFP, 1GHz Arm +
1 GHz Risc-V + 700MHz Risc-V + 8051), Duo-S had 512 MB RAM and
uses SG2000 (205 pin BGA, 1GHz Arm + 1 GHz Risc-V + 700MHz Risc-V +
8051). On 64 MB duo there are some pins that apparently can be
connected to two different ports, reference via "canonical" label
of a pin would exclude such thing.

Well. The DongshanNezhaSTU has a 9 page schematic and the 260 pin DDR4
external finger connector has a legenda like PG4 and PD17 that refer
directly to the Soc description.
I suggest getting this documentation from the manufacturer, because
it is essential to using the board.

--
Waldek Hebisch

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.forth

In article <vfjlan$3vq70$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

albert@spenarnc.xs4all.nl wrote:

In article <vfhgqc$3sajh$1@paganini.bofh.team>,
Waldek Hebisch <antispam@fricas.org> wrote:

which outputs bits to data register. To get actual output one
need to set direction register and associate PIN with GPIO function.

I defined set-function by ( fun# gpio#)
and redefine fun# that I always 0 for input , -1 for output.
This make a 1602 driver almost portable except for defining
the port numbers/

One pin may have several functions, not only GPIO. Do you mean
that you change numbering of functions so that 0 is GPIO input,
-1 is GPIO output and other functions get other numbers?

GA13 is pin 0x1D. That is never changed.
29 CONSTANT GA13
0 GA13 set-function / OR
-1 GA13 set-function /OR

In the following example I use PB0. This is directly
reference in the doc. Function 5 couples PB0 to UART2.
This is documented also.
"$20 CONSTANT PB0 7 PB0 setfunction"
This is all it takes. Screw linux protections and
abstraction layers.
Now it boils down to finding out how the UART works.
Note that 32 uS is the period I want for a midi signal.

We Forthers don't have to rely on Linux kernel gurus,
but we need documentation.

----------------------------

\ $Id: uart.frt,v 1.4 2023/04/19 20:09:55 albert Exp albert $
\ Copyright (2023): Albert van der Horst {by GNU Public License}
WANT $-PREFIX
WANT setfunction
DECIMAL \ All other via prefixes
$20 CONSTANT PB0 7 PB0 setfunction \ PB0 coupled to UART2
\ Common
VMA-IO @ $00,1000 + CONSTANT CCU-BASE
CCU-BASE $090C + CONSTANT UART_BGR_REG
\ Reset all uarts and start the clocks.
-1 UART_BGR_REG L!

VMA-IO @ $50,0000 + CONSTANT UART-BASE
UART-BASE $0000 + CONSTANT UART0
UART-BASE $0400 + CONSTANT UART1
UART-BASE $0800 + CONSTANT UART2
UART-BASE $0C00 + CONSTANT UART3

UART2 CONSTANT UART
: >DLL 0 + ; : >DLH 4 + ;
: >THR 0 + ; : >LCR $0C + ;
: >FCR 8 + ;
\ : >LSR 14 + ; : >HALT $0A4 + ;
\ %0000,0100,0000,0100 UART_BGR_REG BIS \ alternative only UART2.
\ 9.2.4.1
\ 24 Mhz default, leave it alone.
\ clock setting, break, don't care, parity, stop bit, bitlength
%1,0,00,0,0,00 UART >LCR BIS
\ The divider for a midi signal is 48 (24Mhz/48*16 ~ 32 uS)
48 UART >DLL L! 0 UART >DLH L!
%1,0,00,0,0,00 UART >LCR BIC

\ clock set, break, parity aux, parity, stop bit, bitlength
%0,0,00,0,0,11 UART >LCR L!
1 UART >FCR BIS \ Enable fifo.
\ --------- API ------------
\ Start a break for indefinite time.
: break %0,1,00,0,0,00 UART >LCR BIS ;
\ Transmit a byte .
: TRANSMIT-U UART >THR L! ;

\ --------- Tests and checks. ------------
: test BEGIN $0AA TRANSMIT-U KEY? UNTIL ;
: test2 0 DO $0AA TRANSMIT-U 1 MS LOOP ;
: rdump BEGIN DUP H. SPACE DUP L@ H. CR 4 + KEY &Q = UNTIL ;

\ Toggle break fast n times.
: breaky >R %0,1,00,0,0,00 UART >LCR
R> 0 DO 2DUP BIS 2DUP BIC LOOP
2DROP ;
--------------------------------------------------------------
[If I make an UART and object, it becomes infinitely more
elegant.

\ Usage : you have to look up port PB0
$20 CONSTANT PB0 7 PB0 set-function \ PB0 coupled to UART2
2 NEW-UART midi-port 31,125 baudrate fifo-on
]

--
Waldek Hebisch

--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- Synchronet 3.20a-Linux NewsLink 1.114