A RAMLink for the VIC-20 ?

[eslapion]

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?

AFAIK, Jim Brain's device plugs into the IEC port.

It has nowhere near the speed of a RAMLink.

[6502dude]

Why not just get a 1541 Ultimate?

[gklinger]

Why not just get a 1541 Ultimate?

You can't plug that into the VIC-20's cartridge port so all the nifty features, REU included, are a no-go. Once the plans and software are open sourced I suppose someone could design a VIC-20 version but that seems like a chore and a half.

I figure the 1541U plugged into my 64 and connected to both my VIC-20 and my 64 with an IEC switcher and a MegaCart (which will reside permanently in my VIC-20) will avail me access to every piece of VIC-20 software out there (and therefore happiness).

[6502dude]

You can't plug that into the VIC-20's cartridge port so all the nifty features, REU included, are a no-go.

I should have paid more attention when you did your presentation of this back in May

Once the plans and software are open sourced I suppose someone could design a VIC-20 version but that seems like a chore and a half.

Presumably many of the source routines for FPGA should port from 6510 to 6502. I'll bet this task is easier than coming up with CBM DOS look- alike for custom ram-link hardware.

I figure the 1541U plugged into my 64 and connected to both my VIC-20 and my 64 with an IEC switcher and a MegaCart (which will reside permanently in my VIC-20) will avail me access to everyone piece of VIC-20 software out there (and therefore happiness).

This would be a very cool set up!

[nbla000]

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.

This requires a lot of work and relative time at least for me, i need to check 1541/71/81 routines and try this item with real hardware, i think is too much work for me, if you want i may study a different approach.

Why not just get a 1541 Ultimate?

You can't plug that into the VIC-20's cartridge port so all the nifty features, REU included, are a no-go. Once the plans and software are open sourced I suppose someone could design a VIC-20 version but that seems like a chore and a half.

I think this is an easy solution btw to use the 1541 Ultimate via serial port is not too bad.
I don't think there are a lot of c64 programs that use REU functions, how many new Vic programs may use this function ?

[eslapion]

Presumably many of the source routines for FPGA should port from 6510 to 6502. I'll bet this task is easier than coming up with CBM DOS look- alike for custom ram-link hardware.

The 1541U and 1541U+ mains features other than pure 1541 emulation(REU emulation, instant menu for switching D64 files, high speed direct transfer) are almost all based on the fact that the C64 and C128 support DMA.

There is no such support on the VIC-20. DMA support and an extra 8 bit IO port are the main differences between the 6510 and 6502.

[eslapion]

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.

This requires a lot of work and relative time at least for me, i need to check 1541/71/81 routines and try this item with real hardware, i think is too much work for me, if you want i may study a different approach.

A different approach could be good.

Why not just get a 1541 Ultimate?

You can't plug that into the VIC-20's cartridge port so all the nifty features, REU included, are a no-go. Once the plans and software are open sourced I suppose someone could design a VIC-20 version but that seems like a chore and a half.

I think this is an easy solution btw to use the 1541 Ultimate via serial port is not too bad.
I don't think there are a lot of c64 programs that use REU functions, how many new Vic programs may use this function ?

The 1541 Ultimate when plugged to the serial (IEC) port is no faster than a real 1541. At the moment, it doesn't even support JiffyDOS.

There are MANY powerful applications that use the REU on the C64.

The device I would like to create for the VIC is NOT an REU, altough it could be used as one. As I indicated, its more like a RAMLink for the VIC but unlike the real RAMLink, it would not require a big battery and permanent power supply.

[gklinger]

The 1541 Ultimate when plugged to the serial (IEC) port is no faster than a real 1541. At the moment, it doesn't even support JiffyDOS.

Are you quite sure? I haven't checked to see if JiffyDOS works in standalone mode but I don't see why it wouldn't as the 1541U would still be using the JD ROM image. I'll test that later today.

[6502dude]

I haven't checked to see if JiffyDOS works in standalone mode but I don't see why it wouldn't as the 1541U would still be using the JD ROM image. I'll test that later today.

I would be interested to find this out as well.
I have not installed JD on any of my Vic-20s yet, but I am considering this.

[eslapion]

The 1541 Ultimate when plugged to the serial (IEC) port is no faster than a real 1541. At the moment, it doesn't even support JiffyDOS.

Are you quite sure? I haven't checked to see if JiffyDOS works in standalone mode but I don't see why it wouldn't as the 1541U would still be using the JD ROM image. I'll test that later today.

When using the 1541U in standalone mode (IEC port only), there are two modes of operation.

The first is the 1541 emulation. I suppose, in this mode, it should be easy to substitute the standard 1541 ROM with a JiffyDOS configuration. Does it work? AFAIK, Gideon never tested it. Is it easy to alter the files sent to the 1541U to configure it like that? No idea.

The second mode of operation which is as a mass storage device where the 1541U becomes a sort of SD2IEC definitely does not support JiffyDOS.

In any case, even a 1541 with JiffyDOS remains considerably slower than a RAMLink.

I have not installed JD on any of my Vic-20s yet, but I am considering this.

You really should. The transfer speed increase with my JD installed 1541-II, 1581, 1571, FD-2000 and CMD HD is significant.

Loading a 16k game like Donkey Kong or Lode Runner usually takes about 3 seconds.

[Shaun.Bebbington]

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.

Do it, damn it!

And, post on the Commodore Computer Club forums about it too

If you can make them in any numbers, maybe our shop could stock it?

Regards,

Shaun.

[brain]

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?

AFAIK, Jim Brain's device plugs into the IEC port.

It has nowhere near the speed of a RAMLink.

Those are both true statements.

There are plans, though, for a parallel cable for transfers for the uIEC, ala ProfessionalDOS/RapiDOS. If someone would like to help adding VIC-20 support for that, I think it would benefit the community well.

Note that JiffyDOS speeds are very snappy. Since uIEC does not incur any mechanical latency (with CF cards, anyway), transfers are faster than even with the CMD-HD.

Jim

[eslapion]

There are plans, though, for a parallel cable for transfers for the uIEC, ala ProfessionalDOS/RapiDOS. If someone would like to help adding VIC-20 support for that, I think it would benefit the community well.

Note that JiffyDOS speeds are very snappy. Since uIEC does not incur any mechanical latency (with CF cards, anyway), transfers are faster than even with the CMD-HD.

Now that's a very good idea.

However, I would like to point out that the original idea behind this thread was to experiment with the possibilities offered by having a large amount of non-volatile SRAM accessible to the VIC via page selection.

Wether this results in some sort of ultrafast mass storage device or in a form of REU for the VIC is not really a concern to me. I prefer to make it available so programmers can do whatever they feel like doing with it.

A CF card for the VIC will never be near the speed of directly accessible SRAM, not because the CF is slower (its actually much faster) but because of the need for interfacing circuitry. However, it does make a much more appropriate and useable storage device.

[brain]

My comments were more around the idea of laying a DOS on top of the RAM. I agree that writing a new KERNAL with a RAM-based DOS would be time better spent adding parallel support to a project like uIEC.

I think a RAM expander would be fine. My preference would be one that banks in the 16K chunks in the same place as the 16kB RAM expander.

Jim