FE3 RAM Disk

[Kananga]

After sucessfully implementing a Task Switcher for the FE3 last year, I finally spent some time on another idea I had for making use of the extra 512K RAM of the Final Expansion 3: A RAM disk.


Download

As a proof of concept implementation it is not yet fast enough.
Not so impressive results for loading 87 blocks:
SD2IEC without SJLOAD: 39s
SD2IEC with SJLOAD: 3.5s
Loading from RAM: 4s

It is of course possible to make the RAM disk faster, but I wanted to share the current results before I go on
(Source code on Google Code)

[orion70]

Cheers Kananga, but I don't get exactly what is this . I see it's a (huge) virtual drive seen as device 13, is that right? If so, how can I save stuff in it? And does it reset every time I turn off the VIC? Thanks, and pardon my ignorance.

[Diddl]

Yes, Jiffy is very fast for a serial stream. But normally a RAM Disk should be much faster. Even if a memory management is nessecary.


It is a very good idea. I can't await the result of your project ...

[Kananga]

Cheers Kananga, but I don't get exactly what is this .

Sorry, I could have written more.

I see it's a (huge) virtual drive seen as device 13, is that right?

Yes, it is a virtual device in RAM and if you turn of the VIC all is lost.

If so, how can I save stuff in it?

Just like you would do with any other device, for example you can use:
SAVE"TEST",13

Or save stuff (here "ABC") with:
OPEN1,13,1,"mydata":PRINT#1,"ABC":CLOSE1

The directory is available with:
LOAD"$",13

You can use the drive for writing data you can not keep in the VICs memory to the extra RAM and read it on demand. That is what I want to do with the VIC-GUI, where I also work on a dynamic loader+linker, but as long as SJLOAD+SD2IEC is faster, it is not necessary to use the RAM drive.
But, as I wrote above, it is just a demonstration how it could work and it should be possible to improve the performance significantly.

BTW, you can't use SJLOAD together with the RAM drive yet, because it uses the same RAM area ($0400). I intend to make both programs co-exist, but I can't find SJLOAD 8 anywhere.

EDIT:
You could also write a program that copies a whole disk in one go, by storing the image in the RAM drive! But who does still use real 5 1/4'' disks?

[Kananga]

Yes, Jiffy is very fast for a serial stream. But normally a RAM Disk should be much faster. Even if a memory management is nessecary.

If you keep all of the code in the unbanked area ($0400-$0FFF) it should be easy, but I wanted to leave room for SJLOAD.
Having code on one of the banks gives 32K for code. You could implement channel 15 disk commands with that much space.

In addition, the present implementation is slow because:
- data is copied between banks through a buffer in the unbanked area.
- CHKIN/CKOUT is almost ignored and should be used to setup BASIN/BSOUT
- every call to BASIN/BSOUT jumps to the code in BANK 2.
- LOAD and SAVE uses OPEN/BASIN/BSOUT/CLOSE

Should be easy to make it faster

[Diddl]

It would be nice to have it integrated in FE3FIRMWARE.

It wouldn't be nessecary to hold SJLOAD and RAMDRIVE code at $0400, it could stay in ROM also. Only a small code part for fetching bytes from RAM would be nessecary to execute in non banked area.


But since VC-20 has a small RAM area, speed is never a problem. A speed near to jiffy is fast enough normally.


I also thought about a disk copy program using FE3 RAM and OpenCBM diskcode. But there are not many people who have a FE3 and most people doesn't use 5 1/4" disks ...

I think it would be better to have a fast copy from 1541 to SD card (D64 image).

[Kananga]

It wouldn't be nessecary to hold SJLOAD and RAMDRIVE code at $0400, it could stay in ROM also. Only a small code part for fetching bytes from RAM would be nessecary to execute in non banked area.

True, but the footprint in unbanked memory of the current release is around 1.6K.

But I am working on it, stay tuned!

[Kananga]

I changed the way the driver copies data to and from RAM banks and managed to improve speed slightly. It is now faster than SD2IEC+SJLOAD.
Current transfer rate for loading is 9.3KB/s.

Results for loading 87 blocks:
- SD2IEC without SJLOAD: 39s
- SD2IEC with SJLOAD: 3.5s
- Loading from RAM: 2.3s

I also moved the unbanked code to $990 which allows to load SJLOAD to $0400 (at least the last version I have, which is 7).
For you convenience (and easier usage in the FE3 menu) FE3RD loads and initializes SJLOAD, if it finds it in the same directory under the name "SJLOAD$04".

Download

[Diddl]

