8bitflynn
VDRIVE
Test from 10/2
http://8bitflynn.io/Resources/Videos/VDRIVE_Progress.m4v
Test from 10/14 - SEARCH/MOUNT added (local and remote)
https://8bitflynn.io/Resources/Videos/SearchMountVDRIVETest.m4v
On the laptop side the code that serves the data is in C# socket server but I might re-write it in C so it will be more portable. The directory was interesting because c1541.exe extracts the directory as a text file, which it should, but the C64 needed a PRG in disguise so it's now generated when requested.
I am planning on adding a few simple wedge commands to allow me to search my D64 floppy's and PRG's and then a command to "insert the floppy" the mount the disk. I think showing the results with a number next it that would allow user to mount that floppy without having to type it all.
Another thing I plan on adding is a way to transfer an entire D64 directly to the SD card or whatever modern persistence. The protocol already sends data in chunks so I think it should be doable. It will write the data after each chunk and then reset the pointer to the buffer until the end of the file.
The server itself can actually be running anywhere, and I did try this out using Pinggy.io to route my TCP/IP traffic. This allow C64 users to share D64 disks as long as it can connect.
I just fixed an old C64c so I now have two working Commodores and I plan on connecting them directly and through a server in the middle. One could make a "game" server that loads binarys to all the players or similar.
AI SIDE TESTS
I have used this protocol to also bridge AI to a C64 keyboard buffer so AI can "type" and then I hooked the CHROUT vector I think its $ffd2 and that data is sent back to the AI so it can "see" what is going on.
http://8bitflynn.io/Resources/Videos/FirstAI_TEST.m4v
I have not had much time to play around with it, but it allows the AI to write BASIC code, and it can even correct mistakes when it "sees" the CHROUT data. I never planned on connecting it to AI when I started this project but I had been working with AI at my day job quite a bit so why not.
Thanks I am really enjoying searching and downloading directly on my C64. There are lots of cool things that I just would not have ever tried due to modern sneaker net of copy / paste files. It does not work on everything but it does work on quite a bit and also enables users to share full libraries of disks and pair programming in BASIC for sure. I have bigger plans for VDRIVE like copying entire images (d64) to SD2IED when the data is too large and them mount from SD2IC.
When I posted about VDRIVE a few weeks ago another user mentioned meatloaf which was news to me, but I think our designs are quite a bit different as VDRIVE is wrote in assembly and C# .NET Core and the Firmware's only job is to relay so the C64 feels like its talking to TCP/IP because it basically is. The relay is useful for lots of other projects on other types of retro hardware because it just forwards the data. I want to write up an article on how to use just the Firmware relay, UP9600, and about 10 lines of BASIC to communicate. I hope it opens doors for multiplayer games (turn based) and lots of other things.
On a side note this same protocol can be used for interfacing AI with the C64s keyboard buffer to let AI "type" and I hooked into CHROUT so the AI can "see" and I have only tried this a few times because I have been so busy but the AI is capable or progamming my C64 and even running and correcting syntax errors. I want to make a AI called "8bitflynn" that can help kids or old kids learn how to program in environment where they can ask the AI to help them or fix their code with explaination. Should be really cool and if possible I want to hook in VDRIVE to C64 emulators online using WebSockets so users can load their disks and programming anywhere but not sure if that one will ever get done.
Anyway thanks again. Its hard to tell if anyone likes it, but I will be working on for the foreseeable future so hopefully it will gain some traction.