Oliver Schmidt

Hi,

I just released the 'Contiki 2.4 binary release for Retrocomputing'.
It is available at

http://cbm8bit.com/contiki/

and at

http://a2retrosystems.com/contiki.html

This release was built using cc65 2.13.2 from (modified) Contiki 2.4
sources. The orginal sources are available at


http://sourceforge.net/projects/cont...4.zip/download

and the modifications at

http://cbm8bit.com/contiki/contiki-2.4-addon.zip

Contiki 1.x integrated all programs into a common GUI as windows. Very
cool but very complex to to write programs for. In fact there was
never a Contiki 1.x GUI program which was not developed by the Contiki
core team - and as the Contiki core team doesn't develop GUI programs
anymore Contiki 1.x was sort of a deadend street.

So in order to ease development of 3rd-party Contiki program I
modified Contiki 2.x to focus on individual standalone programs with a
fullscreen GUI. This simplification significantly reduced the memory
consumption thus allowing to replace custom "hacks" with generic cc65
components:
- C-library startup code
- Linker config file
- CONIO library
- Mouse driver

As a result Contiki 2.x contains only very little assembler coding and
even less target-specific assembler coding. This allowed for easy
porting to targets beside the C64 namely the C128 and Apple II.
Porting to other cc65 targets wasn't done due to missing Ethernet
hardware.

Contiki 2.4 is the first 2.x release to contain the following
programs:
- dhcp client
- web server
- web browser
- wget
- smtp client
- irc client
- Twitter client

The Twitter client called BREADBOX64 proves that the Contiki 2.x
approach was actual successful as it was independently developed by
the 3rd-party developer Johan Van den Brande.

BTW: In case you want to run Contiki 2.4 on a real Apple II you might
be interested in that fact that there's a new run of Uthernet cards
available right now :-)

Regards,
Oliver

TomCh

On 21 Aug, 14:57, ol...@web.de (Oliver Schmidt) wrote:
> Hi,
>
> I just released the 'Contiki 2.4 binary release for Retrocomputing'.
> It is available at
>
> *http://cbm8bit.com/contiki/
>
> and at
>
> *http://a2retrosystems.com/contiki.html
>
> This release was built using cc65 2.13.2 from (modified) Contiki 2.4
> sources. The orginal sources are available at
>
> http://sourceforge.net/projects/cont...ontiki%202.4/c...
>
> and the modifications at
>
> *http://cbm8bit.com/contiki/contiki-2.4-addon.zip
>
> Contiki 1.x integrated all programs into a common GUI as windows. Very
> cool but very complex to to write programs for. In fact there was
> never a Contiki 1.x GUI program which was not developed by the Contiki
> core team - and as the Contiki core team doesn't develop GUI programs
> anymore Contiki 1.x was sort of a deadend street.
>
> So in order to ease development of 3rd-party Contiki program I
> modified Contiki 2.x to focus on individual standalone programs with a
> fullscreen GUI. This simplification significantly reduced the memory
> consumption thus allowing to replace custom "hacks" with generic cc65
> components:
> - C-library startup code
> - Linker config file
> - CONIO library
> - Mouse driver
>
> As a result Contiki 2.x contains only very little assembler coding and
> even less target-specific assembler coding. This allowed for easy
> porting to targets beside the C64 namely the C128 and Apple II.
> Porting to other cc65 targets wasn't done due to missing Ethernet
> hardware.
>
> Contiki 2.4 is the first 2.x release to contain the following
> programs:
> - dhcp client
> - web server
> - web browser
> - wget
> - smtp client
> - irc client
> - Twitter client
>
> The Twitter client called BREADBOX64 proves that the Contiki 2.x
> approach was actual successful as it was independently developed by
> the 3rd-party developer Johan Van den Brande.
>
> BTW: In case you want to run Contiki 2.4 on a real Apple II you might
> be interested in that fact that there's a new run of Uthernet cards
> available right now :-)
>
> Regards,
> Oliver

Hi Oliver,

Do any of the v2.4 apps use the mouse?
Also now that we've added No-Slot-Clock to AppleWin, would this
benefit any of the apps (or contiki itself)?

Thanks,
Tom

Oliver Schmidt

Hi Tom,

>Do any of the v2.4 apps use the mouse?

Yes:
- Web browser
- DHCP client
- SMTP client
- IRC client (however not much to click on here)

