>A question about this- you're using the store to buffer the incoming data?
>It may be that I'm just being paranoid, but I'm a little worried about
>constantly writing to my flash memory. I don't know how you're doing this,
>but if I make some random guesses (let's see... how about writing when 32K
>has been accumulated, listening to a 128Kbps stream...) we can do an almost
>meaningless analysis: it would take 5 hours of listening to write 10,000
>times. Okay, maybe it's not _so_ bad... but it does add up..
It's just the way it works. Noticed the busy box when
recording/playing sounds in the Notes application?
>I've seen reference to the C++ heap being limited, but it seems like
>it ought to be fairly spacious on a 2100, given that so little of
>the additional memory
>goes to NS heap.
I've been able to allocate up to more than 3 MB on my Newton. Of
course, not everybody has a MP2100.
>That's an interesting remark! I haven't thought about that myself...
>Currently, the buffering is done using VBOs that are never actually
>written to any kind of soup (i.e. no calls to EntryChangeXmit are made).
>I am not sure about the implications this has and how the Newton OS
>acutally caches these VBOs (it could be possible that only parts are
>being swapped to the store), maybe Paul can shed some light on this.
If you just do this with more than 32 KB, you're in big trouble.
Otherwise, it's just like buffering to what you call the C++ heap.
You don't need to actually put the VBO into a soup, but you need to
call ClearVBOCache() say every 32 1K page changed.
Cf:
http://newyork.unna.org/unna/apple/documentation/developer/QAs-2.x/html/vboreset.htm
It's only when this function is called that the VBO data is actually
written to the store.
>I plan however to make the buffering configurable, so that either the
>store or the NewtonScript heap is used, perhaps with the third option of
>using the C++ heap (that has the disadvantage that in case something
>goes wrong, the allocated memory is harder to reclaim and a restart
>might be needed).
If something goes wrong, what tells you that all the references to
your NS buffer will be removed? I can't see the difference.
>The whole buffering issue could possibly be avoided if there was a way
>to talk to the Voyager chipset directly.
Not really. I bet the Voyager chipset uses DMA (well, sort of since
it's he who accesses the DRAM, the CPU only accesses the ROM and the
Voyager chipset).
>A different way to do all this would be to implement a codec (actually,
>only the -dec part might be feasible), but I'm not sure if we have the
>complete tool set for that.
Oh, all you need is an hex editor ;)
Paul
-- Home page: http://www.kallisys.com/ Newton-powered WebServer: http://newt.dyndns.org:8080/-- This is the Newtontalk mailinglist - http://www.newtontalk.net To unsubscribe or manage: visit the above link or mailto:newtontalk-request_at_newtontalk.net?Subject=unsubscribe
This archive was generated by hypermail 2.1.2 : Sat Dec 01 2001 - 20:04:10 EST