can be done and done quite easily. I have been working on one for about a year now. It currently runs on a Raspberry Pi 3 and emulates the CPU, the VIAs and the 16Mhz clocked encoder/decoder logic. It is implemented in bare metal C++. It does not use VICE code but it is approaching the emulation compatibility levels that VICE does. It supports D64, G64 and NIB/NBZ disk images (still experimenting with P64).
It currently runs all of the top 30 of csdb’s demos. I have tested many copy protected originals such as Rapidloc, Vmax, Vorpal, sync counting etc, and most work. I have tested all major cart based fast loaders and JiffyDOS and all work.
Like most people I was a little disappointed in the sd2iec offerings and the FPGA solutions are out of my budget. After a short time my sd2iec device stopped working and I set about researching how to fix it. I then discovered how simple and cheap they are to make. After making a few of my own I then started looking into the source code. After looking at the source I realised that code for proper cycle exact emulation would be less complex than the code I was looking at!
I am so glad I started before the second half of this thread appeared. Not that I’m easily discouraged but I do genuinely respect the opinion of these posters and had they posted earlier I may have believed it was not possible when in fact it certainly is.
When I started out, I just wanted it to be better than sd2iec. I didn’t want to go down the rabbit hole of;- it must be fully compatible with every copy protected original. But as I progressed I found myself enjoying disassembling code and learning not only how the drive worked but how fast loaders and copy protection schemes worked. (I’ve seen some crazy stuff along the way). The rabbit hole wasn’t as bad as I thought. It was exciting to research something or fix a bug and discover that now all of a sudden a whole bunch of stuff just started working.
Like VICE it emulates up until and including the encoder/decoder. Again like VICE, the analog to digital data recovery section consisting of the amplifier, low pass filter, differentiator, zero crossing detector, time domain filter and pulse generator are all simulated.
The Raspberry Pi’s timer is clocked at a rather convenient 1Mhz, hence I use it to keep cycle exact timings. The 16Mhz stuff is implemented as a loop that iterates 16 times inside a 1Mhz step. Everything can be updated in 1us. The emulator runs on core 1. Core 0 handles the Pi’s USB keyboard interrupts and the user interface displayed on the Pi’s screen. Cores 2 and 3 are put to sleep (WFE). However, I do need to be careful how much I try to do on core 0 as any cache pollution can cause core 1 to miss its 1us real-time requirement.
For the emulation of the 6502 I thought that I would need to implement all the reads and writes it performs (That is, the read or a write it does on every cycle even if it is redundant). So I started with "MCS6500 Family Hardware Manual”. The T states for each addressing mode are detailed in this document and the addresses the 6502 uses for the ‘every cycle read or write’ are shown (including interrupts). For the undocumented instructions there now exists a variety of documents on the web describing them (most of them wrong). VICE was my the goto reference when there was a discrepancy.
......
I finally was able to take some time off over Christmas and work on it.
Doesn't show much new, but I have been making a lot of progress.
It now supports;
- disk swapping
- LST files
- Writing altered data back to the disk image (D64 and G64)
I have also fixed a bunch of bugs and improved compatibility.
I have implemented some of the suggestions made in this thread.
Multiple ROMs can be placed on the SD card and you can swap them on the fly (in between disk image mounts).
You can also list the ROM you would like to use inside the LST file.
When the drive resets it will revert back to the originally selected ROM.
This way, if you know a title works with or without JiffyDos you can configure your LST files and the correct ROM image will be selected when the disk images are mounted.
As you can see from the video I have been developing schematics for a variety of ways of hooking it up.
I have also being playing around with supporting TAP files and connecting to the cassette port but I will leave that for v2.0.
I know its not perfect but I don't want to let that hold it back. I set out to make a better SD card solution than SD2IEC and I have achieved that so I will release a version sometime in the next few weeks.
PM me if you would like to help beta test. (You will need the skills to make your own connector)
When I started out I was hoping it would run on a Pi Zero as my goal was for people to have a cheap SD card option with reasonable compatibility.
A Pi Zero would certainly make it cheaper.
Unfortunately, it currently only runs on a Pi3 at the moment.
Even a Pi2 is too slow.
if" Imitation is the sincerest flattery",
imagine emulating ....
There are quite a few people testing it now and giving me some great feedback. According to some of the testers, compatibility is now surpassing other hardware, cycle accurate, SD card solutions! I don't have any of these devices but what I can say is that currently I don't know of any disk image that works with VICE but not on the Pi1541.
Annoyingly, I wasted time after my last video chasing ghosts Pacman Clyde. Let me explain, in my last video I showed how I was testing on other Commodore machines and models. After that video I started receiving feedback from the testers about failing disk images. I set about looking into it. The machine that I was using to do this was my old silver labeled 64. Some testers were reporting that particular demos would sometimes randomly crash or fail, and indeed, when I tried them I experienced the same behaviour. For some of the demos I knew I had them working at some stage so I naturally thought I had now, somehow, broken something in the code. Other testers would try the same demos and inform me that no matter how many times they tried the disk image it would always work! I then started to stress that maybe it was a hardware issue with various Pis or the cables. Then it dawned on me. It was the hardware, the 64's hardware. It was the VSP bug! Swapping out my old silver label (which I now remembered from the days programming a VSP game that machine was susceptible to the bug) to one of my other 64s, everything started working 100%. I checked all the problematic demos and yes the random crashes would only occur during sections of horizontal scrolling.
I still can't get it to load VMAX3b/4 originals. I suspect that they found away to stop the shift register shifting but keep timer two ticking without touching the control registers. They then use the value in this stalled shift register as part of their decryption key. I have another Pi connected to the address and data buses of a real 1541 and can capture the reads and writes as code executes. Examining this I can see the shift register magically stop shifting!
Again, not that I have the hardware to confirm, but my testers have assured me that it works on the new Raspberry Pi 3B+.
Some of the guys testing it that know more than me about hardware have created their own PCB, integrating their own solutions for the voltage level shifting!
So... I am taking a few days of over Easter and with this time I will endeavour to put a few finishing touches to it, try and set up a website so you guys can download the binaries.
κι εφόσον αναφέρεται για release μετά το Πάσχα - btw το Καθολικό Πάσχα
δεν προηγείται μια βδομάδα του Ορθοδόξου ? -
ξέρετε εγκαίρως τι λαμπάδα>(με raspberrypi 3) θα προμηθευτείτε ....
if" Imitation is the sincerest flattery",
imagine emulating ....
I'm working really hard to release a version.
Codewise I'm just cleaning up bits and pieces.
I'm mostly working on documentation and legal stuff now.
For all the 3rd party code I'm using I have permission and the licenses are all compatible (GPL3).
Won't be long now (I know I've said that before) I may have to work this weekend, so just give me another week. Maybe I should release the binary first (open Beta?) and the source code soon after. That way, you guys can get it while I continue to document the code?
I was able to get VMAX4 working. I used a Kryoflux version of Galaxian, once I got it working I tested the versions in C64PP and they all load except alt1 (so I suppose they were good all along).
I am amazed that VICE3.0 can load the Kryoflux version. Its timer2 counts in an incorrect way. As the decryption is XOR based the incorrect timer values work. Even though they are wrong they are consistently wrong. I think the timer is fixed it in 3.1 but now they start the shift too early. I was making the same mistake and always thinking the problem was with the stop when it was with the start. Starting early puts the shift out of phase with the rate of writes to the shift register it fails to stop when it should.
-Did some more work on the IEC command side (ie the mode it boots into before a disk image is selected). Multiple channels and writing is now supported (sequential files only). The format command will create a new blank image.
-Today, due to popular demand, I implemented drive head movement sounds.
Will release a version next weekend, including schematics, part list and Gerbers.
I have had many requests to connect all kinds screens to the Pi. I didn't want to commit to any single device. (Although I have left the SPI bus free for future expansion).
My goal all along was to keep the hardware as simple and inexpensive as possible.
Then one day I thought that the simplest and cheapest screen is the one everyone has in their pockets.
I am developing a smartphone app that will communicate with the Pi via BlueTooth.
All file browsing and disk image selection will be available using your smartphone screen.
Even sending disk images over BlueTooth will be possible, so you should be able to download them on the phone and shoot them over to your favorite Commodore machine.
I have had many requests to connect all kinds screens to the Pi. I didn't want to commit to any single device. (Although I have left the SPI bus free for future expansion).
My goal all along was to keep the hardware as simple and inexpensive as possible.
Then one day I thought that the simplest and cheapest screen is the one everyone has in their pockets.
I am developing a smartphone app that will communicate with the Pi via BlueTooth.
All file browsing and disk image selection will be available using your smartphone screen.
Even sending disk images over BlueTooth will be possible, so you should be able to download them on the phone and shoot them over to your favorite Commodore machine.
Οπως αναφέρει ο δημιουργός του Pi1541 o Steve"Gorack" White στο lemon64 forum
-I now have cassette tape emulation working.
-I am writing a bluetooth driver intended to communicate with a smart phone app so it may be possible in the future. A bare metal blue tooth stack is quite involved so it is taking me taking longer than expected, but I am getting there slowly.
I have been working on other new features I hope to reveal soon.
if" Imitation is the sincerest flattery",
imagine emulating ....