FE3 RAM Disk

Basic and Machine Language

Moderator: Moderators

Kananga
Vic 20 Afficionado
Posts: 317
Joined: Mon Mar 08, 2010 2:11 pm

FE3 RAM Disk

Postby Kananga » Thu Sep 22, 2011 11:26 am

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.

Image
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)
Buy the new Bug-Wizard, the first 100 bugs are free!

User avatar
orion70
Meteo VIC
Posts: 3328
Joined: Thu Feb 02, 2006 4:45 am
Location: Piacenza, Italy
Occupation: Biologist

Postby orion70 » Thu Sep 22, 2011 11:31 am

Cheers Kananga, but I don't get exactly what is this :oops: . 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
Vic 20 Afficionado
Posts: 425
Joined: Wed Jun 10, 2009 3:18 am

Postby Diddl » Thu Sep 22, 2011 11:54 am

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

Kananga
Vic 20 Afficionado
Posts: 317
Joined: Mon Mar 08, 2010 2:11 pm

Postby Kananga » Thu Sep 22, 2011 12:02 pm

orion70 wrote:Cheers Kananga, but I don't get exactly what is this :oops: .

Sorry, I could have written more.
orion70 wrote: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.
orion70 wrote: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?
Buy the new Bug-Wizard, the first 100 bugs are free!

Kananga
Vic 20 Afficionado
Posts: 317
Joined: Mon Mar 08, 2010 2:11 pm

Postby Kananga » Thu Sep 22, 2011 12:17 pm

Diddl wrote: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 :P
Buy the new Bug-Wizard, the first 100 bugs are free!

Diddl
Vic 20 Afficionado
Posts: 425
Joined: Wed Jun 10, 2009 3:18 am

Postby Diddl » Fri Sep 23, 2011 4:36 am

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
Vic 20 Afficionado
Posts: 317
Joined: Mon Mar 08, 2010 2:11 pm

Postby Kananga » Fri Sep 23, 2011 11:32 am

Diddl wrote: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! :)
Buy the new Bug-Wizard, the first 100 bugs are free!

Kananga
Vic 20 Afficionado
Posts: 317
Joined: Mon Mar 08, 2010 2:11 pm

Postby Kananga » Tue Sep 27, 2011 1:02 pm

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
Buy the new Bug-Wizard, the first 100 bugs are free!

Diddl
Vic 20 Afficionado
Posts: 425
Joined: Wed Jun 10, 2009 3:18 am

Postby Diddl » Wed Sep 28, 2011 4:41 am

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

Kananga
Vic 20 Afficionado
Posts: 317
Joined: Mon Mar 08, 2010 2:11 pm

Postby Kananga » Wed Sep 28, 2011 11:45 am

Diddl wrote: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. :D

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.
Buy the new Bug-Wizard, the first 100 bugs are free!

Diddl
Vic 20 Afficionado
Posts: 425
Joined: Wed Jun 10, 2009 3:18 am

Postby Diddl » Thu Sep 29, 2011 2:21 am

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
Vic 20 Afficionado
Posts: 317
Joined: Mon Mar 08, 2010 2:11 pm

Postby Kananga » Fri Sep 30, 2011 1:49 pm

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! :)
Buy the new Bug-Wizard, the first 100 bugs are free!

Kananga
Vic 20 Afficionado
Posts: 317
Joined: Mon Mar 08, 2010 2:11 pm

Postby Kananga » Sat Oct 01, 2011 3:38 pm

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)
Buy the new Bug-Wizard, the first 100 bugs are free!

Kananga
Vic 20 Afficionado
Posts: 317
Joined: Mon Mar 08, 2010 2:11 pm

Postby Kananga » Mon Oct 03, 2011 2:59 pm

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.
Buy the new Bug-Wizard, the first 100 bugs are free!

Kananga
Vic 20 Afficionado
Posts: 317
Joined: Mon Mar 08, 2010 2:11 pm

Postby Kananga » Tue Oct 11, 2011 1:41 pm

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:
Image

EDIT: unnecessary quotes removed.
Buy the new Bug-Wizard, the first 100 bugs are free!


Return to “Programming”

Who is online

Users browsing this forum: No registered users and 2 guests