Very nice work. I would like to see this inside the FE3 firmware integrated. Maybe inside the FE3WEDGE.

If it would be reset resistant, it would be nice for developing on the VC-20.

And another nice idea would be a backup/restore to SD card as a big file.


This RAM disk would be very useful for scener. Big demo files could be played back from RAM disk easyli.

[Kananga]

Very nice work. I would like to see this inside the FE3 firmware integrated. Maybe inside the FE3WEDGE.

Should be possible.

If it would be reset resistant, it would be nice for developing on the VC-20.

Perhaps, the Task Switcher is more useful for developers, because you can save and load machine state at any time (almost ) and it is reset resistant unless you press the red reset button on the FE3 cartridge or the RAM at $A000 is overwritten.
And you could run debugging tools in one of the available virtual environments.

And another nice idea would be a backup/restore to SD card as a big file.

Take a look at the memory map:

Code: Select all

Segment list:
-------------
Name                  Start   End     Size
--------------------------------------------
ZEROPAGE              0000FA  0000FD  000004
LTABLE                000990  0009A3  000014
LCODE                 0009A4  000F98  0005F5
LDATA                 000F99  000FE4  00004C
BASIC                 0011FF  00120C  00000E
BOOT                  00120D  001472  000266
TABLE                 002000  002003  000004
CODE                  002004  0026EB  0006E8
RODATA                0026EC  00272B  000040
DATA                  00272C  002CF1  0005C6

Not much space left in the unbanked area ($0400-$0FFF, $0400-$098F is left free for SJLOAD). Saving and loading the disk state would require a bit more than 28 bytes, I suppose.

This RAM disk would be very useful for scener. Big demo files could be played back from RAM disk easyli.

My intention was to have a disk for loading parts of a bigger system (e.g. a modular VIC GUI) that is unaffected by directory changes on the boot drive (the SD2IEC card).
The program would copy its modules/data to the RAM drive and is then free to navigate through the file system on the SD card without caring about the original location of the modules.
I was also thinking about using D64 format for the RAM disk, which would allow to initialize the RAM disk with a prepared D64 file, but I am not sure, if that is possible with a footprint in unbanked memory that is small enough to co-exist with SJLOAD and not too slow.

[Diddl]

D64 would be great!

But this would take much code. Much code would be no problem, we have 512KB Flash memory ...

... but this much code must be written by anyone. This D64 code would be very complex, nearly as complex as a 1541 DOS.


It should be possible within 8 to 12 KB. It could be DOS compatible, with a command channel #15 which does accept DOS commands to delete and rename files, formatting D64 buffer space, allocate blocks and so on.

---

SJLOAD changes vectors from lower RAM. Same vectors are needed for RAM disk. By checking unit number we can decide if RAM disk is choosen.

If any ROM is available, vectors could directly point into this ROM. If no ROM is selected, a small stub in lower 3K memory is needed to switch on ROM and switch of after finishing procedure.


another idea would be a special kernel ...

no space in any RAM would be needed by a changed kernel. Both SJLOAD and RAMDISk could run seemless.

The problem is changing the kernel, if no socket is in your VC-20.

[Kananga]

There is a new version of the RAM Disk available for download.

A few bugs are fixed (thanks to Mike for the feedback) and the program prints the address of the device number used on startup. Some programs require to use an address in the range 8..11 for saving or loading, so now you know where to POKE it.

Still not everything is working as it should.
From the README:
"At present, the RAM drive stops programs like FB20 (file browser) and
VIN/Diskmenu (graphical file browser) from working for unknown reasons.
Debugging is in progress..."

Cheers!

[Kananga]

There is another new version of the RAM Disk available for download (R4).

Again a few bugs are fixed (thanks to Mike for beta testing)

[Kananga]

I removed a few bugs and added support for wildcards to the RAM Driver. You can use '?' and '*' for filenames (for loading).
It is now possible to replace an existing file by prepending the filename with "@:", e.g. SAVE"@:name",13

Download RAM DISK 0.6 here

Current performance for a file of 22051 Bytes:
Save: 3306Kcycles (PAL: ~3s)
Load: 2354Kcycles (PAL ~2.1s)
Verify: 2405Kcycles (PAL ~2.2s)

Unbanked memory is almost full, but I plan to add a command channel (15) in a future version in order to support deleting files, etc.

[Kananga]

There is a new release of the RAM DRIVE that adds support for the command channel (15). You can now read the status of the last operation, and scratch and rename files.
The driver should survive a reset, if the module area remains untouched.

Download RAM DISK 0.7 here

Running on real hardware as device 9 with the GUI:


EDIT: unnecessary quotes removed.