[openMSX-devel] [ openmsx-Feature Requests-1540929 ] Dynamical LEDs

[SourceForge.net <no...@so...>]

Feature Requests item #1540929, was opened at 2006-08-15 22:53
Message generated for change (Comment added) made by manuelbi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=421864&aid=1540929&group_id=38274

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General/misc
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Manuel Bilderbeek (manuelbi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dynamical LEDs

Initial Comment:
Currently, the LEDs are hardcoded in openMSX. But LEDs
are part of the MSX hardware and some hardware has
other types of LEDs than other. (E.g.: turboR vs.
Toshiba HX-10.)

We should put in the hardwareconfig.xml files what kind
of LEDs (and in what order they appear on the machine,
maybe) are on the hardware.

Also extensions can have hardware, so that floppy
drives, harddisks and CD-ROM players can have their own
LED.

There are several things to consider:
- positioning of the LEDs should be more dynamical
- what to do with order, also if there are LEDs from
inserted devices?
- LEDs can appear and disappear when devices are
removed or added
- LEDs have fixed images now (to show them). Maybe we
should keep those (maybe add a few for CD-ROM and HDD)
and have these as a fixed set of possible LED types?
- or, should we map different devices that use the same
type of LED on one single OSD LED for now, for version 0?

All in all, it doesn't seem too difficult to get this
right.

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

>Comment By: Manuel Bilderbeek (manuelbi)
Date: 2011-06-09 20:54

Message:
Another issue is that the LEDs may have different names on different
machines. A kana LED may be called "CODE" (e.g. VG 8000/8010) or "Pyc"
(Russian machines). So, this should also be configurable.

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

Comment By: Manuel Bilderbeek (manuelbi)
Date: 2006-08-17 11:00

Message:
Logged In: YES 
user_id=78178

Some LEDs depend on the machine. E.g. the Philips VG 8010
has a CODE LED (it's the same as the Kana LED on Japanese
machines, but it doesn't act as a toggle, IIRC).

In your line of thought: what do you do with LEDs that are
on the MSX itself anyway, like the POWER LED and the CAPS
LED? Maybe CAPS and KANA LEDs are part of the PPI or PSG device?
Note that not all machines have a POWER LED... (You can see
the power state anyway in openMSX, because of the snow effect.)

Anyway, I think we still need to configure the LEDs in the
hardwareconfig.xml, but they could be set at the device
sections. The POWER LED would then be global, I suppose.

About the order: you're right, but we could easily make an
order config optional. So, for turboR you might want to
override the order, because it's clear. For other machines
it's not so clear, so also not so important.

There is a demo that uses the turboR LEDs as a VU meter. For
that demo it is important that the order is correct.

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

Comment By: Maarten ter Huurne (mthuurne)
Date: 2006-08-16 00:54

Message:
Logged In: YES 
user_id=358343

Should the set of visible LEDs depend on the real machine 
or on the devices present? Since some of the proposed LEDs 
are external (CD-ROM and HDD), I think using the devices 
as a base makes more sense. If we do it that way, we don't 
really need to say anything about the LEDs in the 
hardwareconfig.xml, since the device implementations know 
which LEDs they control.

About the order of the LEDs: for a turbo R type case it's 
easy to determine the LED order. But what about CAPS LEDs 
that are located on the CAPS LOCK key, do we consider 
those left or right of the POWER LED? Also, the user may 
not be familiar with the real machine at all, so maybe it 
makes more sense to use the same order for all machines, 
so the order is consistent within openMSX.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=421864&aid=1540929&group_id=38274