From: groepaz (groepaz_at_gmx.net)
Date: 2002-11-19 03:10:21
Hello Ullrich, Saturday, November 16, 2002, 1:07:24 PM, you wrote: UvB> On Sat, Nov 16, 2002 at 01:32:51AM +0100, BlackJack/Civitas wrote: >> The last sentence is the reason why I still would use cbm_load/save() >> even if there's C file I/O. A cardrigde with a fastloader speeds >> loading/saving up very well. UvB> Seeing how people argue about this, I came to the conclusion that the old UvB> 90:10 rule is still true: 90% of all programs do not have any problems with UvB> CPU or memory limits, the other 10% do. However, 90% of all programmers UvB> believe that especially their programs belong to the latter group. UvB> So let me take the chance to explain why people often try to optimize in the UvB> wrong places:-) [snip] very true BUT... you forget one thing: 1) i think we agree that any "real" program on the c64 that doesnt involve fastload of any kind (may it be new kernal, cartridge or software) is kindof unuseable, unless the data it loads is very small in size. 2) i think we agree that if its possible, we want the cc65-compiled program to use the existing fastload kernal/cartridge. now 3) all existing fastloaders, except jiffy-dos (not very common in europe) and speed-dos (even less common even in europe ;=P) do speed up kernal SAVE and LOAD... ONLY! ie, any library that tries to imitate stdio, and thus uses sequential file access will NOT be speeded up here! so while what you say is true for most little programs ppl are writing, (which usually dont save/load much data at all) - its very wrong for those who would like to write eg a game-engine (although it would give the crackers a nice challange to replace these dog slow stdio routines by some fastloader...in the compiled code ;=D) -- Best regards, groepaz mailto:groepaz_at_gmx.net ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2002-11-19 03:10:27 CET