From Newsgroup: comp.os.vms

On 2025-10-03, Arne Vajhoj <arne@vajhoej.dk> wrote:

On 10/3/2025 8:12 AM, Simon Clubley wrote:

On 2025-10-02, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <MPG.43477ac440ab7840989764@news.zx.net.nz>,
David Goodwin <david+usenet@zx.net.nz> wrote:

Set top boxes and routers were not the target market for Windows in the >>>> 90s, and they are clearly not a market Microsoft is interested in
pursuing today.

Moreover, 99.9% of those MIPS CPUs that are outselling x86 are
embedded microcontrollers that just happen to use the MIPS
instruction set. If they run any OS at all, it's way more than
likely to be some kind of RTOS.

Here is one example at the lower end (which is also available in hobbyist
friendly packaging):

https://uk.farnell.com/microchip/pic32mx250f128b-i-sp/mcu-32bit-pic32-40mhz-spdip-28/dp/2097773

I think this part of the spec illustrate the target market:

<quote>
MIPS32< M4K< core with MIPS16e< mode for up to 40% smaller code size
</quote>

Switching to 16 bit mode to reduce application size is not where
Microsoft is with Windows today.

As you can see from the specs, and like the lower end ARM MCUs, it still
has a lot of functionality within it however, making it well suited
for its target role.

It's also the most powerful MCU range I know of that has PDIP options.

I do think the ARM architecture is _easily_ the nicer and most elegant architecture of the two however. ARM is also the only real viable option
once you move to more powerful MCUs.

[And before anyone mentions it, I don't think RISC-V is there yet and
it would need to see ARM's industrial strength and long-term staying
power behind it before people were comfortable adopting it across the
board. Basically, I see it as the same problem VMS has when compared
to Linux.]

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10bp20r$1vse5$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-10-03, Arne Vajhoj <arne@vajhoej.dk> wrote:

On 10/3/2025 8:12 AM, Simon Clubley wrote:

On 2025-10-02, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <MPG.43477ac440ab7840989764@news.zx.net.nz>,
David Goodwin <david+usenet@zx.net.nz> wrote:

Set top boxes and routers were not the target market for Windows in the >>>>> 90s, and they are clearly not a market Microsoft is interested in
pursuing today.

Moreover, 99.9% of those MIPS CPUs that are outselling x86 are
embedded microcontrollers that just happen to use the MIPS
instruction set. If they run any OS at all, it's way more than
likely to be some kind of RTOS.

Here is one example at the lower end (which is also available in hobbyist >>> friendly packaging):

https://uk.farnell.com/microchip/pic32mx250f128b-i-sp/mcu-32bit-pic32-40mhz-spdip-28/dp/2097773

I think this part of the spec illustrate the target market:

<quote>
MIPS32< M4K< core with MIPS16e< mode for up to 40% smaller code size >></quote>

Switching to 16 bit mode to reduce application size is not where
Microsoft is with Windows today.

As you can see from the specs, and like the lower end ARM MCUs, it still
has a lot of functionality within it however, making it well suited
for its target role.

It's also the most powerful MCU range I know of that has PDIP options.

I thought NXP offered a Cortex-M CPU in a PDIP package? The
LPC1114FN28 appears to be such a thing.

I do think the ARM architecture is _easily_ the nicer and most elegant >architecture of the two however. ARM is also the only real viable option
once you move to more powerful MCUs.

That's probably true, compared to MIPS.

[And before anyone mentions it, I don't think RISC-V is there yet and
it would need to see ARM's industrial strength and long-term staying
power behind it before people were comfortable adopting it across the
board. Basically, I see it as the same problem VMS has when compared
to Linux.]

There are O(10^9) RISC-V cores shipped per year in the embedded
space at this point; NVIDIA alone shipped that many in 2024.

But if you need something that's an M7-class part, options
become rather more limited (which is a pity). In terms of
providing something roughly equivalent to a Cortex-A5, RISC-V
has been there for a while. What's really lacking, however, is
something a performance-competitive datacenter or desktop CPU.

