A RAMLink for the VIC-20 ?

[eslapion]

I have started a personnal project consisting in a weird alteration to a Behr Bonz board.

It is effectively a 2Mbytes Non volatile RAM expansion for the VIC-20.

Here is a nice invitation to Nicolas: With the proper driver software (a modified version of EasyLoad, perhaps), it could effectively behave as a form of CMD RAMLink for the VIC-20.

Any interest?

At the moment, I'm just doing this for the fun of it.

[nbla000]

It is effectively a 2Mbytes Non volatile RAM expansion for the VIC-20.

Here is a nice invitation to Nicolas...

This is a great invitation !!!

2Mbytes of nvRAM give me a lot of ideas, how you may address nvRAM ? in which BLKs ? May you use blk 0 (400-fff) too ?

Any interest?

yes
but as you can understand, i need additional infos...

At the moment, I'm just doing this for the fun of it.

Good way for fun

[eslapion]

This is a great invitation !!!

2Mbytes of nvRAM give me a lot of ideas, how you may address nvRAM ? in which BLKs ? May you use blk 0 (400-fff) too ?

Presently, the 2Mbytes NVRAM presents itself as 128 windows of 16k. Selecting the window is done by poking to IO3.

The selected window presents itself in BLK3 and BLK5.

Maybe we could rearrange this to offer greater versatility.

[hawk]

I'm also interested...I can see it as an easily re-programmable flash-cart much like I have for my GBA.

It would also allow software to be written which takes advantage of the bank selection to allow access to more data.

I think it would be advantageous if the banks could be switched in 8k, being able to allocate any 8k block to either BLK3 or BLK5.

It sort of becomes an easily re-programmable Mega Cart...much like I have for my GBA.

[nbla000]

Presently, the 2Mbytes NVRAM presents itself as 128 windows of 16k. Selecting the window is done by poking to IO3.

The selected window presents itself in BLK3 and BLK5.

So this unit has not memory expansions...

No problems if it presents itself in BLK3 and BLK5 only but i think that a sort of RAMLink for the vic requires memory expansion selectable via software (BLK0/1/2/3/5) and a sort of software switch between RAM and NVRAM.

It sort of becomes an easily re-programmable Mega Cart...

Not really, you need an user customizable menu, integrated memory expansions and a lot of other things, btw by using a sort of drive Emulation it can be used like a DiskDrive but it requires a lot of work and tests on real hardware.

[hawk]

It sort of becomes an easily re-programmable Mega Cart...

Not really, you need an user customizable menu, integrated memory expansions and a lot of other things, btw by using a sort of drive Emulation it can be used like a DiskDrive but it requires a lot of work and tests on real hardware.

Admittedly it's only the hardware of a Flash Cart, but with menu software installed in the default BLK5 memory block which would allow to either switch to another memory block and reset, or load another memory block from disk that would be saved to nvRAM, it would come very close.

[6502dude]

I have started a personnal project consisting in a weird alteration to a Behr Bonz board.

It is effectively a 2Mbytes Non volatile RAM expansion for the VIC-20.

Here is a nice invitation to Nicolas: With the proper driver software (a modified version of EasyLoad, perhaps), it could effectively behave as a form of CMD RAMLink for the VIC-20.

Any interest?

At the moment, I'm just doing this for the fun of it.

Isn't this just your Flash Cart project from last year, but using NVRAM chip instead?

[eslapion]

Isn't this just your Flash Cart project from last year, but using NVRAM chip instead?

The availability and low cost of FeRAM and MRAM makes the flashcart a completely useless and obsolete design.

These memory types behave like NVRAM or NVsRAM but without the need for a battery or capacitor and can keep their content for 45 years or more.

Writing data to a flash memory chip from the VIC is a tedious and cumbersome process. Also, erasing data must be done by blocks.

To do something equivalent to a RAMLink, it has to offer complete freedom of access on a byte by byte basis, something no type of flashram offers.

So this unit has not memory expansions...

No problems if it presents itself in BLK3 and BLK5 only but i think that a sort of RAMLink for the vic requires memory expansion selectable via software (BLK0/1/2/3/5) and a sort of software switch between RAM and NVRAM.

No memory expansion in there. Just like any other disk drive, mass storage only.

However, I do see the need to have some sort of switching between RAM and NVRAM in the BLK5 area if you want to load something there.

I am presently considering the following:
Instead of having 128 windows of 16k, have 256 windows of 8k, all visible in the BLK5 area and add 1k of RAM expansion in the IO2 area.

Add a passthrough connector for RAM expansion in BLK 0/1/2/3/5 with the BLK5 RAM expansion software selectable.

