Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Coding on a PC for the 64?
2016-01-11 05:53
Stablizer

Registered: Jan 2016
Posts: 19
Coding on a PC for the 64?

I've seen various editors out there, currently starting to use the C64Studio for this, but it seems like getting charsets, graphics, music, etc, is a bit problematic when going at it this way, isn't it?

Would love to get some pointers to reading material on the subject (have done some searches already, but haven't come up with anything notable really).

Thanks!
-Stab
 
... 179 posts hidden. Click here to view all posts....
 
2016-01-21 18:27
soci

Registered: Sep 2003
Posts: 480
Quoting Bitbreaker
What's next? Will you also implement your packers into your .asm source or still use external tools for that?

Obviously such functions in assemblers are meant to be used for simple stuff not warranting the creation of an external generator. I was fed up with creating them for trivial offset tables, and copy/pasted bytes take a long time to tweak later if I need to modify them by hand. Especially if I've already forgot how they were made ;)

"Optimal" speed code solutions (more complicated than just unrolling) comes from external tools which split out an asm source (with labels), which gets included and assembled. This later either stays as it is or I turn it to some much shorter binary data which is converted into executable at runtime by an "expander" code.

Packing and picture conversions inline? Nice as a personal challenge and good luck with that ;)

Better use the proper tools for the job. It's not always the assembler, and not always an external tool either.
2016-01-21 18:52
The Gothicman
Account closed

Registered: Aug 2011
Posts: 40
Quote: Quoting Bitbreaker
What's next? Will you also implement your packers into your .asm source or still use external tools for that?

Obviously such functions in assemblers are meant to be used for simple stuff not warranting the creation of an external generator. I was fed up with creating them for trivial offset tables, and copy/pasted bytes take a long time to tweak later if I need to modify them by hand. Especially if I've already forgot how they were made ;)

"Optimal" speed code solutions (more complicated than just unrolling) comes from external tools which split out an asm source (with labels), which gets included and assembled. This later either stays as it is or I turn it to some much shorter binary data which is converted into executable at runtime by an "expander" code.

Packing and picture conversions inline? Nice as a personal challenge and good luck with that ;)

Better use the proper tools for the job. It's not always the assembler, and not always an external tool either.


Check your FB-account, Rene.
2016-01-21 21:35
Slammer

Registered: Feb 2004
Posts: 416
Quote: Nice to see you playing with little toys, sinus waves and simple code snippets, but how will you do complex code generation that spits out for e.g. the optimal solution depending on the input? Think for e.g. of fading out a koala in independent 40 columns?
What's next? Will you also implement your packers into your .asm source or still use external tools for that?
I really don't get this mixture of tool code and .asm source in one file. What's so complex about having a makesinus.c/.py/.pl/whatever? Some years ago, a few lines of basic were enough to poke your desired sinus into ram, which was then saved out to disk with the monitor. Nowadays you do, as if this is rocket science :-D

P.S. Yes, with having the stuff separated, the generation does not need to happen on every build, but only if there's changes. And this makes pretty much of a difference on demo projects of a certain size. (comaland builds in ~8s on my i7 her after a make clean, but in rebuilds in zero time if just some changes are made)


For simple tasks scripting is very convenient. Things like importing and converting sprites or charsets, importing sidfile from hvsc or just rearranging stuff to the crazy graphics format you are using.

Lets have an example. You can convert a standard 2x2 charset from a gif-file to the standard format with four series of corner chars by this:
   .pc = $2000 
   .var charsetPic = LoadPicture("2x2char.gif", List().add($000000, $ffffff))
   .fill $200, charsetPic.getSinglecolorByte(  2*[i>>3],   i&7) 				 
   .fill $200, charsetPic.getSinglecolorByte(  2*[i>>3], 8+[i&7])
   .fill $200, charsetPic.getSinglecolorByte(1+2*[i>>3],    i&7) 
   .fill $200, charsetPic.getSinglecolorByte(1+2*[i>>3], 8+[i&7])
