Sounds almost like a good argument for a 'Completed Projects' forum. Easier searching.

_________________
Bill

It's Mike you'd need to convince. Perhaps a good way to start would be to collect a list of threads which would best have fitted in the proposed new forum, and see how many there are. If it was 'Completed Projects' that'll be markedly fewer than if it was 'Projects' and my feeling is that this would not be the answer. Far better, in my view, to see ten projects in progress, many of which never will be complete, but some of which will spark interesting discussion and might inspire someone to make something.

As I say, start a thread, collect some interesting things and some interest, and show that the material is there. Even if you don't get the forum you'd like, you do at least then have a place to discuss.

I think a better idea would be to have one of the pages that can have links to project threads in the Hardware forum.

I've been on some forums with ancient sticky threads, dead topics, etc., and, yea, they clutter everything up.

Or, we could just have a topic naming policy in the Hardware forum: "Project: <project name>", then folks can easily search for "Project" threads if they want to.

But at the same time, we have things like what BDD is fighting on his 2.0 board. I wouldn't want EVERYTHING he encounters in his "project" thread. Some things just need to be pulled out for focused, timely discussion vs buried in a 50 page 5 year old thread.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Yes, I think the main point is having things in one place for people to look at. It is really interesting to scroll through and see what people have done, at least on other forums I've been to. There is no easy way to do this now.

This is not very helpful for people looking for projects other people have done.

Agreed, but many people (like me) would not go to the hassle of setting up their own website. It's a lot easier to just start a thread.

Just my opinion, but this is needlessly complicated compared to just starting another forum. I doubt that many people would go to the trouble, unless you're suggesting someone would be in charge of doing this on everyone's behalf (also not very appealing I think).

Agreed! A lot of projects are never really "completed" but still a success.

It might be a better idea to be able to tag threads, and then be able to search with tags. It's still on the poster to tag their thread, of course, and i have seen some awful mis-tags, but it would make filtering search results a little easier.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

All this discussion on forum features should be conducted on the thread which Druzyek already linked.
viewtopic.php?f=1&t=4962

Most of the programs used so far doing the benchmark are using the given algorithm. Long time I thought it is necessary to distinguish between the "classic" BASIC V1 version and e.g. the C-V2 version, but due the feedback here I think the distinction between them is not correct.
The BASIC V1 version is a simple and straight forward implementation of a brute force approach. The particular used BASIC version (a MicroSoft variant) does neither know integer variables nor the modulo function. Further the FOR..NEXT boundaries are computed once, so using the square root isn't a big penalty. These constraints lead to the given program. Later BASICs do know integer variables and accordingly the implementation of the algorithm is adapted in order to verify any effects. This is as well true for other languages. Using their capabilities to construct both loops is simply a continuation. This holds true even for things like variable length division within assembler (Chromatix). So far all programs tested the candidate number against all odd numbers up to the point where the quotient becomes smaller than the divisor or the remainder was zero.

The latest discussion was about extending the algorithm to avoid divisions where possible. This is of course something different. The results of these tests cannot be compared in a simple fashion against the "traditional" ones. Of course they can be compared against each other to verify which measure causes which effect. Some may even be counterproductive if the implementation overhead is bigger then the net effect.

In a lazy moment I took the idea of tweaking the algorithm by using a sieve or by wheeling and write some BASIC variants for them. As I use a SYMimlar old NMOS system running at 1 MHz this took some time and I only run them within 16 bit space but I think one can see some interesting effects. The various source programs are appended. They are quick hacks, neither nice and good readable nor written for utmost performance.

I took the "classic" approach as reference against the "enhanced" versions. -10% means if the reference took 100s the enhanced versions took 90s.

Avoiding divisions by 3 starts great but then the win drops down to 5% only. Avoiding divisions by 3 and 5 are only for small numbers a little better. Sieving (using only primes for division) starts good and maintains its effect perhaps with a little tendency of getting better. Combining sieving and wheeling seems to add linearly.

Next I ported the programs to the Badge where EhBasic V2.22 is installed. Again the "classic" variant is taken for reference:

To my very surprise none of the "enhancements" have had a positive effect! This is a completely different behavior than MS-Basic shows. I am pretty sure that I didn't make a silly mistake. I rerun some of the tests several times without significant changes. Perhaps someone else could verify this strange behavior?

Taking all these numbers into one chart (with corrections for the different clock speeds) shows that EhBasic is still always faster.



Cheers,
Arne

Hmm, interesting, but also rather surprising. Why would a bit of wheeling not improve EhBasic's runtimes? Perhaps the wheeling is adding friction... I see

22 IF C-T3=6 THEN T3=C : GOTO 80

Whereas I would normally like to do something like


X=6-X
C=C+X

but of course when using FOR..NEXT we can't so readily tweak the increment. It's a bit awkward: there's no neat way to restart the loop, other than using a GOTO which (probably) costs a rescan of the program text from the start. Whereas a GOTO in assembly language just goes where it should, and an IF..THEN..ELSE in a block-structured language can skip the body of the loop.

We're seeing limitations in Basic's facilities, I think.

Well, I know I could have use
FOR I=1 TO 4000: D=P(I): ... NEXT
but this idea comes much too late. And it may have side effects when exiting a FOR..NEXT loop early.

And again - I never ever thought that EhBasic response so much different


Cheers,
Arne

Ah, wait, it should be as simple as
22 X=1-X : C = C + X*2
which is to say, every other iteration you increment C by an extra 2, which skips over the multiples of three.

That might be faster as
22 X=1-X : IF X THEN C = C + 2

And of course the same for the inner loop.

Here's another thought: benchmark MS vs Eh Basics in doing a GOTO skipping over a reasonable number of lines. Perhaps EhBasic is much slower at GOTO (and maybe that could be fixed).

Yesterday I tried to get things working on an emulated Tandy CoCo3 (with a 6309), only to discover that VCC fails to implement quite a lot of the 6309's instructions - including, in the ready-compiled versions available, division. BASIC09 exercises the latter when using integer variables; I haven't tried it with floating-point yet. It's really hard to implement any of these algorithms when MOD(int,int) returns zero unconditionally.

BASIC09 looks like a surprisingly sophisticated dialect, with a lot of structured-programming facilities that were apparently inspired by Pascal, and even a degree of type-safety. It might have gone some way towards satisfying the spec for BBC BASIC, if it weren't for the relative difficulty of starting the environment and entering a program (the built-in line editor is very non-intuitive, and the manual has the gall to call it a "screen editor", which it definitely isn't). It even claims to include a compiler, but it produces I-code which sounds very similar to BBC BASIC's tokenised format, and which according to the performance figures in its own manual has something like a 10x interpretation overhead (and that's being generous).

I'll have to see if I can find a CoCo3 emulator that actually *works* in 6309 mode.

NitrOS-9 also apparently includes a C compiler. That will also be interesting to try out...

Have you tried MAME yet? I could not find a good 6309 emulator to play with either, so I ended up copying my code into the rom file that comes with MAME at the address where execution starts. It is not ideal, but it works for playing with assembly.