| |
Burglar
Registered: Dec 2004
Posts: 1089 |
X2016 Competitions: Your Input Wanted!
The 28th of october is still far away but getting closer and closer. The organizers have been getting busy and are now well underway to get everything sorted out for another smashing X!
Since entry delivery and running the compos at X14 went quite smooth and voting is now done in realtime, we believe we may have room for 1 or 2 more (small/fun) c64 competitions. Like a PETSCII compo or a 4k compo, or maybe you guys have an idea?
Or perhaps you think the straightforward demo/music/gfx compos are enough.
Let us know :) |
|
... 214 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
+1 |
| |
Burglar
Registered: Dec 2004
Posts: 1089 |
I'm sorry guys, but this is getting annoying, it's like you guys don't read my replies at all and on top of that, only few of you seem to have any idea on the pragmatic choices we have to make as the persons responsible for running a great compo, without crashes and without huge delays.
So, let me state the facts once again:
1) All compo's we'll be run from a real c64 (both 6581 and 8580), we will not prerecord.
2) The X2014 compo was probably the first big compo ever to run on schedule, with every compo, including voting, dane performance, prize ceremony and a very nice dinner all on time ;)
It was also the first time we used the 1541U and a voting system capable of delivering a clean SD card with compo entries on the fly. Manually copying files/disks was intentionally not part of the process, and if you look at the result... Pretty damn awesome, if I may say so ;)
3) We are always easy going with deadlines, this requires a flexible compofile generation process where everything is automated. Copying disks can not be automated.
4) We are purists too, if we can run everything from real drives easily, we will. Since everything ran so smooth last time, I think we got room to accomodate some disk copying. If only you loaderguys would only write loaders that don't have to be written by the same drive... That's really what causes all the real problems (crashes, delays, the need to copy with one drive only).
Don't forget, all current loaders run perfectly fine on 1541U and Chameleon, you can't say the same with real floppies and real drives. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
" only few of you seem to have any idea on the pragmatic choices we have to make as the persons responsible for running a great compo"
naturally most of us have no experience on that, so best for you is simply ignore what the inexperienced bastards say ;) |
| |
lft
Registered: Jul 2007
Posts: 369 |
Burglar, I do hear what you're saying; sorry for straying off topic. And I'm happy that you'll try to use real 1541 drives for multi-side demos if possible.
For the cases where this doesn't work, I encourage you to consider MagerValp's suggestion (1541U on the cartridge port of another C64, with IEC cable to the compo machine). To me, this makes far more sense than a Chameleon, since apparently if you hook up a Chameleon, a large part of the machine will be emulated. |
| |
Burglar
Registered: Dec 2004
Posts: 1089 |
lft, isnt it possible to just hook up the chameleon to the serial port? as a standalone emulated 1541? :) |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
1541u has standalone mode too, tho d64 selection blindly must be complicated :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11359 |
tape compo then. problem solved \o/ |
| |
Grue
Registered: Dec 2001
Posts: 161 |
Quote: lft, isnt it possible to just hook up the chameleon to the serial port? as a standalone emulated 1541? :)
Chameleon works very badly as external stand alone drive, it has serious timing problem on iec connector that makes some of the demos fail miserably. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 504 |
Quoting Burglar
If only you loaderguys would only write loaders that don't have to be written by the same drive... That's really what causes all the real problems (crashes, delays, the need to copy with one drive only).
Don't forget, all current loaders run perfectly fine on 1541U and Chameleon, you can't say the same with real floppies and real drives.
I am on it :-) Just had more than 1100 successful reads without a single error on 2 other drives on a disk that was written on a a 3rd drive these days :-D @ X 14 the loader was still less tolerant, but the handed in disk worked fine on the censor and oxy setup, but failed on the compo setup :-D At least we always dared to run from real disk, despite the fails :-D Freezing for diskchange always bears the risk of crashes/fuckups when using NMIs, what we also dare to use in turn disk parts :-) |
| |
soci
Registered: Sep 2003
Posts: 479 |
I've just did a small research on the limited set of popular loaders I'm aware of. Mostly by reading the source code but also testing them by injecting random errors.
Result:
* Bitfire - OK
Does checksum and retries.
* Boozeload - Fail
No checksum, no retry. Junk in, junk out.
* Covertbitops - OK
Does a configurable number of retries, might fail if it's set too low.
* Dreamload - Fail
No checksum, no retry. Garbage in, garbage out.
* Krill - OK
Checksums, retries
* Spindle - OK
Checksums, retries
Any corrections are welcome.
Good to see that most still consider real world use. |
| Previous - 1 | ... | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 - Next |
