[CSDb] - User Forums - SID-Wizard

You are not logged in - nap

CSDb User Forums

Forums > C64 Composing > SID-Wizard - further development

2012-07-08 16:59

Hermit

Registered: May 2008
Posts: 208

SID-Wizard - further development

Hi

I opened this new thread to discuss upcoming ideas for SID-Wizard which I released on 7 July.
SID-Wizard V1.0 RC

As you can see the source code is entirely shared, so you might contribute to the code yourself in some way if you wish.

As a starting point I'll try to make a sketch of the whole code-structure which might help to find parts of the program.
Soci gave some ideas which I think will be described soon in this topic.

thx for your great feedbacks

... 47 posts hidden. Click here to view all posts....

2012-10-19 14:31

Hermit

Registered: May 2008
Posts: 208

Hi Guys

Glad to see your interest.

I'm surprised about the fact that the newly added 'startupmenu.inc' isn't in the repo.
If you check out the repo through web-interface, revision 150 contains the file in the list:
http://sourceforge.net/p/sid-wizard/code/150/tree/trunk/source/..

Anyway, according to my experience, sourceforge svn interface has some unreliable things. Sometimes it took some days to see my latest additions through the web-interface and sometimes the trunk version number is very misleading (even went down to around 20 at a time...)

Fortunately at least the core of the svn seems reliable...

About open-source: I like the good side of the open-source, that everything is free, and sometimes really good stuffs can be found. But I agree that teamwork can show some difficulties (especially in assembly), that's why I first code things myself and when the base is ready more or less, and the concept is clear, a help from anyone comes handy.

It was a good experience to work together with Soci for a while after SW went to svn, that was my first time of online open-source teamwork...
(And now Conrad and me will have a little surprise for you if everything goes fine.)

The 1.2 release is coming very soon, but I want to make some example tunes and finish the startup-menu to avoid too many executables in the binary folder :)

Now it supports NTSC since yesterday to a great degree in the editor... The PAL/NTSC detection (in commonsubs.inc) was based on Ninja's code, but I just coded an even simpler (and I guess reliable) method, that doesn't have to check IMR register, just plain $d011,$d012...

detect	sei ;hermit's PAL/NTSC/etc detector...
        bit $d011
	bpl *-3   ;wait for upper screen region above rasterline $100
-	lda $d012
	cmp $d012 ;wait for 1 rasterline (no matter what CPU speed it is :)
	beq *-3
	bit $d011 ;check if we reached 0..$ff raster-region again
	bmi -
        sta max_rasterline_low_byte ;the Accumulator here contains the last rasterline that was before $100
        ...

;the resulted values in Accu.: PAL/Drean:$37, NTSC:6, old NTSC:5

Maybe something like this has been coded already. This way I'll be able to detect some more types and still free up some memo (unless this code turns out to be unreliable)...

2012-10-19 15:31

tlr

Registered: Sep 2003
Posts: 1714

@Hermit: Great! I was just trying to build the current wip.

@SIDwave: ?

2012-10-19 15:42

tlr

Registered: Sep 2003
Posts: 1714

Quoting Hermit

detect sei ;hermit's PAL/NTSC/etc detector... bit $d011 bpl *-3 ;wait for upper screen region above rasterline $100 - lda $d012 cmp $d012 ;wait for 1 rasterline (no matter what CPU speed it is :) beq *-3 bit $d011 ;check if we reached 0..$ff raster-region again bmi - sta max_rasterline_low_byte ;the Accumulator here contains the last rasterline that was before $100 ...

;the resulted values in Accu.: PAL/Drean:$37, NTSC:6, old NTSC:5

Maybe something like this has been coded already. This way I'll be able to detect some more types and still free up some memo (unless this code turns out to be unreliable)...

Your first stop before inventing anything new would be: http://www.codebase64.org/doku.php?id=base:detect_pal_ntsc

by J0x:

l1 lda $d012
l2 cmp $d012
   beq l2
   bmi l1

;)

2012-10-19 16:13

chatGPZ

Registered: Dec 2001
Posts: 11107

Quote:

coder 1 dont know what coder 2 does, bugs appear, planless development with "great" ideas.

so what exactly is the difference to a closed source project then? =)
Quote:

Now it supports NTSC since yesterday to a great degree in the editor... The PAL/NTSC detection (in commonsubs.inc) was based on Ninja's code

as for the editor, i would simply compile two binaries and not bother about detecting anything at runtime.... wasted time and effort it is =)

2012-10-19 18:10

Hermit

Registered: May 2008
Posts: 208

tlr: wow, this is really awesome short TV-system detector. Scene knowledge kicked in here and came very well :)
l1 lda $d012 ; l2 cmp $d012 ; beq l2 ; bmi l1
Lol, I wonder how I haven't come across it after some googling. (And I wonder why assemblers don't use the ; , or some other separator to group commands in one single row.)

