MaxCoderz

The routine may only use a, bc, de, hl, ix and the array given. The stack may be used aswell.

I can't use space in saferam to store data?

And what do you mean with double? Like double bytes aka. a word?

No, saferam is not available.

With double i mean; some values are two times in the array (like 15).

Please don't post in the competition thread

What's the objective here? Smallest or fastest routine? Writing a small one isn't much of a challenge, even my tutorial includes one...

Also about what to optimise for(size or speed). Should the routine be abe to handle an array greater than 256 bytes? Any value in the array or just a limited spectrum?

CoBB wrote:What's the objective here? Smallest or fastest routine? Writing a small one isn't much of a challenge, even my tutorial includes one...

Atm it is size, but if you come up with a system to judge speed-size, it would be both

Should the routine be abe to handle an array greater than 256 bytes? Any value in the array or just a limited spectrum?

The array can be of any length. So that would be a yes I gues. Any value in the array? I don't know. Values can be between 0 and 254.

Like all routines there is one best (smallest) way. And with a routine like this, it's possible more than one person will find it.

Spencer wrote:Like all routines there is one best (smallest) way. And with a routine like this, it's possible more than one person will find it.

Meaning 'multiple' winners

This doesn't sound much like a competition right now, you better set some more rules to define _one_ winner. Figure out and post a weighing system for size/performance and try out the sorter on a set of generated arrays only revealed when the deadline is passed. Some sorters work better on some data (say halfsorted or near totally reversed order etc). Any length, does that mean max 16-bits offset?

I just think competitions should be a bit more strict and follow certain rules that are unquestionable and there should only be one winner. Otherwise, where's the glory of winning?

coelurus is right, there should be rules that will enable a clear winner to be found.

I think it should just be something like a pointer to the array is passed in hl and the routine should sort it and return. No extra args passed, no ability to know before-hand the contents of the array.

If you help me set up better rules it would be nice... I am just human too

Unless there is a prize I don't think better rules are really needed. So what if there are multiple winners, just hand out more congrats.

The problem here is it's hard to judge in speed, because the data affects the speed in most cases. If this were a sprite rouitine or an aligned mapper where the data has little affect on the perfomance speed may be a more viable judgeing criteria.

There's a very simple solution to that: fixed test cases. Like we do for the declarative programming course: homeworks are submitted to an online tutoring system that runs them through some tests and sends back execution time. After the deadline all programs are evaluated on a different test set, so people won't 'optimise' for the submission cases (like hardcoding the results and spitting them out immediately).

Still, how would you wiegh a size to speed ratio. Whats cosidered worth the size or the loss of speed.

Then agian, I would like to see a z80 quicksort routine Does one exist?

Well i think you are right with what you said before ... This isnt really a serious comp. More like a good excuse to write a routine.

Jim e, your entry is ... interesting .

I seem to recall sigma having done that. But it isn't a particularly hard programming problem, so there must be lots of implementations floating around.

Weighing: announce a speed winner and a size winner. It would be rather hard to beat you in the latter category.