|
| |
|
Bongo Linking Engine [2013] |
AKA :
Bongotime
Credits :
Download :
Look for downloads on external sites:
Pokefinder.org
User Comment
Submitted by Glasnost on 17 April 2013
Thx for the answer.
I didnt even think of a loader exchange :) Simple solution that ofcourse saves the day. And yes this LFT gcr program is pure art.
8 months is a long time on the same projekt. I'll look forward to your next demos :)
Best Regards
/Glasnost |
User Comment
Submitted by Mr Wegi on 17 April 2013
Gentlemen,
Thank you for all reviews:
Groepaz - thank you for clarifying nointerleave for Glasnost
Gunnar - thank you for all the explanations and interest in the topic
Wisdom - thank you for appreciating my work. I think it's not just me and Groepaz, but AT THE END we are all people from CSDB see you in hell :)
Glasnost,
It's a little difficult to talk about these things considering that ILTC linking is very bad. But it was the starting point. In particular, the delay before the second part as well as the mean of the file, which was the basis for the development of the compressor. The tests used the demo is exactly the same file. So nasty and spiteful.
I analyzed the linking of many demos. You can be sure that the TP92% also. Unless there found a two moments to improve (no technical - design) . By the way, thank you for this story. I love it. How, for example, the story of justange recorder. So back to the TP92% (exactly TP92%) - this demo gave a new direction and it was groundbreaking. If I have to watch myself sometimes (and I guess not just me) - it means that there is "something" in it.
... so ... Those were hard times. And if it has always been coding it in 1541, I had seen and remember who wrote loader :)
Moving on to your questions. I understand that you accept the idea predictable. There are many different ways to get to your destination. Loaders are the only options available for use at their discretion. Virtually all depends on how you plan your demo. And I should be afraid to impose or suggest anything.
I can say (but only as my opinion and not something existing, or the best) and I will linking the demo. So I go out with the assumption that if 4KB devote to music, it also can be used for advanced loadsystem 1.5kB. And like enough for me to use two versions of the loader - deterministic and 246 bytes. That's enough for me. Unrolled thought - music and loadsystem normally takes 5.5KB, and if extreme situation occurs, then I use the function "exchange loader" and mention loadsystem to 246bytes loader, which if necessary can also overdub me separate the decompression procedure. When passing an extreme situation, it reloads the advanced system and use it. The music also (EOD) can be appended parties. So I'm trying to build up an efficient system for, and if necessary I use a minimum.
Even if the effect taken all my RAM (except 5.5KB msx / load) - within 1sec. I can overdub a transition and 1sec. do not stagnation. But it really is my personal opinion and not something that should be regarded as a religion.
I may add further that integration decompressor occupied a lot of bytes and bytes can be used to save a "clean" loader and a separate decrunchers (in extremis)...
As you can see in the CL13 nonfly decompression did not make it worse demos yet. We have many different ways ...
So shortstream is our minimum, the fast stream is a little faster, nointerleave highly optimized and deterministic nointerleave is slightly improved. The first and second are dependent on the interleave (see loading the vader picture in demos 03 loaderdemos sample - bad interleave) the third and fourth are free from this problem...
And it's probably something I hope I defined these Loaders - but I must point out I did not want to interfere with the user's choice.
"- (Linker) For stream loading you might want to set interleave independantly for each file. (Though Deterministic version solves this in its own way)"
It is possible, and we have two problems here:
- We lose compatibility with the version of the deterministic
- I can not promise that it will be very soon (I'm sick and tired of doing this by 8 month - I want do demo :) )
You can use any other d64maker and then use functions "get_start_track_and_sectors" (one time at the start demo)
"- (Cruncher) Ability to crunch several files together in 1 file."
I wonder about it and almost came to the conclusion that the same line in the one asm short file with. ".binary" as directive will enter the command line compressor. So the compiler can do this for us - right? (Unless I do something misunderstood)
"- (Loader) LFT has this nice invention, which might fit in well...
http://linusakesson.net/programming/gcr-decoding/"
Something like this could come up with someone from another planet I think. This is an example that others look may be the key. I have no words to express my appreciation. I typed on the LFT page and sent a congratulatory email. This is really something big and this young man is like Nicolas Tesla. I can only add that I'm ashamed that I just could not come up with :) I look forward to the next demo. And when it comes to the speed of the loader is in the trackmolinker release is yet another loader, which takes 62 cycles receive byte (as could remember... in average with screen on 1byte per line - hi take 8 bytes between badlines). But he is not as comfortable to use (sprites, $D011, sei code over 8 lines delay etcetera) and does not use such cosmic ideas: (
"It also bothers me a bit that inc$01/dec$01 takes almost 9% of the timeusage of the inner transferloop to be able to write under IO area"
I do not think that it gave a lot of losses, because you have to keep in mind when 1541 is ready to send the next byte.
I would like return to this:
"I had a closer look on the Bongo c64 sourcecode, test results etc. and I think what impresses me the most is the fast decrunch time compared to other crunchers. This combined with some smart algorithms makes it very useable. "
It killed me decompressor LZWVL speed (in average about 10% only longer data !!!) . I would like to draw the attention to the unnoticed and unappreciated DOYNAX compressor. I do not think that is something bongo best and only. And here, too, did not want to interfere with the user's choice. Bongo is simply the result of my research and experimentation and indeed the consequence of my laziness. As in second parts of ILTC had non-generated a lot of speedcode.
Something to took me a lot of work was the development of all the things that I missed in some compressors. Such as exclusion (or not) load address (ability to compress data with or without a load address) safe the load address, a safe margin for encored bytes, save as rawdata. Possibility of recording the data with its own load address or no ... It was really tiring.
"of smaller files is a bit faster with stream versions. "
Frankly small files, and so quickly unzip 1..1.5 maybe 2 sec. :)
I wanted to thank you for delving deep into the "all"
Best regards
wegi |
User Comment
Submitted by Krill on 16 April 2013
| I knew it's a bad sign if the only somewhat coherent definition can be found on answers.com :) |
User Comment
Submitted by chatGPZ on 16 April 2013
| krill: its not that well defined... i have seen it used in different contexts, some of which were plain old out of order loading, and some of which were like you say :) i dont think it is any more specific than "loading in non linear way from block oriented source". |
User Comment
Submitted by Krill on 16 April 2013
I believe scatter loading is something else than out-of-order block loading, hence the last part of the definition, "but the several sections of the program need not be adjacent to each other."
It seems to be more like "you could pack several files together, so you didnt need to relocate afterwards, and it automatically put things in different places in memory under decrunch."
I call that option "chained compressed files" in my loader though. |
User Comment
Submitted by Wisdom on 16 April 2013
One should appreciate that someone took the time to put this all together. It might be incomplete or buggy, and it might not have documentation to a degree that will satisfy everyone's expectations. But these are things that can be improved, as with all other software.
Treating the author as if he committed a crime just because he has released this piece of software for potentially others to benefit from, is plain rude. Considering the fact that this act has been taken by the one and only beloved moderator of these forums, with usual sarcasm and slang mixed together, shows where CSDb came to be in recent years.
As a side note for "proper English" criers; proper use of English (or any other language) also involves proper use of capitalization, and more importantly; punctuation.
Good work, Wegi. You have my respect for the time you have spent on this.
|
User Comment
Submitted by chatGPZ on 16 April 2013
| yes, scatter loading is usually referred to as "no interleave (dependend) loader" when it comes to c64 :) |
User Comment
Submitted by Glasnost on 16 April 2013
User Comment
Submitted by chatGPZ on 16 April 2013
"What advantage is there in the nointerleave loader compared to the others?"
if it does what "no interleave loader" usually means, then it will load blocks out of order and not waste time waiting for the "next" block - just like what krills loader is doing. |
User Comment
Submitted by Glasnost on 16 April 2013
Hey Wegi,
Funny you remember me for my loader system... The only thing it was comparable to yours, krills, LFT's and others is that it runs on the same little breadbox :)
It was around 5x speed on the fly decrunching if i remember correct, and was made with almost no knowledge of the 1541 properties.. Back then we didnt have internet :) I knew nothing about the 300 rpm, gcr coding, smart sectorplanning and only had a memorymap of the 1541 plus some notes from a guy from X-factor i think... And Trackmos was a new concept.. The resulting loader sounded like two camels mating inside the 1541, when Camel Park was running... I even used single bit transfer.. Oh dear!...
The first cruncher version took ages, resulting in a lot of Work for Slammer in Tower Power.. (So sorry.) Every time he should test something in the linking he had to wait for ages..
The cruncher had only 1 smart thing, that you could pack several files together, so you didnt need to relocate afterwards, and it automatically put things in different places in memory under decrunch.
I had a closer look on the Bongo c64 sourcecode, test results etc. and I think what impresses me the most is the fast decrunch time compared to other crunchers. This combined with some smart algorithms makes it very useable. I also like that you can fly/Nonfly decrunch with the same loader. I have a feeling that the deterministic version uses a bit much memory in the c64 compared to my hopes, and also my guess is that flydecrunching of smaller files is a bit faster with stream versions.
And about "Deterministic" i was also wondering about the word at first, but i figured it refers to the File organisation, and infact the time consumption of the loader must be more predictable also during varying rastertime usage thus making it fit with the name. A streaming approach for an IRQ loader requires some good guessing in the sector interleave factor i guess.
I have some proposals:
- (Linker & Cruncher) A better documentation of your ideas behind this, and when you think deterministic, faststream, shortstream etc. should be chosen. (The source documentation itself is fine)
- (Linker) For stream loading you might want to set interleave independantly for each file. (Though Deterministic version solves this in its own way)
- (Cruncher) Ability to crunch several files together in 1 file.
- (Loader) LFT has this nice invention, which might fit in well...
http://linusakesson.net/programming/gcr-decoding/
- (Loader) The jumps in the beginning of the source fill up 12 bytes that can be erased. Good the sourcecode is available.
It also bothers me a bit that inc$01/dec$01 takes almost 9% of the timeusage of the inner transferloop to be able to write under IO area. But then again, the sourcecode is there so i can go and play around. (BIG THX!)
One thing i dont understand is:
What advantage is there in the nointerleave loader compared to the others?
Best Regards
/Peter "Glasnost" Rasmussen
|
User Comment
Submitted by Clarence on 11 April 2013
"Clarence: Nice to know C128DCR does not work any more, how about just sending me a bug report next time? (Or did you and i forgot?) :)
"
Krill, I bugged you yes :), I don't remember exactly, but I tested some disks for you back then. I send you a pm with my current experiences.
|
User Comment
Submitted by Mr Wegi on 11 April 2013
http://csdb.dk/release/?id=115756&show=summary#summary
This I say without counting points.
I can not blame you, that other OS did not run the program and pressed the F1 key, but then it was already here and it is advertised that you re-translation, in which I describe the idea of deterministic. As well as can be deduced from the batch file.
I suspect also that the majority thinks that the bongo cruncher version of the GUI doesn't work from the command line - yes, it also works with CMD.
@Krill
Unfortunately I do not have sources of LC.
As you write - deterministic loader works and is the only reason that it requires absolutely trackmolinkers because both know the order written sectors.
For other systems, you can not use it without at least Win4Lin. You could possibly use a different D64maker and give the script with information about the files, instead use "get_start_tracks_and_sector" functions and use the version nointerleave.
I suppose it could be to try to build the project tracmolinker Lazarus - but I do not have a clue.
"Not sure if i understand this right" - absolutely wrong :) I think it's something very good that you support so many devices. In the circle of my interest is only in 1541 and 1570 to 1571 in 1541 mode, no such miracles as the D71 format support. This is what I have, this behavior JIFFYDOS compatibility.
Immediately throw trackmolinkers sources, although I doubt any of this chaos was good - And to be honest as this gentlemen insist on the source - would be nice if some of you compiled it for Linux in Lazarus.
edit:
I do not want to throw a couple of times in different places.
http://csdb.dk/release/download.php?id=147012 |
User Comment
Submitted by Krill on 11 April 2013
Mr Wegi: Do you happen to have the source to Taboo Levelcrush? I only have this ancient DOS binary. Sucks to have to run Dosbox or so just to pack a C-64 file..
So the loader knows the file interleave because the disk has been mastered with an interleave option known to the loader, thus it does not need to scan for sector links, correct?
Also, "Such spells as support for C16 and other computers are also Krill gave up and here is a man with a lot of insight on the hardware." - Not sure if i understand this right, but what have i given up on? C16 support? No, the loader compiles for C16 just fine, only important thing still missing is 1551 support.
And... Where can i find the complete source of everything, not only the C-64 code and the cruncher? |
User Comment
Submitted by Krill on 11 April 2013
| Clarence: Nice to know C128DCR does not work any more, how about just sending me a bug report next time? (Or did you and i forgot?) :) |
User Comment
Submitted by Mr Wegi on 10 April 2013
Provides a source trackmolinker although embarrassing for me. Please though a few hours delay.
I see that Clarence really familiar with bongotime. For many of the things he figured without question. If anyone has questions - please ask - not necessarily here can be priv. From myself I might add, if someone is afraid to ask - you can read a lot of batch files. There are also examples of how to pack in a batch file included with the source bongo. TEST subdirectory crunch.bat file 924 bytes. Or I'm not here just copy the:
cruncher.exe -i "demodata.prg" -DepackAdr $0801 -o "bongo1passwithgoldenseq.prg" -prgfile -JMP $080D -Value01 $37
cruncher.exe -i "demodata.prg" -DepackAdr $0801 -o "bongo1passwithgoldenseq.bin" -binfile
cruncher.exe -i "demodata.prg" -DepackAdr $0801 -o "bongo2passwithgoldenseq.prg" -prgfile -JMP $080D -Value01 $37 -iterate
cruncher.exe -i "demodata.prg" -DepackAdr $0801 -o "bongo2passwithgoldenseq.bin" -binfile -iterate
cruncher.exe -i "demodata.prg" -DepackAdr $0801 -o "bongo1passwithOUTgoldenseq.prg" -prgfile -JMP $080D -Value01 $37 -nogoldenseq
cruncher.exe -i "demodata.prg" -DepackAdr $0801 -o "bongo1passwithOUTgoldenseq.bin" -binfile -nogoldenseq
cruncher.exe -i "demodata.prg" -DepackAdr $0801 -o "bongo2passwithOUTgoldenseq.prg" -prgfile -JMP $080D -Value01 $37 -iterate -nogoldenseq
cruncher.exe -i "demodata.prg" -DepackAdr $0801 -o "bongo2passwithOUTgoldenseq.bin" -binfile -nogoldenseq -iterate
|
User Comment
Submitted by chatGPZ on 10 April 2013
"Trackmolinker is unfortunately only "Windoze" and rather Groepaz not throwing."
WAT. seriously. NO SENSE IT MAKES YOUNG PADAWAN.
clarence: ok, so basically again "bad documentation". point taken :)
other than that, source for that linker wouldnt hurt (as without the linker, the rest isnt very useful either) |
User Comment
Submitted by Mr Wegi on 10 April 2013
Since the decompressor bongo and doynax is addressing indexing'm one hundred percent sure of the two. And 99% of the exo - it seems to me that by my caution gave exo exaggerated.
Trackmolinker is unfortunately only "Windoze" and rather Groepaz not throwing. Nevertheless - apart from deterministic loader - you can compile it under Unix and use the additional features "get_start_track_and sectors" |
User Comment
Submitted by Clarence on 10 April 2013
Groepaz:
trackmolinker.exe -INC "tracksdata" "project.C64LINK" -D64 "myd64" -diskname "TRACKMOLINKER" -diskID "V1.2!" -DIRENT -LF -INTERLEAVE $0A
In project.C64LINK list the files to be included on the d64.
|
User Comment
Submitted by chatGPZ on 10 April 2013
"what command line flexibility do you miss from this release?"
being able to create a d64 without using the GUI for example. my makefiles do that already :) (that includes adding files, reordering directory, etc) |
User Comment
Submitted by Clarence on 10 April 2013
| Wegi, the "mod 254" problem with on the fly depcaking is occuring with all packers, or just with the 4 (LZWVL, Byte Boozer, Exomizer or Level Crusher) you documented? |
User Comment
Submitted by chatGPZ on 10 April 2013
| not for me - i am waiting for bitbreakers rewrite in C (including bugfixes) |
User Comment
Submitted by Clarence on 10 April 2013
"no it isnt. the point is that it is infact NOT linux only. (infact at least one of the supported packers is windows only) *sigh*"
I am familiar with Krill's loader until a few years ago, where Gunnar had to skip nmake compatibility, to have more makefile options.
This meant, you needed linux/unix shell to recognize all build directives in the latest versions. This is what I was referring to
as lesser problem (for me) as I could use VM/Cygwin or whatever solution.
The big problem is the 'lost' c128d/cr internal drive compatibility, which means in other words, that the latest loader simply hangs
on my main machine, this includes fe the Offence demos or your demos too, unusable for my own projects, until fixed, I hope you understand?
*sigh*
But please, back to topic, you did not answer my question, what command line flexibility do you miss from this release? |
User Comment
Submitted by Mr Wegi on 10 April 2013
Could anyone ask very politely to compile source Cruncher bongo and added them to the production here? Anyone who has a free pascal and know how to handle this ...
Very kindly please ... |
User Comment
Submitted by chatGPZ on 10 April 2013
"@Groepaz - NOT TRUE - few lines before You have explanation"
so it wont improve by fixing the broken english? ok
and yes, i did look at the zip and even some of the sources. seen lots of .bat files where there should be proper makefiles. another turn-off. wont go through the hazzle of fixing that and installing freepascal just to find out there are undocumented commandline switches either, sorry. |
User Comment
Submitted by Mr Wegi on 10 April 2013
And the only Legend here, as far as I know is Glasnost. :)
When your nickname here I saw my first flash memory was the screen that says "cadgers Noter by Clarence". Glasnost remember as a member of Camelot and a man from doing loaders :)
"please keep up the good work!"
Time will tell if it's worth it to develop .. It is eight months of my work and I knew that with the need to see the same few weeks, I knew that earlier comments may provide only seeing the gif. Basically, my point is similar to HCLs - standard station is 1541 - the rest are rare and really support 1570/71 is because it does not require great changes in the code. In fact, in our exp. ports, and so it is more and more that do not emulate Ultimate 1571.1581. Such spells as support for C16 and other computers are also Krill gave up and here is a man with a lot of insight on the hardware.
Of course that will depend on demand and my free time - including no less doing something for myself that I've always preferred it was not hidden that only he used no other - on the contrary. Also I did not want to force anyone to choose whether trackmolinker bongo - where it is only absolutely required for deterministic version of the loader.
There was no intention of any depreciating my achievements Krills. I am aware also of human habits and did not think I could do any competition of its users. I just created a very comprehensive tool to be used if someone is willing to delve into it.
I must admit that I expected to hate, and of course I do not have my finger Whose point. Deterministic name was chosen deliberately because obviously I decided to show what I was expecting. As for the "mod 254" - the error was in my mind and although mixtures not happened to think it was possible - just in case I decided to document it. As you can see it is very easy to control and direct human hatred. Just to show any of its own weakness and the result is totally predictable. You can write an incorrect syntax of English and be ridiculed. You can enter a strange name and demonstrate how one oscillates at the level of hatred. You can document the expected error ... This allows you to explicitly prove all things human beliefs, prejudices and feelings. It's easy to play the hate if someone is prone to ...
It does not take a great genius to read the post and make sure that the speaker did not even unpack the zip file if it lacks the command line - if all 30 above example is compiled and packed with batch file - is there a command line or not?
Until then - hungry cruncher bongo sources can be compiled on linux system through free pascal. Just replace one line CONSOLE {APP} to {$ MODE Delphi}.
@ Burlgar - thanks for the constructive criticism - each example is compiled demos from the command line, for example:
.. \ .. \ TOOLS \ cmdcruncher.exe-i "exotest.prg"-o "EXODEMO.prg"-prgfile -JMP $080D -Value01 $37
Cruncher without GUI after running shows a list of parameters. All these parameters are described in the GUI tooltips as well as after the compression and the file is saved to the creation of the command line in this case.
Thank you for anything more than watching the picture and draw conclusions.
@fungus Also, I was thinking of the old models 1541.
@Groepaz - NOT TRUE - few lines before You have explanation |
User Comment
Submitted by Kisiel on 10 April 2013
@Burglar,
German Drama = Vote Drama = Hardware Drama = ordnung muss sein aka Greopaz at work. Find a word which not fit and you have one and only Greopaz but if you find real crap on this site where is no ordnung :)
This tool is for coders so if it's crap let history make jugment. |
User Comment
Submitted by chatGPZ on 10 April 2013
"Groepaz, which is the lesser problem ofcourse."
no it isnt. the point is that it is infact NOT linux only. (infact at least one of the supported packers is windows only) *sigh* |
User Comment
Submitted by Clarence on 10 April 2013
Burglar, an example worked for me:
cmdcruncher.exe -i filetocrunch.prg -o crunched.prg -PRGFILE yes -JMP $1000
For the rest type of the packers you can use their original command line tool.
Groepaz, which is the lesser problem ofcourse. |
User Comment
Submitted by Fungus on 10 April 2013
- workin on 1541xx and 1570/71 in 1541 mode
does this mean you made it with 1541-II in mind or only and not older 1541's? I notice many demos from that region do not work on older hardware. I hope it is tested on breadbox and old 1541, as many of us don't like or use 64C and 1541-II. |
User Comment
Submitted by Burglar on 10 April 2013
yes, groepaz can be a whiny bastard sometimes (like now), but he does have a few valid points.
every working loader is indeed deterministic, so why not call it the "Bongo Foreknowledgeable Loader"?
Also a fancy word, but one that covers the system a bit better. Or maybe call it "I know where your sectors are this summer".
Or you keep calling it deterministic, who cares about a word, code is more important ;)
So, I tried to test the (for me) more interesting stuff, the bongo cruncher...
but I'm with groepaz here, only partial commandline support is a turnoff for me. I couldn't figure out how to crunch something selfextracting with basic line.
and the cli support you do have isn't documented.
And that's constructive criticism, keep up the good work and keep sharing your progress, it is much appreciated! |
User Comment
Submitted by chatGPZ on 10 April 2013
| krills loader is linux only? wow. i rest my case. |
User Comment
Submitted by Clarence on 10 April 2013
Groepaz, this tool *has* command line options for both crunching and linking the d64. What else do you miss? I will have to try it thoroughly to see the packer issue, but as I understand, the Doynax/Bongo packers have no issue with the filesize+on the fly depack.
Krill's loader is no option for me, since it is: linux only, it has 1571 compatibility issues. |
User Comment
Submitted by Danzig on 10 April 2013
Please reconsider about "German drama". This is not the uro crisis nor WWII. I myself don't feel offended but utter sorrow for you lame and silly idiots. I would even sign a petition to get your dumb asses banned!
Groepaz has a point here, he just advises the author Mr. Wegi to get some help for proper english. Please be aware that written words are not spoken. So you have to read them in a positive way unless any harsh words are used. |
User Comment
Submitted by chatGPZ on 10 April 2013
i just find it hilarious that someone would insist on this trainwreck of a documentation to be great stuff, thats all. and all i am doing is hinting at the fact that having someone rewriting it (and the on screen texts) in proper english would improve the whole "product" a lot.
and i am pretty confident that i am not the only one who wouldnt touch this stuff. a few comments on csdb mean nothing really. |
User Comment
Submitted by Beastifire on 10 April 2013
| @Groepaz @Kisiel Aw go get a room. |
User Comment
Submitted by Kisiel on 10 April 2013
@Groepaz,
You are one and only man whos not going to use the tool but have plenty of complains about it, this is what we call "German Drama"
I see your point but 80% stuff on this site is 100% of crap and you find something interesting for complain... lucky bastard !!!
Example: your demo is loading to slow, sorry I am not going to watch this crap ;) Downvote them all |
User Comment
Submitted by chatGPZ on 10 April 2013
"this is the biggest effort anybody invested to make a full trackmo linking system publicly available for cross developers"
wat? krills stuff has been available for quite a while. this cant really do anything krills stuff cant (infact, due to the gui stuff and not being commandline, it is less flexible). and other than krills stuff, this one has bad documentation, and is not actually tested much in the wild. (and yes, also that bongo cruncher is bugged, you'll see eventually when/if bitbreaker ever releases his rewrite) |
User Comment
Submitted by Clarence on 10 April 2013
So here we are, as far as I know, this is the biggest effort anybody invested to make a full trackmo linking system publicly available for cross developers,
and we have to read lamentation over the developer's English knowledge, questioning the naming of loader methods, or emphasis on a few avoidable (documented) bugs?
Like every other tool here on csdb is flawless and well documented but this one, yeah, and the scene never ever had controversial naming for technical things.
I rather have it like this, than not have it at all. A bit more positive attitude wouldn't hurt sometimes, you know...
Wegi, please keep up the good work! And the only Legend here, as far as I know is Glasnost. :) |
User Comment
Submitted by chatGPZ on 9 April 2013
| its not "drama" if you expect english words to actually mean what they are supposed to mean, really. or even words being ordered in a commonly accepted order that makes them readable sentences. no documentation at all is better than documentation that you can only decypher if you know the authors personal definition of them. |
User Comment
Submitted by Kisiel on 9 April 2013
Very interesting topic of how to use English words.
I thought CSDB is for stuff from scene not a German Drama aka Groepaz at work ;) |
User Comment
Submitted by chatGPZ on 9 April 2013
"After You clear show what You want - You can't never await from me - I'll treat You seriously."
maybe you should start with writing english that can be read and understood without already knowing what it is supposed to mean. ("You can't never await from me" ? WAT)
as said multiple times already, get someone who knows english and have him proofread your gui text, and your documentation. and eventually learn to accept that some english words actually have a commonly accepted meaning that doesnt match what you think they maybe mean.
|
User Comment
Submitted by Mr Wegi on 9 April 2013
Maybe better go back to Your first post where clear You show what is "incorrectly". Maybe You are not ready for all true. Maybe call deterministic and "MOD 254" was intentionally and I wanted to prove something by providing hate mind... You need get purpose: every one people think not only You... If no one answered on Your post - this not true "You had right" - basically people don't want empty talk.
HCLs simple true logic under Biba 3 VS lot of demagogy and big effort putted in this... Fairy tales for self...
Oh btw. loved demagigic word "randomly" = unknown. MOD 254 <> unknown.
After You clear show what You want - You can't never await from me - I'll treat You seriously. |
User Comment
Submitted by chatGPZ on 9 April 2013
"This seems to be related to file size me guess... Yet another language barrier thing or PC coder talk? Huh for complete coder like yourself this should be quite obvious."
sure. it means that the loader fails when the file has a certain size. ie: unuseable |
User Comment
Submitted by Mr Wegi on 9 April 2013
@Krill - we have 5 infobytes about file here: load address, start trac and sector, lengthblocks of file. We know interleave for all disk - so basically loader recalculated and restoring order for write data sector.
@Glasnost @Clarence - Glad to see You comments - from people I know with credits and who are true legend of C64.
Best regards |
User Comment
Submitted by Clarence on 6 April 2013
I second Glasnost, looks like a very capable loader/packer system, and very easy to use/configure. I will give it a try too in the future.
I don't see a huge problem if it crashes with the aformentioned packers, since it has an own designed flawless packer system which performs quite good according to the tests, no reason to use the rest. |
User Comment
Submitted by snerg on 6 April 2013
@Krill: "Okay, so the main idea of the no-interleave loader is to have a list of sectors for every file track so there is no need for scanning? This is basically what lft's Spindle system does, too.
Or does it skip scanning by knowing the file interleave and thus the block order? This is what i will implement in my loader."
As far as I know you get list of tracks and sectors for all files and you can also set an interleave for whole disk as you wish. More over there are other options implemented like keeping on a drive motor on full speed if needed...
EDIT:
@Groepaz: ""During fly decrunch in case decruncher LZWVL, Byte Boozer, Exomizer or Level Crusher when length crunched file MOD 254 = about 247 (guess between 242 to 254) would be crashed decruncher process."
whatever that means then"
This seems to be related to file size me guess... Yet another language barrier thing or PC coder talk? Huh for complete coder like yourself this should be quite obvious.
Get into the code itself as it is not that hard to understand, play with it and see how clever the loaders routine is. Know nothing about the packers implemented tho.
|
User Comment
Submitted by chatGPZ on 6 April 2013
"During fly decrunch in case decruncher LZWVL, Byte Boozer, Exomizer or Level Crusher when length crunched file MOD 254 = about 247 (guess between 242 to 254) would be crashed decruncher process."
whatever that means then |
User Comment
Submitted by Isildur on 6 April 2013
| Groepaz, as far as I know there is no such bug you are talking about. |
User Comment
Submitted by chatGPZ on 6 April 2013
"Groepaz i have no idea, absolutely no idea why you try to find every little weakness instead of showing a bit of respect for the effort, which is intended to make the life easier for us on the scene..."
i just find it hard to see the benefit behind all the "little" weaknesses. fixing them all seems more work than its worth, thats all. and i can write a loader that doesnt load packed files correctly myself =) |
User Comment
Submitted by Glasnost on 6 April 2013
This pack looks very interesting. I look forward to try it. Big respect from me for ideas and efforts. Groepaz i have no idea, absolutely no idea why you try to find every little weakness instead of showing a bit of respect for the effort, which is intended to make the life easier for us on the scene...
Good work Mr. Wegi. Guys like you make this scene worth participating in.
|
User Comment
Submitted by Krill on 6 April 2013
Okay, so the main idea of the no-interleave loader is to have a list of sectors for every file track so there is no need for scanning? This is basically what lft's Spindle system does, too.
Or does it skip scanning by knowing the file interleave and thus the block order? This is what i will implement in my loader.
I found it hard to navigate the sources. Assuming it takes the former approach, is there a list being processed in a linear fashion, or does the loader find each block passing by the head in the list and then sends or discards it? |
User Comment
Submitted by Isildur on 29 March 2013
| YES it works with virtual D64 disk (1541xx and 1570/71 in 1541 mode but doesn't on d71, d81) |
User Comment
Submitted by Monte Carlos on 29 March 2013
| Does d64 support means emulator support? |
User Comment
Submitted by Kisiel on 26 March 2013
User Comment
Submitted by skull on 26 March 2013
| great work and excellent presentation |
User Comment
Submitted by Urban Space Cowboy on 25 March 2013
| Hey, thanks for releasing your cruncher's source code this time! |
User Comment
Submitted by Mr Wegi on 25 March 2013
| Irony is Your second name - so we go back to bad (In Your opinion) name LOL Groepaz You are pretty essentiall. Trolling and sweet speak own "smart" rules and opinion |
User Comment
Submitted by chatGPZ on 25 March 2013
| quite ironic how that actually means the loader is anything BUT deterministic =) |
User Comment
Submitted by Mr Wegi on 25 March 2013
| Dont be sad Groepaz - go cry to HCL if You read in Byte Boozer can't crunched sometimes any data. Also I don't saw how You cry over EOD - doesn't work on 1570/71. Known bugs - be honestly I guess is possible don't crush over my tried but I wrote this for clearity |
User Comment
Submitted by chatGPZ on 25 March 2013
"I'm not a coder, but quotation from the guide helps me to understand what "deterministic" (in this case) means:"
deterministic means: "always the same predictable result". it has little to do with the loader features.
and no i dont want to use it because the "known bugs" tells cleary that it doesnt even work correctly. (i have no use for a loader that wont depack on the fly, or which crashes randomly if trying to do so)
|
User Comment
Submitted by Isildur on 25 March 2013
@Groepaz,
- "I won't use it because I don't like the name"
- "Girl you are soooo smart" - Daddy said :P
I'm not a coder, but quotation from the guide helps me to understand what "deterministic" (in this case) means:
"When creating trackmo you can predict, assume and most important intend many things. This is
due to fact that you know what you want to achieve, you got some kind of plan or structure in
your mind of how things in your demo should roll. Part of that are all files with your effects,
graphics, music, tables that you want to put together. There is no guessing here I believe. You
know which bank in RAM has been released and how much of a rastertime is free at certain point. You also exactly know what kind of stuff should be loaded to memory at what time. File
name, file length, load address... All that is a base for my deterministic loader.
Idea is pretty simple yet very efficient. Let say you could create a list of all files that should be on your disk. List that apart of file names stores also data about start tracks and start sectors, file lengths and load addresses. What are the advatages of having all these sorted that way?
Well this is what makes my loader deterministic as it has list of info about all files on disk. This way we do not lose 0.2 sec on every one of 35 tracks for scanning. We also do not have to
wait for first block of the file with it's load address and that is another 0.1 sec per file on
average. When there is more than one file on track we do not lose yes again 0.2 for scanning
the same track again. Time savings are massive and all just because we know where our files
are placed before we even try to load them!" |
User Comment
Submitted by Mr Wegi on 25 March 2013
| Discussion with You is empty. You never don't want use it, only do depreciate from any You "smart" reason. Deterministic idea was wroted and retranslated for You in trackmolinker. Of course You will be allways grumbler even when You have solution - only from own malignancy. Save Your breath. Bad called deterministic cos Groepaz have copyright for this... |
User Comment
Submitted by chatGPZ on 25 March 2013
| i might test it if the "known bugs" wouldnt tell me that what i wanted to do with it would randomly not work =P |
User Comment
Submitted by Mr Wegi on 25 March 2013
| You don't even need penetrate it. You fast depreciate comment is enought. Wrong called "deterministic" "disqualifies it". Thanx for "deep tests" and essentially opinion. |
User Comment
Submitted by chatGPZ on 25 March 2013
| its only the tip of the iceberg regarding this trainwreck. and that it wasnt fixed although well known says enough. |
User Comment
Submitted by Mr Wegi on 25 March 2013
| Of course - but You finded cardinal reason - bad name in Your opinion - yes, of course essentially... This is a point... |
User Comment
Submitted by chatGPZ on 25 March 2013
| every loader is deterministic. if it is not, then its broken and unuseable. |
User Comment
Submitted by Mr Wegi on 25 March 2013
| Final2, Final3, AR, this one - every one is deterministic but they have a different methods. I'm sure You understand... So now You have own reason to depreciate - nice =P |
User Comment
Submitted by chatGPZ on 25 March 2013
| dude, you STILL call it "deterministic"? that alone disqualifies it for me, wtf? |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
