Re: Commodore Emulators

2007-11-18 Thread Ed Montgomery

  [Same goes for C64 emulators... there are still
folks in chemistry
 and
  biology and physics who have useful code that
runs on the
 Commodore
  machines.. even at Big 10 universities.  ;)]
 

I have found this to be an EXCELLENT commodore
machines emulator, which I've run on several linux
distros :-)
Shouldn't be too tough to port, if that is even
necessary.  Have fun!

http://www.viceteam.org/




  

Be a better pen pal. 
Text or chat with friends inside Yahoo! Mail. See how.  
http://overview.mail.yahoo.com/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Commodore Emulators

2007-11-18 Thread Albert Cahalan
Ed Montgomery writes:

 I have found this to be an EXCELLENT commodore
 machines emulator, which I've run on several linux
 distros :-)

Maybe a fresh new BASIC would be better. It could certainly run
much faster than one going through two levels of interpretation.

The thought had already crossed my mind in fact. I think I can
make it outperform Python; I have a bit of x86 JIT experience.
(though actually one can write a regular compiler)

A live view of the stack would really help people learn.

I see 3 ways to do graphics:

1. expose the native 1200x900 (maybe a portion of it)
2. let the user choose, then scale coordinates
3. vector representation with scale-to-fit

Color numbers might be 24-bit or 3-digit decimal. The former
can represent more, while the latter is really easy to use.

One can make a nice parser with Antlr. Since such parsers indicate
the character position of an error, it is possible to show where
an error occurs as the user is typing.

I like the Atari syntax, but would of course want to support
Microsoft's string features as well. Unicode is a must.

For fun, CLOAD can be run over the audio ports. One could
stick to the standard format, which survives the frequency
dependant phase shift of a magnetic tape, or do something
more modern.

Question: if I jump from one for..next loop to another
with a goto, where do I go when I hit the second next?
I just tried two of the interpreters in Debian, and they
didn't do the same thing.

Of course, a truly bad-ass hacker would rip the FORTH out of
the firmware, putting BASIC where it rightfully belongs.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


New joyride build 305

2007-11-18 Thread Build Announcer Script
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build305/

-Calculate-12.xo
+Calculate-13.xo

--- Calculate-13 ---
* Parser converted to unicode
* Updates to improve translation #4527
* Mul/Div symbol i18n #4573
* Mul/Div button fixed #3526
* Addressed #4250
* Added palettes to buttons in toolbar
--
 This email was automatically generated
 Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Acoustic distance measurement test results

2007-11-18 Thread Benjamin M. Schwartz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joyride builds currently include my Acoustic Tape Measure activity, designed to
turn any pair of laptops into a tool for measuring distance.  Today, I decided
to test the maximum range.  I used two B4's running clean installs of joyride 
289.

I went to the MIT football field, because it is a large, flat, open space with
clearly labeled distance markings.  Unfortunately, there were no markings
visible on the field, so I made measurements on the adjacent long-jump track,
which is labeled in feet.

Measurement worked perfectly up to 30 m (100 ft), with at most 1 cm of
variability, and usually none. Measurement worked unreliably up to 40 m, giving
spurious answers except during lulls in the wind. (Almost all microphones record
high-amplitude noise in the presence of wind.)

I have several ideas for increasing range (or equivalently, improving noise
tolerance).  However, I did not make any attempt to implement them, because it
was too cold out for programming.

I also encountered some difficulty when sharing the activity over the mesh at
distances greater than 25 meters.  This might be because the default mesh
frequency (Channel 1) is the same as MIT's pervasive wireless network.  After
switching to mesh channel 11, I had no difficulty sharing over distances up to 
40 m.

- --Ben Schwartz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHQMRCUJT6e6HFtqQRAiaLAKCMbxGd4W0kk9WutMSuGrwxSohkQQCdECDB
hTrx9Mz95WyPW4zFVmT3Ub0=
=hRjf
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Acoustic distance measurement test results

2007-11-18 Thread quozl
On Sun, Nov 18, 2007 at 06:01:22PM -0500, Benjamin M. Schwartz wrote:
 I also encountered some difficulty when sharing the activity over the
 mesh at distances greater than 25 meters.  This might be because the
 default mesh frequency (Channel 1) is the same as MIT's pervasive
 wireless network.  After switching to mesh channel 11, I had no
 difficulty sharing over distances up to 40 m.

Your observations are consistent with mine, subject to variables you
didn't mention.

How high off the ground were the laptops?  At ground height, with ears
up, the node to node transmission distance is very small.  That's why
school server antennas will be mounted high.

A football field normally has very little slope, so the terrain
obstruction is easily understood.

It might also be an area with a large radio noise background.  By
placing the laptops on the ground you may also have reduced the noise
from nearby transmitters.

With two laptops in a paddock or dirt road away from any city, I can
easily get to 300m on with the laptops at 1.5m above ground.

Nearby, I can reproduce 1.6km on a tar road with about 5% packet loss.

-- 
James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Acoustic distance measurement test results

2007-11-18 Thread Benjamin M. Schwartz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:
 How high off the ground were the laptops?  At ground height, with ears
 up, the node to node transmission distance is very small.  That's why
 school server antennas will be mounted high.

The laptops were sitting directly on the ground.

 A football field normally has very little slope, so the terrain
 obstruction is easily understood.

Specifically, the laptops were sitting on the rubberized track surrounding the
field.  The surface appeared perfectly level to me, and free of obstructions
apart from myself.

It's entirely possible that what I saw was actually some unknown unrelated
software bug.  I wasn't intending to test wireless range, so I can't really say
anything more conclusive than it worked easily to at least 25m.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHQNlHUJT6e6HFtqQRArurAJ0en7WqDgiPnXT5YUgI8SdKWtjK6ACfUVLG
d29XGyyeDz+LXB2U5BWHwxA=
=8Vqm
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Acoustic distance measurement test results

2007-11-18 Thread James Cameron
On 19/11/2007, at 11:31 AM, Benjamin M. Schwartz wrote:
 The laptops were sitting directly on the ground.

Good, consistent results confirmed.

 Specifically, the laptops were sitting on the rubberized track  
 surrounding the
 field.  The surface appeared perfectly level to me, and free of  
 obstructions
 apart from myself.

Hmm, interesting.  Black rubberised track may contain a lot of  
carbon, may end up behing a good reflector for the signal.  Excluding  
grass improves the signal.

--
James Cameron

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: Acoustic distance measurement test results

2007-11-18 Thread Jim Gettys

Heh.  He said MIT; the field is surrounded by dormitories: very noisy
environment

-- 
Jim Gettys
One Laptop Per Child


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: [Xiph-dev] What's the status of Xiph codecs support in the Helix project?

2007-11-18 Thread Samuel Klein
Ivo, perhaps we could come up wit ha set of compliance elements that
typical users of OLPC laptops will need, as a case study for what free
formats should be supported for other users to be considered
'complete'.

Aaron, it would be tremendous to have speex working cleanly on the XOs,
since a primary use case is sharing voice data via the cleanest
lightweight recordings.   (I would like to have that working
seamlessly both in Helix and in gstreamer, but that's another issue.)

SJ

On Oct 8, 2007 12:06 PM, Aaron Colwell [EMAIL PROTECTED] wrote:
 Comments inline

 Ivo Emanuel Gonçalves wrote:
  Hello lists,
 
  Personally, I have not yet had an opportunity to test the different
  components in the Helix project.  As such, most of what I know comes
  from Wikipedia.
 
  In Wikipedia, it is stated that the Helix DNA Client supports Vorbis
  and Theora, but apparently, not Speex.  Is it this true?

 This is true.

   How hard
  would it be to port an implementation of Speex to the Helix Client?

 Not that hard.

  Is anyone working in it?
 Not at the moment. I'm essentially the maintainer of the Xiph related
 code and haven't had the time lately to add speex support. At a minimum
 I'm hoping to do a new release with the Theora Beta 1 decoder in the
 next week or so.

   What about Ogg Skeleton, which is now a
  requirement for Theora videos served under the video/ogg media type?
 
 Has this been formally made a requirement yet? It seems like this is
 still being hashed out on the xiph lists. I have yet to comment on the
 proposal because I haven't completely groked the whole thread yet. For
 now Skeleton is not supported.

  In Wikipedia, it is stated that the Helix DNA Server only supports
  streaming of MP3 and Real Media formats.  Why??
 Because streaming of Ogg has not been implemented yet.

   The Ogg format was
  created mostly for streaming.
 Ogg was created mostly for _HTTP_ streaming. The Helix server is
 traditional RTSP streaming server.

  That means that streaming Vorbis and
  Theora is (in theory) an easy process to implement for developers.
 Not true. Since Ogg allows arbitrary chaining of streams, implementing
 something that handles all of the various cases is quite difficult.
 Ogg's ability to chain segments together that have different numbers of
 streams in them are particularly taxing on the Helix Media Engine
 implementation.

  Then there's also streaming through RTP.  Vorbis, Speex, and Theora
  may be streamed through RTP.
 Implementing this has been on my list of things to do. This is
 non-trivial especially if I want to properly handle chained streams.

 
  With the Helix software becoming part of the XO laptop (the OLPC
  project) it is highly important that free formats work properly in
  Helix, but that doesn't seem to be the case right now.

 Since you haven't even used the Helix code I find it difficult to accept
 your criticism that it isn't working properly. The code works great for
 the codecs and modes of playback that I have implemented. My primary
 focus was to get the most robust local playback of Theora  Vorbis files
 that I could. Making the ogg file format plugin work with the Helix
 Server and supporting Speex were secondary goals. I plan on adding
 Speex, and RTP delivery when I get a chance.

 Since there isn't a compliance document for ogg support and no specified
 minimal codec support, I think it is a stretch to say that Helix doesn't
 support free formats properly. Ogg is woefully under specified
 especially in the chained and multi-stream cases. Having a document that
strictly outlines how to handle funky chained files (ie. audio-only,
 followed by audio/video, followed by a segment with 2 video streams) as
 well as files with say 2 audio tracks or 2 video streams would be of
 great help and would provide a way for all of the implementations out
 there to converge on a single interpretation.

 This has been a side project of mine for several years. I haven't spent
 much time on it lately because I have gotten little to no feedback on it
   . I've pretty much interpreted that as any of several things; users
 are happy with the current code, they don't care about this work, or
 they are unhappy but don't post anything to the list so I can fix it. In
 all of these cases there isn't much incentive to work on the code since
 there is no outside feedback. Also since there really isn't a minimum
 bar for claiming compliance, spec compliance isn't a motivator either.

 Aaron
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel