Wow!
What a huge help!
Just seeing a working read and write routine with this setup will keep me from a lot of frustration.
Thanks!
I can't wait to try them out! I can't quite use it as-is with my current setup since the CPU halts in this stock(ish) setup I need to use PB7 to do square wave audio.
I think that also means I can't use CB2??
http://forum.6502.org/viewtopic.php?f=2&t=562
"Unfortunately, T2CH will have no effect when using T2 for shift register timing. That means you're left with only 256 speeds, range from very, very high notes to ultrasonic. In fact, with a clock speed of about 10MHz or above, they'd all be ultrasonic. Not much good. Instead, use T1 free-running, toggling PB7 "

So, I think since I'm using PB7 for sound, and I am at 5mhz and 'dividing' the timer I can't use CB2?
Maybe not? The VIA is still pretty mysterious to me.

As for treating each bit on it's own....
Thanks! I really do need to be thinking that way!
I need to run the tests on Kowalski to run the cycle counts but I can think of a lot of ways I could use a simple:

to speed up the decoding I already do a LOT!
I also could load two bits and use BCC and BCS to do a 3 way branch.....
I'm using 2 bit video (black/white/dark grey/light grey) so I need more than 1 bit to store color somehow, but I still can think of many things to do along these lines.
Again, I bet the Python Encoder will actually eat up all my time.....


One issue is that up until this point my encoder/decoder were both perfectly content to encode any arbitrary data and copy it into that 8k region of ram. Color images, program data, etc.
Some of my 'premature optimization' was that I wanted to also be able to encode in color as well as B/W.
I had ideas of a simple way of the encoder updating the lookup table as colors changed to improve performance with changing content without having to do a more complex encoder/decoder....
I am moving a little away from that for the moment because I am focused on getting this Bad Apple demo working properly.
Really appreciate all this help! I can't wait to use it!

The VIA is... versatile! It has a lot of different functions all stuffed into one IC, so can be quite hard to know all the ins and outs - I certainly don't, only the bits I've used.

CB2 in particular has a lot of different uses, and in my code above it's just being used as a constant output - nothing to do with the shift register in this case, nor handshaking - so activity on port B won't affect it. However, my code above does use PB7 for MOSI because that was the most efficient way to write bytes out. I think it would be fine to use PB6 for MOSI instead and just add an extra "rol" at the top of the sd_writebyte routine, a minor cost that only affects write operations. It does rely on there being no other output bits on port B, but if setting T1 to drive PB7 overrides any writes we make to the port B register, then I think it will be fine.

Absolutely - if your data works well as a bit stream then this saves you going through all the trouble of assembly a byte of data only to then break it apart again.

Yes, you could shift right after loading the first bit so that it goes in the carry, then load the second bit, and have two flags to use for branching. Or just load the first bit, shift it left, then OR in the second bit like in my sd_readbyte routine, then you have a two bit value in the bottom bits of the A register, to do with as you please - e.g. AND #3, TAY, LDA lookuptable,Y - that sort of thing.

Possibly. It's a critical part of the system though, and one that's relatively easy to debug. For my Bad Apple player, I had a separate Python script to decode the sequence and preview it on the PC, so I could check the encoder was working properly. It was very useful.

You also need to do something about the need to read 10 dummy bytes at the end of each 512-byte sequence. If you're just streaming bits one by one then you don't really want to also be updating a counter of the number of bits you've streamed. One option I thought of was to make the encoder just know that these 10 bytes were coming, and have a way for it to output something that makes the 6502 side just skip over those bytes. But another option is to connect the SD CLK signal also to PB6, and use T2 in pulse counting mode to count 512*8 bits and trigger an interrupt, and have the interrupt handler quickly read out those 10 bytes and return. This would mean your mainline code doesn't need to worry about skipping those bytes any more.

Yes, I think with Bad Apple it's necessary to embrace the monochromish nature of the video, and take as much advantage of it as you can. My Bad Apple player was pure monochrome, I didn't do the shades of grey because they were quite rare in the video. But that's cheating I suppose.