When something requires loading in the BLK5 area, first load it in the BLK2 area (we now know that all carts that use BLK5 never use BLK2 at the same time), copy a small ML routine in the IO2 RAM area, jump to this ML routine which will set the BLK5 area to RAM expansion and copy the data from BLK2 to BLK5.

Maybe this small ML routine could also be placed in the tape buffer area to alleviate the need to have a 1K RAM expansion.

For the moment, let's consider this device can only load data in BLK0/1/2/3 and that there is no ability to switch between RAM NVRAM in BLK5.

[nbla000]

Maybe this small ML routine could also be placed in the tape buffer area to alleviate the need to have a 1K RAM expansion.

Yes maybe but i need to use the "firmware" from the default 8k block (0 or 255) but where to store file names and pointers....

For the moment, let's consider this device can only load data in BLK0/1/2/3 and that there is no ability to switch between RAM NVRAM in BLK5.

I need to reflect on how to use this kind of item

btw a software controlled expansion memory is better for me, yes you may use your Ultimate Expander using the passthrough connector but based on my MegaCart experience a software controlled expansion is much more better.

I never remove the MegaCart from my vic and i load everything from disk/tape too, just hold F1 on boot for a vic unexpanded, F3 for a Vic+3K and F5 for a Vic+32K, F7 for a vic Full expanded with EasyLoad on BLK5.

[gklinger]

I never remove the MegaCart from my vic and i load everything from disk/tape too, just hold F1 on boot for a vic unexpanded, F3 for a Vic+3K and F5 for a Vic+32K, F7 for a vic Full expanded with EasyLoad on BLK5.

You are making everyone very jealous.

[eslapion]

btw a software controlled expansion memory is better for me, yes you may use your Ultimate Expander using the passthrough connector but based on my MegaCart experience a software controlled expansion is much more better.

To me, software controlling RAM expansion is very dangerous. As experienced with Shamus, Atlantis, Demon Attack and Dragonfire, all it takes is one poke at the wrong address (especially in the IO memory areas) and your VIC goes nuts.

What I would suggest is to have the firmware for the file system in window 0. Window 1 carries the directory information with regards to the files, something similar to track 18 of a 1541. This leaves 254 windows of 8k each to store data.

Just like on a 1541, file names are limited to 16 characters and data is stored on a series of "sectors" except they are 1k in size, each carrying 1022 bytes of information with the two first bytes telling where the next is or 00 XX where 00 means this is the last sector of the file and XX*4 is the number of bytes left in that last sector.

Since the first 16 sectors are used for firmware and directory, usable sectors begin at 17 or $00 11 and end at $07 FF. Swap the bytes and you get $1100 to $FF07 making it impossible to have a sector number that begins with $00.

If we design a 16Mbytes version in the future, sector numbers will range from $00 11 to $3F FF carrying sector numbers $1100 to $FF3F.

[Richard James]

To me, software controlling RAM expansion is very dangerous. As experienced with Shamus, Atlantis, Demon Attack and Dragonfire, all it takes is one poke at the wrong address (especially in the IO memory areas) and your VIC goes nuts.

Maybe you could have two locations. The first one is a lock and the correct hex value must be placed in it. When that is done the second location can be used to alter the RAM expansion. As soon as the second memory location is altered the lock activates again. That is probably very hard to do in hardware though (forgive me I'm a software guy).

[nbla000]

What I would suggest is to have the firmware for the file system in window 0. Window 1 carries the directory information with regards to the files

Yes but if window 0 starts automatically on BLK5, how i can read datas on window 1 ? i need to write code on tape buffer or IO/area that swap to windows 1 read datas and return to window 0...

Just like on a 1541, file names are limited to 16 characters and data is stored on a series of "sectors"....

A little bit complicated, i need to reflect

[eslapion]

Yes but if window 0 starts automatically on BLK5, how i can read datas on window 1 ? i need to write code on tape buffer or IO/area that swap to windows 1 read datas and return to window 0...

That is exactly what I had in mind.

Just like on a 1541, file names are limited to 16 characters and data is stored on a series of "sectors"....

A little bit complicated, i need to reflect

Since this is going to be a true storage device, it is necessary to use for of the methodologies used by the 1541 and/or 1581.

Users will want to load, save, rename and delete PRG files, more than likely SEQ files too. Maybe USR and REL files as well.

Just like with any other drive, they will want to be able to list the directory on screen.

You have to consider that unlike a series of files stored sequentially at fixed addresses in a ROM, this requires a true filing system to meet the basic requirements.

Also, eventually, people will need to "defragment" this drive and a special software will be needed to clear out the deleted entries and reorganise the data to make it contiguous again.

Copy software may be necessary for people to copy files to/from a 1541 or 1581.

[6502dude]

So this project is essentially CBM DOS for a hardware based memory device that emulates a 1541/1581 drive.

Hasn't Jim Brain already done this?