[CSDb] - User Forums - Why wont it let me LOAD....

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Why wont it let me LOAD....

2018-07-19 22:38

Nova

Registered: Jun 2012
Posts: 13

Why wont it let me LOAD....

Screw it,
If i had solved my problem you would all have had to
watch 36 fucking parts of Retroholica by genesis project at X2012 so i guess there is a higher purpose to not letting me irq load with on the fly decompression...

I thought i saw the light when i discovered the
Plushsqueezer V2 and integrated that loader in several
of my unfinished demos but it keeps fucking up some of my stable interupts, not all and i cant see a pattern and i have kind of given up.

I am not a multi platform programer, i love oldschool coding on the 6502 but if you ask me to compile something in a linux environment or some weird C++ cross platform compiling there is just no way, and since life still gets in the way i will most likely give up because there are more fun things to do then failing at compiling a loader with on the fly decompression for a 35 year old fucking computer !!

I managed to compile Dreamload with just the "normal" unpacked irq loading and it worked great but diskspace will soon be an issue..

Could someone please come up with a guide for compiling
both the Krill and Dreamload loaders with decompression and flip disk options in a Windows 7 64bit enviroment..

Sincerly yours:
Nova.

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

2018-07-22 04:24

Compyx

Registered: Jan 2005
Posts: 631

Quoting Martin Piper

If you want to learn C++ then Microsoft Windows Developer Studio is the way to go. It has the best compilers, debugger and documentation. It is by far the best free IDE.

If you want to learn Java then IntelliJ. It is much better than Eclipse and is also free.

Well, that's complete bollocks. You don't learn a language by using some "awesome" IDE. that's exactly the opposite of getting to know a language properly. Especially when using IDE's from MS, Oracle and the like, they all have their specific "extensions" to the language proper.

Quoting Martin Piper

Being cross-platform allows me to engineer much better ideas, much quicker, than I could on a C64. Complex compression needs complex code, lots of debugging and lots of memory.

Uh, what?

2018-07-22 08:28

oziphantom

Registered: Oct 2014
Posts: 478

Quoting Golara

Krill's loader has couple of dependencies, but he listed them all together with links to where download it from. Here's a quick guide of compiling this loader.

1. Download the source code, extract it somewhere.
2. Go to Loader / Docs / Prerequisites.txt
This file lists all the programs you need and the environment paths you need to set. To check if you have the required program already just type it's name into the terminal. If you see "command not found" then you have to install it:

2.a first try sudo apt-get install NAME_OF_PROGRAM. It will download compiled program and install it for you if it's in the repository (for standard stuff like c compiler, make etc.)

