Registered: Sep 1999
Location: Burlington, VT, USA
Posts: 127

Okay, I posted this over in the general topic, but it's more appropriate here.

I'd love to see a CompactFlash Springboard. I have two 4MB CompactFlash cards I don't really use since upgrading my digital camera. Plus it'd be nice to be able to pop in my camera's CompactFlash card and view images in 16-shade grey.

Here's the original post:

Given that the Springboard slot is more or less electrically equivalent to a PCMCIA Type 2 slot, and that the CompactFlash interface is a subset of the PCMCIA standard, it seems to me that it would be relatively simple to to create a CompactFlash Springboard for the Visor, for Microdrives and similar devices.
You'd put a set of drivers to handle the most common CompactFlash devices on the Springboard's ROM. If TRG would cooperate with creating a standard, you could probably even use the same drivers as the TRGPro for any devices NOT handled by the ROM drivers.

The electronics would be pretty simple in this Springboard -- excluding the driver ROMs, it'd probably be very similar to those $15 adapters that let you plug your digital camera flashcards into your laptop's PCMCIA slot.

If such a Springboard comes to be made (and it certainly seems a logical and easy-to-design device), then the Visor would be the more flexible solution than the TRGPro, given that it would be able to use CompactFlash *and* Springboards.

Registered: Sep 1999
Location:
Posts: 81

If TRG would cooperate with creating a standard, you could probably even use the same drivers as the TRGPro for any devices NOT handled by the ROM drivers.
...
If such a Springboard comes to be made (and it certainly seems a logical and easy-to-design device), then the Visor would be the more flexible solution than the TRGPro, given that it would be able to use CompactFlash *and* Springboards.


Sounds like a great idea to me, though you may have trouble convincing TRG to cooperate in something that might hurt sales of the TRGpro.

Registered: Oct 1999
Location: Clinton, UT 84015
Posts: 71

Personally, I would love to see a CF Springboard. I have a 30 Meg CF memory card I would love to use. I can't use it, since my Casio E-11 bit the dust.

Registered: Oct 1999
Location: Sydney, Australia
Posts: 42

Mmm! Some solid state memory would be great. T'would save you buying the backup module and be more useful besides!

M.

Registered: Sep 1999
Location:
Posts: 27

quote:

---

If TRG would cooperate with creating a standard, you could probably even use the same drivers as the TRGPro for any devices NOT handled by the ROM drivers.

---

Registered: Oct 1999
Location: Missississauga, ON, CA
Posts: 2

hmm, doesn't the Palm OS only support addressing memory up to 12megs? or did Handspring change something that would allow it to address more memory from the springboard? hmm, i guess it has to work, since the MiniJamm (or whatever, sorry) mp3 player will be using 32/64/etc meg cards....

Registered: Oct 1999
Location:
Posts: 103

Think hotsync .... the hotsync has unlimited size... as I understand it the hotsync is "wired" thru the springboard slot thats why the larger memory sizes are able to be "virtualy" addressed. Unfortunately the palm OS and hardware archetecture has not progressed past the phase where more than ( As I understand it)12 megs of ram are addressable .


[This message has been edited by Bane (edited 10-20-1999).]

Registered: Oct 1999
Location: Clinton, UT 84015
Posts: 71

orKID,

When dealing with Springboards, you must keep in mind the board may contain its own processor.

In the case of an MP3 player, it will certainly keep its own processor and will nopt be available to the Visor.

Thomas

Registered: Sep 1999
Location:
Posts: 27

There was a very good post somewhere around here about how the memory limitation is it an I/O chip used with the Dragonball processors, not the PalmOS itself and that this limitation can easily be overcome using page swapping, similar to how your Windows/Mac/Linux box has swap space and virtual memory sources.

I wouldn't worry too much, I'm sure they have a way around the memory limitation ... if they didn't, they'd be wasting their time on the springboard slot (and TRG would be wasting their time doing a CF enabled palm.)

------------------
Wes Salmon
PDA Buzz Guy
www.pdabuzz.com

Registered: Sep 1999
Location: VA, USA
Posts: 27

The DragonBallEZ doesn't use another chip for memory I/O (or most other I/O either!). that's part of why it is popular for low cost and compact applications.

It does have a limited number of chipselect lines (which basically stear memory accesses to a device, like a ROM/FLASH or RAM, or the springboard). I think it has four, but I don't know for sure, would have to look at the databook to be sure (Mot's link is scrod, I can see the databook entries at http://www.mot.com/SPS/WIRELESS/doc...tion/index.html but I can't get to them).

The springboard gets two of them, I assume the RAM gets one, and the OS/app ROM gets the other.

Each can address 16M (24 address pins). So the CPU can see 32M on a springboard with ease. You could do more by say using one 16M space to select the other (bank switching, ask an Apple II programmer). It is unplesent for many tasks, but could be mostly transparent for others (like holing applications for the Launcher, or DB files the OS copies into "real RAM" when they are accessed by an application).

I think the real reason handspring used two chipselects for the springboard is so one can easally be used for the (FLASH?) ROM holding the application, and the other for talking to the hardware, avoiding the need to select on the address pins, making each springboard a tiny bit cheeper.

As for PalmOS itself it handles as many memory "slots" (or maybe they call it "cards") as you could ever possably stuff into a device (thousands). Each one can be independently inserted and removed (not that any PalmOS platform prior to the Visor actually did that!). Each is limited to 16M, but I don't think there is a deep meaning for that (i.e. they don't give you a 32bit "pointer" with 9 bits used for something else). Even if it could only support 16M per "card" any physical device could just appear as multiple cards to the software anyway.

There, that sure was long winded :-)