Ram Expander

gklinger · Post by **gklinger** » Mon Mar 30, 2009 3:32 pm

Kweepa wrote:Megacart sucks! I want a 512k expansion!

Back to the drawing board, 6502dude.

carlsson · Post by **carlsson** » Tue Mar 31, 2009 4:04 am

Hm, what is the size of the EPROMs in Mega-Cart? While it won't be user programmable like a RAM or Flash memory, capacity-wise it should well exceed 512 kB.

amramsey · Post by **amramsey** » Tue Mar 31, 2009 5:01 am

The MegaCart definitely has more memory than this thing..... not to mention lots of cool features that make the two boards very different.

While the battery backed ram in my prototype could theoretically be used to create something like a megacart, my intention was more to prove that a banked ram cart was feasible for larger games or apps which could use the banked area to store large amounts of data or code. 512K is definitely way overkill I think, given the crazy amount of time that it took the Vic-20 to write all 0s to all 60 banks of 8k.

Loading that much data from disk would be insane.

Something like a 64k or 128k cart is more in the realm of usability. That being said, I'm not sure that there is much software out there that is even maxing out the 32k of normal Vic-20 memory, aside from maybe Realms of Quest 3.

I've got a crazy idea for a neat demo with the 512k cart though. I'm wondering if it would be possible to store some video frames on the cart just for fun. I'm not sure how long it would take to copy data from the cart to the video ram though... Might only be able to get to a couple of frames a second. Still would be fun to try out though.

amramsey · Post by **amramsey** » Tue Mar 31, 2009 5:03 am

6502dude wrote:I wish I had the spare time to experiment more.

Hey! Are you insinuating that I have too much time on my hands?

Don't tell my wife... she'll have me outside cleaning the damn gutters.

6502dude · Post by **6502dude** » Tue Mar 31, 2009 7:28 am

carlsson wrote:Hm, what is the size of the EPROMs in Mega-Cart? While it won't be user programmable like a RAM or Flash memory, capacity-wise it should well exceed 512 kB.

Total ROM on MegaCart is 2Mb

amramsey wrote: Hey! Are you insinuating that I have too much time on my hands?

No, not at all.
MegaCart project has been very time consuming and I have put a lot of project ideas on hold for now. Experiments are fun, production is not.

amramsey · Post by **amramsey** » Tue Mar 31, 2009 7:36 am

6502dude wrote:MegaCart project has been very time consuming and I have put a lot of project ideas on hold for now. Experiments are fun, production is not.

Happily the end is in sight for you on the MegaCart. Well, at least until you need to do another run of the boards.

carlsson · Post by **carlsson** » Wed Apr 01, 2009 1:03 am

Regarding video player, I think you will need double buffering. It would limit your resolution to 128x128 or so (max 2K bitmap). The speed of it could be previewed with a regular 16-24K RAM cartridge filled with image data and a program to shuffle it into either buffer.

For testing, you could make it even simpler, a program just to fill then clear 2K of memory.

On the other hand if you made an internal mod that let you switch in any 4K block to $1000, it would be quite fast.

By the way, how much more work would it be to switch in 16K or 32K at a time instead of one slot of 8K?

Mike · Post by **Mike** » Wed Apr 01, 2009 3:17 am

In my rotating globe demo I use the following routine to copy a full 160x192 bitmap from $B100 to $1100:

Code: Select all

.Blit
 LDX #192
 LDY #191 
.Blit_00
 LDA $B100+19*192,Y:STA $1100+19*192,Y
 LDA $B100+18*192,Y:STA $1100+18*192,Y
 LDA $B100+17*192,Y:STA $1100+17*192,Y
 LDA $B100+16*192,Y:STA $1100+16*192,Y
 LDA $B100+15*192,Y:STA $1100+15*192,Y
 LDA $B100+14*192,Y:STA $1100+14*192,Y
 LDA $B100+13*192,Y:STA $1100+13*192,Y
 LDA $B100+12*192,Y:STA $1100+12*192,Y
 LDA $B100+11*192,Y:STA $1100+11*192,Y
 LDA $B100+10*192,Y:STA $1100+10*192,Y
 LDA $B100+ 9*192,Y:STA $1100+ 9*192,Y
 LDA $B100+ 8*192,Y:STA $1100+ 8*192,Y
 LDA $B100+ 7*192,Y:STA $1100+ 7*192,Y
 LDA $B100+ 6*192,Y:STA $1100+ 6*192,Y
 LDA $B100+ 5*192,Y:STA $1100+ 5*192,Y
 LDA $B100+ 4*192,Y:STA $1100+ 4*192,Y
 LDA $B100+ 3*192,Y:STA $1100+ 3*192,Y
 LDA $B100+ 2*192,Y:STA $1100+ 2*192,Y
 LDA $B100+ 1*192,Y:STA $1100+ 1*192,Y
 LDA $B100+ 0*192,Y:STA $1100+ 0*192,Y
 DEY
 DEX
 BNE Blit_00
 RTS

It only needs ~37000 cycles to complete, which allows for nearly 30 frames per second. If one then maps in fresh data in BLK5 this is practically everything that's needed ...

The routine works "against the grain", i.e. it copies in the other direction than the raster beam displays the screen. This helps (a bit) to make tearing effects less noticeable.

