Back to the drawing board, 6502dude.Kweepa wrote:Megacart sucks! I want a 512k expansion!
Ram Expander
Moderator: Moderators
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.
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.
Total ROM on MegaCart is 2Mbcarlsson 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.
No, not at all.amramsey wrote: Hey! Are you insinuating that I have too much time on my hands?
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.
Mega-Cart: the ultimate cartridge for your Commodore Vic-20
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?
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?
Anders Carlsson
- Mike
- Herr VC
- Posts: 4976
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
In my rotating globe demo I use the following routine to copy a full 160x192 bitmap from $B100 to $1100:
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
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
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
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.
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.
Anders Carlsson
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.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.
Definitely not going to happen overnight though. Just putting video onto the cart is going to take a small lifetime in the first place.
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.
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.
Last edited by ral-clan on Fri Apr 03, 2009 6:56 pm, edited 1 time in total.
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.
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.
Anders Carlsson
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.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.
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
- ultimate expander
- Posts: 5037
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
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.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.
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.
Be normal.