After figuring some things out on paper, the only operation that would have to be done is to shift the cpu address to the right 6x, then truncate [31:21], to form a proper address for the videoRAM. This would be after putting the X in the LSB and the Y in the MSB for indirect indexed in the address space $8000_0000 to $8FFF_FFFF.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

The way I had intended was :

(639,0) -> CPU address $8000_027F -> video address $27f
(0,1) -> CPU address $8001_0000 -> video address $280

The idea is that video is contiguous in physical memory, but for the CPU it looks like the screen is 64K pixels wide.

Also, keep in mind this only makes it easier when you're doing random access, for instance when drawing lines, or writing text. For a clear screen routine, there's no advantage.

Yes, I was thinking Mandlebrot that Bruce had made for the 65816 and adapt it to 65Org16 (I thought he had originally made it for the 65Org16, guess I was wrong). EDIT: Here is the thread.

Maybe there would be an advantage to have the ability for the cpu to easily select how to address the videoRAM? If the cpu is accessing $80000000-$8FFFFFFF it uses the optimized addressing scheme, if it's accessing $90000000-$901FFFFF is uses the standard linear addressing.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Even when the CPU is accessing memory linearly, like in a clear screen, the overhead of using the new mapping isn't too bad. It's just a matter of adjusting your loops so that the inner loop clears exactly one line, and then you repeat that 480 times. It will be a few microseconds slower than what you have now.

Plus that you could very easily modify the code to only clear a specific rectangle, with about the same performance.

Even just 1 more opcode, like an ORA #$1010 for example, in the main loop is very noticeable in the clearscreen speed and I'm talking multiple frames per second. Also, reading picture data or even sprites would favor the linear addressing I would think.
I can experiment with the optimized addressing tomorrow.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

There wouldn't be any change to the inner loop itself, but instead of running the inner loop for 64k times, it would run for 640 times (one screen line). The effect would be that you'd have to set it up 480 times, instead of 5 times. So, there's a small penalty, but since the code spends 99% of the time in the inner loop, the penalty is very small.

If you wanted it really fast, a hardware bit blitter would be a nice project.

This is my area of interest, but there is so much to learn! And I only seem to learn by doing, such a slow process.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

and there's Samuel Falvo's blitter article at http://6502org.wikidot.com/blitter-theory-part-1 (although it looks like a few equations need fixing in order to show up at all. I'll contact him.)

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

Another trick that you could do, is to do a 'banking' scheme. So, instead of mapping the entire video memory in the CPU space, you can map a single line. The mapping is done by writing the Y coordinate in a special register, and this causes the hardware to map one 640-pixel line in a fixed memory area. The advantage is that you can then access this memory using ABS,X addressing (or even ZP, X if you map it into zero page), which saves a cycle compared to (ZP), Y.

Having fixed address also makes it easier to unroll the loop. So, you could do something like:

And then let X go from 63 to 0.

I'll think about your latest idea and let it sink in over the next few days. If at least 1 cycle can be saved, I will take that suggestion! But first, I'll try your previous idea using indirect indexed addressing and extracting X and Y values from the LSB and MSB.

Also, I have been thinking about 'unrolling' loops as well in order to save cycles. Then I start thinking about some simple self modifying code. Unrolling loops takes alot of RAM especially if that videoRAM is mapped entirely in the cpu address space...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I'd be more worried about running out of block RAMs than running out of 4GB memory space! And even then, I'd only worry when I'd really started to run out. You can always reduce the unrolling later if you find that you need the extra 20 bytes.

My brain must have been in software mode, because in the Verilog all I needed to do is a simple reassignment:
I've changed from a single linear pixel counter to a dual X, Y counter. I will have to change my character plotting software now for this new setup, but first I'll write a clear screen routine.

Then I can take advantage of the dual FPGA PROM and do a quick speed comparison. Linear addressing clear screen in 1 and optimized clearing in the other. They will be cycling through the 4-bit color look up table. Speed is back down to 50MHz. The addition of the X,Y counters put the design over the edge. It's ok though, towards the end of the project I can increase VSYNC and HSYNC frequency to boost the pixelclock then hopefully that will put the CPU closer to 80MHz.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Wow, it works, this is really cool! Arlet, thanks for the idea.
Now simple plotting is math free at the expense of a slightly larger memory map. Awesome. It's just as fast as linear addressing too.

EDIT: After cleaning up the some of the Verilog speed is back up to 100MHz, without smartXplorer. I chose Performance with IOB Packing for Design Strategy.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I think page flipping is the next logical step to start thinking about.

But today and tomorrow, I'm gonna try converting Bruce's Mandlebrot and Garth's geometric tables for plotting shapes.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

My mind is wandering with all the possibilities of this math free plotting! Now an origin based, 4 quadrant system seems easy without the burden of the math which has clouded my thinking in the past.
I can see how easy on paper it is to draw rectangles hollow and filled. I must put it to the test next, then move onto parallelograms. Then circles and ellipses. I need to add a hardware timer in the next PVB design.

I will have some pics soon.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502