>Another idea - and yes, I know how far out _this_ is.....<deep breath>
>I have a Nokia 8810. Data comms via IR only. Ability to act as a
>modem - but in 'software'
>only on the PC (or WINCE device..).
>As stated, Smartdog don't think they're ever likely to get Newt to
>talk data with an IR
>phone.
>BUT - we have a 'modem' slot in a 2x00. What chances of building an
>EPROM that (either)
>software-modems OR is a hardware modem and in either case 'directly'
>accesses the IR port?
>My thought is to 'trick' the NOS into thinking a 'normal' modem is
>attached to the second
>(unused) serial port and use a hardware implementation to do the
>'talking' via IR.
>Any thoughts? - or is this just way too big a step?
Sorry to say that, but it's the third time I read your message, and I
still think that you are misunderstanding the problem.
The Newton has a IR output/input. This is hardware.
Hardware interfaces with software the following way: a software only
read/write data to memory and CPU registers. Usually, the hardware is
reached by reading and/or writing to memory, because there is a
decoding address system on the bus.
(OK, I don't speak about MMU, but it is basically the same, you just
need to declare those addresses uncachable and indeed, this is what
the Newton does).
The Newtons have a special circuit (ASIC) for this decoding: the Runt
or the Voyager chipset. (haven't check for the Runt based Newtons,
but on the MP2x00/eMates, the StrongArm doesn't access the DRAM
directly but thru the Voyager).
The IR hardware is linked to this chip.
Therefore, if you want to use IR, you have to read/write at special
addresses. Fortunately, the system offers APIs to do that for you. On
the Newton (like on most systems), we have three levels for any
hardware like IR (for example, PCMCIA)
-> accessor: a hardware driver for basic operation reading/writing at
this level. It reads/writes at those addresses and offers commands
relatives to the hardware. It may pass the address to the second
layer or just be a wrapper. For PCMCIA this is the socket interface.
-> one or several function drivers. There are several for both IR and
PCMCIA. For IR, these are TVRemoteIRTool, TSniffIRTool, TSharpIRTool.
For PCMCIA these are Flash, Serial, Ethernet, ATA.
On the Newton it is a little more complex by the duality C++/NS. Some
of those APIs are available from NS, some are not.
-> a communication layer on top of that. You can specify that you
want IR or an Ethernet Card, but the calls will finally be the same.
Finally, you had application on top of that. Those may use the
communication layer or not. They rarely access the lowest level, but
it is possible. For example, the current ATA driver allows at NS
level to read/write sectors to the card. This is of no use except to
write handlers for foreign systems and will disapear from the NS
level but will remain accessible from the C++ level. (and be
documented).
Now, what you want is to talk to the Nokia. Hence, either the Newton
can at the lowest level talk at the lowest level of the Nokia phone,
or it cannot. If it can, well, then you will have to re-write part of
the upper layers depending on what works with the Nokia and what
doesn't. Let's show an example with ATA cards, a domain I know quite
well now.
The bottom layer is the socket. The Newton socket cannot do True IDE
AFAIK. But it can do PCMCIA standard (2, not 7 btw) accesses.
The next layer, we have (for PCMCIA) Flash, some Ethernet (for this,
it is a little more complex because of 'Newton Devices' aka Lantern),
and a driver, TATASimple. None of them work for ATA cards. (on the
contrary to what I hoped first and I probably wouldn't have started
the project if I hadn't discovered TATASimple and made the hypothesis
that it worked).
Therefore I had to write the TATADriver and TATACardHandler (those
work very fine today - sure, the TATADriver can be improved).
Next layer was the store handling. Unfortunately, it is based on
Flash (with some flags to process SRAMs or Internal Store). I cannot
interface with TATADriver and TATACardHandler, hence, alike there is
TFlashStore, I have to write TATAStore. This is the remaining part.
I can interface with the system making TATAStore a store. Once I have
done that, it is over, the system will take it as any kind of store
(although, I should ensure some extra things like registering as
store not as a package store). That's why I won't have any control on
the data handled there because a store never knows about soups,
entries, VBOs, etc. (I mean a TStore, the NS Store does, but this is
at another level).
However, I decided that a card may handle several store because if
you get a 1GB card, it won't do any good to the Newton to have a
single store on it. Therefore I wrote a mechanism to have several
stores (and foreign partitions) and the GUI to handle them: the
Newton will never use the standard store slip but a new one I made
screenshots of.
In any case, a ROM hack or EPROM hack won't help. It has nothing to
do with the modem port. What you can do is to add a second IR
interface, but I'm not sure at all it is required. What you need is
to rewrite some layers trying to write the smallest amount of code.
I hope I have been clear enough.
Regards,
Paul
-- P&M Consulting Newton Program http://www.pnm-consulting.com/newton/ *************************************** NewtonTalk brought to you by:EVOTE.COM -- the ESPN of politics on the Internet! All the players, all the news, and the hottest analysis and features (plus 'toons!) anywhere.... visit http://www.evote.com today!
*************************************** Need Subscribe/Unsubscribe info?
Visit the NewtonTalk section at http://www.planetnewton.com
This archive was generated by hypermail 2b29 : Fri Sep 01 2000 - 00:00:15 CDT