Maybe it doesn't like the spaces in the path.

As Arlet noted, it could be the blanks in the pathname, which generally should be avoided. I'm assuming you manually "walked" the D:\Shared\Plans\AVRCade\Logic 400x300 Vulcan-74\TestCode\6502 - Test Program\ path to verify that the Vulcan-74.65s file is at the end of it. Also, make sure you have read permissions on each component of the path. This is one of those things where the Windows DOS prompt can be useful.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks, it is probably the spaces as suggested. I will look into this more once all of my routines (Kernal) are ready, as they will end up as one big Include file.

Everything else is coming along nicely!
I have perfect operation at 10MHz, and before I dig into my clock hold-back idea, I want to optimize the entire set of routines so that I can give the board a real workout. Since I do not have the large Flash Memory (External Cartridge) installed yet, I am storing a few sprites as .BYTES directly in the 64K program memory, but this is working fine for testing. My testing goal will be to write a demo that exercises every single Vulcan IO pin and function extensively from a 6502 program that fills the entire 64K Program Memory space. Once successful, I will add the SPI Flash reading routine to the Kernal and then continue testing using massive Sprites and PlayField graphics loaded form the Cartridge by the 6502.

I have also been considering the idea of some 64K math lookup tables, since I am using only 64K of the 512K SRAM that directly connects to the 6502. With 7 free 64K pages, I could add a simple "Bank Switch" register that would allow the 6502 to swap into a lookup table, store the results in some unused Video Memory address, and then swap back t the main program. This could allow for seriously fast multiplication, division, and even a Sine lookup table. i have several ideas on how to make this work in less than 10 clock cycles.

My AVR <-> 6502 assembly learning curve is also starting to flatten out.
It has really just been a translation issue so far, as I can already code AVR assembly as fast as I can type (2 finger typing, but still fairly quick!).
The only smack across the face has been lookup tables. Having only an 8 bit index is a real clunker! Even my tiniest sprite is 1k in size (32x32)!!

On the AVR, you just set the Z register to some 16 bit value, and then do a post increment after reading from data space. You can read 64K this way.
On the 6502, you specify and address and an 8 bit index, so you can only reach 256 bytes of data before needing to re-address!
Once I have the Cartridge memory to store graphics, this won't be an issue, but for now, I am needing to read about 16K of Sprite data.
As a work around, I modified my Bitmap to Sprite converter to add address labels every 256 bytes. This is working ok for testing.

Some aspects of 6502 assembly seem clunky, but others seem better than AVR. I do like the BIT command!
In order to "ease" my transition, I consider Zero Page to be working registers R000 to R255. Nice to have 256 general registers!

I am currently coding a test program that will bounce a bunch of 32x32 colored balls over a scrolling PLayField image drawn programmatically.
The test program will also include the dual joystick port for a full test of all of the Vulcan-74 IO space.
I will post photos and a video when this is completed. Perhaps next week if my progress on the Chicken Coop I am building is good! Cluck! CLuck!

The Kowalski Assembler has been great to use so far. The inline help is all I am using to learn 6502 assembly!
http://www.exifpro.com/utils.html

I have automated my programming procedure, so I can make a code change and see it on the Vulcan-74 screen within 10 seconds...

- Write code in the Kowalski Assembler.
- Press assemble, and then save the Binary image
- Click my 6502 -> AVR data converter, which makes an AVR include file, then launches AVR Studio automatically.
- Click "Start" in AVR Studio, and within 4 seconds, the 64K on the Vulcan board is loaded with the image.
- As soon as the image is loaded, the 6502 is taken out of BE and RS, and the program runs.

This type of rapid development will also be possible when I have only the Vulcan-74 Boot System completed.
I intend to add a "Programming" jack that will allow uploading directly to the Cartridge that is plugged into the Vulcan-74 Cartridge slot.
This would be like using a Cross Compiler for the 64 that directly burns a Cartridge plugged into the C64 in 10 seconds!