Looking forward to seeing what you can achieve!

Good to eavesdrop on this conversation. I had a 6502 running at 25.175MHz to beam race 640x480 VGA. I only have the vertical blanking period to load next picture so for 20fps, I only have 3 vertical blanking periods to do next frame. You guys gave me hope this is do-able after all.

Finding time to do it is the hard part, however.
Bill

Thanks again for your help!
Sorry, is that ora VIA_PORTANH a typo?
How do I read that last bit without causing that clockpulse? I think I'm missing something about the VIA again..

_________________
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 must have missed that one. That is spectacularly twisted, to do it by injecting a stream of code via an I/O window. Kudos to Chris Morley.

It won't help the OP, who is stuck with bit-banging, but I did something similar ages ago for my own product GoMMC (you can google that, first link). This was on an Acorn BBC as well (so 2 MHz 6502) but with byte-banged SPI (via serial to parallel circuitry in a CPLD) and for all types of video (not just those that compress well). The code for that was essentially a sequence of "LDA abs, STA abs, Y" (so 9 cycles per display byte), plus a bit of overhead once in a while (to INY and wait for the next SD card sector). Video here :

https://www.youtube.com/watch?v=FF19FZnWsno

Of course, the Morley setup can instead do "LDA imm, STA abs" (so 6 cycles per display byte) and derives a lot of extra speed from writing only the frame 'diff' instead of the whole thing, and can only do that because the code can be generated on the fly. That is mighty clever (goosebumps), but only works well for videos where little is changing between frames.

I also never bothered syncing with the CRTC, I was slower than the frame rate anyway (although not by much), and it was more a demonstration of GoMMCs SD card to memory bandwidth than anything else.

OK, WOW!
Thanks for the help!!

I knew the SD card reads could be better and that I should be able to clock with reads from port A but I was having one issue after another.
Your code was invaluable to say the least!!!

So, got it wired up with the clock on CA2, Data in on PA0.
That crazy fast deal with asl : ora PA0 is great!
Got a working SD_init with all this help.. Changed my code a little...
AND......
Ohhhhhhh WOW!
There was so much room to fix that read routine!
37 Frames A SECOND!!!
30
+ 7
frames
a
second..
Like 7 more frames in a second on average than the 30 frames a second encode!!!!

Just WOW.
Thanks for the help!
I haven't improve the encoding/decoding to pack the bits better or removed the code that lets it do color or anything like that.
Just this improved SD read ability.

I KNOW I have enough overhead to smooth out the framerate now, and I should have plenty of bits and cycles for simple square wave music as well.
I can't believe this project is going along so smoothly!
I couldn't have done it without all the great resources put out there and comments from the 6502 community.

Thanks so much gfoot and everyone else who commented!!!
Just wow! Great help on this everyone!
Here is a link:
https://www.reddit.com/r/beneater/comments/181p7v6/37_frames_a_second_37_frames_a_second_on_the/?utm_source=share&utm_medium=web2x&context=3

Excellent! It certainly looks good in the video. Scenes like Fran's appearance are probably the hardest to keep up with, that one was ridiculously expensive in my version.

Thanks!
Is that the girl with the dangling shapes on her wings?
If so that one scene is what inspired me to tackle adding a 3 pixel dictionary to my Run Length routine. I realized that the transitions between black and white is usually a combination of 3 grey pixels and a run of black or grey.
It helped A LOT... But it still lags a bit.
It is just a lot of pixels to move no matter what. I might 'cheat' and store the first few frames of that scene and a couple others in RAM and add logic for grabbing these 'key frames' from ram instead of streaming off the sd card.

Nice idea. I think cmorley's one used the hardware palette to deal with the cases where most of the screen changed colour. Another trick is to not faithfully update the entire frame, if it's going to take too long - update alternate lines first, then the other lines in the next frame. The Python script could detect when the delta for a frame is too large and switch to this mode. You could also deprioritise pixels that are going to change yet again in the very next frame...

