Nemo έγραψε:
Υ.Γ.
Ποιός ξέρει ίσως στο μέλλον δούμε C64 με 3 Raspberri Pi το ένα ως για Cpu Boost ,το δεύτερο για Gpu boost και Hdmi out, το τρίτο με το uno2iec
Ή και ως αντικαταστάτης του C64 floppy drive
Raspberry Pi as a 1541
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.
......
Nemo έγραψε:
Υ.Γ.
Ποιός ξέρει ίσως στο μέλλον δούμε C64 με 3 Raspberri Pi το ένα ως για Cpu Boost ,το δεύτερο για Gpu boost και Hdmi out, το τρίτο με το uno2iec
Ήκαι ως αντικαταστάτης του C64 floppy drive
Raspberry Pi as a 1541
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.
......