The macro language of the assemblers I've used was nearly identical, so it would take little or no effort to convert macros already written for one assembler to work with another-- probably no more than a quick search-and-replace function.

Properly written and used, macros just make the programmer more productive, and usually have no effect on the size or speed of the machine language produced. In fact, looking at the machine code produced from code with versus without macros, you should usually see no difference. They're usually the same. Macros will make the source code more clear, maintainable, and bug-free though.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I understand your point, but can't bring myself to get in the groove with them. The examples I've seen hide too much detail for my taste, since I always seem to find myself fiddling around with unstructured optimizations. It's an addiction of mine that certainly doesn't aid clarity, productivity or maintainability, but I just can't help myself ... I'm putting my hands directly on the machine to get it to do exactly what I want, and it doesn't seem right going away without some grease under my fingernails. [Edit: oh ... and a few burns and scraped knuckles as well!]

Mike B.

That doesn't surprise me, other than some rather expensive compilers i've not seen efficient code generation for some of these older processors.

I also just noticed that i must have number blindness typing 5602 (twice) rather than 6502

The other reason (besides GPU power) that C would be fine for coding the main game logic on the Vulcan-74 hardware is program memory usage.
On a platform like C64 or even Amiga, all active graphics and sound data must be loaded into the program memory, as it is the only memory.
On Vulcan, there are 6 independent memory systems, each having their own function and busses.

1) Video Memory : Dual 120K banks @ 20MHz for double buffering.
2) Sprite Memory : 1024K @ 4MHz with automatic alpha pixels.
3) PlayField Memory : 1024K @ 16MHz for background images.
4) Sound Memory : 1024K @ 2MHz for 4 Voice Stereo Output.
5) Program Memory : 64K @ 10ns for 6502 Program.
6) Cartridge Memory : 4-64MB SPI Flash (External) used as game cartridge.

Once the 64K Program Memory is loaded from the Cartridge by the Vulcan Boot Logic, the 6502 is free to load all the other Memories by selecting data from the Cartridge Memory.
The 6502 main program can be 65280 bytes in size (256 bytes are mapped as Vulcan IO).

So depending on how "friendly" I find CC65, a little bulky code produced by the compiler may still make it worthwhile once the assembly libraries are completed.
Since all screen access is 16 bit, and all memory access is 20 bit, a C compiler would certainly make doing things like this much easier...



This simple bit of code just cycles the location of the stored Checker Ball images in the Sprite Memory as they move.
Since each Sprite is 76x76 in size, the 20 bit address is changed by 5776 for each new rotation.
I wrote that in 30 seconds, but even as a "half-assed" assembly programmer, I doubt I could have coded that in a few hours.

The real magic happens in this line, though...



Here, an assembly routine takes over and sends the required data to the Vulcan GPU, toggling the required IO lines.

Anyhow, I will see if this kind of thing can be done in CC65 without having to piss around for hours in a DOS box!

Brad

I've never used a macro that I myself didn't write. You have complete control over what's in it, and you can change it at any time-- it's just that you don't have to look at the internal details every time you use them. If you want something a little different, you can write another macro that's nearly identical, or write nearly the same thing without a macro. There's no obligation to an all-or-nothing approach. Mix to your heart's content.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I think of macros as abstracting detail rather than hiding it and I like using them. But these are often just personal preferences. i know there are plenty of "productivity" features I've passed up simply because for me it's more trouble than it's worth.

On the subject of using C, it depends on the task. I know I would rather write game logic in C but would prefer assembler for a video driver.

_________________
C74-6502 Website: https://c74project.com

I have a handle on CC65 now.
Managed to whip up a custom "Target File" and get an output file.
Not sure what the output file format is yet though... it's not a 64K binary image like I would have expected.
Once I figure out the output file format, I will rework my converter and see how things go.
My converter currently takes the Kowalski Binary Image and makes an AVR loadable file for my boot simulator.

If this works well, I will then create a "One Button" wonder that does all the work so I don't have to play around in the command line.
I also don't want to mess around trying to get paths working, so my program will only need to know where the CC65 dir is located.
Here is how it will work...

1) Code a C program in your favorite editor, like Notepad++ and then save your work to any folder.
2) Open my Vulcan-74 ToolKit and choose "Create Cartridge".
3) From there, point to the C file and the program will do everything else (calling CC65, CA65, etc).

At that point, a complete game cartridge is loaded and sent to the Vulcan-74 hardware.
My Vulcan-74 Toolkit also takes care of converting and adding graphics and sound samples to the image.

If this works, then someone else can get into coding my system without having to EVER open a DOS box.
Simply unzip CC65, and then tell the Vulcan Toolkit where it lives.
Time can then be more wisely spent fighting your own code rather than the toolchain!

I will try this over the next week once I figure out what type of binary file is being produced here.

Cheers,
Radical Brad

cc65 makes a toolchain specific object file (xo65 format). You need to link them together using ld65, and use a config file to define your memory areas. The ld65 tool produces a plain binary.

See http://www.cc65.org/doc/ld65.html and specifically http://www.cc65.org/doc/ld65-5.html

Ok thanks, I will do my homework!
In my case, I need the entire 64K binary image, including the reset vector value of 768 in the image.
Basically, a snapshot of the entire program memory as it needs to be just after a reset.
This is what I get now from using Binary Image in the Kowalski Assembler.

Has anyone seen a printable version of the entire CC65 documentation?
Something that will print all at once?

Brad

Just found this...

http://www.retroremakes.com/remaketalk/index.php?p=/discussion/114/visual-studio-cc65-winvice/p1

Seems to good to be true! Will be trying this later. VS is my favorite IDE, so this would be great.

Brad

Time has not been on my side lately!
I have been readnig though, so here are my goals for the next phase of testing...

1) Figure out how to get a true 64K Binary image out of CC65 (00000-65535 Bytes).
2) Create a simple assembly routine (Screen_Flip) to test calling from C.
3) If 1 & 2 are successful, get some kind of modern IDE going with CC65, like Visual Studio.

Number 1 will require the most research, as it will involve defining my 64K ROMless target.
I may work "outside the box" here, and strip down the necessary bulk of the CC65 package to only what I need.
Would be nice to have nothing but a few executable and a framework program left in a directory called CC65_Vulcan74

When I have time to get these 3 things tested, I will report back the results.

Brad

You might find this post helpful:
viewtopic.php?p=25277#p25277
or search for ld65 on this forum for more.

I have not been able to make ld65 generate the binary output for the zero page. It probably assumes you'll initialize ZP yourself, rather than preloading it from a binary.

But, I'm not an expert on this either, so maybe someone could make it work with a bit more effort I was willing to put into it.

Thanks for the info!
That thread seems to sum it all up nicely.

Regarding Zero Page, I don't need to initialize that segment, so even just zeros would be fine.

My required Binary Image needs to be the full 64K, but can be zeroes up to address 00768, where my program code starts.
I do require the reset vectors to be set though.

In the Kowalski assembler, I just added this line at the end of the program, and it set the memory location as needed.



Note : I am still resistant to using HEX, and will keep fighting the good fight.
As long as I remain at least 60% human, I will continue to work in decimal!

I believe I have enough direction now so that my next free weekend will result in a successful test!

Thanks,
Brad

Yes, but even that I've not managed to do. So, you may end up having to deal with a binary file of 64k - 256 bytes, starting at page 1. Of course, it wouldn't be too hard to use an external tool to add 256 zeroes to the front of that.