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