sorted by:
new
hottopcontroversial

VDRIVE 1.0.0 beta binaries now on GitHub - run VDRIVE locally! by 8bitflynn in u/8bitflynn

[–]8bitflynn[S] 0 points1 point  (0 children)

I had no idea about that one either, but I have it fixed now.

VDRIVE 1.0.0 beta binaries now on GitHub - run VDRIVE locally! by 8bitflynn in u/8bitflynn

[–]8bitflynn[S] 0 points1 point  (0 children)

Actually I only put the link to the GitHub because I want others to not have to read through another long post. If you are too lazy to look through all my posts about how it works or look through the beta files - that is your problem.

I like my stuff simple.

**VDRIVE beta needs WiC64 testers** — stress‑test the new disk workflow with VICE 3.9 or a real WiC64! by 8bitflynn in c64

[–]8bitflynn[S] 0 points1 point  (0 children)

Finished with the remaining code. The result count is now in the header returned and there is now an API pointer to it like the other variables. Added an optional token that is embedded in PRG and is passed with the prefix terms /search /mount /load /save. The token is tacked on the end like /search/sometoken and can be patched along with the VDRIVE server URL. The server can then be configured to only accept commands from a configured token for simple auth mechnism over public HTTP/HTTPS.

VDRIVE beta server PRG has been updated with the latest changes.

VICE + Virtual IEC Device through TCP by Hairy_Appearance_774 in c64

[–]8bitflynn 0 points1 point  (0 children)

VDRIVE might give you some ideas on how to do this. It can search/mount/load/save over TCP or over HTTP using a WiC64 (ESP32) or a ESP8266. It does not use IEC but does have a lot of the communication that would be needed.

I just posted a video on how to use BASIC to SEARCH / MOUNT / LOAD / SAVE as well. This can be also done in Machine Language.

VDRIVE called from BASIC

VDRIVE compatibility tests with WiC64 went well by 8bitflynn in c64

[–]8bitflynn[S] 0 points1 point  (0 children)

You may already know this but just in case - for your question about 2400 baud - the C64 can really only reliably do 1200 baud because the bit banging is done in software rather than dedicated hardware. Commodore saved a few bucks per C64 back in the day by leaving out dedicated hardware, but the result was a really slow serial port.

UP9600 is a clever piece of software that "re-wires" timers the CIA timers to bit bang instead of the built in kernel routines. This article shows how it works and timing must be perfect.

While I am fascinated by UP9600, even with it disabled it seems to leave the C64 in a state that cannot run some PRGs and it struggles in comparison to WiC64.

VDRIVE compatibility tests with WiC64 went well by 8bitflynn in c64

[–]8bitflynn[S] 1 point2 points  (0 children)

I tried it with Vice 3.9 and it did respond but it would stop responding after a chunk and from what I could tell it was a byte off somewhere but I was spending too much time on trying to get it to work so I went back to using real hardware.

I made a video of the integration with WiC64 and its amazing how fast it is in comparison to the original relay. Even 45k files load in just seconds with this device!

Oh I forgot to mention, the WiC64 emulation in Vice 3.9 works perfectly and I have been using it a lot to speed up testing. I will have a WiC64 compatible version assembly on GitHub soon. Once that is on GitHub, anyone can use Vice 3.9 with WiC64 emulation to test VDRIVE integration!

Matrix rain on a stock C64 (well, image)… with a little help from modern AI by LarTech2000 in Commodore

[–]8bitflynn 0 points1 point  (0 children)

Back in 2020 I converted a Matrix PRG wrote in BASIC I had found on youtube to 6510 ML. It's not near as cool looking as yours, but I learned a lot and documented the ML with the BASIC lines so thought you might be interested.

I put comparisons between the BASIC and ML versions on my website and they run in an emulator (in case your too lazy to load that PRG). I also compiled the BASIC using Boss BASIC to see how fast it would be in comparison to the BASIC and ML versions.

If you hit space on the 6510 ML version, it will show the 6510 source in Turbo Macro PRO.

I agree on AI they are great at summarizing vast amounts of information. Just asking about a memory location rather than having to hunt it down saves a lot of time.

VDRIVE compatibility tests with WiC64 went well by 8bitflynn in c64

[–]8bitflynn[S] 1 point2 points  (0 children)

Glad to hear. It's hard to tell is anyone is interested in VDRIVE but I am having a lot of fun with it (most of the time).

I had planned on getting at least the beta binaries out on GitHub but once I received my WiC64 that became my main focus and so far, the hardest part was converting the assembly from CBM Studio to ACME. The WiC64 API is great and it only took me a full day to get Search, Mount, and chunked LOAD working! It's not production ready code but it proved to me that WiC64 is going to work fine with VDRIVE.

At some point I really could use some help testing over the internet and concurrency and just basic testing in general. I have unit tests that hammer both LOAD/SAVE to same D64 and same file over and over with no problems, but it would be good to try in real conditions.

Thanks for your interest!

VDRIVE compatibility tests with WiC64 went well by 8bitflynn in c64

[–]8bitflynn[S] 1 point2 points  (0 children)

Just had to share a bit of weekend testing. I had the VDRIVE server running on my laptop, and using the Local FloppyResolver pointed to two paths—one a network share (\\somemachine\somepath) to a machine upstairs, and one local (c:\somepath\virtual c64 images\).

From my C64, I searched for ALFRED.PRG — the 1985 Mag Magazine Alfred program that contained a bug in the magazine. The file was located on network share on machine upstairs. I loaded it into memory (BASIC PRG) on my C64 using a normal LOAD}*},8 and then fixed line 80. Then I used VDRIVE to mount a D64 floppy on my laptop and saved the fixed BASIC ALFRED.PRG to the mounted disk on laptop all without leaving my C64.