@SIDwave: I know what you're talkin' about, in the past I tried a hundred bunch of Linux distributions and variants. Linux is still not perfect as the underlying mainstream hardware is kinda shit too ('Neumann bottleneck' caused by slow RAMs, cache/buffer 'workarounds', pipelining, etc.). Btw now I have a MacMini and I use Lubuntu on it, good combination with low noise and power consumtion, and small size. Still far from my ultimate platform - the planned parallel architecture - (sometimes Lubuntu even slows down in simple text editor too), but Lubuntu is what I like the most of all. The power of Ubuntu 'comfort' with much lightweight GUI. (In the past I used puppy linux, that's great too, but less 'user friendly' so to speak...)

@Groepaz: What I'm trying to do is to have the different player/driver versions (normal/light/medium/extra) in the same app. It's not new idea of mine after all, e.g. JCH editor can load different player versions IIRC. What I'll do that I include all of them in one binary (until it's easy to handle the binary-size under different circumstances). Coz only the player is the difference between the versions in the 'binary' dir. On the other hand some guys reported that they would like to have different frequency-tables (some prefer DMC's, and some wouldn't use equal-tempered scale in some musical keys), and that'd be a really nice feature from musician point of view to be able to select/load players/frequency tables. I'll see what I can do about it...
The best solution still would be to be able to assemble player.asm on the real C64 and optimize code on-the-fly where possible, but I don't know about a suitable assembler that I could build into the programs, that would identify at least '.if' directives...if someone points out something useful it would be great...

2012-11-14 21:48

Hermit

Registered: May 2008
Posts: 208

Well...you know I released SID-Wizard 1.2 some days ago, thanx for the nice comments & votes.
SID-Wizard V1.2
I added some features that were wished here in this forum, and more to come till it fits into the memory of C64 ;)

The feedback is really appreciated and needed to improve (and not to overcomplicate) the tool into right direction. Especially because I don't have too much time yet to test in practice, I'm trying though. Thanks to Necropolo who tested it a lot and reported possible bugs and created the majority of the example tunes. Testing is a very important (if not the most important) part of the development.

And special thanks to the new CSDB member WitchMaster for 'Creating Chip Tunes with SID-Wizard' and the fast reference charts/cheat-sheets.
Creating Chip Tunes with SID-Wizard
Charts and Tables for SID-Wizard V1.2

At the moment I'm taking some relaxation with other activities to continue then with fresh brain...
The plans for the near future - end of this year:
SID-Wizard 1.4 will possibly come out around Xmas with these significantly new features:
-sng2swm will be finished soon
-due to memory constraints I'll have to optimize the editor-code, and player-code too of course. Some help would come well in this area, I might not be a good code-optimizer. Soci helped me a lot already to simplify keyboard-handling, especially key-repeats.
-improved keyboard-navigation, maybe use of mouse/joystick to go into panels/windows/tables
-some more keyboard layouts (not just note-keys but function keys too)
-support for 2 SIDs - the interface will only show 3 channels/tracks at a time but they'll be scrollable sidewise or up/down in orderlist.
-native help-text as a .prg executable on the disk
-some more frequency tables (e.g. Verdy tuning at 432Hz, non-equalTempered) will be calculated on-the-fly (in start-up menu) after selecting tuning and musical key...
-I'll finalize the promised MIDI-hardware. First the easy-to-build simpler monophonic one, than I'll go for polyphonic too for full composition/performance experience.
-Metronome...in case the composing starts with the solo-melody theme
-The Video tutorial. And at last I'll translate the manual to Hungarian as it was requested at Arok Party.

that's it for now ;)
Sould you have any ideas or you experience problems you can still post it here...

2012-11-16 08:45

SIDWAVE
Account closed

Registered: Apr 2002
Posts: 2238

forget all about joy/mouse stuff, it will make things bad.
IMO

2012-11-16 11:51

Frantic

Registered: Mar 2003
Posts: 1627

@Hermit: Not sure if it helps, but Turbo Macro Ass (in contrast to Turbo Assembler) has pseudo opcodes like:

.IF
.IFNE
.IFEQ
.IFPL

2012-11-16 12:54

Hermit

Registered: May 2008
Posts: 208

Thx, frantic.

Accidentally I just checked it yesterday and it really has. My problem is that I couldn't find a source at 1st glance, and from this macro-assembler I only need the assembler part without the editor code.
The other issue is that I'm not sure if the source-code (stripped from the comments of course) will fit into memory together with the assembler-code beside the music data which can be very big in cases. Possibly it would fit, because there would only be one instance of the player (source) and relocation-tables wouldn't be needed in that case.
The biggest benefit without doubt would be the .IF .ENDIF to leave out the code-parts which are unused in the music.

If this reloc.-table solution remains TLR told me another good idea, to generate the reloc. table by code, not by hand. If the assembler (64tass) itself would be able to generate a list with the absolute-addressing instructions that would be the best.

Btw, there's another issue with the code-optimization: If timing changes due to the optimizations, it can be enough to make the exported tune sound differently than it was in the editor with the full player.
there could be a workaround to solve that, namely using ghost-registers. This is the way GT can export the tunes to sound the same as the edited version.
At the moment in SW It's guaranteed to sound nearly the same because the 4 player-types are compiled the same way as they're in the editor (however in editor zeropage is extensively used for the player to compensate timing differences caused by the injected editor-related code, badlines and cursor-sprite.)

In the current player.asm the big-effects are arranged in a way that the most used are in the beginning and the less used are at the end, so it wouldn't be hard at this point to cut down the unnecessary big-effects from the compiled player in SID-Maker and get a considerably reduced player-size.

good to have some brainstorming around this topic because the resultant music's size and rastertime can be very important after all...

2013-01-15 01:13

SIDWAVE
Account closed

Registered: Apr 2002
Posts: 2238

deleted

Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next

Refresh

Subscribe to this thread: