news | articles | reviews | software | modules | accessories | discussion | faq | mobile | store
VisorCentral.com >> Discussion >> Visor Related >> Springboard Modules
???Any Memory Constraints for a Springboard module???

Post a New Thread | Post A Reply

  Last Thread   Next Thread
Author
Topic: ???Any Memory Constraints for a Springboard module???    
palmoser
Member

Registered: Sep 1999
Location: Cupertino, CA, USA
Posts: 7

Question

Would anybody out there know if there are any limitations on the size of a springboard module in terms of the memory that can be supported?
If I were to develop an app that is rather "fat" but does not need any memory on the Visor memory card would I be limited to 8MB or 32MB
The application will run on a springboard module with its own processor and memory but would use the LCD screen for user interaction. I don't know what it is yet but the possibilities are endless.

Sorry for the length of the message

PalmOS-er.

palmoser is offline Old Post 09-22-1999 11:13 PM
Click Here to See the Profile for palmoser Edit/Delete Message Reply w/Quote
john
Member

Registered: Sep 1999
Location: New Mexico, USA
Posts: 112

Post

***PalmOSer writes:

Would anybody out there know if there are any limitations on the size of a
springboard module in terms of the memory that can be supported?

*** get thee to the developer's kit, available by signup at www.handspring.com. There's 32M of address space reserved for a Springboard module.

If I were to develop an app that is rather "fat" but does not need any memory on
the Visor memory card would I be limited to 8MB or 32MB
The application will run on a springboard module with its own processor and
memory but would use the LCD screen for user interaction. I don't know what it is
yet but the possibilities are endless.

**** "The Springboard expansion slot provides a slave-only interface for expanding the capabilities of the main handheld unit"- from developers' kit.

**** I got my doubts as to whether you could throw another CPU into the mix. You can't address the screen directly from the Springboard I/O.

**** Your mileage may vary, but it doesn't look very multi-processor friendly. The Springboards hook right in to the main cpu bus, and (other than the sanctified interrupt) the cpu may not want to share nicely.



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

john

john is offline Old Post 09-22-1999 11:39 PM
Click Here to See the Profile for john Edit/Delete Message Reply w/Quote
Tiroth
Member

Registered: Sep 1999
Location: Urbana IL
Posts: 144

Lightbulb

Well, I could be mistaken, but I don't see why having an external processor would be a problem at all. You "hide" your CPU ops from the Visor and set up a memory window to communicate with it. If all you need is a GUI, then you could make yourself a springboard that connects to your PC, which is obviously a lot more hardware than any springboard will be. If this wasn't the case, there wouldn't be any way to do most of the planned springboards. Stuff like MP3 decoding requires robust floating point support, which the DragonBallEZ lacks.

Tiroth is offline Old Post 09-26-1999 10:34 PM
Click Here to See the Profile for Tiroth Edit/Delete Message Reply w/Quote
Briareos
Member

Registered: Sep 1999
Location:
Posts: 54

Post

The Innogear MP3 module is supposed to ship in a version with 64MB of RAM, FYI.

Briareos is offline Old Post 09-27-1999 12:15 PM
Click Here to See the Profile for Briareos Edit/Delete Message Reply w/Quote
ToolkiT
VisorCentral Staff

Registered: Sep 1999
Location: Sydney Australia
Posts: 1883

Post

yeah, but that memmory will probably only be used by the MP3 module and not the Visor itself...

So I think 32Mb will be the max...unless you bypass the Visor's CPU...

ToolkiT is offline Old Post 09-27-1999 12:40 PM
Click Here to See the Profile for ToolkiT Edit/Delete Message Reply w/Quote
bpowell423
Member

Registered: Sep 1999
Location: Dayton, TN, USA
Posts: 66

Talking

Anybody remember "bank switching" on the old 8-bit computers (Z80, 6502)? I'm sure some insightful person could figure this out for a Visor. I don't know the nitty-gritty of the Dragonball (yet... once I have my Visor...), but couldn't you latch the output of a particular memory address or I/O port with a TTL octal latch and use that as the high order bits of a memory address? This would give you 256 banks (2^8) of memory. If you're using 8MB banks, this is 2GB, or 8GB if you're using 32MB banks. Plenty of space for any conceivable application. Any possibilities here or am I completely off my rocker?

bpowell423 is offline Old Post 09-27-1999 01:04 PM
Click Here to See the Profile for bpowell423 Edit/Delete Message Reply w/Quote
emeyer
Member

Registered: Sep 1999
Location: Pittsford,NY,USA
Posts: 223

Post

Your right on target. There are many methods for implementing a memory segmentation scheme, so there is no practical limit on what could be addressed. -Eric

[This message has been edited by emeyer (edited 09-27-1999).]

emeyer is offline Old Post 09-27-1999 01:32 PM
Click Here to See the Profile for emeyer Edit/Delete Message Reply w/Quote
palmoser
Member

Registered: Sep 1999
Location: Cupertino, CA, USA
Posts: 7

Lightbulb

Well, bpowell423, you are talking about the memory that an application will be able to access. But what about the limits on the size of the executable itself. If you have an executable that itself is big (I know 32MB is large enough for a handheld app) what good is the segmentation scheme if the OS is not built to handle that. So you squeeze your executable in the 32MB, with the extended/expanded memory management scheme, and make it work. Unless, what Tiroth says will be possible.
This is valuable input.

PalmOS-er.

palmoser is offline Old Post 09-27-1999 08:12 PM
Click Here to See the Profile for palmoser Edit/Delete Message Reply w/Quote
All times are GMT. The time now is 05:41 PM. Post New Thread    Post A Reply
  Last Thread   Next Thread
[ Show a Printable Version | Email This Page to Someone! | Receive updates to this thread ]

Forum Jump:

Powered by: vBulletin Version 2.3.4
Copyright ©2000, 2001, Jelsoft Enterprises Limited.