Hi,
I'm currently in the process of adding C65 (Mega65) support to the C64 port of VolksForth. My in-progress work is here:
https://github.com/dvdkhlng/VolksForthMega65
This adds two new architecture targets: C65 and C65n. the "c65" target mostly switches the C65 to its C64 compatibility ROM mapping and runs pretty well with minimal changes (the biggest change is supporting the track+sector layout of the C65's 1581-style floppy drive). Even the graphics demo appears to work. So this is pretty boring.
Now the "C65n" target runs VolksForth natively on the C65 operating system, defaulting to the 50x25 character terminal with all the neat C65 extensions being available.
The biggest single change for C65 native support is VolksForth's floppy disk access implementation. This used to live in vf-sys-cbm.fth. On the C65, the internal floppy is not on the IEC bus, so this does not work, unless we run the C64 emulation ROM, which knows how to fake this.
I now rewrote this based on an extended version of cbmopen.fth, so this now uses the higher-level SETLFS SETNAM OPEN etc. APIs.
However this also necessitates rewriting of e.g. SAVESYSTEM which lives in the source code blocks of the first disk. There appears to be no viable way to have a hybrid SAVESYSTEM that uses (C64 ) conditional compilation to support both IEC bus based and the newer CBMOPEN based disk access. So effectively all the C64-based targets need to change how the deal with file I/O and move to use CBMOPEN (unless we want to have diverging implementations of the source-code disks).
I currently have my emacs set up to be able to edit the block files, so I'm prepared to wade through the block-file sources and rewrite this as required. Though this does not integrate all too well with Git, and I'm not looking forward to ever resolve merge conflicts on the block files. Also I'm now working on a .d81 disk image (800 blocks) that holds all 4 of VolksForth .d64 disk images in a single image, as this is what the Mega65 can work with. I'll have to eventually update the .d64 images using DD to reflect those changes, which is maybe also not the kind of Git history one would usually want to have in a modern software project.
I now have a week of vacation to get this cleaned up for presentation at the Forth Tagung. If anybody of the devs here want to affect the direction into which this is moving, now this would be the time to chime in. Also, I would prefer this to be merged back into the primary VolksForth code base, if this is ok with you. In that case to prevent head-scratching merge conflict resolution, please anybody planning to do large changes in the near-term, give me a heads-up :)
If anybody here wants to do a quick review and discussion of my changes and see how this operates in an emulator, I'd be happy to do a Zoom session, or whatever video-chat system we have working on forth-standard.org.
cheers,
David
PS: even the block editor now runs natively on the Mega65 (though limited to 40x25 resolution), so this is now becoming a viable development system on that platform.
Hi,
I'm currently in the process of adding C65 (Mega65) support to the C64 port of VolksForth. My in-progress work is here:
https://github.com/dvdkhlng/VolksForthMega65
This adds two new architecture targets: C65 and C65n. the "c65" target mostly switches the C65 to its C64 compatibility ROM mapping and runs pretty well with minimal changes (the biggest change is supporting the track+sector layout of the C65's 1581-style floppy drive). Even the graphics demo appears to work. So this is pretty boring.
Now the "C65n" target runs VolksForth natively on the C65 operating system, defaulting to the 50x25 character terminal with all the neat C65 extensions being available.
The biggest single change for C65 native support is VolksForth's floppy disk access implementation. This used to live in vf-sys-cbm.fth. On the C65, the internal floppy is not on the IEC bus, so this does not work, unless we run the C64 emulation ROM, which knows how to fake this.
I now rewrote this based on an extended version of cbmopen.fth, so this now uses the higher-level SETLFS SETNAM OPEN etc. APIs.
However this also necessitates rewriting of e.g. SAVESYSTEM which lives in the source code blocks of the first disk. There appears to be no viable way to have a hybrid SAVESYSTEM that uses (C64 ) conditional compilation to support both IEC bus based and the newer CBMOPEN based disk access. So effectively all the C64-based targets need to change how the deal with file I/O and move to use CBMOPEN (unless we want to have diverging implementations of the source-code disks).
I currently have my emacs set up to be able to edit the block files, so I'm prepared to wade through the block-file sources and rewrite this as required. Though this does not integrate all too well with Git, and I'm not looking forward to ever resolve merge conflicts on the block files. Also I'm now working on a .d81 disk image (800 blocks) that holds all 4 of VolksForth .d64 disk images in a single image, as this is what the Mega65 can work with. I'll have to eventually update the .d64 images using DD to reflect those changes, which is maybe also not the kind of Git history one would usually want to have in a modern software project.
I now have a week of vacation to get this cleaned up for presentation at the Forth Tagung. If anybody of the devs here want to affect the direction into which this is moving, now this would be the time to chime in. Also, I would prefer this to be merged back into the primary VolksForth code base, if this is ok with you. In that case to prevent head-scratching merge conflict resolution, please anybody planning to do large changes in the near-term, give me a heads-up :)
If anybody here wants to do a quick review and discussion of my changes and see how this operates in an emulator, I'd be happy to do a Zoom session, or whatever video-chat system we have working on forth-standard.org.
cheers,
David
PS: even the block editor now runs natively on the Mega65 (though limited to 40x25 resolution), so this is now becoming a viable development system on that platform.