Now for a complex task I would use java or C# (But C, C++ etc. would be just as fitting). For example I did a routine to precalculate some halfcut hidden vector coordinates in Java and at the same time got the visualization library from Java to verify they where correct. Its just a matter of picking the tool that is right for the job.

Now if you misjudge the task and it turns out to be heavier than expected, you can always dump the result to a file and import it as a binary.

By the way. I don't see anything against using techniques like this together with a make or ant file. And its only an option, you don't have to use them if you use KickAssembler. You can perfectly well start out with the traditional: *=$1000, .byte, .text etc. and then later pick the features that suits you like scripting, pseudocommands, macros and scoping if you feel like it.
2016-01-22 00:44
chatGPZ

Registered: Dec 2001
Posts: 11386
Quote:
importing sidfile from hvsc

seriously, if you cant write
.incbin "gurken.sid",,$7c

then please go stand in the corner :)
2016-01-22 06:10
Oswald

Registered: Apr 2002
Posts: 5094
I cant, since I dont know the header length, but I can find it out for myself tho :)

its a pointless argument anyway, tastes differ, everyone does it as he likes it.
2016-01-22 08:56
mankeli

Registered: Oct 2010
Posts: 146
Quote:
Nice to see you playing with little toys, sinus waves and simple code snippets, but how will you do complex code generation that spits out for e.g. the optimal solution depending on the input? Think for e.g. of fading out a koala in independent 40 columns?
What's next? Will you also implement your packers into your .asm source or still use external tools for that?
I really don't get this mixture of tool code and .asm source in one file. What's so complex about having a makesinus.c/.py/.pl/whatever? Some years ago, a few lines of basic were enough to poke your desired sinus into ram, which was then saved out to disk with the monitor. Nowadays you do, as if this is rocket science :-D


Actually it would be nice if an assembler could directly output an exomized .prg :-D

Also, it's not complicated to write separate data generators, it's just more convenient (for me) this way. I need a sinus, so i'll just write a for-loop directly to the source file to generate it. If I need to load a picture, i can just load a .png, run hires conversion right there and then just output bytes. If I want to fade out a koala in independent 40 columns, i can just generate my tables (and code) there as well. :)

But in the end, it's just one more tool in the toolbox. Like some people prefer to program in monitor, some like assemblers. And think about early 6502 coders who wrote machine code directly, I bet that some of them never wanted to move beyond that.
2016-01-22 17:56
Slammer

Registered: Feb 2004
Posts: 416
People should do it the way they are most comfortable with and that fit them best. In the end its the result that counts. I hope this has given some positive examples of scripting to balance Groepaz' rather negative view where everything is 'stupid', 'silly' and 'improper'. Also, it have been cool to see the different approaches!
2016-01-22 18:00
chatGPZ

Registered: Dec 2001
Posts: 11386
bitbreaker, perplex, tmr, axis, fungus, 4mat, algo, radiance...

i think you will find that actually most ppl prefer to work with those seperated tools, and that most ppl are actually able to use incbin for including their data. and for good reasons :)
2016-01-22 19:23
Hoogo

Registered: Jun 2002
Posts: 105
Quoting Slammer
...Also, it have been cool to see the different approaches!
Yes, really interesting to see how new concepts and elements from Basic or Java are put into an Assembler.
What about esoteric elements? Maybe someone could put an Assembler in an Assembler, so we can assemble while we assemble?
2016-01-22 19:42
Pantaloon

Registered: Aug 2003
Posts: 124
while you all have been writing in this forum ive almost completed my revision demo :)
Previous - 1 | ... | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | ... | 19 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
katon/Lepsi De
MWR/Visdom
Chesser/Blazon
hedning/G★P
LightSide
Mike
Steffan/BOOM!
t0m3000/hf^boom!^ibx
Trap/Bonzai
4gentE/ΤRIΛD
Perplex/Offence
Walt/Bonzai
REBEL 1/HF
Mibri/ATL^MSL^PRX
Inge/HVSC
Guests online: 119
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 No Listen  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Fullscreen Graphicians
1 Joe  (9.7)
2 Sulevi  (9.6)
3 The Sarge  (9.6)
4 Veto  (9.6)
5 Facet  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.06 sec.