So to sum up my ramblings... everything is progressing nicely under 6502 control!
I am looking forward to populating the other massive breadboard with the 4 Voice Sound Generator.

Ok.... back to the boring, bloated, redirected and obfuscated 64 bit World until next weekend!

Cheers!
Radical Brad

You would use the (zp),y addressing mode, and inc the zp+1 location to go the next page. Alternatively, you could use the abs,x mode, and self-modify your code.

Interesting, my web scouring has not reveled this info, so I will do my research and figure out how it works.
I actually printed the entire 469 pages of "Programming the 65816, Including the 6502, 65C02 and 65802", but am only into page 60!

Thanks for the tip... I will look into the addressing mode, which sounds a lot like using the high bits of the Z register on the AVR.

This is the code I will have to modify, since indexing rolls over 4 times as it wraps the 8 bit barrer while counting to 1024...



What is happening here is pixels are read from the program memory and then written to the 24 bit Sprite Memory SRAM. Sprite memory is a contiguous serial stream, which is why the routine SPRITE_PLOT expects 4 values; 3 bytes to form a 24 bit address, and the actual color value.

I realized my indexing mistake when the 32x32 ball sprite actually appeared on the screen as 4 stacked ball tops, which makes perfect sense since it simply repeated the first 256 bytes of the 1024 bytes needed. Note: STZ is correct, as I am just zeroing the address above 16 bits.

This part of the learning curve is where the most fun is!

Brad

You seem to have the right attitude, but you're going to have to practice before you get into the 6502 frame of mind. I know that you asked us to not hand you the answers, but perhaps you can study this thread for some ideas on efficiently handling large tables.

viewtopic.php?f=2&t=3054

Mike B.

Perfect, thanks!
A little kick n the ass followed by some self-directed learning is always the answer!

Brad

I offer 64K-cell lookup tables, pre-calculated, at http://wilsonminesco.com/16bitMathTables/ for multiplication, inversion (for division), squaring, square root, trig functions, log functions, and bit reversal (for FFTs), along with a lot of supporting info. The whole set takes 2MB, but you might choose to use only certain tables.

_________________
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?

"self modifying code"...

I should smack myself for not considering this!
Coming from AVR, there are penalties to this, since program memory is flash based, but no such restrictions in my new 6502 World.
I will try this when I have the time, as it seems like the easiest solution...

At the wrap of each loop, just increment the value at the Label "LOOP_ADR:" +1 (high byte) to get to the next 256 bytes.



I best be tossing out my old bag of AVR tricks and make room for some new ones!

Thanks again to everyone in this great community!
Brad

I knew you would like it

Oh no, what's next, asynchronous state machines?

Next is self modifying hardware. Use a robot arm to add chips and wires to the breadboard...

Please be careful, Brad. That LDA instruction is three bytes long, and the "high byte" resides at LOOP_ADR+2, due to the 6502's little-endianness ... op-code, low-byte, high-byte, in that order.

After you get things working, you can fiddle with stuff to make your code tighter and/or faster, assuming you enjoy that type of activity. One thing you can consider relates to the way the 6502 updates the N and Z flags after the majority of the data update operations (except store). This feature allows you to get rid of lots of compare instructions, by carefully crafting your loops to take advantage of this "built-in" compare-to-zero.

If your sprite engine doesn't care which order the bytes are loaded, doing them "backwards" may save you code bytes and machine cycles as well.

After you get into the groove, you should start to get a form of intuition, where your gut tells you the best way to juggle the registers, so things end up where they are supposed to be with minimal loads, stores, and transfers. I can't always do it, but I know enough about it to recognize and envy it when I see it ... kind of a Mozart/Salieri thing, if you know what I mean.

viewtopic.php?f=2&t=2656&hilit=deep+end

Mike B.

Hopefully more Mozart and less Salieri. I assume, of course, that you are referring to Antonio Salieri, not Mario Salieri.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks again!
The self-mod code worked perfectly...



I am starting to let go of my AVR way of thinking when I work with the 6502 now!

Brad