Yesterday I took a closer look at the floppy disk image described here and how should I say it was a short night to sleep. 
I am trying to describe my approach as clearly as possible.
First I opened the "C65-JAR.SFX" file with the "DirMaster" program. SFX is an extension for a compressed file. DirMaster shows me the D64 file and can therefore also be saved as an uncompressed D64 file.
The first five files are text files that I can export as PETSCII and ASCII text.
The other 8 files ("65r6dmp ...") are binary files. I had these exported as SEQ files and then looked at them more closely with a hex editor. Parts of it sounded familiar to me. I've been working with the C65 ROM for some time and I had the feeling that I was seeing code fragments from the ROM. So I rummaged through here a little more. 
Each of these "65r6dmp ..." files is exactly 16,384 bytes. 8 x 16,384 bytes result in 131,072 bytes and that is exactly the size of a C65 ROM. 
So I tried what happens when I merge the files. After a
cat 65r6dmp7.seq 65r6dmp6.seq 65r6dmp5.seq 65r6dmp4.seq 65r6dmp3.seq 65r6dmp2.seq 65r6dmp1.seq 65r6dmp0.seq > 65r6dmp
I integrated the resulting file "65r6dmp" as a C65-ROM into the emulator xc65 and then started the emulator. Unfortunately just a black screen with an error message.
Next, I reversed the order when joining and with
cat 65r6dmp0.seq 65r6dmp1.seq 65r6dmp2.seq 65r6dmp3.seq 65r6dmp4.seq 65r6dmp5.seq 65r6dmp6.seq 65r6dmp7.seq > 65r6dmp
create a file "65r6dmp". This file integrated as a C65-ROM creates a black screen with the xc65 (this time without an error message).
Okay, then I took a closer look at this file with the hex monitor. A lot of things reminded me of the ROM that I had already considered several times to create the memory map. I then had this file compared with the 911001-ROM.
It was noticeable that in the range $04000 - $0692E in contrast to the 911001-ROM there were only $FF. I can explain that to the extent that some demo programs were stored in this area in the 911001 that were also missing in the other ROM versions. I don't see that as "critical" now.
What was more of a headache was the range $0E593- $0FFFF. There is only $00 in the generated file. That is a range of 6,764 bytes.
The problem here is the "65r6dmp3.seq" file on the D64 image. From address $2593 to $3FFF there are only $00 as values in this. Either there must have been an error creating the D64 image or the file on the floppy disk itself was defective. Pity ...
I then looked at the ROM again and it occurred to me that the C64 kernal of the C65 is in $0E500 to $0FFFF.
This quick drawing from me, showing how the files are build to the rom file:
A "nasty idea" occurred to me and I took the area $0E593- $0FFFF from the 911001-ROM and inserted it into the file "65r6dmp" at the appropriate places. All incorrect $00s have been overwritten with the corresponding values from the 911001 ROM.
Okay, so that the xc65 started again and ... 
... wow! It seems to work! 
The most striking thing was the blue frame instead of the yellow one from the 911001-ROM. And of course the displayed version number: 911210
I haven't heard anything about it yet and went looking for it. I came across these two pages in the web archive (this and this), both of which mention a ROM version 911210 as the last ROM for the C65:
Funny, so far I thought that the 911204 would be the last. If you read the statement by Fred Bowen carefully, however, he speaks of "... something like 911204 or so ...". So not exactly this version number. 911210 could get there.
In the ROM itself, the DOS version 911203 is mentioned at the beginning.
And in $0CFFD- $0CFFF the version number is entered in decimal numbers in the last ROMs. This is in this ROM 91, 12 and 03.
If you disregard the range $04000- $0692E, the 911001 and the new ROM differ in 368 bytes. It's not much, but there are quite a few changes to the 911001.
The text on the floppy disk image "note jar" contains a note about the completion of the DOS area of the C65 from December 3, 1991 by Dennis Jarvis:
Quote from note jar.txtDisplay MorenNote:
This project was terminated prior to this software's completion.
The following notes should guide you thru correcting one software bug, and one change.
Both mods were installed then removed because there was not enough testing time to verify they worked correctly.
The first bug is in the OPEN routine.
To set up the bug just create any size text file greater than 506 bytes. Close down the file and ensure there at leaste two sectors allocated to the file. Then OPEN the filename up with the APPEND mode set, followed up with doing a CLOSE on the file. You will now only have two sectors assigned to the filename. This bug is caused by the MARKTS routine when it fails to read in the LAST track, and sector used by the file into the buffer, and the failure to update HDRS correctly.
To correct this problem just clear the read only T & S flag, then call READSEC to read the sector into the buffer. Also MARKTS will need to be changed to correctly detect the WLINDX value as not being used by MARKTS.
A change is required in the DSKCPY routine to allow you to concantate two BASIC programs together.
To make this change just recode the compare to the program type to BCS only if the file type is greater than a program type to prevent REL, CBM, RDM file types from being concantated.
There is a few place in the dos that needs to be looked at closely to see if it is handling the CBM file types correctly. Mainly need to make sure that when filetype 7, and REL files are being handled correctly, also need to look at DSKCPY, and the new command structures.
Estimated time to complete the dos from this point would be less than 200 hours.
12/03/91 Dennis Jarvis
When using the ROM itself, no changes are noticed at first (apart from the missing change of the frame color in the event of a diskette error, which according to the documents was always intended to be temporary).
I just typed in a few commands that have not yet been implemented. With PASTE and CUT an "?UNIMPLEMENTED COMMAND ERROR" no longer appears with this ROM, but an "?SYNTAX ERROR". The question is whether that's "better", but at least it's different.
In this respect, I am currently assuming that the disk image contains a C65-ROM version 911210, divided into 8 files with 16kB each (for whatever reason).
Unfortunately I have no idea who this diskette originally came from. As described here, I had it years ago in an archive of a lot of C64 disc images from an FTP server in Eastern Europe (Bulgaria or Romania, if I remember correctly). Since then it has been lying unseen on the hard drive, as is usual by many "data collectors". 
It would be very interesting to know where the ROM came from, or at least who created the D64 image from a floppy disc?
Finally, some information from me:
As described, the ROM as it is now is not 100% created from the files on the floppy disk! 
The area $0E593- $0FFFF has been replaced by me from the corresponding area of the 911001 ROM. Since the C64 kernal is located in it, I assume that at this point in time no (major) work was done on it. The C64 kernal of the C65 has been the same as the last ROMs. In this respect, I am currently assuming that the exchange will have no consequences for the C65-ROM itself.
And of course I don't have any rights to this ROM, I just call it "911210.bin" for the sake of the familiar name of the ROMs.
The publication here is for "historical" interest only, as I was previously not aware of this ROM version and I would like to make this data available to the community.
If someone can be found with an error-free floppy disk image "C65-JAR.SFX", they can assemble the complete ROM themselves using the instructions above. Or just ask here, if desired.
I attached a zip file with the SFX images (as I got it from the FTP server), the exported files as SEQ and the texts ASCII-TXT and the reconstructed ROM named 911210.bin.
If anyone know more about this disc image or ROM I would be - of course - very glad to hear about it!
The good news is: There is a new ROM.
The "bad" news is: There is a new ROM (after I spent months with the 911001 version ...) 
That's all for the moment ... family is waiting ... Christmastree is calling and so ... 
