Personally I prefer using a "Makefile generator" like CMake, because CMake is able to take care of the platform differences. On top of that, CMake has builtin tools for writing and running tests, and packaging the build results.

But then you have to include CMake in the list of dependencies you have to download.

Personally I prefer using a "Makefile generator" like CMake, because CMake is able to take care of the platform differences. On top of that, CMake has builtin tools for writing and running tests, and packaging the build results.

But then you have to include CMake in the list of dependencies you have to download.

If your opinion is that the disadvantage of adding one more dependency (possibly removing a bunch of other ones at the same time) balances out the advantages of platform compatibility, and ease of writing the build scripts, and the n+1 other useful features provided by CMake, then certainly that's a valid complaint.

BTW, I'm not saying CMake is perfect. I've used it enough to know it has a number of problems, but I would choose it over handwritten makefiles every time. But to each his own.

I finally got around to looking at this code. Ho-ly-shit. Really? God dude, I don't even know where to begin. The code itself is fine (sort of -- very bad init routine from the look of it), but it's nearly impossible to follow given formatting, things in files that don't make any sense (like why is the reset vector code in snesheader.s), and a ton of other things. Can you honestly read this given the formatting and almost "inline" comments without any actual structure?

I at least got part of Espozo's code assembling (writing the Windows batch file was about 70% of the work), but I'm having to go through one thing at a time and it's very very painful. I had no idea ca65 would be this... I don't know... powerful yet absolutely and totally ridiculous. There's even some WLA DX code (a macro) that makes zero sense to me at this time and not having a listing file from WLA DX makes me sit here going "how the hell does this even work?"

What the hell happened to SNES development? How is it we had more or less better assemblers and sane tools than now? Wow.

I felt the same way you do, I just didn't want to say anything. I think tepples brain is wired differently from ours. I don't think my work environment is way too complex.

Edit: What follows is my work environment, which I think is easier to understand. I originally forgot to mention this, so my post made no sense.

Attachment:

Work Environment.png [ 2.93 KiB | Viewed 5818 times ]

In this, 2input does something with the controllers, (I honestly don't know, but it works, so...) Header is the header (no duh) InitSNES2 just sets all the registers back to 0, LoadGraphics is a macro that makes it easy to DMA graphics to vram, Metasprite2 is a metasprite creating routine, Metasprite Test2 is the main file, (I always specify this) and Sprites sets all the sprites off screen.

Last edited by Espozo on Sat Jan 31, 2015 3:07 pm, edited 1 time in total.

What is \4 here? It refers to the 4th argument to the macro, but the comment preceding the macro doesn't mention it. The code clearly uses it (note 2nd SpriteTiles load; it's the only call where it's non-zero)

I fully understand what LoadVRAM does -- the contents of X make it into $4302, which is the 16-bit portion of the 24-bit address that DMA channel #0 is going to read from when populating VRAM, but I do not understand why the logic in the macro is to add argument 1 and argument 4 together to make up the 16-bit base address of where the source data is. Argument 1 = SRC_ADDR, which should be a full 24-bit address (according to the comments).

The WLA DX docs, as I expected, don't shed any light on this either.

Code:

Also, if you want to use macro arguments in e.g., calculation, you cantype '\X' where X is the number of the argument. Another way to referto the arguments is to use their names given in the definition of themacro (see the examples for this).

To me, ldx #\1+\4 when doing SpriteTiles, $100, $0040, $0040 (assume SpriteTiles full 24-bit address is $02f3f0 would result in ldx #($20f3f0 + $0040) (the bank byte is effectively stripped), thus ldx #$f430. What I don't understand is what the purpose of the 4th argument actually is. If I had seen ldx #\1 I might think "the lower 16-bits of the 1st argument", but again the WLA DX docs don't shed any light on this, going back to the need for a listing generation.

I think it's used as an "additional offset" within whatever you provide in argument 1, i.e. SpriteTiles+$0040, but the fact the macro doesn't properly document the use of the 4th argument worries me.

Edit: and your code isn't very well organised either. :-) But it's at least something I can follow a lot easier than the ca65 lorom example.

It's from the LoadGraphics code on the SNES starterkit. Well, mostly. I took some stuff bazz did to the palette uploading macro (it was truly useless beforehand) and I added a 4th argument on the LoadBlockToVram that serves as an offset in the picture.

It's from the LoadGraphics code on the SNES starterkit. Well, mostly. I took some stuff bazz did to the palette uploading macro (it was truly useless beforehand) and I added a 4th argument on the LoadBlockToVram that serves as an offset in the picture.

The ca65 error, given the complaint about a colon, seems to imply it's having issues comprehending labels.

I'd guess that it doesn't know LoadPalette is a macro, and then assumes it must be a label, and then craps out because there's no ":". Is the macro included into the file, or assembled separately? If assembled separately, it won't be visible in other modules.

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum