A Propeller BIOS Project
jazzed
Posts: 11,803
Hi, I've spent some time putting together a "Propeller BIOS".
This was originally started because of discussions in the "Standards ..." thread.
The project is experimental, and various inefficient low-level designs may change.
Why a Propeller BIOS?
1. To·allow a user·application to function without the application needing to configure hardware.
2. To provide a way for low level hardware to be configured as a compile or a run-time decision.
Features:
1. Fully enabled BIOS today provides TV,VGA,FDSERIAL,EEPROM,SDCARD,MOUSE,KEYBD devices.
2. A CLI "command line interface" configuration utility is provided (compile time selectable).
3. All device features are compile-time selectable.
4. Applications can be built without including the BIOS.
5. Applications use an API; the API could be reproduced for use in a simulation environment.
Possible Future Features:
1. Make code smaller and faster if possible.
2.·Make it possible to·"run" a binary from SDcard or other media.
3. Make access to·network attached storage possible.
4. Provide a "tftpboot" facility.
5. Provide limited graphics interface ability.
6. Provide a configuration GUI for offloading configuration to free memory.
Advantages:
1. Employ an API interface abstraction layer for applications.
·· This means any low level implementation can be used either real or simulated.
2. Given knowledge of the interfaces, any Propeller language could be used for applications.
3. Lower level changes would be transparent when API stabalizes.
Disadvantages:
1. Code size for the full feature-set is a problem.
·· This is mitigated somewhat by the ability to choose features before compiling.
2. Perfomance will never be on par with "normal" SPIN embedded applications.
3. Graphic intense games will most likely never work with this infrastructure.
·
Added:
I've officially given up on most this concept. While it is entirely possible to use a variation of this,
some of the complications associated with running an applications which use the services (like
ensuring exclusive access to·the serial port for example) and being able to clean up previously
run programs make it less attractive and more of a problem than I want to address.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (jazzed) : 7/27/2008 11:40:32 PM GMT
This was originally started because of discussions in the "Standards ..." thread.
The project is experimental, and various inefficient low-level designs may change.
Why a Propeller BIOS?
1. To·allow a user·application to function without the application needing to configure hardware.
2. To provide a way for low level hardware to be configured as a compile or a run-time decision.
Features:
1. Fully enabled BIOS today provides TV,VGA,FDSERIAL,EEPROM,SDCARD,MOUSE,KEYBD devices.
2. A CLI "command line interface" configuration utility is provided (compile time selectable).
3. All device features are compile-time selectable.
4. Applications can be built without including the BIOS.
5. Applications use an API; the API could be reproduced for use in a simulation environment.
Possible Future Features:
1. Make code smaller and faster if possible.
2.·Make it possible to·"run" a binary from SDcard or other media.
3. Make access to·network attached storage possible.
4. Provide a "tftpboot" facility.
5. Provide limited graphics interface ability.
6. Provide a configuration GUI for offloading configuration to free memory.
Advantages:
1. Employ an API interface abstraction layer for applications.
·· This means any low level implementation can be used either real or simulated.
2. Given knowledge of the interfaces, any Propeller language could be used for applications.
3. Lower level changes would be transparent when API stabalizes.
Disadvantages:
1. Code size for the full feature-set is a problem.
·· This is mitigated somewhat by the ability to choose features before compiling.
2. Perfomance will never be on par with "normal" SPIN embedded applications.
3. Graphic intense games will most likely never work with this infrastructure.
·
Added:
I've officially given up on most this concept. While it is entirely possible to use a variation of this,
some of the complications associated with running an applications which use the services (like
ensuring exclusive access to·the serial port for example) and being able to clean up previously
run programs make it less attractive and more of a problem than I want to address.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (jazzed) : 7/27/2008 11:40:32 PM GMT
zip
88K
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Aka: CosmicBob
Again I hope, someone will download the cmap tools and start to document his projects this way
ErNa, that's an interesting rendering. I suppose someone could easily
integrate links to other docs such as API descriptions and design specs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
In the browser you only see a rendered version of the original map with limited functionality.
Post Edited (ErNa) : 7/8/2008 10:08:21 PM GMT