If the command above fails, go to the link in the Prerequisites.txt for a given program (for example exomizer http://hem.bredband.net/magli143/exo/, download source from there and compile it (recursive :P )

General stuff on compiling.
If you see a file called Makefile then all you have to do is to type make in the terminal and the compilation will begin. Read the error messages (if any). You might get simple
exomizer : no command found meaning you don't have exo installed...

Installing compiled programs:
most makefiles will have a rule for "install", so you just type sudo make install. If it says no rule for install, then you have to copy the compiled file yourself to some path you can access from terminal. Instead of making your PATH longer and longer with every program, you can copy your compiled program to some standard path like ~/.local/bin

Setting environment variables:
easy thing. The command is called export. For example
export CC65_INC="~/some/path/you/want"

if you want to add something to already set variable (for example PATH) you do this:
export PATH = "$PATH:/another/path:/maybe/yet/another/one"

setting environment variables this way will be only remembered in the terminal window you typed it. If you want to set these for good then you have to save them to a file that is run every time you open a new terminal window. It's called .bashrc and it's in your home folder (files starting with dot are hidden, so you need to enable show hidden files in your file browser, in terminal it doesn't matter, just nano/vim/ed/whatever_turns_you_on ~/.bashrc

This is true...If you are using a Debian based version?/variant/strain and that version has bash installed as its shell, and it uses the debian package manager. Of which it needs then be noted that Ubuntu and Lubuntu are branches from Debian and I think one of the Mint's is but the other isn't? or maybe they just change the window manager, or one of the window managers is a cross blend that kind of uses both. Its hard to find answers in the holy wars. Or it uses the other package manager. These things are not really spelt out and every single "version" seems to be something this one person made for themselves 10 years ago...

2018-07-22 08:33

oziphantom

Registered: Oct 2014
Posts: 478

Quoting ChristopherJam

Eh, I remember having issues with that when I was a linux n00b.

Like, editing it in my .login instead of my .cshrc and wondering why it didn't take effect even in new shells, fucking up the syntax, accidentally overwriting instead of prepending, appending instead of prepending and wondering why my addition was getting shadowed.

TBH I probably fucked it up in DOS a few times too back in the day.

I still don't think I have been able to permanently change mine on my linux vms. Probably because of all of the above. I also assume all the people that do the "well I just make a script that opens a window and sets them for me" are also people who have failed and just gave up...

I've installed software that has an installer and it still fails, I have to dig through the folder structure and find the right elf and then run it with sudo from the command line...

2018-07-22 09:39

Krill

Registered: Apr 2002
Posts: 2839

Quoting Golara

Krill's loader has couple of dependencies [...]
export CC65_INC="~/some/path/you/want"

Just a side-note: Most of the dependencies, including cc65's C-64 run-time library, were only really needed if you built the whole package, including both the statically-linked relocateable object files and the dynamically-linked incarnation of the loader library.

What most people want and do, however, is just something like a simple "make prg ZP=02 INSTALL=1000 RESIDENT=0200", and out come install.prg, loader.prg and loadersymbols.inc, ready to be .incbin'd and .included by their favourite assembler, whatever it may be.

That said, i've recently removed a lot (all?) of the over-engineered cruft nobody really ever needed, like the facility to link the loader dynamically (which was initially thought as a simple means for any user to update the loader of an existing production without the creators having to rebuild it, by simply overwriting the loader library with a more recent build, or even an entirely different loader sharing the same API/ABI).

2018-07-22 11:08

ChristopherJam

Registered: Aug 2004
Posts: 1378

Agreed on Quote:

Complex compression needs complex code, lots of debugging and lots of memory.

but that's orthogonal to whether IDEs suit your working style.

Admittedly I've started playing with JetBrains IDEs for their Python and Rust support, but most of my complex data munging in those languages for c64 demos has been with no more than vim and Makefiles. Same with when I was using c++ for the quantizer for Effluvium's escher zoom.

2018-07-22 17:49

Golara
Account closed

Registered: Jan 2018
Posts: 212

Quote: Quoting Golara
Krill's loader has couple of dependencies, but he listed them all together with links to where download it from. Here's a quick guide of compiling this loader.

1. Download the source code, extract it somewhere.
2. Go to Loader / Docs / Prerequisites.txt
This file lists all the programs you need and the environment paths you need to set. To check if you have the required program already just type it's name into the terminal. If you see "command not found" then you have to install it:

2.a first try sudo apt-get install NAME_OF_PROGRAM. It will download compiled program and install it for you if it's in the repository (for standard stuff like c compiler, make etc.)

If the command above fails, go to the link in the Prerequisites.txt for a given program (for example exomizer http://hem.bredband.net/magli143/exo/, download source from there and compile it (recursive :P )

General stuff on compiling.
If you see a file called Makefile then all you have to do is to type make in the terminal and the compilation will begin. Read the error messages (if any). You might get simple
exomizer : no command found meaning you don't have exo installed...

Installing compiled programs:
most makefiles will have a rule for "install", so you just type sudo make install. If it says no rule for install, then you have to copy the compiled file yourself to some path you can access from terminal. Instead of making your PATH longer and longer with every program, you can copy your compiled program to some standard path like ~/.local/bin

Setting environment variables:
easy thing. The command is called export. For example
export CC65_INC="~/some/path/you/want"

if you want to add something to already set variable (for example PATH) you do this:
export PATH = "$PATH:/another/path:/maybe/yet/another/one"

setting environment variables this way will be only remembered in the terminal window you typed it. If you want to set these for good then you have to save them to a file that is run every time you open a new terminal window. It's called .bashrc and it's in your home folder (files starting with dot are hidden, so you need to enable show hidden files in your file browser, in terminal it doesn't matter, just nano/vim/ed/whatever_turns_you_on ~/.bashrc

This is true...If you are using a Debian based version?/variant/strain and that version has bash installed as its shell, and it uses the debian package manager. Of which it needs then be noted that Ubuntu and Lubuntu are branches from Debian and I think one of the Mint's is but the other isn't? or maybe they just change the window manager, or one of the window managers is a cross blend that kind of uses both. Its hard to find answers in the holy wars. Or it uses the other package manager. These things are not really spelt out and every single "version" seems to be something this one person made for themselves 10 years ago...

Yes I know and I guess I should have stated it, but for a linux noob I think everyone says go Ubuntu or some derivative (I use MINT).

I'm also a C/C++ programmer (I get paid for writing "enterprise c++" even though I like C more) and we (guys in the company) are all doing this on linux. There's Visual Code (made by MS) if you want that Visual Studio feel but I just use plain text editor, specifically notepadqq (notepad++ clone) and gcc with make/cmake to build, grep to find some text in all files etc. It's small, fast, nice and slick. The source code is over 300mb btw, so it's not like we're working on some tiny thing like you might have thought. I'm programming my own game in C++(98) on linux, but it can build for any platform, even my old 166Mhz pentium 1 laptop. I just say, hey, use mingw instead of gcc and here comes my windows .exe instead of elf. Good luck converting a project which was made in Visual Studio to linux. Not that it's impossible, but it's just stupidly hard, especially if you use the functions provided by MS.

But that's me. I didn't go to university and I had all bad grades at school. I learned everything I know about computers myself (i was reverse engineering games, making cheats and later even fixing said cheats on the private servers of that game), at the very beginning I didn't even know IDA can insert assembly code from text, so I was just looking up tables of x86 opcodes and writing the bytes myself in the hex view. So I learned x86 asm first, then C (which I used like a macro assembler, lol), then C++ and I might have this weird view on computers. That's also why when I discovered there's a whole community writing shit in assembly for this cool tiny computer I had to jump in !

2018-07-22 19:16

chatGPZ

Registered: Dec 2001
Posts: 11108

we dropped all MSVC support from VICE because it required a stupid amount of effort to support that shitty C compiler (yes the C compiler really _IS_ utter crap) and build system.

2018-07-22 23:49

Martin Piper

Registered: Nov 2007
Posts: 634

Only if you stick with the oldest versions.
Newer versions have the better compilers like LLVM.
You really need to understand what's available before making engineering decisions.

2018-07-23 00:08

Martin Piper

Registered: Nov 2007
Posts: 634

Quoting Compyx

Well, that's complete bollocks. You don't learn a language by using some "awesome" IDE. that's exactly the opposite of getting to know a language properly. Especially when using IDE's from MS, Oracle and the like, they all have their specific "extensions" to the language proper.

No, it's true. Modern IDEs will scan/compile in the background, offer code suggestions, flag errors while typing, have large searchable documentation and rich interactive debugging. All these enable the programmer to concentrate more on developing rather than keeping lots of stuff in memory.

GCC also has its own non-standard tweaks. https://www.ibm.com/developerworks/linux/library/l-gcc-hacks/

Lots of compilers do. There is no compulsion to use all of them. Sometimes what was a tweak becomes standard or shared across compilers.

Sometimes compression algorithms require gigabytes of working memory for working tables. Good luck doing that on a C64. Also modern multi core machines with lots of storage mean it's possible to build whole C64 games in seconds compared to minutes or hours on a C64.

2018-07-23 00:40

ChristopherJam

Registered: Aug 2004
Posts: 1378

Martin, I don't think anyone here is arguing against cross developing.

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

Refresh

Subscribe to this thread: