Denial

As some of you may or may not know I've been working on merging C64PrgGen and VIC20PrgGen into one app, you guessed it, CBMPrgGen.

I've got a framework together and like your opinion on it, basically. Note that it's just a demo of the framework, you can't do any prg genning with it yet!

http://www.mediafire.com/?7rhhs0wh723fcox

A few others have already had a look at it and the consensus is a 50/50 split between those who like it and those who thinks it's a bit overkill.

Anyway, please take a look (don't forget to read the readme!) and let me know what you think, either here or at ajordison@yahoo.com

Cheers

I haven't tried it, but I think it's a good idea, so you don't have to make the same updates on both applications in the future.

Boray wrote:I haven't tried it, but I think it's a good idea, so you don't have to make the same updates on both applications in the future.

That was the idea really. It's a pain keeping two apps, which are 99% the same, up to date. Plus it's a good opportunity to give both prggens a lick of paint!

Looks good so far. I like the color you have added to the text. Keep up the great work.

I like the look of this a lot.
I don't think it's overkill in the slightest. Then again, I don't really know what overkill would be - the more user friendly you can make it the better!
Looking forward to the finished product!

Seeing the assembly window reminds me of something I started but will never finish - an editor that instantly assembles what you are typing (with instruction codes and timing displayed). The little demo I did in C# demonstrated to me that it's easily fast enough...

Kweepa wrote:I like the look of this a lot.
I don't think it's overkill in the slightest. Then again, I don't really know what overkill would be - the more user friendly you can make it the better!
Looking forward to the finished product!

What I mean't by overkill is that I don't want to force people to create projects when all they want to do is throw a quick program together. I think I've covered that with the default project though.

Kweepa wrote:Seeing the assembly window reminds me of something I started but will never finish - an editor that instantly assembles what you are typing (with instruction codes and timing displayed). The little demo I did in C# demonstrated to me that it's easily fast enough...

That sounds interesting, how does it cope with branches/jumps etc?

ajordison wrote: What I mean't by overkill is that I don't want to force people to create projects when all they want to do is throw a quick program together.

Oh, I see. Yeah, it's pretty quick to get a project started, so I think you're on the right track.

Kweepa wrote: That sounds interesting, how does it cope with branches/jumps etc?

Well, it doesn't yet, but the idea is to keep track of labels and references in a couple of dictionaries so that if a label moves, I update references, or if one changes, I invalidate the references (and write XX in the compiled instructions) and so on.

I have another thing to add to my wish list if at all possible. I want to be able to use the undocumented op codes. At least the ones that don't end in a reset or crash. I know back then they were "undocumented" but today they are well documented.

Just a thought if possible.

GreyGhost wrote:I want to be able to use the undocumented op codes.

Excuse my curiosity, but what opcodes do you use and in which context?
I am always eager to learn new tricks despite being an old dog

The only opcodes I have encountered so far are ANC, ASO, AXS and that was in a demo.

Not saying that I would have use for all of them but, a few of them would come in handy now and again. If you are interested in learning about them a quick search of the internet will produce many texts on the subject. My interest was peaked when I was looking over DEC2HEX converter from this thread.

http://sleepingelephant.com/ipw-web/bul ... highlight=

Seeing your name peppered throughout that thread makes me wonder if you are poking fun. While some of those opcodes would do no good to a noob like myself, I'm sure you and some of the others here could find many fine things to do with them. It doesn't have to be a demo to utilize them. It was only a suggestion because they are there, why not try to use them.

As far as the opcodes I use, I use the ones that are available to me. I am unable to use the undocumented ones because Vic20 PRG GEN does not allow them and that is the program I have adopted to start learning assembly language(of course I could add them in using .byte I guess). If I had the ops to choose from I'm sure I would find a use for them eventually.

GreyGhost wrote:My interest was peaked when I was looking over DEC2HEX converter from this thread.

http://sleepingelephant.com/ipw-web/bul ... highlight=

Seeing your name peppered throughout that thread makes me wonder if you are poking fun.

You got me here. Honestly I did not notice the use of illegal opcodes back then. dec2hex uses "lax" to load A&X at the same time. May save a byte every now and then.

GreyGhost wrote:While some of those opcodes would do no good to a noob like myself, I'm sure you and some of the others here could find many fine things to do with them.

No need to be humble, I am a noob myself. I just started learning about disk I/O on the VIC, because in the 80ies I only had a tape recorder.

I have to admit I never used illegal opcodes yet. Recently, I stumbled across the three opcodes mentioned above in a demo and that got me started thinking about possible uses.
But as Mike said in another thread, mostly performance/code size is influenced by optimisation of the algorithm, not a few cycles/bytes saved by tricky code.
That is perhaps the reason why I only found some in a demo where indeed every cycle counts.

@GreyGhost, @Kananga: I made a follow-up in the Programming section, the thread '65xx Opcode statistics, an example'. Maybe we should discuss this matter over there before the thread here gets derailed.