>Also now that we've added No-Slot-Clock to AppleWin, would this
>benefit any of the apps (or contiki itself)?

I've seen the announcement :-) However the idea of Contiki 2.x (in
contrast to Contiki 1.x) is to keep things as simple as possible in
order to allow others to understand it.

Therefore Contiki 2.x almost fully relies on the services provided by
the cc65 C library - the mouse is a great example.

So from that perspective the question would be if it makes sense to
include some NSC support in the cc65 C library. As we all know a stock
A2 lacks any type of timer support resulting in the cc65 C library
missing the clock() API present on most other cc65 targets.

I've been recently thinking about the options for implementing clock()
on the A2. The result was that I believe that there are more machines
with some sort of mouse hardware than machines with NSC. Therefore my
plan is to implement clock() based on the mouse VBL interrupt and
_not_ based on the NSC. As both the mouse and the NSC can't be
presumed to be present it would of course make sense to check for both
on program startup time in order to increase the likelyhood of being
able to have an actually funtional clock().

However given the time it typically takes me to actually implement
stuff (instead for just writing about it) and given that codesize is
always a concern (checking for two things is oviously larger) I
wouldn't wait for NSC support to arrive.

Hope my thoughts make sense to you...

Regards,
Oliver

sicklittlemonkey

On Sep 20, 7:40 am, ol...@web.de (Oliver Schmidt) wrote:
> So from that perspective the question would be if it makes sense to
> include some NSC support in the cc65 C library. As we all know a stock
> A2 lacks any type of timer support resulting in the cc65 C library
> missing the clock() API present on most other cc65 targets.

NSC (aka Phantom Clock/Dallas SmartWatch) can probably be used on many
systems, including C64/128 - there are GEOS drivers. If you want
sample code I can send you partial disassemblies of the GEOS and
ProDOS Apple II drivers. It's pretty simple.

> I've been recently thinking about the options for implementing clock()
> on the A2. The result was that I believe that there are more machines
> with some sort of mouse hardware than machines with NSC. Therefore my
> plan is to implement clock() based on the mouse VBL interrupt and
> _not_ based on the NSC. As both the mouse and the NSC can't be
> presumed to be present it would of course make sense to check for both
> on program startup time in order to increase the likelyhood of being
> able to have an actually funtional clock().

How about time()?

Cheers,
Nick.

Michael J. Mahon

On 9/19/2010 12:40 PM, Oliver Schmidt wrote:
> Hi Tom,
>
>> Do any of the v2.4 apps use the mouse?
>
> Yes:
> - Web browser
> - DHCP client
> - SMTP client
> - IRC client (however not much to click on here)
>
>> Also now that we've added No-Slot-Clock to AppleWin, would this
>> benefit any of the apps (or contiki itself)?
>
> I've seen the announcement :-) However the idea of Contiki 2.x (in
> contrast to Contiki 1.x) is to keep things as simple as possible in
> order to allow others to understand it.
>
> Therefore Contiki 2.x almost fully relies on the services provided by
> the cc65 C library - the mouse is a great example.
>
> So from that perspective the question would be if it makes sense to
> include some NSC support in the cc65 C library. As we all know a stock
> A2 lacks any type of timer support resulting in the cc65 C library
> missing the clock() API present on most other cc65 targets.
>
> I've been recently thinking about the options for implementing clock()
> on the A2. The result was that I believe that there are more machines
> with some sort of mouse hardware than machines with NSC. Therefore my
> plan is to implement clock() based on the mouse VBL interrupt and
> _not_ based on the NSC. As both the mouse and the NSC can't be
> presumed to be present it would of course make sense to check for both
> on program startup time in order to increase the likelyhood of being
> able to have an actually funtional clock().
>
> However given the time it typically takes me to actually implement
> stuff (instead for just writing about it) and given that codesize is
> always a concern (checking for two things is oviously larger) I
> wouldn't wait for NSC support to arrive.
>
> Hope my thoughts make sense to you...

They do.

However, a source of periodic interrupts can only be used to implement
a time of day function if 1) the interrupts are never disabled long
enough to lose some, and 2) the user is willing to "set the clock"
on each boot.

The Apple II disables interrupts for seconds at a time when accessing
5.25" disks, causing loss of "ticks". And users often don't bother to
enter the real time when prompted.

If a stable RTC is desired, for file date-time stamping, for example,
then the NSC/SmartWatch is a desirable solution.

If a reasonably stable source of periodic interrupts is desired, then
the mouse card is hard to beat (and the NSC is no help at all).

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Oliver Schmidt

Hi Michael,

>> [...]
>>
>> Hope my thoughts make sense to you...

>They do.

:-)

>However, a source of periodic interrupts can only be used to implement
>a time of day function if 1) the interrupts are never disabled long
>enough to lose some, and 2) the user is willing to "set the clock"
>on each boot.

The cc65 clock() function is just supposed to return the current clock
tick count - and there's additionally some way to look up, how many
clock ticks make up a second.

So we're definitively not taking about a time-of-day function here.

>If a stable RTC is desired, for file date-time stamping, for example,
>then the NSC/SmartWatch is a desirable solution.

Full ACK.

Regards,
Oliver

Oliver Schmidt

Hi Nick,

>> So from that perspective the question would be if it makes sense to
>> include some NSC support in the cc65 C library. As we all know a stock
>> A2 lacks any type of timer support resulting in the cc65 C library
>> missing the clock() API present on most other cc65 targets.

>NSC (aka Phantom Clock/Dallas SmartWatch) can probably be used on many
>systems, including C64/128 - there are GEOS drivers. If you want
>sample code I can send you partial disassemblies of the GEOS and
>ProDOS Apple II drivers. It's pretty simple.

If you don't tie any expectations to sending me code than I'm happy to
receive it and store it away in order to check it out when the time
has come...

>How about time()?

Good question :-)

@Michael: time() is the time-of-day function you were thinking
about...

After thinking about the pro's and con's for some time I decided to
implement time() simply by calling the appropriate ProDOS function.
The con's:
- Only available when running ProDOS 8 (not DOS 3.3)
- No seconds
THe pro's:
- Works with any clock supported by the currentl yrunning ProDOS
(either via built-in or loaded/patched driver

So a NSC *is* already used (at least indirectly via ProDOS) by the
cc65 C library.

Regards,
Oliver

sicklittlemonkey

On Sep 22, 1:26 am, ol...@web.de (Oliver Schmidt) wrote:
> If you don't tie any expectations to sending me code than I'm happy to
> receive it and store it away in order to check it out when the time
> has come...

Fine. Tom has checked them into the AppleWin project docs:
http://svn.berlios.de/wsvn/applewin/...s/NoSlotClock/

> So a NSC *is* already used (at least indirectly via ProDOS) by the
> cc65 C library.

Good! :-)

> The con's:
> - No seconds

Not so good! :-(

Cheers,
Nick.

Michael J. Mahon

On 9/21/2010 4:03 PM, sicklittlemonkey wrote:
> On Sep 22, 1:26 am, ol...@web.de (Oliver Schmidt) wrote:
>> If you don't tie any expectations to sending me code than I'm happy to
>> receive it and store it away in order to check it out when the time
>> has come...
>
> Fine. Tom has checked them into the AppleWin project docs:
> http://svn.berlios.de/wsvn/applewin/...s/NoSlotClock/
>
>> So a NSC *is* already used (at least indirectly via ProDOS) by the
>> cc65 C library.
>
> Good! :-)

I agree--a very appropriate way to deal with time().

>> The con's:
>> - No seconds
>
> Not so good! :-(

IIRC, the seconds are available in the $200 buffer at a well-known ;-)
location after a time call, depending on the particular clock driver.

For high-resolution timing (sub-second resolution), there are other
methods for syncing with the "second" transition, doing the activity
to be timed, then re-syncing to the "second" transition while counting
in a timed loop. This method is capable of sub-millisecond resolution
for doing measurements.

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."

Oliver Schmidt

Hi Michael,

>>> So a NSC *is* already used (at least indirectly via ProDOS) by the
>>> cc65 C library.
>>
>> Good! :-)
>
>I agree--a very appropriate way to deal with time().

:-)

>>> The con's:
>>> - No seconds
>>
>> Not so good! :-(
>
>IIRC, the seconds are available in the $200 buffer at a well-known ;-)
>location after a time call, depending on the particular clock driver.

Yes, bu the whole idea of implementing time() based on ProDOS was to
abstract from the actually used clock hardware...

Regards,
Oliver