Some of the SiFive cores are ok, but they have a long way to go
to reach the performance levels of Ampere, Graviton, or Apple
Silicon, let alone AMD EPYC or Intel Emerald Rapids.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10bslgs$qfk$1@reader2.panix.com>,
cross@spitfire.i.gajendra.net (Dan Cross) wrote:

In terms of providing something roughly equivalent to a Cortex-A5,
RISC-V has been there for a while. What's really lacking, however,
is a performance-competitive datacenter or desktop CPU.

Some of the SiFive cores are ok, but they have a long way to go
to reach the performance levels of Ampere, Graviton, or Apple
Silicon, let alone AMD EPYC or Intel Emerald Rapids.

Yup. I've ported my employer's product to, um, quite a lot of 32- and
64-bit architectures over the past thirty years. It runs on servers,
desktops and high-end mobile devices Five years ago, I was looking
forward to doing a RISC-V port to Linux and/or Android before I retired.

Then SiFive made job cuts and abandoned development of high-end
general-purpose cores in October 2023. Since then, there doesn't seem to
have been much in the way of performance advances in the RISC-V space.
Ahead Computing was set up to offer that, but have gone rather quiet.
MIPS switched to RISC-V, but have been acquired since then.

I'm starting to become suspicious that the claims that it's hard to make
very fast RISC-V cores are accurate.

John
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-10-04, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10bp20r$1vse5$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

As you can see from the specs, and like the lower end ARM MCUs, it still >>has a lot of functionality within it however, making it well suited
for its target role.

It's also the most powerful MCU range I know of that has PDIP options.

I thought NXP offered a Cortex-M CPU in a PDIP package? The
LPC1114FN28 appears to be such a thing.

Yes they do, and yes, that's the one.

Unfortunately, it's not as capable as the PIC32MX PDIP options.

For example, it does not have a USB interface and has more limited memory.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <memo.20251005174852.10624Q@jgd.cix.co.uk>,
John Dallman <jgd@cix.co.uk> wrote:

In article <10bslgs$qfk$1@reader2.panix.com>,
cross@spitfire.i.gajendra.net (Dan Cross) wrote:

In terms of providing something roughly equivalent to a Cortex-A5,
RISC-V has been there for a while. What's really lacking, however,
is a performance-competitive datacenter or desktop CPU.

Some of the SiFive cores are ok, but they have a long way to go
to reach the performance levels of Ampere, Graviton, or Apple
Silicon, let alone AMD EPYC or Intel Emerald Rapids.

Yup. I've ported my employer's product to, um, quite a lot of 32- and
64-bit architectures over the past thirty years. It runs on servers,
desktops and high-end mobile devices Five years ago, I was looking
forward to doing a RISC-V port to Linux and/or Android before I retired.

Then SiFive made job cuts and abandoned development of high-end >general-purpose cores in October 2023. Since then, there doesn't seem to
have been much in the way of performance advances in the RISC-V space.
Ahead Computing was set up to offer that, but have gone rather quiet.
MIPS switched to RISC-V, but have been acquired since then.

I'm starting to become suspicious that the claims that it's hard to make
very fast RISC-V cores are accurate.

I could see it go either way: it took quite some time for ARM64
to get to the point of adoption where we saw Graviton and Ampere
Altra. So it may just be taking time: on the embedded side,
they hit the target of shipping a billion CPUs a year faster
than ARM did, but that's a different market.

On the other hand, everything you wrote is true, and it sure
seems like they're taking their sweet time about getting there,
which does make one wonder what's going on.

I've been told that the BOOM (Berkeley Out-of-Order Machine) was
quite zippy, so I don't think there are any architectural issues
making RV64 fast. I know that they way they do optional
features gives folks a lot of pain, and basically requires hot
patching code at startup to cover the set of implemented
features on any given platform, if you want to run a generic
binary portable across different implementations, so that could
have something to do with it: otherwise you've got a lot of
branches and indirect jumps through thunks and similar things to
work around the differences, which will slow down baseline
execution. Anyway, fragmentation is a real issue, and may be
hindering adoption.

There are definitely a few things I wish they had done
differently (I'm not a fan of the page table formats, page
frames are too small for the memory sizes we have now, and I
don't like SBI), and from a systems perspective, last time I
looked it felt a little immature; the mechanism for doing
uncached access to memory-mapped IO devices, for instance, based
on PMAs felt limited for a large system and felt like an extra
hoop to jump through versus encoding that in page tables and
having something like MTRRs for the physical side. It's unclear
how well they support large numbers of hart contexts in the PLIC
architecture for MSIs, let alone MSI-X.

Also, the Chinese are pushing it pretty far, and things like the
Milk-V systems look pretty cool. I suspect we'll see RV64 in
supercomputers relatively soon; whether those chips will be
readily available in the western markets remains to be seen.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10c0bvp$9gii$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-10-04, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10bp20r$1vse5$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

As you can see from the specs, and like the lower end ARM MCUs, it still >>>has a lot of functionality within it however, making it well suited
for its target role.

It's also the most powerful MCU range I know of that has PDIP options.

I thought NXP offered a Cortex-M CPU in a PDIP package? The
LPC1114FN28 appears to be such a thing.

Yes they do, and yes, that's the one.

Unfortunately, it's not as capable as the PIC32MX PDIP options.

For example, it does not have a USB interface and has more limited memory.

Fair point. Amusingly, I see that Microchip now has a fairly
serious standalone RISC-V offering they're marketing under the
PIC label: https://www.microchip.com/en-us/product/pic64gx1000
(This is hardly a microcontroller, though it appears to have an
MCU "monitor" core embedded in the SoC). It looks pretty cool: https://ww1.microchip.com/downloads/aemDocuments/documents/MPU64/ProductDocuments/SupportingCollateral/64-bit_RISC-V_Embedded_Microprocessors_White_Paper.pdf

For a project I did not too long ago (a custom mouse), I found
a RISC-V core in a TSSOP20 package that seemed like a good fit: https://www.wch-ic.com/products/CH32X035.html

Not PDIP, but I actually prefer SMT form factors anyway. A
colleague convinced me to go with an ARM core (Cortex-M4)
instead, however.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-10-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10c0bvp$9gii$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-10-04, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10bp20r$1vse5$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

As you can see from the specs, and like the lower end ARM MCUs, it still >>>>has a lot of functionality within it however, making it well suited
for its target role.

It's also the most powerful MCU range I know of that has PDIP options.

I thought NXP offered a Cortex-M CPU in a PDIP package? The
LPC1114FN28 appears to be such a thing.

Yes they do, and yes, that's the one.

Unfortunately, it's not as capable as the PIC32MX PDIP options.

For example, it does not have a USB interface and has more limited memory.

Fair point. Amusingly, I see that Microchip now has a fairly
serious standalone RISC-V offering they're marketing under the
PIC label: https://www.microchip.com/en-us/product/pic64gx1000
(This is hardly a microcontroller, though it appears to have an
MCU "monitor" core embedded in the SoC). It looks pretty cool: https://ww1.microchip.com/downloads/aemDocuments/documents/MPU64/ProductDocuments/SupportingCollateral/64-bit_RISC-V_Embedded_Microprocessors_White_Paper.pdf

I didn't know about this thanks, so I've just been looking at this board.

One question: Where exactly do you plug in a USB keyboard and/or USB mouse
into this board ? Also, what about an external USB drive or other external
USB devices ?

That USB port on the board is described as a UART-USB port/debug/power interface only. What's more strange is that the board _does_ have a HDMI
port, which seems really strange unless you have the ability to attach
input devices to it as well.

Unless there's something I am missing, it appears you can only use this
from another device as an embedded board instead of as a standalone machine.

I'm also not seeing any onboard flash memory in the images published in
the quick start guide, so if it really is missing you would have to always
boot from the SDcard.

For a project I did not too long ago (a custom mouse), I found
a RISC-V core in a TSSOP20 package that seemed like a good fit: https://www.wch-ic.com/products/CH32X035.html

Not PDIP, but I actually prefer SMT form factors anyway. A
colleague convinced me to go with an ARM core (Cortex-M4)
instead, however.

I'm a software guy first and a hardware guy a (distant :-) ) second.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10c3kco$13ejq$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-10-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10c0bvp$9gii$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-10-04, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10bp20r$1vse5$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

As you can see from the specs, and like the lower end ARM MCUs, it still >>>>>has a lot of functionality within it however, making it well suited >>>>>for its target role.

It's also the most powerful MCU range I know of that has PDIP options. >>>>

I thought NXP offered a Cortex-M CPU in a PDIP package? The
LPC1114FN28 appears to be such a thing.

Yes they do, and yes, that's the one.

Unfortunately, it's not as capable as the PIC32MX PDIP options.

For example, it does not have a USB interface and has more limited memory. >>

Fair point. Amusingly, I see that Microchip now has a fairly
serious standalone RISC-V offering they're marketing under the
PIC label: https://www.microchip.com/en-us/product/pic64gx1000
(This is hardly a microcontroller, though it appears to have an
MCU "monitor" core embedded in the SoC). It looks pretty cool:

https://ww1.microchip.com/downloads/aemDocuments/documents/MPU64/ProductDocuments/SupportingCollateral/64-bit_RISC-V_Embedded_Microprocessors_White_Paper.pdf

I didn't know about this thanks, so I've just been looking at this board.

One question: Where exactly do you plug in a USB keyboard and/or USB mouse >into this board ? Also, what about an external USB drive or other external >USB devices ?

That USB port on the board is described as a UART-USB port/debug/power >interface only. What's more strange is that the board _does_ have a HDMI >port, which seems really strange unless you have the ability to attach
input devices to it as well.

Unless there's something I am missing, it appears you can only use this
from another device as an embedded board instead of as a standalone machine.

I'm also not seeing any onboard flash memory in the images published in
the quick start guide, so if it really is missing you would have to always >boot from the SDcard.

I'm not sure which board you're referring to. The link I gave
are to a CPU, not a devboard or other finished product, and I
don't think they mention one?

I would imagine you'd have to design and fabricate a board for
this (though I also image that Microchip probably sells a
devboard for it). The CPU appears to come in a couple of
different BGA packages; the one that looks more intereseting is
a 484 pin "FCVG484" package, compatible with Microchip's
PolarFire FPGAs. For USB, I presume one would have to line out
whatever leads go to the CPU's USB functions to an external
connector; for USB 2.0 I've done it before, and it's not too
hard (you need a ferrite bead and a couple of bypass caps; I
can't remember whether you AC couple the +/- data pair, though;
I rather think you don't).

For a project I did not too long ago (a custom mouse), I found
a RISC-V core in a TSSOP20 package that seemed like a good fit:
https://www.wch-ic.com/products/CH32X035.html

Not PDIP, but I actually prefer SMT form factors anyway. A
colleague convinced me to go with an ARM core (Cortex-M4)
instead, however.

I'm a software guy first and a hardware guy a (distant :-) ) second.

No worries! I guess the main point is that there is _some_
momentum around RISC-V across a variety of spaces.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10c2vif$c1q$1@reader2.panix.com>,
cross@spitfire.i.gajendra.net (Dan Cross) wrote:

I've been told that the BOOM (Berkeley Out-of-Order Machine) was
quite zippy, so I don't think there are any architectural issues
making RV64 fast. I know that they way they do optional
features gives folks a lot of pain ... fragmentation is a real
issue, and may be hindering adoption.

That's meant to be handled by the RVA series of "profiles." Meeting an application profile requires a specified set of extensions, with a
smaller set discoverable at run-time.

The latest profile is RVA23, which was ratified in October 2024. <https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc>


I'm hoping that RVA24 will be ratified soon, and will contain the
extensions that the Android kernel team have been waiting for.

John
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-10-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10c3kco$13ejq$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-10-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

Fair point. Amusingly, I see that Microchip now has a fairly
serious standalone RISC-V offering they're marketing under the
PIC label: https://www.microchip.com/en-us/product/pic64gx1000
(This is hardly a microcontroller, though it appears to have an
MCU "monitor" core embedded in the SoC). It looks pretty cool:

https://ww1.microchip.com/downloads/aemDocuments/documents/MPU64/ProductDocuments/SupportingCollateral/64-bit_RISC-V_Embedded_Microprocessors_White_Paper.pdf

I didn't know about this thanks, so I've just been looking at this board.

One question: Where exactly do you plug in a USB keyboard and/or USB mouse >>into this board ? Also, what about an external USB drive or other external >>USB devices ?

That USB port on the board is described as a UART-USB port/debug/power >>interface only. What's more strange is that the board _does_ have a HDMI >>port, which seems really strange unless you have the ability to attach >>input devices to it as well.

Unless there's something I am missing, it appears you can only use this >>from another device as an embedded board instead of as a standalone machine. >>
I'm also not seeing any onboard flash memory in the images published in
the quick start guide, so if it really is missing you would have to always >>boot from the SDcard.

I'm not sure which board you're referring to. The link I gave
are to a CPU, not a devboard or other finished product, and I
don't think they mention one?

This one:

https://uk.farnell.com/microchip/curiosity-pic64gx1000-kit/curiosity-kit-64bit-pic-quad-core/dp/4734470

On the Microchip website:

https://www.microchip.com/en-us/development-tool/CURIOSITY-PIC64GX1000-KIT

As mentioned above, there are things missing from Microchip's dev board
that I would expect to see as standard.

Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 2025-10-07 1:58 p.m., Simon Clubley wrote:

One question: Where exactly do you plug in a USB keyboard and/or USB mouse into this board ? Also, what about an external USB drive or other external USB devices ?

That USB port on the board is described as a UART-USB port/debug/power interface only. What's more strange is that the board_does_ have a HDMI
port, which seems really strange unless you have the ability to attach
input devices to it as well.

Unless there's something I am missing, it appears you can only use this
from another device as an embedded board instead of as a standalone machine.

usb-c port of existing Windows or Linux machine to usb-c port on the board.

It looks like there is step-by-step documentation for it in the
quick-start guide:

https://ww1.microchip.com/downloads/aemDocuments/documents/MPU64/ProductDocuments/UserGuides/production-kit-qsguide/Curiosity-PIC64GX1000-Kit_QSGuide.pdf

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <memo.20251007223453.10624Z@jgd.cix.co.uk>,
John Dallman <jgd@cix.co.uk> wrote:

In article <10c2vif$c1q$1@reader2.panix.com>,
cross@spitfire.i.gajendra.net (Dan Cross) wrote:

I've been told that the BOOM (Berkeley Out-of-Order Machine) was
quite zippy, so I don't think there are any architectural issues
making RV64 fast. I know that they way they do optional
features gives folks a lot of pain ... fragmentation is a real
issue, and may be hindering adoption.

That's meant to be handled by the RVA series of "profiles." Meeting an >application profile requires a specified set of extensions, with a
smaller set discoverable at run-time.

The latest profile is RVA23, which was ratified in October 2024. ><https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc>

Yeah, I understand the profiles idea, but it's supporting that
smaller set of extensions discoverable at run-time that's the
problem. I know a lot of people working on RISC-V firmware, and
this (and the forced use of the SBI) seems to be the major
sources of friction. Folks have gone as far as calling it a
"soft core target."

I'm hoping that RVA24 will be ratified soon, and will contain the
extensions that the Android kernel team have been waiting for.

Cool. Standardized atomics will be good.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10c61pt$sa8$1@reader2.panix.com>,
cross@spitfire.i.gajendra.net (Dan Cross) wrote:

Yeah, I understand the profiles idea, but it's supporting that
smaller set of extensions discoverable at run-time that's the
problem. I know a lot of people working on RISC-V firmware, and
this (and the forced use of the SBI) seems to be the major
sources of friction. Folks have gone as far as calling it a
"soft core target."

Aha. I'd be working on application libraries, and would simply assume the basics of the profile and ignore the optional parts. Different viewpoint.


John
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10c5lbh$1ip9q$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-10-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

In article <10c3kco$13ejq$1@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

On 2025-10-07, Dan Cross <cross@spitfire.i.gajendra.net> wrote:

Fair point. Amusingly, I see that Microchip now has a fairly
serious standalone RISC-V offering they're marketing under the
PIC label: https://www.microchip.com/en-us/product/pic64gx1000
(This is hardly a microcontroller, though it appears to have an
MCU "monitor" core embedded in the SoC). It looks pretty cool:

https://ww1.microchip.com/downloads/aemDocuments/documents/MPU64/ProductDocuments/SupportingCollateral/64-bit_RISC-V_Embedded_Microprocessors_White_Paper.pdf

I didn't know about this thanks, so I've just been looking at this board. >>>
One question: Where exactly do you plug in a USB keyboard and/or USB mouse >>>into this board ? Also, what about an external USB drive or other external >>>USB devices ?

That USB port on the board is described as a UART-USB port/debug/power >>>interface only. What's more strange is that the board _does_ have a HDMI >>>port, which seems really strange unless you have the ability to attach >>>input devices to it as well.

Unless there's something I am missing, it appears you can only use this >>>from another device as an embedded board instead of as a standalone machine. >>>
I'm also not seeing any onboard flash memory in the images published in >>>the quick start guide, so if it really is missing you would have to always >>>boot from the SDcard.

I'm not sure which board you're referring to. The link I gave
are to a CPU, not a devboard or other finished product, and I
don't think they mention one?

This one:

https://uk.farnell.com/microchip/curiosity-pic64gx1000-kit/curiosity-kit-64bit-pic-quad-core/dp/4734470

On the Microchip website:

https://www.microchip.com/en-us/development-tool/CURIOSITY-PIC64GX1000-KIT

Aha. I hadn't really looked for a devboard for the chip, so I
didn't see that.

Looking at the datasheet now, the USB-C connector on that board
appears to feed the power tree from the 5V/GND leads, and
terminate the data pair on an FTDI FT4232HL chip, which in turn
is lined to the CPU's UARTs and JTAG interface.

But the schematic is available on the Microchip web site; the
relevant pages are 7 (which describes the pin bank connections,
specifically bank 2 here) and 8 (which describes peripherals).

The way bank 2 is wired, it appears that they've configured the
internal pin mux so that functions for the pads that would
connect to USB expose GPIOs for the mikroBUS interface and
driving LEDs instead. I suspect you could probably desolder a
couple of those LEDs and reconfigure the functions for those
pins for USB use; the 5V rail and ground are already exposed
through the mikroBUS socket. Then dead-bug a USB-A connector
onto the board somewhere, and that would likely be good enough
to get you USB 2.0, so that you could connect an external hub
for HID peripherals and possibly a storage device.

As mentioned above, there are things missing from Microchip's dev board
that I would expect to see as standard.

No idea. I wouldn't necessarily expect USB HID support on a
board like this one.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <memo.20251008170801.10624b@jgd.cix.co.uk>,
John Dallman <jgd@cix.co.uk> wrote:

In article <10c61pt$sa8$1@reader2.panix.com>,
cross@spitfire.i.gajendra.net (Dan Cross) wrote:

Yeah, I understand the profiles idea, but it's supporting that
smaller set of extensions discoverable at run-time that's the
problem. I know a lot of people working on RISC-V firmware, and
this (and the forced use of the SBI) seems to be the major
sources of friction. Folks have gone as far as calling it a
"soft core target."

Aha. I'd be working on application libraries, and would simply assume the >basics of the profile and ignore the optional parts. Different viewpoint.

Ah, ok; that's fair. I'd guess this would mostly affect things
at the application level with respect to the vector extensions,
and if you don't care about that (or don't invoke the compiler
in a way that those instructions are emitted) then no big deal.

- Dan C.

--- Synchronet 3.21a-Linux NewsLink 1.2