Why apps?...

[Don Y]

On 1/9/2022 3:26 PM, Dimiter_Popoff wrote:

On 1/10/2022 0:06, Don Y wrote:

You stick with what you already have/had -- insofar as it is able
to meet your ongoing needs.

Or, embrace more \"open\" offerings... often with the need to make some
commitment (time or money) to ensuring their continued availability,
development, etc.

(Too often, folks buy into FOSS for $0 -- thinking it \"free\" and not
realizing that it can go away just as easily, without support, as
any other offering!)

Well we have dps for power only but it comes with everything necessary
to do all the software for pretty sophisticated products without needing
a single bit of software from anyone else.

This is the approach I\'ve taken with all of my projects -- even if the
toolchain had to be purchased, commercially (it will still function
years later -- albeit without potential updates).

And, if you avoid \"exotic\" hardware/components, you can usually avoid
any dependence on particular suppliers (alas, the days of multiple
second-sources are long gone but you can still minimize the effort
involved in \"porting\" a design to a different BoM).

> How does product lifetime licensing sound?

That\'s what you have when you own the technology. Many folks now
*can* have this by adopting open toolchains AND SUPPORTING THEM
(as most folks aren\'t interested in building tools from scratch but
*can* contribute -- bug reports, test cases, etc. -- to improving
an open toolchain\'s codebase)

Have you tried to guesstimate the effort required to port DPS to
another processor? (genuine question as I\'ve not delved into
your code enough to understand it\'s \"assumptions\")

 

[Phil Hobbs]

Tom Del Rosso wrote:

Phil Hobbs wrote:
Tom Del Rosso wrote:

Google\'s OS and Apple\'s OS probably wouldn\'t allow it. If more people
had Linux phones it could be done, but they cost around $800 which
gives an idea how much Google and Apple make from your phone.



Nah, you can get a Pinephone for $200.

Wow. I only looked at the high end with switches to power off
components.

I have a Pinephone Beta and an early Pinephone tout court (not Pro).
Both have the dip switches.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[Tom Del Rosso]

Phil Hobbs wrote:

Tom Del Rosso wrote:
Phil Hobbs wrote:
Tom Del Rosso wrote:

Google\'s OS and Apple\'s OS probably wouldn\'t allow it. If more
people had Linux phones it could be done, but they cost around
$800 which gives an idea how much Google and Apple make from your
phone.

Nah, you can get a Pinephone for $200.

Wow. I only looked at the high end with switches to power off
components.


I have a Pinephone Beta and an early Pinephone tout court (not Pro).
Both have the dip switches.

On the models I was looking at, there were slide switches on the side,
not DIP switches.


--
Defund the Thought Police
Andiamo Brandon!

 

[Dimiter_Popoff]

On 1/10/2022 3:00, Don Y wrote:

On 1/9/2022 3:26 PM, Dimiter_Popoff wrote:
On 1/10/2022 0:06, Don Y wrote:

You stick with what you already have/had -- insofar as it is able
to meet your ongoing needs.

Or, embrace more \"open\" offerings... often with the need to make some
commitment (time or money) to ensuring their continued availability,
development, etc.

(Too often, folks buy into FOSS for $0 -- thinking it \"free\" and not
realizing that it can go away just as easily, without support, as
any other offering!)

Well we have dps for power only but it comes with everything necessary
to do all the software for pretty sophisticated products without needing
a single bit of software from anyone else.

This is the approach I\'ve taken with all of my projects -- even if the
toolchain had to be purchased, commercially (it will still function
years later -- albeit without potential updates).

And, if you avoid \"exotic\" hardware/components, you can usually avoid
any dependence on particular suppliers (alas, the days of multiple
second-sources are long gone but you can still minimize the effort
involved in \"porting\" a design to a different BoM).

How does product lifetime licensing sound?

That\'s what you have when you own the technology.  Many folks now
*can* have this by adopting open toolchains AND SUPPORTING THEM
(as most folks aren\'t interested in building tools from scratch but
*can* contribute -- bug reports, test cases, etc. -- to improving
an open toolchain\'s codebase)

Have you tried to guesstimate the effort required to port DPS to
another processor?  (genuine question as I\'ve not delved into
your code enough to understand it\'s \"assumptions\")

It won\'t be a huge effort but there will be a performance hit for
ARM, not that much for MIPS. The hit won\'t be that huge anyway.
But at the moment I am finishing something I have started a few
years ago (and had to put on hold for scheduling reasons), it started
as a file browser and is becoming an \"object browser\", fingers crossed
it won\'t take much longer (getting back into it took nearly a month).
So porting is not directly on the agenda, not yet anyway.

 

[Carlos E.R.]

On 08/01/2022 20.17, legg wrote:

On Sat, 8 Jan 2022 08:56:33 -0800 (PST), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 8. januar 2022 kl. 16.33.18 UTC+1 skrev legg:
On Sat, 08 Jan 2022 14:18:24 +0100, Jeroen Belleman
jer...@nospam.please> wrote:

For years, interaction with the internet worked through a
universal browser. Lately, every service, gadget or whatnot
wants you to download their special-purpose app. Why??
What\'s the deal? It seems like a huge step backwards to me.

Jeroen Belleman
Have been trying to get an Android OS running on a PC,
just in order to communicate with hardware using a
bluetooth link - which is what mfr app provides.

Android cannot recognize, access or use most of
PC hardware, to do this. Complete flop.

Android not ready for anything other than use as toy.

there are 3 billion active Android devices ...


The option of buying an android tablet and setting it
up to run the app seems the only current alternative.

Why? because Google doesn\'t want to do the work of
creating a real OS. Revenue from toys id apparently
enough.

There is no reason at all why they would want to do that. It is an OS
designed to run on phones and tablets, not computers. And in that role
it is king.


--
Cheers, Carlos.

 

[Carlos E.R.]

On 08/01/2022 14.18, Jeroen Belleman wrote:

For years, interaction with the internet worked through a
universal browser. Lately, every service, gadget or whatnot
wants you to download their special-purpose app. Why??
What\'s the deal? It seems like a huge step backwards to me.

Not being limited by the browser.

For example, a radio station promotes their own app to listen to that
station. To make it run, you have to login, so they have you pinpointed.
Once there, you can not refuse their adverts. Your privacy is lost. Of
course, they also provide features to entice you and keep you in.

Even if you close the app, it can keep running in the background, and
for example, tell you that your favourite program is coming now.

--
Cheers, Carlos.

 

[Don Y]

On 1/10/2022 1:47 AM, Dimiter_Popoff wrote:

Have you tried to guesstimate the effort required to port DPS to
another processor? (genuine question as I\'ve not delved into
your code enough to understand it\'s \"assumptions\")

It won\'t be a huge effort but there will be a performance hit for
ARM, not that much for MIPS. The hit won\'t be that huge anyway.

What drives the efficiency aspect? My impression of your code
was that it abstracts a register-file based architecture (?); does
number (and color) of registers factor into how well it layers onto
a new platform?

But at the moment I am finishing something I have started a few
years ago (and had to put on hold for scheduling reasons), it started
as a file browser and is becoming an \"object browser\", fingers crossed
it won\'t take much longer (getting back into it took nearly a month).

For development use? Or, just as a general utility?

I tried to avoid building many tools for my system -- beyond ones that
let me watch transactions across multiple processors (e.g., flatten
RPCs so they look like simple function calls -- though annotated with
system timestamps and related metrics). Here, that\'s the toughest
aspect of debugging to wrap your head around (as the actual function
isn\'t executing on the node that initiates it so watching execution is
problematic).

And, a simple monitor that lets me attach a console to a node and step
through code, pull down binaries over the network, check clock
synchronization, etc. \"Old tech\" :>

> So porting is not directly on the agenda, not yet anyway.

\"Agenda\"? What\'s that?! :>

[I\'ve some other questions but probably not suitable to ask in a
public forum. I\'ll drop you a line when I get all my immediate
\"issues\" behind me...]

 

[Dimiter_Popoff]

On 1/10/2022 12:56, Don Y wrote:

On 1/10/2022 1:47 AM, Dimiter_Popoff wrote:
Have you tried to guesstimate the effort required to port DPS to
another processor?  (genuine question as I\'ve not delved into
your code enough to understand it\'s \"assumptions\")

It won\'t be a huge effort but there will be a performance hit for
ARM, not that much for MIPS. The hit won\'t be that huge anyway.

What drives the efficiency aspect?  My impression of your code
was that it abstracts a register-file based architecture (?); does
number (and color) of registers factor into how well it layers onto
a new platform?

Mainly the number of registers, much of the code thinks 32 registers
(r0-r31, d0-d7 are r8-r15, a0-a7 are r16-r23, a7 being the SP by
convention). Now I first use do-d7 a0-a5 (a6 usually holds the top
of the current stack frame), in the 68340 days I had only these
anyway, then I resort to r24-r31 as needed, r0-r3 have meanwhile
some specialized use (mapping them in memory would mean almost
no efficiency hit though - I think). r4-r7 are volatile on a per
source statement basis, used to calculate effective address etc.
Another aspect is the endianness, if the core cannot do both
accesses, especially big endian, this will cost something, too.
But the code is so compact and efficient things will still be
way better than a compiler output for something written in a
high level language.

But at the moment I am finishing something I have started a few
years ago (and had to put on hold for scheduling reasons), it started
as a file browser and is becoming an \"object browser\", fingers crossed
it won\'t take much longer (getting back into it took nearly a month).

For development use?  Or, just as a general utility?

Mostly as a general utility for the users, people are used to see
something similar to windows explorer etc. Only this is becoming
very flexible/expandable, being based on dps objects (which are
runtime maintained, located etc., it is a largish thing and I
have spent well over a decade getting better and better at utilizing
it... never mind I have changed its basics very little since I
introduced it, wait, this was > 20 years ago, 1995-6 or so).

I tried to avoid building many tools for my system -- beyond ones that
let me watch transactions across multiple processors (e.g., flatten
RPCs so they look like simple function calls -- though annotated with
system timestamps and related metrics).  Here, that\'s the toughest
aspect of debugging to wrap your head around (as the actual function
isn\'t executing on the node that initiates it so watching execution is
problematic).

I also do tooling \"on demand\", like everyone else I suppose.

And, a simple monitor that lets me attach a console to a node and step
through code, pull down binaries over the network, check clock
synchronization, etc.  \"Old tech\"  :

Oh I am using a monitor which is the basic part of the ROM like
forever, a new board still first comes up talking through an UART
(the flash being written to using boundary scan via jtag, never
had the details of the debug port beyond that, an NDA was not
enough for it and well, I can live without it anyway).
On a booted system it is the same monitor only the terminal is a
window via a \"link\" driver and a task entering the monitor
does not block the scheduler (but try to have a second task
exit to the monitor while the first one is in it and wait for
the reboot .
I made a (now pretty old) version of this monitor freely available,
there has been no huge crowd downloading it but from time to time
someone does. ( http://tgi-sci.com/tgi/download/m52.htm )

 

[Don Y]

On 1/10/2022 8:00 AM, Dimiter_Popoff wrote:

But at the moment I am finishing something I have started a few
years ago (and had to put on hold for scheduling reasons), it started
as a file browser and is becoming an \"object browser\", fingers crossed
it won\'t take much longer (getting back into it took nearly a month).

For development use? Or, just as a general utility?

Mostly as a general utility for the users, people are used to see
something similar to windows explorer etc. Only this is becoming
very flexible/expandable, being based on dps objects (which are
runtime maintained, located etc., it is a largish thing and I
have spent well over a decade getting better and better at utilizing
it... never mind I have changed its basics very little since I
introduced it, wait, this was > 20 years ago, 1995-6 or so).

Ah! I had a mistaken impression as to how the user interacts with
your instrument! I had assumed it was mainly a data collection
device and any real interaction/analysis was done on an attached
PC (even if that attachment was over the network).

I tried to avoid building many tools for my system -- beyond ones that
let me watch transactions across multiple processors (e.g., flatten
RPCs so they look like simple function calls -- though annotated with
system timestamps and related metrics). Here, that\'s the toughest
aspect of debugging to wrap your head around (as the actual function
isn\'t executing on the node that initiates it so watching execution is
problematic).

I also do tooling \"on demand\", like everyone else I suppose.

Yes, esp if your needs don\'t fit neatly with existing tools (or
design approaches)

And, a simple monitor that lets me attach a console to a node and step
through code, pull down binaries over the network, check clock
synchronization, etc. \"Old tech\" :

Oh I am using a monitor which is the basic part of the ROM like
forever, a new board still first comes up talking through an UART
(the flash being written to using boundary scan via jtag, never
had the details of the debug port beyond that, an NDA was not
enough for it and well, I can live without it anyway).

Likewise. In my case (on production hardware), the serial port
is just a set of pads that can be probed with the right \"accessory\"
(similar to many consumer devices -- except I don\'t \"dedicate\"
the I/Os to that purpose). If the monitor detects that accessory
as being present, then it configures the I/Os as necessary and then
spawns a console on that port (overriding any intended use for those
pins)

On a booted system it is the same monitor only the terminal is a
window via a \"link\" driver and a task entering the monitor
does not block the scheduler (but try to have a second task
exit to the monitor while the first one is in it and wait for
the reboot .

My monitor runs in several different modes. In single-threaded
mode it controls the processor exclusively -- sort of like the
monitors of decades past. This is primarily useful for bringing
up new I/O subsystems as I can peek and poke various bits of the
hardware without worrying about anything else running on
the board.

In multi-threaded mode, it (can) \"attaches\" to a process and
let the rest of the system operate normally while the attached
process is subject to the control of the monitor. This is more
useful in bringing up core services -- like debugging the
initial network stack (used before the OS and *its* stack is
loaded) -- as it lets other services on the node run that
the new service may rely upon (e.g., timing services).

Bootstrap is painfully complicated because the code all has
to be loaded over the wire. And, the boot ROM doesn\'t know
what I/Os are present on the local node. Plus, the whole
transaction has to be \"secure\" so a node can\'t be compromised.

And, because there is no user interface (other than an idiot light),
a node has to convey \"issues\" to the rest of the system indirectly
(and hope something else can get the user\'s attention).

E.g., after power is applied, the PSE expects a hardware handshake
in a certain short interval - else it will remove power (this to
safeguard against the processor being insane and the hardware
being in an indeterminate state -- you wouldn\'t want a mechanism
\"in motion\" because the hardware had faulted.

So, there are lots of \"baby steps\" between application of power and
the intended invocation of \"main()\".

I suspect I will remove the monitor functionality from the boot ROM
image as it is unlikely that anyone will ever try to debug (at that
level) in the field. In consumer applications, they\'ll just replace
a node thinking it to be \"defective\". In industrial and commercial
applications, they\'ll swap out a node as downtime isn\'t worth the
cost of diagnosis.

[And, I\'m not sure how vulnerable things would be if I left this
sort of \"back door\" in such an accessible place!]

I made a (now pretty old) version of this monitor freely available,
there has been no huge crowd downloading it but from time to time
someone does. ( http://tgi-sci.com/tgi/download/m52.htm )

My monitors have evolved from simple to incredibly complex (including
support for breakpoint and trace hardware before processors had
those abilities). And, now, back to simpler (with the exception of
things like support for VMM).

As with most things, old ideas become new and the cycle endlessly repeats.

 

[Don Y]

On 1/10/2022 3:55 AM, Carlos E.R. wrote:

On 08/01/2022 14.18, Jeroen Belleman wrote:
For years, interaction with the internet worked through a
universal browser. Lately, every service, gadget or whatnot
wants you to download their special-purpose app. Why??
What\'s the deal? It seems like a huge step backwards to me.

Not being limited by the browser.

For example, a radio station promotes their own app to listen to that station.
To make it run, you have to login, so they have you pinpointed. Once there, you
can not refuse their adverts. Your privacy is lost. Of course, they also
provide features to entice you and keep you in.

Using any device with it\'s own unique identifier (think MAC) means
your privacy is lost.

\"I\" may not know who you are, today, when I encounter your \"identifier\".
But, if I kabitz with others -- esp places where you are likely to identify
yourself directly (like a login/UID) or indirectly (like making a credit card
purchase) -- then the identifiers can be correlated and augmented, over time.

Amazon, ebay, google, etc. all \"recognize\" me even without logging in.
Even if I *never* log in! Because they can see my IP, fingerprint my
browser, etc.

So, when/if I ever *do* make a purchase (or otherwise identify myself),
they can now *add* my identity to the past observations they have made
about my interests, activities, etc.

Even if you close the app, it can keep running in the background, and for
example, tell you that your favourite program is coming now.

You can do the same with a browser. But, it is a considerably heavier
weight process -- because it has to cover more contingencies -- than an
app using (ONLY) the resources that it needs for given functionality.

 

[Dimiter_Popoff]

On 1/10/2022 20:30, Don Y wrote:

On 1/10/2022 8:00 AM, Dimiter_Popoff wrote:
But at the moment I am finishing something I have started a few
years ago (and had to put on hold for scheduling reasons), it started
as a file browser and is becoming an \"object browser\", fingers crossed
it won\'t take much longer (getting back into it took nearly a month).

For development use?  Or, just as a general utility?

Mostly as a general utility for the users, people are used to see
something similar to windows explorer etc. Only this is becoming
very flexible/expandable, being based on dps objects (which are
runtime maintained, located etc., it is a largish thing and I
have spent well over a decade getting better and better at utilizing
it... never mind I have changed its basics very little since I
introduced it, wait, this was > 20 years ago, 1995-6 or so).

Ah!  I had a mistaken impression as to how the user interacts with
your instrument!  I had assumed it was mainly a data collection
device and any real interaction/analysis was done on an attached
PC (even if that attachment was over the network).

Oh no, the user gets a screen of dps on a display, with the netMCA
this is on a PC etc. via VNC (like a remote desktop) as the netMCA has
no display controller - but it does maintain a framebuffer in system
memory all right.

http://tgi-sci.com/tgi/wwwfront.gif <- 3 netMCA-s via VNC on a PC
http://tgi-sci.com/tgi/pnfrxx.gif <- with own display (around y. 2002)
http://tgi-sci.com/tgi/fr64.gif <- earlier (pre-2000).

I never wanted to work on software running under anyone\'s OS but
mine - for reasons we both mentioned earlier - so even the first TGI
product had its version of dps and MCA software, no PC needed at all
(last link above, with mono display, no TFT back then).

I still do have the file browser from that time which is
good enough for use with 8.4 names (the only type of directories
dps supported until some 10 years ago, now it does also up to 255 byte
long names). Not a \"windows explorer\" but you can load/save a
spectrum easily, will prompt you if you have typed in a unique
name beginning etc., has been around since 1995 or so.
http://tgi-sci.com/misc/fbr.gif <- just did a shot, 1995 was mono.

On a booted system it is the same monitor only the terminal is a
window via a \"link\" driver and a task entering the monitor
does not block the scheduler (but try to have a second task
exit to the monitor while the first one is in it and wait for
the reboot .

My monitor runs in several different modes.  In single-threaded
mode it controls the processor exclusively -- sort of like the
monitors of decades past.  This is primarily useful for bringing
up new I/O subsystems as I can peek and poke various bits of the
hardware without worrying about anything else running on
the board.

In multi-threaded mode, it (can) \"attaches\" to a process and
let the rest of the system operate normally while the attached
process is subject to the control of the monitor.  This is more
useful in bringing up core services -- like debugging the
initial network stack (used before the OS and *its* stack is
loaded) -- as it lets other services on the node run that
the new service may rely upon (e.g., timing services).

So pretty much the same what my monitor does (mine is limited to
a single task at a time though, keeps the user registers in the same
locations etc.; while the entire monitor work area is changeable
by a single pointer - done so for this purpose nearly 30 years
ago - I never got around to do it... well, never really needed to,
the \"on demand\" thing came into play.

Bootstrap is painfully complicated because the code all has
to be loaded over the wire.  And, the boot ROM doesn\'t know
what I/Os are present on the local node.  Plus, the whole
transaction has to be \"secure\" so a node can\'t be compromised.
And, because there is no user interface (other than an idiot light),
a node has to convey \"issues\" to the rest of the system indirectly
(and hope something else can get the user\'s attention).

E.g., after power is applied, the PSE expects a hardware handshake
in a certain short interval - else it will remove power (this to
safeguard against the processor being insane and the hardware
being in an indeterminate state -- you wouldn\'t want a mechanism
\"in motion\" because the hardware had faulted.

So, there are lots of \"baby steps\" between application of power and
the intended invocation of \"main()\".

Debugging the boot process is the thing I most hate, especially
after not having had to do it for years (so I have forgotten
plenty of details).

I suspect I will remove the monitor functionality from the boot ROM
image as it is unlikely that anyone will ever try to debug (at that
level) in the field.  In consumer applications, they\'ll just replace
a node thinking it to be \"defective\".  In industrial and commercial
applications, they\'ll swap out a node as downtime isn\'t worth the
cost of diagnosis.

[And, I\'m not sure how vulnerable things would be if I left this
sort of \"back door\" in such an accessible place!]

The back door consideration makes sense but I would not remove it
just to not have it there. You never know what and when will end up at
your desk...

 

[Don Y]

On 1/10/2022 12:19 PM, Dimiter_Popoff wrote:

On 1/10/2022 20:30, Don Y wrote:
On 1/10/2022 8:00 AM, Dimiter_Popoff wrote:
But at the moment I am finishing something I have started a few
years ago (and had to put on hold for scheduling reasons), it started
as a file browser and is becoming an \"object browser\", fingers crossed
it won\'t take much longer (getting back into it took nearly a month).

For development use? Or, just as a general utility?

Mostly as a general utility for the users, people are used to see
something similar to windows explorer etc. Only this is becoming
very flexible/expandable, being based on dps objects (which are
runtime maintained, located etc., it is a largish thing and I
have spent well over a decade getting better and better at utilizing
it... never mind I have changed its basics very little since I
introduced it, wait, this was > 20 years ago, 1995-6 or so).

Ah! I had a mistaken impression as to how the user interacts with
your instrument! I had assumed it was mainly a data collection
device and any real interaction/analysis was done on an attached
PC (even if that attachment was over the network).

Oh no, the user gets a screen of dps on a display, with the netMCA
this is on a PC etc. via VNC (like a remote desktop) as the netMCA has
no display controller - but it does maintain a framebuffer in system
memory all right.

Yes, but I didn\'t think the user \"did work\" on the instrument.
I thought the display was just to coax it to \"do its thing\"
and review results. Anything beyond that would be handled
\"offline\".

http://tgi-sci.com/tgi/wwwfront.gif <- 3 netMCA-s via VNC on a PC
http://tgi-sci.com/tgi/pnfrxx.gif <- with own display (around y. 2002)

Was the case a \"custom\"? Or, something you found COTS?

> http://tgi-sci.com/tgi/fr64.gif <- earlier (pre-2000).

The probe looks like Q-bert:
<http://images3.wikia.nocookie.net/__cb20130323030456/wreckitralph/images/5/5e/Qbert.png>

[Which reminds me to rewatch _Pixels_... maybe tonight!]

I never wanted to work on software running under anyone\'s OS but
mine - for reasons we both mentioned earlier - so even the first TGI
product had its version of dps and MCA software, no PC needed at all
(last link above, with mono display, no TFT back then).

I still do have the file browser from that time which is
good enough for use with 8.4 names (the only type of directories
dps supported until some 10 years ago, now it does also up to 255 byte
long names). Not a \"windows explorer\" but you can load/save a
spectrum easily, will prompt you if you have typed in a unique
name beginning etc., has been around since 1995 or so.
http://tgi-sci.com/misc/fbr.gif <- just did a shot, 1995 was mono.

On a booted system it is the same monitor only the terminal is a
window via a \"link\" driver and a task entering the monitor
does not block the scheduler (but try to have a second task
exit to the monitor while the first one is in it and wait for
the reboot .

My monitor runs in several different modes. In single-threaded
mode it controls the processor exclusively -- sort of like the
monitors of decades past. This is primarily useful for bringing
up new I/O subsystems as I can peek and poke various bits of the
hardware without worrying about anything else running on
the board.

In multi-threaded mode, it (can) \"attaches\" to a process and
let the rest of the system operate normally while the attached
process is subject to the control of the monitor. This is more
useful in bringing up core services -- like debugging the
initial network stack (used before the OS and *its* stack is
loaded) -- as it lets other services on the node run that
the new service may rely upon (e.g., timing services).

So pretty much the same what my monitor does (mine is limited to
a single task at a time though, keeps the user registers in the same
locations etc.; while the entire monitor work area is changeable
by a single pointer - done so for this purpose nearly 30 years
ago - I never got around to do it... well, never really needed to,
the \"on demand\" thing came into play.

In practice, you really only need to deal with one process at a time
AS A MONITOR. If you\'re trying to debug \"real\" code, I rely on a more
capable set of tools (with a PC hosting them).

But, I learned from early projects that there is a lot of value
to being able to \"hot patch\" a system in development. Esp if
the system executes out of RAM.

Bootstrap is painfully complicated because the code all has
to be loaded over the wire. And, the boot ROM doesn\'t know
what I/Os are present on the local node. Plus, the whole
transaction has to be \"secure\" so a node can\'t be compromised.
And, because there is no user interface (other than an idiot light),
a node has to convey \"issues\" to the rest of the system indirectly
(and hope something else can get the user\'s attention).

E.g., after power is applied, the PSE expects a hardware handshake
in a certain short interval - else it will remove power (this to
safeguard against the processor being insane and the hardware
being in an indeterminate state -- you wouldn\'t want a mechanism
\"in motion\" because the hardware had faulted.

So, there are lots of \"baby steps\" between application of power and
the intended invocation of \"main()\".

Debugging the boot process is the thing I most hate, especially
after not having had to do it for years (so I have forgotten
plenty of details).

Booting the processor module is relatively straightforward
(CPU, ROM, RAM, NIC, internal I/Os). And, knowing how large
a \"bite\" to take in each step is now second nature (e.g.,
can\'t use RAM until you know it works; can\'t use ROM
until you know it\'s not been corrupted; etc.)

But, each node can have any number of I/O modules attached
(same boot rom in the processor module). So, the CPU has to
probe the I/O \"space\" and identify the modules that are
present on *this* node (without powering them up!). Then,
issue a request to the database server for the appropriate
\"boot rom\" for each of those modules... run POST on them,
etc.

Only when all of that is done can the OS be loaded. And,
then whatever applications the system wants hosted on that
node. (but, once the OS is in place, there are lots of
services that can make life easier)

I suspect I will remove the monitor functionality from the boot ROM
image as it is unlikely that anyone will ever try to debug (at that
level) in the field. In consumer applications, they\'ll just replace
a node thinking it to be \"defective\". In industrial and commercial
applications, they\'ll swap out a node as downtime isn\'t worth the
cost of diagnosis.

[And, I\'m not sure how vulnerable things would be if I left this
sort of \"back door\" in such an accessible place!]

The back door consideration makes sense but I would not remove it
just to not have it there. You never know what and when will end up at
your desk...

I won\'t have to support this so, from a personal perspective, it buys
me nothing to leave it in place (I could always replace the CPU module
on a given node with one that has a \"fleshier\" ROM image, in a pinch).

I just don\'t like leaving what is essentially \"dead code\" in a product.
Esp if the product is trying to be secure. (one more potential
attack surface to analyze)

There\'s some protection from abuse as the monitor doesn\'t activate unless it
recognizes particular hardware \"bolted on\". But, that\'s security-by-obscurity
(never to be trusted).

 

[Dimiter_Popoff]

On 1/10/2022 23:55, Don Y wrote:

On 1/10/2022 12:19 PM, Dimiter_Popoff wrote:
On 1/10/2022 20:30, Don Y wrote:
On 1/10/2022 8:00 AM, Dimiter_Popoff wrote:
But at the moment I am finishing something I have started a few
years ago (and had to put on hold for scheduling reasons), it started
as a file browser and is becoming an \"object browser\", fingers
crossed
it won\'t take much longer (getting back into it took nearly a month).

For development use?  Or, just as a general utility?

Mostly as a general utility for the users, people are used to see
something similar to windows explorer etc. Only this is becoming
very flexible/expandable, being based on dps objects (which are
runtime maintained, located etc., it is a largish thing and I
have spent well over a decade getting better and better at utilizing
it... never mind I have changed its basics very little since I
introduced it, wait, this was > 20 years ago, 1995-6 or so).

Ah!  I had a mistaken impression as to how the user interacts with
your instrument!  I had assumed it was mainly a data collection
device and any real interaction/analysis was done on an attached
PC (even if that attachment was over the network).

Oh no, the user gets a screen of dps on a display, with the netMCA
this is on a PC etc. via VNC (like a remote desktop) as the netMCA has
no display controller - but it does maintain a framebuffer in system
memory all right.

Yes, but I didn\'t think the user \"did work\" on the instrument.
I thought the display was just to coax it to \"do its thing\"
and review results.  Anything beyond that would be handled
\"offline\".

http://tgi-sci.com/tgi/wwwfront.gif <- 3 netMCA-s via VNC on a PC
http://tgi-sci.com/tgi/pnfrxx.gif <- with own display (around y. 2002)

Was the case a \"custom\"?  Or, something you found COTS?

It was a \"custom\". Ventso (the father of my niece) made both cases
you saw, pretty much handmade. Incredible guy.
Died in January 2018 aged 66, just dropped dead in the street.
I hope I\'ll manage to repeat that when my time comes, drop while
still active, like him.

https://www.flickr.com/photos/didi_tgi/43422741851/in/album-72157698828238075/

....

Booting the processor module is relatively straightforward
(CPU, ROM, RAM, NIC, internal I/Os).  And, knowing how large
a \"bite\" to take in each step is now second nature (e.g.,
can\'t use RAM until you know it works; can\'t use ROM
until you know it\'s not been corrupted; etc.)

Hah, we have a language issue here . To me this is \"coming
out of reset\", it goes into the monitor and stays there or
boots the OS automatically from disk (a bit in an eeprom called
autoboot); if it autoboots it gives you a chance for 2 seconds
to press escape and still go to the monitor (and perhaps boot
from some device/partition other than the default found in
the eeprom).
IOW, to me \"boot\" is about starting the OS, the thing before
that is \"reset\".
The part I hate to debug is exactly this boot process, when you
still don\'t have the OS running but you are starting it,
many addresses are still unknown etc., memory paging is being
setup etc.

> ....

 

[Don Y]

On 1/10/2022 3:55 PM, Dimiter_Popoff wrote:

On 1/10/2022 23:55, Don Y wrote:
On 1/10/2022 12:19 PM, Dimiter_Popoff wrote:
On 1/10/2022 20:30, Don Y wrote:
On 1/10/2022 8:00 AM, Dimiter_Popoff wrote:
But at the moment I am finishing something I have started a few
years ago (and had to put on hold for scheduling reasons), it started
as a file browser and is becoming an \"object browser\", fingers crossed
it won\'t take much longer (getting back into it took nearly a month).

For development use? Or, just as a general utility?

Mostly as a general utility for the users, people are used to see
something similar to windows explorer etc. Only this is becoming
very flexible/expandable, being based on dps objects (which are
runtime maintained, located etc., it is a largish thing and I
have spent well over a decade getting better and better at utilizing
it... never mind I have changed its basics very little since I
introduced it, wait, this was > 20 years ago, 1995-6 or so).

Ah! I had a mistaken impression as to how the user interacts with
your instrument! I had assumed it was mainly a data collection
device and any real interaction/analysis was done on an attached
PC (even if that attachment was over the network).

Oh no, the user gets a screen of dps on a display, with the netMCA
this is on a PC etc. via VNC (like a remote desktop) as the netMCA has
no display controller - but it does maintain a framebuffer in system
memory all right.

Yes, but I didn\'t think the user \"did work\" on the instrument.
I thought the display was just to coax it to \"do its thing\"
and review results. Anything beyond that would be handled
\"offline\".

http://tgi-sci.com/tgi/wwwfront.gif <- 3 netMCA-s via VNC on a PC
http://tgi-sci.com/tgi/pnfrxx.gif <- with own display (around y. 2002)

Was the case a \"custom\"? Or, something you found COTS?

It was a \"custom\". Ventso (the father of my niece) made both cases
you saw, pretty much handmade. Incredible guy.

Impressive.

Died in January 2018 aged 66, just dropped dead in the street.
I hope I\'ll manage to repeat that when my time comes, drop while
still active, like him.

https://www.flickr.com/photos/didi_tgi/43422741851/in/album-72157698828238075/

....

Booting the processor module is relatively straightforward
(CPU, ROM, RAM, NIC, internal I/Os). And, knowing how large
a \"bite\" to take in each step is now second nature (e.g.,
can\'t use RAM until you know it works; can\'t use ROM
until you know it\'s not been corrupted; etc.)

Hah, we have a language issue here . To me this is \"coming
out of reset\",

There are different OS\'s running at different times in the
boot process.

\"Coming out of reset\" is purely a bare-metal event. Nothing
is known about the state of the hardware.

I first reset the \"field\" (the attached IOs) to ensure that,
if no other instruction executes, it will be driven to a safe
state. Then, I reset the processor.

Then, verify integrity of ROM -- before using *more* ROM
to perform other tests (like checking the RAM, etc.).

Once the \"CPU module\'s resources\" are known to be operational,
I set up a small/fast RTOS that lets me use those to probe the
I/O space to determine which modules are present, here (with
the RTOS, I can now rely on things like timers and alternate
threads to perform these tests).

Part of that process is probe()ing for the monitor hardware. If
it is not detected, then that code is never activated. No
*way* to interrupt the boot process if you physically don\'t
have the monitor hardware to provide an interface to a human! :>

And, I can bring up the initial network stack to contact the
database server (which acts as my filesystem) to load the POST
routines for the modules that have been detected. POST doesn\'t
require the advanced features of the real RTOS -- and wants to
be relatively static over the life of the product -- so it
can run on the streamlined RTOS more deterministically.

Eventually, I can load the real RTOS from the RDBMS and start
to resemble a functional node.

[If I can\'t access the RDBMS or the real RTOS is unavailable,
I can still react to the system but can\'t participate in
its activities (because the \"real\" services rely on the
real RTOS)]

At this point, I can load the BIST (which runs on the real RTOS
as it has to be able to operate while the application is running)
to provide advanced diagnostics to the rest of the system so *it*
can decide what parts of my functionality it wants to use, or
make note of for later use. (a node sits idle, running diagnostics,
until the system has a need for its resources *or* powers it down
so it acts as a \"warm spare\")

it goes into the monitor and stays there or
boots the OS automatically from disk (a bit in an eeprom called
autoboot); if it autoboots it gives you a chance for 2 seconds
to press escape and still go to the monitor (and perhaps boot
from some device/partition other than the default found in
the eeprom).
IOW, to me \"boot\" is about starting the OS, the thing before
that is \"reset\".

My nodes \"do things\" before the (real) OS is up because the
real OS isn\'t \"locally\" accessible. I wouldn\'t want to have to
keep running on bare metal just because the *real* RTOS isn\'t
loadable. E.g., it\'s a much nicer environment to be able
to run the network stack *alongside* the code that is trying
to fetch the RTOS image instead of having to do these in
sequential code.

Likewise, with the real RTOS already running, the system can
migrate any process to the node with a single system call so
there\'s no real need to \"load\" an application. It\'s more
like another (set of) cores coming online, suddenly, and
the workload manager becoming aware of the availability of
those resources.

The part I hate to debug is exactly this boot process, when you
still don\'t have the OS running but you are starting it,
many addresses are still unknown etc., memory paging is being
setup etc.

Yes. That\'s the value of the monitor in development. You can
verify the values that you *think* need to be poked into the
PMMU and actually see if they work properly. In ages past,
you might have a real ICE to do this interactively on a
desktop. The monitor is just a poor-man\'s alternative.

All of that has to be known to work before I can load the real
RTOS. So, I want as rich an environment as possible *before*
loading the RTOS to make that determination easier.

 

[server]

Dimiter_Popoff <dp@tgi-sci.com> wrote in news:sridg9$ls1$1@dont-
email.me:

Died in January 2018 aged 66, just dropped dead in the street.
I hope I\'ll manage to repeat that when my time comes, drop while
still active, like him.

I just hope it doesn\'t hurt and that I don\'t poop all over the place.
Not that I should care anyway.

 

[Ian]

On 2022-01-08, Jeroen Belleman <jeroen@nospam.please> wrote:

For years, interaction with the internet worked through a
universal browser. Lately, every service, gadget or whatnot
wants you to download their special-purpose app. Why??
What\'s the deal? It seems like a huge step backwards to me.

Jeroen Belleman

Do you want us to send you a brochure (browser), or shall we
send someone round to hand you the brochure and search through
your house while you\'re reading it, to see what else we can sell
you (app)?

</cynical>

--
Ian

\"Tamahome!!!\" - \"Miaka!!!\"

 

[Jeroen Belleman]

On 2022-01-11 10:16, Ian wrote:

On 2022-01-08, Jeroen Belleman <jeroen@nospam.please> wrote:
For years, interaction with the internet worked through a
universal browser. Lately, every service, gadget or whatnot
wants you to download their special-purpose app. Why??
What\'s the deal? It seems like a huge step backwards to me.

Jeroen Belleman

Do you want us to send you a brochure (browser), or shall we
send someone round to hand you the brochure and search through
your house while you\'re reading it, to see what else we can sell
you (app)?

/cynical

I don\'t even have a smart phone, so myself, I\'m not at risk.
However, it\'s quite clear that more and more things are
done through smart phone apps. (Covid vaccination certificates,
access to e-banking, on-line payments, to mention just a few
that have harassed me lately.)

Jeroen Belleman

 

[Jeff Layman]

On 08/01/2022 23:17, Don Y wrote:

It is amusing that no one has developed a sandbox that you can interpose
between any/every app and your actual resources. This would allow
the user to see *which* resources are ACTUALLY being accessed as well
as allowing you to \"dummy up\" some bogus resources to appease/confuse
the app.

<https://netguard.me/>

--

Jeff

 

[Don Y]

On 1/11/2022 3:53 AM, Jeff Layman wrote:

On 08/01/2022 23:17, Don Y wrote:

It is amusing that no one has developed a sandbox that you can interpose
between any/every app and your actual resources. This would allow
the user to see *which* resources are ACTUALLY being accessed as well
as allowing you to \"dummy up\" some bogus resources to appease/confuse
the app.

https://netguard.me/

That addresses a different problem (and I\'m not sure it does so
comprehensively).

What I think would be more useful is a filter that lets existing
resources masquerade as something else.

So, your GPS location is reported as
\"Oval Office, White House, Washington, D.C.\"
regardless of where you are actually located -- but, only for application X.
For application Y, it may report a completely random (lat,lon).
And, for application Z, it may report the truth.

Likewise, your contacts listed as \"Mickey Mouse, Goofy, Pluto\" for
application X but \"Fred, Barney, Wilma, Betty\" for application Y.

The list of installed apps reported as \"NONE\" for application X
but a truthful disclosure for application Y and a fanciful list for Z
(that doesn\'t include Z in that list! sort that one out, Z-developer!)

Etc.

You\'d still need to add a number of active and conditional hooks to take
actions that you\'d likely be too undisciplined to take consistently
(e.g., turn off BT and WiFi when near the following locations -- so
infrastructure in those locations can\'t \"see\" your phone).

The System is gamed against the user if privacy is a goal. \"The only
winning move is not to play\".