Vulcan-74 - A 6502 Powered Retro MegaProject

[Arlet]

You can also use the INC instruction to increment memory directly.

[Oneironaut]

Right!... I keep forgetting that the 6502 is not evil like the PIC, (Accumulator VS W Register)!

Code: Select all

 
 ; LOAD AND PLOT 1024 PIXELS (32x32)
 LDX #0
 LDY #0
SPR_LOOP:

 ; LOAD PIXEL FROM PROGRAM MEMORY
 LDA BALLS,X

 ; PLOT PIXEL TO SPRITE MEMORY
 STX 0 ; DEST ADDRESS.LO
 STY 1 ; DEST ADDRESS.MD
 STZ 2 ; DEST ADDRESS.HI
 STA 3 ; PIXEL DATA
 JSR SPRITE_PLOT

 ; COMPLETE LOOP
 INX
 BNE SPR_LOOP
 INC SPR_LOOP+2
 INY
 CPY #32
 BNE SPR_LOOP

Thanks,
Brad

Arlet wrote:

You can also use the INC instruction to increment memory directly.

[jmp(FFFA)]

If you aren't particular about the order of plotting, this will be somewhat faster and smaller:

Code: Select all

; LOAD AND PLOT 1024 PIXELS (32x32)
 LDX #0
 LDA #32
 STA 1
SPR_LOOP:

 ; LOAD PIXEL FROM PROGRAM MEMORY
 LDA BALLS+$1F00,X
 
 ; PLOT PIXEL TO SPRITE MEMORY
 STX 0 ; DEST ADDRESS.LO
 DEC 1 ; DEST ADDRESS.MD
 STZ 2 ; DEST ADDRESS.HI
 STA 3 ; PIXEL DATA
 JSR SPRITE_PLOT

 ; COMPLETE LOOP
 INX
 BNE SPR_LOOP
 DEC SPR_LOOP+2
 BPL SPR_LOOP

Note that it assumes that the address BALLS+$1F00 is less than $8000. If you want it to be fully general, you'll probably have to add that pesky compare instruction back in place.

[Arlet]

If you use self-modifying code, don't forget to initialize it before entering the loop.

[Oneironaut]

Coding is coming along nicely now. Those bouncing balls are back, this time under 6502 command!

Just wondering...

How popular is CC65?
I was thinking about making .S libraries for all of my Vulcan Commands so that games and demos can also be done in C.
On my AVR systems, doing this made them much more popular (and easy) to use.
Looking at the docs, it would appear easy to make an assembly library for CC65, and get this kind of functionality...

Code: Select all

DrawSprite(X,Y,CheckerBall);

But if C is not that popular, there would be no point.

Brad

[jmp(FFFA)]

Oneironaut wrote:

How popular is CC65?
I was thinking about making .S libraries for all of my Vulcan Commands so that games and demos can also be done in C.
On my AVR systems, doing this made them much more popular (and easy) to use.

It has been around six years since I played with cc65, but when I did I was extremely disappointed at the quality of code it produced. Not only was execution speed disappointing, but it was ghastly in terms of bytes used. You wouldn't be able to write a very complicated game and have it fit in 64K.

I'm not a big Forth user myself, but from what I do know, it would make a much better choice than compiled C on the 6502 because the code would be much more compact and likely just as fast as the compiled C code.

If you dislike Forth, another option would be to use one of the several C compilers that compile to p-code. They may not be as fast as cc65, but they will make up for that with the compactness of their code, which IMHO is an important consideration when you only have 64K of address space to work with. Now if you want to throw some more 74HC logic chips at the problem, you can probably make a decent MMU and then hack up the compiler runtime to work with it as yet another alternative...

[nyef]

jmp(FFFA) wrote:

Oneironaut wrote:

How popular is CC65?
I was thinking about making .S libraries for all of my Vulcan Commands so that games and demos can also be done in C.
On my AVR systems, doing this made them much more popular (and easy) to use.

It has been around six years since I played with cc65, but when I did I was extremely disappointed at the quality of code it produced. Not only was execution speed disappointing, but it was ghastly in terms of bytes used. You wouldn't be able to write a very complicated game and have it fit in 64K.

I don't know about CC65 the compiler, but I found the assembler and linker to be fairly usable at one point. Admittedly, that may have been more than a decade ago, and my memory for the details is basically gone.

[Arlet]

I don't think C is very popular, but assembly libraries would be useful for anybody wanting to use the hardware. And it would be fairly easy to add bindings for CC65 (or Forth, or whatever) on top of them.

[porcupine]

I saw an interesting project that had created a kind of high level macro-assembler for 6502 on the NES using Common Lisp. Sort of half-way between a high level language compiler and an assembler. Used Lisp macros and functions to generate 6502 machine code representing more high level operations.

Just found it, here it is:

https://github.com/ahefner/asm6502

I believe there's a similar tool written in Python, where you write Python code that generates 6502. Not compiled python, but python functions that emit 6502 assembly for very specific functions.

To me that's a better method than using a C compiler on an architecture whose instruction set isn't really ideal for C.

[Oneironaut]

Ok, thanks, I will probably just stick to assembly then. I also downloaded the free TIDE IDE from WDC but have not tried it yet.

