Navigation
« 

Anonymous




Register
Login
« 
« 

Amiga Future

« 

Community

« 

Knowledge

« 

Last Magazine

The Amiga Future 168 will be released on the 5th May.

The Amiga Future 168 will be released on the 5th May.
The Amiga Future 168 will be released on the 5th May.

The Amiga Future 168 will be released on the 5th May.
More informations

« 

Service

« 

Search




Advanced search

Unanswered topics
Active topics
« 

Social Media

Twitter Amigafuture Facebook Amigafuture RSS-Feed [german] Amigafuture RSS-Feed [english] Instagram YouTube Patreon WhatsApp
« 

Advertisement

Amazon

Patreon

« 

Partnerlinks

Amiga Future News Portal

Choose the language for the News (current shown in english): Show news in german EN
Back to previous page


Fryin Pan News

Published 07.07.2007 - 13:00 by AndreasM

please hold on with registrations

since i've been delegated to fort worth (texas), i will not be able to parse your requests until i come back. please keep that in mind. my stay should not affect the development much, but i can't do much testing either, so no release till i come back. sorry.

minor information update

Just to let you know: the work on fryingpan has not been suspended.
at the very moment i can tell you that cd-text is working and session importing and exporting takes its shape. i've managed to export a cue sheet of audio-only disc, import it back and record on disc (with cd-text!). it worked. i hope to be able to give you more with next release.

speedup patches for morphos

i am aware that fryingpan takes some time to burn discs on morphos. i want you to consider certain patch - not for fryingpan, but for morphos itself.
it turns out memory allocations are real pain in the butt on morphos. i've done some benchmarks and it seems that i can perfrorm ten million (10'000'000) allocations on OS3 and OS4 within few seconds (~5.6s and 1.8s respectively), while ten times less (one million, 1'000'000 allocs) take over 30 seconds on morphos.
i've tried to reduce the allocation time by reducing security mechanisms (semaphores). to make allocations safe i tried to associate tasks with pools (so one memory pool per task), but the code turned out to execute 3x longer (due to extremely slow FindTask(0) command, that is unthinkable).
So I would like you to give 'APooler' a try. You can find the utility here:
Morgoth's Download Page
And.. no, I won't reduce the allocations. Memory allocation is a system time critical operation. FP operates on memory alot (virtually every string now uses at least one memory allocation, many string operation create a temporary buffer, and the whole is object oriented to give me some control over behavior and memory control). I haven't done that for fun or to make fp a pain in the ass. i won't revert to one huge structure. Talk to MOS team to fix this flaw.

http://www.tbs-software.com/fp/

Back to previous page