Banked RAM cart
Moderator: Moderators
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
Banked RAM cart
---
Last edited by eslapion on Fri Jul 31, 2020 4:54 am, edited 1 time in total.
Be normal.
Re: Banked RAM cart
There are choices over how much flexibility you want, specifically whether the bank control is over the entire region or individual 8K blocks. I'm not convinced all the modes supported by the FE3 are useful but some level of control is needed.
Re: Banked RAM cart
Alliance has a 1MB SRAM that is 5V: https://www.digikey.com/product-detail/ ... ND/4234598
I'd recommend using the UltiMEM register structure. It allows RAM or ROM at a location, banks in all the spots (3KB, BLK1,2,3,5, and IO2,3) and can write protect the RAM so it can be used like ROM.
Jim
I'd recommend using the UltiMEM register structure. It allows RAM or ROM at a location, banks in all the spots (3KB, BLK1,2,3,5, and IO2,3) and can write protect the RAM so it can be used like ROM.
Jim
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
Re: Banked RAM cart
---
Last edited by eslapion on Fri Jul 31, 2020 4:54 am, edited 1 time in total.
Be normal.
- pixel
- Vic 20 Scientist
- Posts: 1361
- Joined: Fri Feb 28, 2014 3:56 am
- Website: http://hugbox.org/
- Location: Berlin, Germany
- Occupation: Pan–galactic shaman
Re: Banked RAM cart
Nice of you to raise that issue but I'm afraid that I've got to disappoint you a little bit, eslapion. Am pretty busy with the Ultimem. INGLE needs to get finished, ARUKANOIDO has been in the pipe for epochs (new apartment next month and hopefully all the man cave stuff back as well) and another top secret and totally crazy thing is in the making. As far as I'm concerned the Ultimem settles all concerns for these projects. Am in for future cartridge releases on ROM.
But to do the impossible it'd take scary proportions in matter of memory size. What'd really warp the VIC into another dimension would be a memory-mapped SD card reader.
But to do the impossible it'd take scary proportions in matter of memory size. What'd really warp the VIC into another dimension would be a memory-mapped SD card reader.
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
https://github.com/SvenMichaelKlose
- pixel
- Vic 20 Scientist
- Posts: 1361
- Joined: Fri Feb 28, 2014 3:56 am
- Website: http://hugbox.org/
- Location: Berlin, Germany
- Occupation: Pan–galactic shaman
Re: Banked RAM cart
True. Only thing I'd wish for the UltiMEM II would be 256 memorized register sets so one can switch between them with a single byte write. And more memory as the number of apps for the VIC will explode soon. :p
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
https://github.com/SvenMichaelKlose
Re: Banked RAM cart
Thats not really doable without massive effort (huge buffers). What's doable though is a large memory mapped SPI flashrom (like what GMOD3 does.a memory-mapped SD card reader.
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
- Mike
- Herr VC
- Posts: 4845
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Banked RAM cart
Also, ("just") a memory-mapped SD card reader would not be able to read from/write to the internal RAM.groepaz wrote:Thats not really doable without massive effort [...]
For faster file I/O, what had been proposed in another thread - nearly 9 years ago - was a method that constructs transfer routines on the fly (most probably in I/Ox to keep RAMx and BLKx free for 'regular' code/data). A microcontroller would access the SD card in a known fashion, but not just providing a single register byte to load a byte from the file. Rather, when loading a file to memory (i.e. KERNAL load replacement/wedge), it would provide unrolled code in I/Ox like thus:
Code: Select all
LDA #aa
STA $1001
LDA #bb
STA $1002
LDA #cc
STA $1003
[...]
A replacement for KERNAL save could similarly work with a 'byte write to file' register and, again, unrolled code:
Code: Select all
LDA $1001
STA I/O_write_to_file
LDA $1002
STA I/O_write_to_file
LDA $1003
STA I/O_write_to_file
[...]
Single character file I/O (OPEN, CHKOUT, CHROUT, CHKIN, CHRIN, CLRCHN, CLOSE), would use the I/O_write_to_file and - instead of the immediate operand in the load transfer code above - another I/O_read_from_file register with auto increment. Not quite as fast as the unrolled transfer loops above, but still much faster than the KERNAL single character file API.
...
This fast file access would help a lot to abstract from a bunch of different, incompatible register layouts for memory mapping. Instead standard KERNAL calls are used to move data between memory and files, with transfer speeds in excess of 100 KB/s! That would benefit not only a few applications specific to the cartridge, it would benefit *all* existing and behaving programs/games/tools!
...
As said, that method was discussed here in Denial already in 2011. TLovskog presumably has a working implementation of that file access method at hand, but thus far no one could persuade him to make it available to the public - and it wouldn't be fun either for anyone to re-implement this on ones own for possibly wasted duplicate effort in case TLovskog gets his backside up.
Re: Banked RAM cart
So, since the IO range is 1kB, and lda #$xx;sta $xxxx = 5 bytes, that means you cna store ~200 bytes this way. Then, you'd need to trigger another unroll of code. COmpared to lda $io2_base ; sta location,x ; inx ; bne loop ; inc $xxxx ; cmp $xx ; bne loop, or whatever the fastest non unrolled loop option would be, what is the speedup per kB?
That seems like a lot of uC code to write and debug for 3.5kB of RAM. The expansion RAM code can be side-loaded by the uC without any lifting by the 6502.
Just wondering, as I'm game to try something, but it seems effort is more valuable in other spaces.
Jim
That seems like a lot of uC code to write and debug for 3.5kB of RAM. The expansion RAM code can be side-loaded by the uC without any lifting by the 6502.
Just wondering, as I'm game to try something, but it seems effort is more valuable in other spaces.
Jim
Re: Banked RAM cart
Actually, I'm not sure it's that tough, at least for reads. With a CPLD, and a uC, I could easily shunt the RAM to the uC, load it up with data from the SD, and then switch it back to the CPU.
Or, am I misunderstanding this idea?
Jim
Re: Banked RAM cart
Actually, I have figured out a way to do that now, so I'm game. But, the list of apps using UltiMEM is unfortunately huge at present
Jim
Re: Banked RAM cart
Well, the design is open source, so it can be remixed if needed, or I am game to try something new, or make a low cost version (a < 1MB RAM version that is 5V could use a much smaller CPLD, and if it's just the 2 ICs, and no FLASH ROM, cost could half or less.eslapion wrote: ↑Sun Jul 12, 2020 2:03 amYup! That's less than half the price of the Cypress equivalent.brain wrote: ↑Sun Jul 12, 2020 1:02 am Alliance has a 1MB SRAM that is 5V: https://www.digikey.com/product-detail/ ... ND/4234598
IMHO, I'm wondering why Pixel made that comment about making his own banked RAM cart and why he wouldn't simply buy an UltiMEM cart.I'd recommend using the UltiMEM register structure. It allows RAM or ROM at a location, banks in all the spots (3KB, BLK1,2,3,5, and IO2,3) and can write protect the RAM so it can be used like ROM.
Jim
Unlike other folks, you seem to know very well what you're doing.
Unless perhaps he would explain his specific custom requirements.
Jim
Re: Banked RAM cart
This project can be done cheap: it contain a TTL chip, a PLD (22V10) and a 128K static ram.
This system can be extended for having more Ram than 128K (more 8k pages)
http://sleepingelephant.com/ipw-web/bul ... f=3&t=7706
This system can be extended for having more Ram than 128K (more 8k pages)
http://sleepingelephant.com/ipw-web/bul ... f=3&t=7706
"Two things are infinite, the universe and human stupidity, and I am not yet completely sure about the universe." (Albert Einstein)
- Mike
- Herr VC
- Posts: 4845
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Banked RAM cart
2 KB, but one would simply choose an arrangement of register map, transfer code buffer and boilerplate code buffer most suitable for the task.brain wrote:So, since the IO range is 1kB, [...]
The math is easy enough. Regardless, non-unrolled is slower.[...] whatever the fastest non unrolled loop option would be, what is the speedup per kB?
5 KB internal RAM for a stock VIC-20; or on a VIC-20 with VFLI mod, 8 KB internal RAM. When the file transfer method works there, it also works for expansion RAM ...That seems like a lot of uC code to write and debug for 3.5kB of RAM.
... and, again, it would work the same way there, using standard KERNAL API calls and would not require programs to be adapted to the cartridge.The expansion RAM code can be side-loaded by the uC without any lifting by the 6502.
Well, you dismissed this idea already once, why should I expect you have changed your mind since then?Just wondering, as I'm game to try something, but it seems effort is more valuable in other spaces.
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
Re: Banked RAM cart
---
Last edited by eslapion on Fri Jul 31, 2020 4:55 am, edited 1 time in total.
Be normal.