Greetings,

Michael

amramsey · Post by **amramsey** » Wed Apr 01, 2009 11:54 am

carlsson wrote:By the way, how much more work would it be to switch in 16K or 32K at a time instead of one slot of 8K?

That's a piece of cake, just a quick change of code. What do you have in mind?

carlsson · Post by **carlsson** » Thu Apr 02, 2009 1:05 am

I don't have anything in particular in mind, but would assume the larger blocks of memory you can switch in, the more flexible the program can be. Of course you can only execute one instruction at a time, but you can make far jumps or access data elsewhere.

Mike: Cool, I didn't think you can reach as high frame rate. The amount of visible glitches will probably depend on the video data.

amramsey · Post by **amramsey** » Thu Apr 02, 2009 5:22 am

Mike wrote:It only needs ~37000 cycles to complete, which allows for nearly 30 frames per second. If one then maps in fresh data in BLK5 this is practically everything that's needed ...

The routine works "against the grain", i.e. it copies in the other direction than the raster beam displays the screen. This helps (a bit) to make tearing effects less noticeable.

Nice! I watched the rotating globe demo a few months back and it blew my mind. When I started thinking about playing out video for some fun, I didn't put two and two together though.

Now that I know its possible, I'm going to have to give it a try just to see. I think I may be able to figure out a way to use the ppm2vic software discussed in another thread to help convert video to vic frames.

Definitely not going to happen overnight though.

Just putting video onto the cart is going to take a small lifetime in the first place.

ral-clan · Post by **ral-clan** » Thu Apr 02, 2009 5:49 am

If you're just using PPM files for the video, then couldn't you just use something like VirtualDUB to take an AVI and spit out a series of bitmaps, then use something like Irfanview in batch mode to convert those bitmaps to PPM files?

That's if you are using raw PPM files for the video. With only 512K of storage you'll only get a few seconds of video, I guess. If you were able to do some sort of on the fly decompression, you could get more.

carlsson · Post by **carlsson** » Fri Apr 03, 2009 4:06 am

Um, to my knowledge there is no VIC tool to read/convert foreign image formats. Remember Pasi's converter runs on a PC to generate a custom VIC-20 format, I think ~4400 bytes per image including colour data? If that estimate is correct, I think the 512K memory will hold up to 119 images. Using a simpler format with no/fixed colour data he could fit 131 frames.

If you can get 25-30 frames per second, the video will be between 3.97 and 5.24 seconds. So yes, a few seconds until it loops.

At 128x128 pixels and 15 fps, you can store 256 frames and get a 17 seconds long video. Slower than 15 fps may feel like a slideshow.

amramsey · Post by **amramsey** » Fri Apr 03, 2009 3:54 pm

carlsson wrote:At 128x128 pixels and 15 fps, you can store 256 frames and get a 17 seconds long video. Slower than 15 fps may feel like a slideshow.

Sounds like I'll have to wire up the 4M version of that chip for some fun.

And it would take me about 8 hours to get a minute of video on there.

Might be better off with a flash card hooked up to a microprocessor which can ping-pong data between two memory banks. For instance, the processor could be filling BLK3 from the sdcard while the Vic is displaying data from BLK5 and then swap. Would make for a cool demo, albeit pointless. I'm sure that there are lots of other uses that an cartridge with a microprocessor to run as a coprocessor + sdcard for storage could be used for...

eslapion · Post by **eslapion** » Fri Apr 17, 2009 11:29 am

amramsey wrote:While the battery backed ram in my prototype could theoretically be used to create something like a megacart, my intention was more to prove that a banked ram cart was feasible for larger games or apps which could use the banked area to store large amounts of data or code. 512K is definitely way overkill I think, given the crazy amount of time that it took the Vic-20 to write all 0s to all 60 banks of 8k. Loading that much data from disk would be insane.

Something like a 64k or 128k cart is more in the realm of usability. That being said, I'm not sure that there is much software out there that is even maxing out the 32k of normal Vic-20 memory, aside from maybe Realms of Quest 3.

I've got a crazy idea for a neat demo with the 512k cart though. I'm wondering if it would be possible to store some video frames on the cart just for fun. I'm not sure how long it would take to copy data from the cart to the video ram though... Might only be able to get to a couple of frames a second. Still would be fun to try out though.

A while back, I envisioned the possibility of using MRAM or FRAM to create a sort of RAMLink for the VIC-20. The beauty of this type of memory is that it requires no capacitor to transfer to/from flash/ram or any type of battery backup. It is therefore more reliable than anything else.

This VIC-20 RAMLink could easily carry up to 64MBytes (65536 windows of 1kbytes) instantly accessible. Since there is no DMA on the VIC-20, transfer speed would be limited to how fast the 6502 can transfer blocks of 1kBytes to/from its 32kRAM expansion.

Still, it would be considerably faster than anything that connects to the IEC port but to truly exploit it, a true DOS, just like RAMLink, would be needed. Creating it could prove to be a lot of tedious work.

Nonetheless, a VIC-20 RAMLink, even with far less capacity than 64Mbytes, would a considerably better and more versatile cartridge than the megacart, on which you can't store anything permanently other than its originally burned EPROM content.