Banked RAM cart

[eslapion]

---

[srowe]

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.

[brain]

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

[eslapion]

---

[pixel]

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.

[pixel]

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.

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

[groepaz]

a memory-mapped SD card reader.

Thats not really doable without massive effort (huge buffers). What's doable though is a large memory mapped SPI flashrom (like what GMOD3 does.

[Mike]

Thats not really doable without massive effort [...]

Also, ("just") a memory-mapped SD card reader would not be able to read from/write to the internal RAM.

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
[...]

... and so on, with boilerplate around it to set up the transfer, notify the controller to provide the code for the next 'sector' access and finally setting the usual bunch of ZP registers ($2D/$2E, etc.) as if the KERNAL had loaded the data originally from disk or tape.

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
[...]

The controller should prepare the next 'page' of code while the VIC-20 executes these transfer routines, so when a hand over to the next sector comes, there's no significant delay for the VIC-20.

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.

[brain]

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

[brain]

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.

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

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

[brain]

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.

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

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

[brain]

Alliance has a 1MB SRAM that is 5V: https://www.digikey.com/product-detail/ ... ND/4234598

Yup! That's less than half the price of the Cypress equivalent.

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

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.

Unlike other folks, you seem to know very well what you're doing.

Unless perhaps he would explain his specific custom requirements.

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.

Jim

[MCes]

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

[Mike]

So, since the IO range is 1kB, [...]

2 KB, but one would simply choose an arrangement of register map, transfer code buffer and boilerplate code buffer most suitable for the task.

[...] whatever the fastest non unrolled loop option would be, what is the speedup per kB?

The math is easy enough. Regardless, non-unrolled is slower.

That seems like a lot of uC code to write and debug for 3.5kB of RAM.

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 ...

The expansion RAM code can be side-loaded by the uC without any lifting by the 6502.

... 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.

Just wondering, as I'm game to try something, but it seems effort is more valuable in other spaces.

Well, you dismissed this idea already once, why should I expect you have changed your mind since then?

[eslapion]

---