Ohhhh... I super like that idea!
I can think of a way I can manually stitch together an even/odd line encode in the problem areas...
But I really like the idea of detecting when there is a lot going on and deprioritizing pixels that are about to change again anyway.
Now that I think about it.... If I just dropped the grey colors or maybe alternate between dropping light grey and dark grey on the bad frames that might be enough in itself. It would reduce the load a lot and with the Bad Apple source I'm using and I bet it would have almost the same effect as deprioritizing pixels that are about to change since the grey colors are transitions between black and white usually.
Though, shadows might suffer if they get deprioritized.
Maybe manual frame tweaking and interlacing in a couple spots might be the quicker choice?

For instance, with greyscale when the apple is thrown at the beginning there is a trail of grey left behind as the sleeve moves with the arm. It looks good in motion but it really lags because a lot of pixels change from black to dark grey, then light grey, then white. I've noticed that even with this super fast SD read throwing the apple is still less smooth than it should be.
If I just manually reduce the motion blur shadows on the source I can keep the grey trail but reduce the size of it until it plays at full speed I would think?

Regardless I'm super happy with the performance so far!

I should try out adding a Beep command to the decoder and see what I can do to inject the right notes at the right time into the stream?
I'm also wondering what it would look like if I added a simple vsync command to the end every frame? I could maybe detect when I have a lot of changes and just skip a few vsyncs every time it happens.
Seems like the easy way to get some music and even out the framerate some.
This Demo project is fun!
Thanks again gfoot and everyone out there in 6502 land!

Hey, here is a vid of my setup playing the start of Bad Apple!.
The current decoder can read 'Beep' commands, but I still need to work on a good way to inject them into the data stream. That's next.

Here is what a breadboard 6502+Worlds Worst Video card streaming out an average of 37 FPS looks like:
https://youtu.be/tA9Q4KJTYVs?si=7B_Tb3bqFpno-Uv9
https://github.com/Fifty1Ford/Ben-Eater-Bad-Apple

Thanks again everyone!
Couldn't have done it without 6502.org!

Nice video and enjoyed the discussion. Animated video, BadApple specifically, on retrocomputer is interesting topic because it is about overcoming the limitation of the 8-bit computers in hardware and software. One needs to understanding the inner workings of the machine and find new ways to make it work and that's the point of doing retro computing.
Bill

Exactly what I find fun!

I'm pretty pleased at how much I got from just hooking a wire up between the VGA Vsync and the 6502 NMI pin! Talk about being close to the hardware!
I posted this elsewhere:

https://www.youtube.com/watch?v=ysJHTtSuPqE

My Bad Apple! Demo was running well at 37 Frames Per Second on average. So now I wanted to even out the frame rate and make it match the 30 Frames Per Second source.

The first thing I did was hook a wire up to the Vsync on the VGA and connected it to the CPU Non Maskable Interrupt/NMI .

I then added this to the system boot ROM:



Now the memory location $E2 will count down each time there is a Vsync pulse from the VGA.
If it gets to 0 it resets to 255. This happens 60 times a second.
This gives me what I need to do a Vsync for each frame.
To actually wait for a Vsync all I do is this:




However I knew that I had some ‘problem’ frames and could not just wait for vsync or it would bog down. (Testing also showed this.) I did not want to do anything too complicated to start with, but I knew I could do something to make it better.

I realized that the VGA setup is 60 frames a second, and that my source is 30 frames a second. Meaning each frame of the source should be two VGA Vsync pules if I could always load and draw them fast enough. But I can’t (yet)... So I made two functions on my 6502 decoder.

One function to wait 1 Vsync pulse and one to wait 2 Vsync pulses. Then on the python encoder side I added a counter for the number of times in a frame I update pixels.

I just guessed and made it so that frames that had:

200 or less changes would wait for the full 2 Vsync’s.

201-500 changes would wait for 1 Vsync.

501+ changes would not wait for Vsync before starting to draw the next frame.

In the encode of ~6,500 frames it:

Skipped vsync for 2,150 frames

Used One vsync on 2,891 frames

Used Two vsync on 1,443 frames

And to my absolute astonishment, that got me a version that clocked in at almost exactly the right runtime!