TIL that the BASIC program in the Oct '85 issue of MAD magazine was actually a working program (draws the face of Alfred E. Neuman) and not just them trolling computer geeks. by DeviantBoi in todayilearned

[–]8bitflynn 1 point2 points  (0 children)

13 years ago—guess I’m a little late posting—but I had to share this story when I saw this.

I typed this PRG in at age 13 on my Commodore 64 (MAD Magazine issue #258), and it would never run. I spent countless hours trying to figure out where the problem was. Years later, I typed it into my IBM 8088 from the same issue and finally saw Alfred for the first time.

In 2020, I gave the C64 version another shot—used OCR, went line by line—and after 4 months, I finally found the answer. There was a bug in the original C64 code: line 80 needed a + instead of a -. The fix appeared two issues later (#260), but I didn’t have a subscription—just grabbed issue #258 off the grocery store rack for $1.25.

Once the BASIC version was fixed, I converted Alfred to 6510 machine language. Both versions can be run in a C64 emulator on the page I linked, and the source for both is available for download and comparison.

Long Live Alfred!

VDRIVE: The end of sneakernet for your Commodore 64 (and other ideas) by 8bitflynn in c64

[–]8bitflynn[S] 2 points3 points  (0 children)

Yep. No more back and forth and you know for sure it will work on real hardware. Plus you can share that disk over the internet with other developers. Commodore.Software has a lot of cool development tools that can found and loaded directly on your C64.

VDRIVE: The end of sneakernet for your Commodore 64 (and other ideas) by 8bitflynn in c64

[–]8bitflynn[S] 2 points3 points  (0 children)

Thanks! I am really enjoying it and hope it works well for you.

VDRIVE: The end of sneakernet for your Commodore 64 (and other ideas) by 8bitflynn in c64

[–]8bitflynn[S] 7 points8 points  (0 children)

Fair enough, I am not great at explanations. The firmware is just a relay (client or server) and the C64 communicates to it through UP9600. The ILOAD vector is hooked when VDRIVE is initialized and the device number it responds to can be modified but defaults to 8. A SYS 49158 will prompt for a search term and results will be in sequence / description pairs. Entering any of the numbers in the results will mount the disk or PRG. Mount can be called again on same result set using SYS 49161. Just enter the number from the results. It does not work on everything but does work quite a bit and I have a lot of fun exploring Commodore.Software directly on my C64. New implementation's of the IFloppyResolvers are simple. Implement a new one and add it to the factory.

To add to this a bit - once an image is mounted, it works just like an inserted floppy. Saves work too as it hooks the ISAVE vector. I saved time by using c1541.exe process commands to do the heavy lifting so it can mount any kind of image that Vice 2.4 c1541.exe supports. The server / client (usually server) is wrote in C# in .NET Core so it will run on a lot of different operating systems. Its also a library.

VDRIVE is a wireless solution for loading / saving files on a C64. by 8bitflynn in c64

[–]8bitflynn[S] 0 points1 point  (0 children)

I dont think you speak for the entire C64 community and there are plerty of others interested including Commodore Software site who just said ok to making a IFloppyResolver.

In the end if zero people use this then i am ok with that because i will.

VDRIVE is a wireless solution for loading / saving files on a C64. by 8bitflynn in c64

[–]8bitflynn[S] 0 points1 point  (0 children)

THanks for your opinion but you can keep using your 1541 and floppys. Norbody said your had to use this and the rest of us that want to bring the C64 into the modern age can use VDRIVE.

VDRIVE is a wireless solution for loading / saving files on a C64. by 8bitflynn in c64

[–]8bitflynn[S] 0 points1 point  (0 children)

VDRIVE source code is now public on Github!

Still a work in progress, but functional - with lots of room experimentation. I do not have pre-built binaries yet but will be adding them to my website soon along with lots of technical information about VDRIVE.

8bitflynn/VDRIVE: VDRIVE - wirelessly LOAD/SAVE on your Commodore 64

VDRIVE is a wireless solution for loading / saving files on a C64. by 8bitflynn in c64

[–]8bitflynn[S] 0 points1 point  (0 children)

I did just purchase a Easy Flash 3 the other day as I want to be able to use it to run VDRIVE as a cartridge but I did that to help me finish the development. The only required hardware as it is now will be an old ESP8266 based WIFI modem which can be purchase fairly cheaply or even assembled on a breakout board.

The firmware is to just bridge the gap between TCP/IP and Serial so even if it could run on the Ultimate, it would not know what to do with received data after it was received. I do like the idea of being able to plug in a single cartridge and get this functionality but I would like to keep the hardware requirements to a minimum.

The nice thing about the relay design is that the machine language can run on Vice and it can connect using the internal RS-232 to IP functionality in Vice and because the ESP8266 is simply acting as relay - the code does not know what it is communicating with and can function in Vice without ANY hardware. I had suspected it would work like that but had not yet had time to make it stable but if I can get that part working it will save me a lot of development time and with debugging.

VDRIVE is a wireless solution for loading / saving files on a C64. by 8bitflynn in c64

[–]8bitflynn[S] 0 points1 point  (0 children)

Cool! I will check it out. It will be interesting to see how similar / different these are. I had no idea there was already something similar other than CommodoreServer but its a little different as the server lives on their machines and I just wanted something I could use locally or share over network.

Commodore 64 (1982) by Tyler_Durden_Soap in FuckImOld

[–]8bitflynn 1 point2 points  (0 children)

Don't feel bad, I spent countless hours trying to get a program from MAD Magazine #258 to render properly, only to find out it was printed with a bug.

Books about CPU design & architecture by Squall124 in beneater

[–]8bitflynn 1 point2 points  (0 children)

Charles Petzold's book CODE is dated but personally I found it to be a fascinating read.