>>>>> "MR" == M R Brown <mrbrown@0xd6.org> writes:

Jack> Sure.  So don't use their firmware.  The traditional way around
Jack> that particular dilemma is to develop other firmware that has
Jack> sufficient capabilities to match the needs of the device driver.

MR> Please point out a "traditional" situation where someone was
MR> forced to develop their own firmware for a completely proprietary
MR> device.

There is at least one device in my FreeBSD box that downloads
firmware, but I haven't bothered to examine the origins of the SCSI
host adapter development.  I don't think Adaptec said "here's our
proprietary data", but it's possible.

MR> Especially when it's an unknown, proprietary DSP (that only Sega
MR> and Conexant knows about).

Jack> It's a start.  If more is known about the hardware, then more
Jack> can be written to support it.  I'm not trying to be annoying
Jack> here, but it's possible that the chipset used by this modem
Jack> could have been used by another modem that's supported by
Jack> another free operating system like Linux if not by NetBSD
Jack> already.  If not, perhaps one related to this one has already
Jack> been done.

MR> It's a Conexant RP56LD.  It's entirely CPU-driven.  You can find
MR> useless hardware specs on the Conexant at their website.  The
MR> modem's interface to the G2 bus is via a Sega PLD, numbered
MR> 315-6137.  You can enable the modem by writing 0 (use 8- or 32-bit
MR> accesses) then 1 to 0xa0600480.  The modem IRQ is bit 2 of
MR> 0xa05f6904.  There is no detailed information *anywhere* on the
MR> PLD used to interface the modem.

Thank you for all the information.  

MR> Even if a driver does exist in Linux or NetBSD, it won't help you
MR> here.

How so?

MR> The modem will not be supported, by *any* non-licensed Sega
MR> software, period.

Jack> That's a rather pessimistic assertion, and it flies in the face
Jack> of the whole concept.  But whatever.

MR> Actually it's quite realistic.  Given the general uselessness of
MR> the modem, the fact that no one (even those with cursory info,
MR> like how to detect it and enable it) has stepped forward yet to
MR> take credit for cracking it, and the amount of man hours it would
MR> take to devise a firmware that could drive it, it's very safe to
MR> say it will never be supported.

I'm glad you feel safe saying that.

MR> Keep wishing though.  You want to paint a rosy picture about how
MR> we could derive modem support by doing X and Y, but if I asked you
MR> to commit to reverse-engineering modem-enabled software to prove
MR> me wrong, you wouldn't do it.  That's how I know it's not going to
MR> happen, because no one is willing to do it.  You can spout off
MR> about the theory of it getting done all night long, I know how it
MR> could get done, but the simple fact is, it won't - there's no
MR> point.

Of course I wouldn't commit to reverse-engineering the modem within a
time period.  I have *zero* personal experience with writing device
drivers, as I have mentioned.  While I am currently unemployed, my
girlfriend would prefer I spend more time looking for work than
learning how to make the Dreamcast do things she doesn't understand,
and I can't blame her.  While I will be looking into it for my own
curiosity, I don't have the experience to commit to having any actual
code written for this part of the project.  In addition, my lack of
desire to commit to providing code proves nothing from your
perspective.  My point is that saying there's no point is incorrect,
at least from one user's point of view.  I respect the fact that we
disagree.  I'm just not willing to argue with you.

[... useful information elided ...]

Watch for another post with more possibly useful information.

Jack.
-- 
Jack Twilley
jmt at twilley dot org
http colon slash slash www dot twilley dot org slash tilde jmt slash