| |
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....
|
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Quoting PerplexI prefer many small tools that do one thing each and do it well, and that can be combined in a limitless number of ways that even the authors themselves never thought about.
What he said. |
| |
Fungus
Registered: Sep 2002
Posts: 686 |
Same with dedicated small tools that do things right rather than some integrated IDE that does everything but nothing well.
NP++, tass64 w/syntax highlighting, batch scripts, and other small tools like exo and CC1541 for me. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
fungus is my cross-ass bro! |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
Quote: http://codebase64.org/doku.php?id=base:crossdev
batchfiles?
Burglar provided this excellent article http://codebase64.org/doku.php?id=base:cross_development_using_.. and is just too modest to stick your nose right at it :)
PS: I am using sublime 3 and whatever assembler is required. Mostly Dreamass and ACME - very rarely kickass. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
I dont understand that make tut.
# our implicit build rule
%.prg: %.s
java -jar /usr/share/java/KickAss.jar $< -o $@
# default build target
all: intro.prg
so how does make know that intro.prg should be fed into the implicit rule? how does it even know its an implicit rule ? |
| |
T.M.R
Account closed
Registered: Dec 2001
Posts: 749 |
Using ACME with Crimson Editor here, the latter can call the former directly from it's user-configured tools menu or with control/1 so i don't need batch scripts for the majority of jobs. |
| |
soci
Registered: Sep 2003
Posts: 480 |
No idea what's this fuss about using graphics, and music in productions.
At minimum you need to be familiar with the "data" you're trying to "import". Unless you're favouring black boxes instead of learning something.
Common formats are well documented all over the Internet, so there's no need to disassemble utility programs to gain knowledge of save formats, or display code.
Most common assemblers can split out parts of binaries just fine. Figure out once, then copy it forever. This also applies for display code and other reusable stuff.
Converters were around for a while too. And seriously, would I want to write a special case one-off converter scripted in assembler while I have access to general purpose languages with tons of libraries?
Well, probably some operating systems are rather unfriendly in this regard in their default install, but that's usually easy to fix. Still wondering why one would want an emulator launching capability in an assembler for example ;)
IDEs. Well, it probably makes sense for huge projects for cross referencing and refactoring reasons, like stuff written in java for example.
For 6502 code? A fast text editor with syntax highlighting, auto indent and quick searching is usually enough. I tried to love cross referencing but mostly I don't have the need for that. Possibly I need a bigger mess in my sources like reusing the same random 2 character label in different scopes all over the place ;)
This thread goes into the weapons of choice direction. So for me:
* Vim. With a rather complex syntax highlighting for expression syntax checking. Also with custom on-the-fly source reformatting ala C64 tass/tasm. And it's nice for comparing changes, merging, folding, auto completion, quick jumping around, split editing etc, etc.
* C/Python for any sort of non-trivial conversion or generation.
* vbindiff for hex-editing, c1541 for image files. VICE. cat, dd, bash, whatever.
* Make for incremental building, svn for version control. Exomizer/pucrunch for compression (space/speed).
* Did mostly one filers for the last 10 years, but for the few older trackmos I used home grown loader/disk layouter.
* Coded tons of (unreleased) converters over the years. Also several disassemblers, picture rippers, optimizers, etc. View64 for quick checking of the result.
* Surprisingly I eat my own dog-food, so I use 64tass. By now it does most of the things I've only wished for years before.
* I use IDEDOS and PClink for quick testing on the real thing. Which is either a C64C or a C128DCR.
Where's all the stuff then? Unfortunately not all of it is tightly scene related, therefore not here. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"would I want to write a special case one-off converter scripted in assembler" -> " Figure out once, then copy it forever." applies here too, I guees, and no need to install yet another compiler ide, and its all compact in the source. |
| |
soci
Registered: Sep 2003
Posts: 480 |
Conversion in the same file as the asm source, uh. It converts stuff every time, even if just tweaking the code.
Almost as bad as having pictures/music/font embedded in source as byte lines...
Wondering which assembler will get base64 or uudecoding first to optimize this use case ;) |
| |
soci
Registered: Sep 2003
Posts: 480 |
"yet another compiler ide".
Right. If you mean stuff like VS, then it grew so much over the years that it might be more space efficient to install a complete operating system with a compiler and editor instead ;) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 19 - Next |
