|
| |
Credits :
Download :
Look for downloads on external sites:
Pokefinder.org
User Comment
Submitted by TheRyk on 3 November 2014
| the true reason why our trackmo didn't get finished, we were waiting for bitbreakers latest shit. since I guess this is the real mac coy now, I guess I should check it out and forget about the OXY & ASC buildline from X 2012 xD |
User Comment
Submitted by chatGPZ on 1 November 2014
<insert drama about not getting tester credits> =)
finally out! finally can delete my local modded loader stuff and replace by this. \o/ |
User Comment
Submitted by St0fF on 1 November 2014
| Leider geil (tm) - this code reminds me of my tests and floppycoding 10 years ago. Inline GCR decoding and good ACME pseudopc. Great Job, Alter! Now we have LoadAKrill and Load1Breaker :) |
User Comment
Submitted by Bitbreaker on 29 October 2014
| Indeed, the biggest speed gain is saving the scan revolution. I also had the transfer routine squeezed down to 75 cycles per byte, but ran into problems on some drives then. A fast transfer should however not be underestimated, it is up to 10% that you loose on overall speed when needed 80 compared to 75 cycles. I'm trying to find the sweet spot here still. Other things that gain speed are, that i halfstep when the floppy is busy after a halfstep anyway, for e.g. with transferring a sector, so no waiting via timer needed except as fallback for partly filled sectors. Also, as all files usually are sequential on disk for a demo, things can be read with minimum seeking, also no dir seeking is needed for the first 42 files, above another 42 file descriptors are fetched and so on. And finally, one also has the option to let the floppy just spin and save on spin up/down. |
User Comment
Submitted by Bitbreaker on 29 October 2014
| Soci just supplied me with a version suitable for tass, thanks for that! Download added. |
User Comment
Submitted by Pantaloon on 28 October 2014
| propably awesome but im waiting for Krills code :) |
User Comment
Submitted by Oswald on 28 October 2014
| I remember krill's receive code and it didnt looked like there was 44% speed gain in it, so I thought wow :) but I understand now what happened. get the t/s stuff now, thanks. |
User Comment
Submitted by Krill on 28 October 2014
Oswald: Having a fixed interleave and sector layout is the main contributor to the speed gain, imho (it removes the need for an extra scan revolution, and as said, has been on my to-do list for a while).
I'm not convinced of $0100 instead of $fe data bytes blocks when it comes to overall speed, though (but smaller code, yes indeed). |
User Comment
Submitted by Bitbreaker on 28 October 2014
| Oswald: that t/s link i sacrificed also to get rid of all the $fe sectorsize gayness. $100 byte blocks are just so much nicer to handle with less code. Also it is simply not needed anymore if you load with a predictable sectorchanin. |
User Comment
Submitted by Oswald on 28 October 2014
| just splendid, 44% gain on krill's one wow :) I'm not entirelly convinced that gaining 1k on loosing t/s links and loosing 1541 files worths it tho. |
User Comment
Submitted by CreaMD on 28 October 2014
| This or that This is so far the *BEST* debate around things released on X that I have read (and couldn't add anything valuable to, which didn't stop me to comment anyway ;-). I love what you guys do. Krill, respect. |
User Comment
Submitted by Krill on 28 October 2014
Bitbreaker: I merely mentioned the facts as they appeared to me, no name-calling or ad-hominem attacks including flinging faecal matter involved.
I can find a few very similar code passages, but this is nothing new in this scene. I don't intend to spawn a dramatic discussion about what "open source" constitutes and the implications for derivative work and attribution, or where the line, if actually relevant, between re-implementation and copy&modify is.
In the end, it's a separate product with different design objectives and features.
And about enough time, no, i didn't really have any time until you finished your loader. And yes, i should work on other things anyways, for a change, so it's good to have a product that fits your needs and possibly a few other people's as well. |
User Comment
Submitted by Flavioweb on 28 October 2014
Oh... i'm used to hurt myself when i study someone else code while it try to understand it to convert and use it with my "coding environment".
I use 64tass with makefiles and some "scripting" if needed, so i almost never find "canned" code that fit in...
But i want code to study and not just to use... so i think your work is perfect for me, especially your "c" tool for.d64 creation...
Thanks again, and keep on! |
User Comment
Submitted by Bitbreaker on 27 October 2014
| Krill: no need to throw shit at me now. Have a look into the code and compare on your own. I took over some common knowledge from your loader, nothing more, nothing less, besides it being open source anyway. Still several months of very painful testing and bugtracking followed. You had enough time to implement those long desired features (and more, like intermittent half track stepping, basic code upload, painless turn disk, ...), but i found implementing all on my own is also a valid option. So stay sportif, kthxbye |
User Comment
Submitted by Brush on 27 October 2014
| i didn't know that Marco resumed the development of ACME. Good to hear. And i'm heading to sf.net to fetch it. Although i've moved to KickAss ever since Ilmatic. |
User Comment
Submitted by Krill on 27 October 2014
Dr.j: As far as i understood it, Bitbreaker took my loader, removed everything not strictly needed by a demo (Kernal fallback, support for non-1541-drives), then changed the file layout to have no T/S link for 256 data bytes per block, and finally squeezed everything to work with Doynax-LZ decompression in $0200 bytes.
The final result doesn't look much like the initial material any more, so he could move my credit over to "help" :)
Anyhow, the bottom line is
1. It's faster (but i still have some speed optimisations on my TODO list, so that should be only a temporary "issue")
2. It's smaller (with the Doynax-LZ option, but saving size for the magical $0200 limit is on my list as well)
3. It doesn't use standard file format (but remains D64 compatible)
4. It's less compatible (irrelevant for many demos) |
User Comment
Submitted by Bitbreaker on 27 October 2014
| Sharing is easy, using it without hurting oneself maybe an other :-) |
User Comment
Submitted by Flavioweb on 27 October 2014
User Comment
Submitted by spider-j on 27 October 2014
User Comment
Submitted by Bitbreaker on 27 October 2014
Ah, there's still those people out there that use that ancient acme windows version 0.93, right? 0.94.1 is out with a lot of very sexy features like label defining on commandline and new for loops :-)
Some comparisons (however not up to date, as i meanwhile had to mild down the timing a bit) can be found here:
http://www.style-kurve.de/temp/benchmark.pdf |
User Comment
Submitted by Dr.j on 27 October 2014
| Could be nice to point highlight/summery comparing to Krill (which a standard imho for loaders and heavily used) |
User Comment
Submitted by Brush on 27 October 2014
No editing of comments :)
i mean does not accept -D switch at all not only that particular example i gave. |
User Comment
Submitted by Brush on 27 October 2014
Almost there Bitbreaker :)
What version of ACME are you using? Neither .91 nor .93 accepts -DBITFIRE_CONFIG_INTERLEAVE=4 cmd line switch :) |
User Comment
Submitted by Bitbreaker on 27 October 2014
| Brush: Shit, right you are, haha, please bear with me, it is the day after X and i am at work since 7am %-) Added another download containing the packer stuff :-) |
User Comment
Submitted by Brush on 27 October 2014
Great release! And highly useful indeed.
The docs are mentioning the "bitnax" packer which i believe is not released yet. And without it it's not really possible to use Bitfire. Or am i missing something? |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
