Vulcan-74 - A 6502 Powered Retro MegaProject

For discussing the 65xx hardware itself or electronics projects.
User avatar
GARTHWILSON
Forum Moderator
Posts: 8773
Joined: 30 Aug 2002
Location: Southern California
Contact:

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by GARTHWILSON »

Oneironaut wrote:
So at this point, it looks like assembly all the way. I am also avoiding any kind of macros or IDE dependent lingo, this way my code will compile on any flavor.
To be honest, I never did like macros anyhow... almost feels like mold on an otherwise clean block of cheese!
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?
User avatar
barrym95838
Posts: 2056
Joined: 30 Jun 2013
Location: Sacramento, CA, USA

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by barrym95838 »

GARTHWILSON wrote:
... They're usually the same. Macros will make the source code more clear, maintainable, and bug-free though.
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.
SteveMoody
Posts: 3
Joined: 27 Apr 2009

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by SteveMoody »

BigDumbDinosaur wrote:
Excepting WDC's TIDE package, 6502 C compilers produce klunky, inefficient object code. It isn't so much a case of "overhead" as it is just plain bulky code that doesn't use the 6502's characteristics to best advantage. I don't recommend C with the 6502 unless reduced application development time is much more important than performance.
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 :(
User avatar
Oneironaut
Posts: 734
Joined: 25 May 2015
Location: Gillies, Ontario, Canada
Contact:

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by Oneironaut »

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...

Code: Select all

// MOVE BOING BALLS
for(q=0;q<balls;q++){
	xx[q]=xx[q]+dx[q];
	if (xx[q]>400-76-5) dx[q]=-dx[q];
	if (xx[q]<4) dx[q]=-dx[q];
	yy[q]=yy[q]+dy[q];
	if (yy[q]>300-76-5) dy[q]=-dy[q];
	if (yy[q]<4) dy[q]=-dy[q];
	RunSprite(xx[q],yy[q],76,76,BoingBalls);
	}
BoingBalls = BoingBalls + 5776;
if (BoingBalls == 86640) BoingBalls = 0;
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...

Code: Select all

RunSprite(xx[q],yy[q],76,76,BoingBalls);
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
User avatar
GARTHWILSON
Forum Moderator
Posts: 8773
Joined: 30 Aug 2002
Location: Southern California
Contact:

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by GARTHWILSON »

barrym95838 wrote:
GARTHWILSON wrote:
... They're usually the same. Macros will make the source code more clear, maintainable, and bug-free though.
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!]
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?
User avatar
Drass
Posts: 428
Joined: 18 Oct 2015
Location: Toronto, ON

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by Drass »

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
User avatar
Oneironaut
Posts: 734
Joined: 25 May 2015
Location: Gillies, Ontario, Canada
Contact:

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by Oneironaut »

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
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by Arlet »

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
User avatar
Oneironaut
Posts: 734
Joined: 25 May 2015
Location: Gillies, Ontario, Canada
Contact:

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by Oneironaut »

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


Arlet wrote:
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
User avatar
Oneironaut
Posts: 734
Joined: 25 May 2015
Location: Gillies, Ontario, Canada
Contact:

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by Oneironaut »

Just found this...

http://www.retroremakes.com/remaketalk/ ... winvice/p1

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

Brad
User avatar
Oneironaut
Posts: 734
Joined: 25 May 2015
Location: Gillies, Ontario, Canada
Contact:

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by Oneironaut »

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
Last edited by Oneironaut on Tue Oct 27, 2015 12:07 pm, edited 1 time in total.
User avatar
BigEd
Posts: 11463
Joined: 11 Dec 2008
Location: England
Contact:

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by BigEd »

You might find this post helpful:
viewtopic.php?p=25277#p25277
or search for ld65 on this forum for more.
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by Arlet »

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.
User avatar
Oneironaut
Posts: 734
Joined: 25 May 2015
Location: Gillies, Ontario, Canada
Contact:

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by Oneironaut »

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.

Code: Select all

 ; ********************************************************************************
 ; *** SET RESET VECTOR TO ADDRESS 00768
 ; ********************************************************************************
 .ORG 65532
 .DB <00768
 .DB >00768
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
User avatar
Arlet
Posts: 2353
Joined: 16 Nov 2010
Location: Gouda, The Netherlands
Contact:

Re: Vulcan-74 - A 6502 Retro MegaProject

Post by Arlet »

Quote:
Regarding Zero Page, I don't need to initialize that segment, so even just zeros would be fine.
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.
Post Reply