Announcement: Contiki 1.3
Oliver Schmidt
I'm pleased to announce the availablity of Contiki 1.3 for the Apple2.
General informations on Contiki - a modern, Internet-enabled operating
system and desktop environment - can be found on:
http://www.sics.se/~adam/contiki/
Contiki for the Apple2 needs an Apple2 Ethernet card for TCP/IP
connectivity. These two cards are supported:
- Uther (http://www.a2retrosystems.com/products.htm)
- LANceGS (http://lancegs.a2central.com/)
Contiki for the Apple2 can be downloaded from:
http://www.a2retrosystems.com/downloads.htm
Contiki 1.3 for the Apple2 comes again (like 1.2) in two flavours:
- The 40 Col. variant that requires at least an ][+ with Language
Card.
- The 80 Col. variant that requires at least an Enhanced //e with
Extended 80 Col. Board.
Changes for both variants:
- Configuring the ProDOS prefix for user level file I/O.
Changes for the 80 Col. variant only:
- Requires an _EXTENDED_ 80 Col. Board. /RAM needs to be active and
_EMPTY_ on Contiki startup. /RAM may very well be used for user level
file I/O while running Contiki.
- More memory to run Contiki programs. Allows to keep the Directory
program active while running the Web Browser. Allows to run the Web
Server - which however does _NOT_ allow access to the ProDOS file
system :-(
- Mouse support (Mouse Card, //c mouse, IIgs mouse). Searches for a
mouse in all slots. If no mouse is found Contiki just runs without
mouse support without further notice. So IIgs ROM3 users make sure to
set Slot 4 to the Mouse Port in order to have Contiki find the mouse.
- 'Quit' option in 'Contiki' menu.
- ProDOS startup file protocol support. Allows to run any Contiki
program instead of Welcome on Contiki startup. May i.e. be used with
the ProSel menu or the Davex shell to i.e. run the Web Browser.
- GS/OS Finder Icon file. Allows to use the ProDOS startup file
protocol support for "opening" a Contiki program from the GS/OS
Finder.
- Text mode screen saver. As the two existing lores graphics screen
savers unfortunately now show screen distortions due to the banking
implemention a text mode screen saver was added.
Enjoy, Oliver
aiia...@gmail.com
> Hi,
>
> I'm pleased to announce the availablity of Contiki 1.3 for the Apple2.
I am pleased you've made progress!
Mouse support works good... We need AppleWin Mouse emulation!
I noticed that if you click the directory from the desktop, and then
click the DIRECTORY name on the directory window, the screen
flickers badly when you move the mouse.
Rich
Oliver Schmidt
>Mouse support works good... We need AppleWin Mouse emulation!
Indeed.
>I noticed that if you click the directory from the desktop, and then
>click the DIRECTORY name on the directory window, the screen
>flickers badly when you move the mouse.
Contiki allows to drag a window over the desktop by selecting the
window title. Due to performance constraints (especially on 1 MHz
machines) the necessary redraws become very visible.
The directory application window is as big as the desktop so it can't
actually be moved. But the redraws happen anyway. My assumption is
that it's this what you refer to as flicker.
Trying the same with a smaller window should help to clarify if my
assumption is correct...
Best, Oliver
aiia...@gmail.com
Oliver Schmidt wrote:
> The directory application window is as big as the desktop so it can't
> actually be moved. But the redraws happen anyway. My assumption is
> that it's this what you refer to as flicker.
Ok, that is the flicker... I see the desktop flickering through to the
directory
window when the directory window title is highlighted (IE move window
mode)
... I was seeing flicker because my machine is accelerated... Forcing
a
1mhz boot shows the screen flash between the directory and the
desktop...
It appears as if the entire screen is restored each time the mouse is
moved (when a window title is highlighted).... Perhaps the screen
redraw routine could be optimized to only redraw the screen area that
is
revealed when a window is moved..
Rich
Michael J. Mahon
> Oliver Schmidt wrote:
>
>>The directory application window is as big as the desktop so it can't
>>actually be moved. But the redraws happen anyway. My assumption is
>>that it's this what you refer to as flicker.
>
>
> Ok, that is the flicker... I see the desktop flickering through to the
> directory
> window when the directory window title is highlighted (IE move window
> mode)
> a
> 1mhz boot shows the screen flash between the directory and the
> desktop...
>
> It appears as if the entire screen is restored each time the mouse is
> moved (when a window title is highlighted).... Perhaps the screen
> redraw routine could be optimized to only redraw the screen area that
> is
> revealed when a window is moved..
Or to simply animate the *rectangular frame* that the window will occupy
until the movement has stopped for a certain period...
Back in the days of slower processors, this was a common approach.
-michael
Fast Sudoku solver for Apple II's!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
Oliver Schmidt
>> It appears as if the entire screen is restored each time the mouse is
>> moved (when a window title is highlighted)....
Indeed.
>> Perhaps the screen
>> redraw routine could be optimized to only redraw the screen area that
>> is
>> revealed when a window is moved..
If you have enough memory for all the special handling - which will be
used somewhere between seldom and never as the interesting windows are
as big as the desktop anyway and as the interesting applications are
so big that you can't run two simultaniously and thus don't have
multiple windows...
>Or to simply animate the *rectangular frame* that the window will occupy
>until the movement has stopped for a certain period...
>
>Back in the days of slower processors, this was a common approach.
In fact you don't have to look back that much. It's the default
behaviour of Win95 and still an option for Win2k.
Best, Oliver
aiia...@gmail.com
>
> If you have enough memory for all the special handling -
I'd really like to see and help code Contiki that uses multiple
banks on Ramworks III aux RAM.
Rich
Michael J. Mahon
I expect that you'll find that processor speed is the limiter, not
memory.
Oliver Schmidt
>I'd really like to see and help code Contiki that uses multiple
>banks on Ramworks III aux RAM.
The Contiki source is freely available - just go ahead. BTW: Contiki
1.3 makes (very limited) use of banking. From the CVS readme.txt:
----------
Generally it's very hard to make use of memory mapping for an event
driven system like Contiki but the Apple //e allows to map only 8kB of
Aux memory to the address space $2000-$3FFF to facilitate double hires
graphics. this feature is accompanied by ProDOS 8 which allows to keep
/RAM generally active while doing double hires graphics by saving a
8kB file as first file to /RAM and thus preserving $2000-$3FFF of Aux
memory. Contiki makes use of all this double hires support while just
staying in text mode and using the 8kB as additional memory.
The additional 8kB are used to store the code of the uIP TCP/IP stack.
They are mapped in both on calls from the Contiki event kernel to the
TCP/IP stack process (poll and event handler) and calls to the uIP API
from programs. Most of the time the 8kB are just kept mapped in when
the uIP code calls other code. This is possible because the only
memory not reachable from the uIP code are the corresponding 8kB of
Main memory - and the Contiki kernel objects are linked in an order
which makes only CTK code (which is never called by uIP code) use that
8kB of Main memory. The only call from uIP code that triggers mapping
out the 8kB of Aux memory is the uIP upcall into a program for
processing incoming IP data as some program may potentially call CTK
code while processing that data.
Beside that Contiki makes use of the Language Card bank 2 to store the
code of the C-libary. Most of this 4 kB can be considered free
although officially marked as reserved by ProDOS 8. Only $D100-$D3FF
are actually used to store the ProDOS 8 dispatcher. As it is only used
after terminating Contiki it can be saved to /RAM on startup and
restored from there while cleanup.
The code doing all that code relocation gets overwritten on setting
the BSS segment to zero. The code doing this (and the C-library
initialization) gets overwritten later by the heap content.
----------
Best, Oliver
Oliver Schmidt
>I expect that you'll find that processor speed is the limiter, not
>memory.
That doesn't match my experience. There's only one area where Contiki
feels slow: The web browser re-getting the document every time one
pages down one screen. That could obiously improved by cashing the
document - if there was memory available.
Best, Oliver
Michael J. Mahon
Ah--caching is another matter. The fastest processing is the
processing that is avoided! ;-)
-michael
New, faster SUDOKU v2.0 solver for Apple II's!
Michael J. Mahon
> Hi Rich,
>
>
>>I'd really like to see and help code Contiki that uses multiple
>>banks on Ramworks III aux RAM.
>
>
> The Contiki source is freely available - just go ahead. BTW: Contiki
> 1.3 makes (very limited) use of banking. From the CVS readme.txt:
>
> ----------
>
> Generally it's very hard to make use of memory mapping for an event
> driven system like Contiki but the Apple //e allows to map only 8kB of
> Aux memory to the address space $2000-$3FFF to facilitate double hires
> graphics. this feature is accompanied by ProDOS 8 which allows to keep
> /RAM generally active while doing double hires graphics by saving a
> 8kB file as first file to /RAM and thus preserving $2000-$3FFF of Aux
> memory. Contiki makes use of all this double hires support while just
> staying in text mode and using the 8kB as additional memory.
Since you've made the point that data caching is the primary win, it's
much easier to use a wierd banked memory system as a RAM disk, which
would be a great match to the data caching problem.
-michael
New, faster SUDOKU v2.0 solver for Apple II's!
Michael J. Mahon
> ...wierd banked memory system...
Ack! I think I have to stop using weirds that I can't fpell. ;-)
sicklittlemonkey
> Michael J. Mahon wrote:
> > ...wierd banked memory system...
>
> Ack! I think I have to stop using weirds that I can't fpell. ;-)
>
> -michael
Console yourself that English is a Germanic language, and your spelling
is more correct in German phonology (except for that whole 'w' thing
;-) and actually makes sense.
Pity the American reformers of English didn't sort that one out.
Cheers,
Nick.