As you watch you can see the ‘rubber band’ effect that happens...
But wow!
These were started at the same time (3 and a half minute video in total) and it is pretty close for such a simple solution!

Hey all.
I'm really zeroing in on the last optimizations needed to get a true 30FPS lock on this demo.
When I first started I kept using the 30FPS encode as an aspirational thing and never really thought I would end up getting a 37 FPS average!
Wow!
Thanks to all the 6502 people who contributed directly with help and indirectly with your old comments and articles!

With my current encoder/decoder I get a pretty even and good looking 30fps on average. Just a couple 'edge cases' that are a bit to fast or slow.
But with the frame locked music I added the uneven slowdown and speed up 'rubber banding' is very, very obvious.

Yes, I will disconnect the music routine from the video and key off the Vsync NMI.
That fixes the audio issue well enough.
But the video......
I just know it can be improved!!

Here is how:

As gfoot recommended I looked into treating each bit more individually instead of always reading a whole byte.
I was surprised that my existing encoding was as good as it was without taking that into account.
But yes indeed!
There are many, many bytes I was leaving on the table by 'byte encoding' instead of 'bit encoding'
It looks like if I go that route I'll save at least 20% on the encode otherwise as-is.
If I drop the ability to display arbitrary colors that gets me another 10% or so. This is a surprise to me that it looks like it is that low, but on the flip side it increases the decode speed a decent amount since it is a conditional branch on every 'change' or currently half the bytes read that I get to skip.
Either way this will be a good uplift on the problem frames.

Though I now have to find a good way to deal with the 10 mandatory CRC bytes that SD cards barf out every 512 bytes. I count every 2 bytes read currently so I can do a 8 bit counter and then do a unrolled read of 10 bytes when it rolls over to zero.. That's bad enough.
I don't want to count every bit.... Ouch... I'll have to think on how to handle that....
I was going to 'waste' bytes and decode at the time of read from the SD card.
I could read whole bytes into memory and then decode, but I loose some of the gains by reading bits from the SD card and then I'd still need to 'unpack' the bits from RAM.

Error checking, great for file copies, bad for 6502 demo coding...


Also I've been working through what help a 7 kilobyte read buffer would do and the routine needed to keep it filled up.
My rough math told me that while it would help a lot...
But it would still empty out just a bit too quickly right where I need it in the first place.
Even with the new bit level encoding!





But I think there is still a way!


Back ground:
The screen is 100x64 bytes. It has 28 bytes 'wasted' on the right side that are off screen.
Meaning that a line on screen is 128 bytes long, but you can't see the last 28 bytes.
I need the Screen address to roll-over to the start address ($2000) once it gets to the end of the possible screen address space.
That roll-over happens at $3F34 or $4000 depending on how you want to look at it/code it.

Right now I skip these 28 bytes on the side of the screen by encoding 2 bytes as 'skip' bytes on the edge of the screen with my encoder.
That routine simply adds the skip length to the Screen Address and moves on.


If I can find a efficient way to skip over the 28 wasted bytes on the edge of the screen then I can also often avoid encoding these skip bytes.
Since I encode as one long line I sometimes am already in 'skip mode' at the edge of the screen so I get to just continue the skip so there are no saved bytes in that case.

It takes 47 cycles to read a byte from the SD card. So anytime I can skip these bytes encoding off screen skips in less than 94 cycles a line I'm ahead. It also allows a better RLE encode since I get to ignore the skips on the edge. It could also mean reducing the average bytes per frame from ~500 to ~400.
This will reduce the bytes per frame by around 20% and free up time for decoding, drawing, and reading more bytes.
Also, I want to find a way to better optimize the Run Length draw code as it just seems too pokey to me.

The below code takes something between 37 and 43 cycles a pixel/byte to fill the screen and I must encode the skips on the edge of the screen.
I'm sure there must be a faster way to do this:



Any suggestions from the folks around here?
It is working but it feels so awkward!
And 30+ 40+ cycles a byte?
That seems like too much to me!
I'm sure if I can chip away at that I can get this demo where it needs to be!