On the AVR platform, I was in the "odd bunch" being into assembly, so when I did optimized libraries for GCC, it really worked out well.
Seems in the 6502 World, assembly rules the roost already.

Brad

[jmp(FFFA)]

Oneironaut wrote:

Ok, thanks, I will probably just stick to assembly then. I also downloaded the free TIDE IDE from WDC but have not tried it yet.

On the AVR platform, I was in the "odd bunch" being into assembly, so when I did optimized libraries for GCC, it really worked out well.
Seems in the 6502 World, assembly rules the roost already.

Oh, I don't know about that. See the viewforum.php?f=9 subsection. If you've never experienced it before, it's definitely worth a try. I personally really like the interactive environment you get with it -- something that went away with interpreted BASICs decades ago. It's also nice not to have to run back to your "big iron" every time you want to tweak your code a bit. I'm pretty sure I've even seen a few articles on people running it on PICs and AVRs though you'd definitely be among the "even odder" bunch were you to do so in that community.

[Oneironaut]

For this project, I want to build my codebase on the most popular language.
Because of the almost insane speed of the Vulcan hardware, the 6502 has it easy, so as long as I keep the library tight, the code can be a little "loose".
Currently, I am bouncing 256 ball sprites (32x32) while scrolling a 2048x512 background screen, and the 6502 can keep 60 FPS with a 1 MHz clock!

It would be great to one day offer a board or kit and have a huge library of code to work with for those interested in trying something like this.
Perhaps offering a C framework with assembly libraries would make something like this easier to reach for those just starting out?

Anyhow, the only way this would work is if the response to my C question was... "Hell yeah, everyone is using CC65"!
On the AVR, the vast majority use GCC, and dabble in assembly when needing to count cycles.

The end game is make this project attainable to anyone, and I want to target the most popular and easy to use toolchain, language, etc. I have already made BMP and WAV converters for this system, so all that is left is to choose the toolchain. Once I have enough documentation and code examples, I will launch Vulcan74.com. Documenting with schematics and a possible PCB will probably be the bulk of the time, since I just built everything on the fly so far!

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!

I still may try creating a "Vulcan-74 Kernal" (C Library) in CC65 and see if it can generate decent code.
Having the game logic done in C with all IO stuff in assembly would be a decent mix of speed vs ease of use.

Ok, back to my outdoor chores. Free time has been extremely scarce over the last few weeks, so no pretty pictures yet!

Cheers,
Radical Brad

[SteveMoody]

Hi Brad,

I've been watching this project since it was posted on Hackaday. Absolutely amazed with the progress you've made so far.

I've not done much in with the 5602 since the commodore 64 and one small side project. I would go with assembly for speed but if you want to open this project for more people i would suggest using C. It would make it easier for people new to the 5602 and at the speed you're planning to run it at i don't think the extra overhead of C will be much of an issue. It's not the 1mhz Commodore any more.

I program embedded systems for my day job and with quite a few resource constrained processors. It's only on the rare occasion i need to drop into assembly for speed these days.

Steve

[BigDumbDinosaur]

jmp(FFFA) wrote:

I personally really like the interactive environment you get with it -- something that went away with interpreted BASICs decades ago.

Interpreted BASIC, at least in the transaction processing computing universe, is very much alive. Stop by here to get an idea as to just how powerful such environments are.

SteveMoody wrote:

I've not done much in with the 5602 since the commodore 64 and one small side project. I would go with assembly for speed but if you want to open this project for more people i would suggest using C. It would make it easier for people new to the 5602 and at the speed you're planning to run it at i don't think the extra overhead of C will be much of an issue. It's not the 1mhz Commodore any more.

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.

[Oneironaut]

Thanks for the comments.

I am going to evaluate the friendliness of CC65 as a possible environment for general game programming on Vulcan-74.
From my reading, TIDE is not friendly at all, so only CC65 remains for me.

When I say friendly, I do NOT mean this...

"All you need is Ubanta Linux Vesion 33.33.22.2.001, and fourteen other command line utilities to link, process, tickle, convert, massage, and then compile. From there, simply export the binary to a working C64 BBS and then back through a serial to usb cable using the FTDI V2.2001c chipset (not version 2.001b). From there, you need to relink using.... bla bla bla".

In other words, if I can setup a tool-chain whereas a user can start entering familiar C code into MAIN, and simply tell Vulcan what do do with easy to use C commands, than that would be perfect. getting the code to the Cartridge should also be a one button process that does not require the use of some old 486DX-33 running something bizarre. Nothing kills it for me worse than a tool-chain that involves a learning curve steeper than the damn target hardware I am trying to program. If CC65 works well, but requires a lot of command line, I will just code up a GUI for it. No problem! It should take no longer than 10 seconds to go from coding to seeing results on the V74 screen. Any longer and the tool-chain is garbage. Am am currently getting this kind of performance using the Kowalski Assembler and the converter I wrote.

I am not too woried about speed of game logic code, as the code is mostly simple logic, with Vulcan doing all of the heavy lifting in hardware.
It would sure be easier to code up something simple like Pacman in a few hours using C though.
Of course, for the real intense graphic effects, assembly is always the way to go.

When I have time, I will see what it takes to make a C callable Assembly routine for CC65. For GCC, it is very easy.

Brad