search

randyrossi / bmc64

A bare metal Commodore 64 emulator for the Raspberry Pi with true 50hz/60hz smooth scrolling, low input latency and better audio/video sync.
GNU General Public License v3.0
491 stars 59 forks source link

Peripherals support #191

Open pkor opened 3 years ago

pkor commented 3 years ago

Not really an issue but an idea. How possible would it be to make this project interface with original peripherals like a real 1541, cartridges, user port etc.? I'm thinking maybe with some bindings to the GPIO it could be possible to communicate with these devices. I know that the pi has a limited amount of GPIOs by default and this is probably used up mostly by the keyboard interface but the GPIOs can be expanded using I2C chips like the MCP23017. It gives an extra 16 GPIO pins and can be combined with up to 8 chips for an extra 128 pins. I think that would be sufficient to support the I/O, user and expansion ports. I don't know what that would take from the software side though. What do you think? Is it possible? What would that take? I like this project and I think it would be great to expand it to the full CBM experience.

rhester72 commented 3 years ago

About 0%. GPIO is too high latency and doesn't have enough bandwidth to achieve it.

pkor commented 3 years ago

Ah. That's too bad. It's strange that such a modern device can't keep up with a 1mhz machine from the 80s. I mean, what about interrupts? Or why couldn't the rx and tx lines be used for that? Wouldn't that be fast enough communication? At least for RS232?

rhester72 commented 3 years ago

Well, for one thing, the 1541 sits on the IEC bus, and the bit-banging timing required is INCREDIBLY precise - the same reason why you couldn't do the same thing strapping a 1541 to a late 90s multiple-hundreds-of-megahertz PC. Speed isn't the problem - the number of layers is.

Every time you introduce another chip/layer, you're further increasing that latency path - the same reason chaining USB hubs is a poor idea. 2400 baud was the best that could be hoped to achieve on the software layer on the C64 with direct access to the hardware...what do you think the odds are of having a small portion of a concurrency thread system servicing those signals through five layers of abstraction actually working out will be? Keyboards and joysticks are fine - interactive "high-speed" single-bit peripherals, not so much.

In many ways, a simple Arduino is preferable to a $3000 gaming rig for incredibly repetitive, latency-sensitive tasks...it's all about the right tool for the job. The Pi's GPIO is not the right tool for this job...but if you manage to hack something together in a lab that defies physics and works great, we're all anxious to see it!

pkor commented 3 years ago

Wow dude. Just trying to put some ideas out there. Didn't think it would start a fight.

randyrossi commented 3 years ago

Y, it's not a bad idea. I think it was discussed on the forum a while back. It's just very difficult to implement on an emulator. There was some support added for userport data I/O line manipulation but it has limits (see the ReadMe on the project page).

The emulated machine has every 20ms of real time 'crunched/bunched up' into something less than 20ms (depending on how fast your machine is). So the 20ms 'worth' of real time may have only taken 10 ms if you have a powerful machine. And that includes CPU + video + sound, so the cpu cycles emulated could have been done in even less time than that with the instructions executed in a non-uniform manner (over time). So a program on the C64 that thinks it might be pulsing a data line evenly 10 times over 20ms, for example, would in fact not be doing anything close to that. The actual pulses you would see in the real world would be bunched up in just a couple ms probably. So the C64 program expecting real world timing would not work.

VICE can use real 1541's but only because there is essentially a hardware driver (opencbm?) that it hooks into to delegate the actual serial communication to a real device. That driver can speak to the 1541 in real time on behalf of the emulated machine and then feed the data back to the emulated registers. That could be done with BMC64 too since the hooks are already in VICE. It's just a matter of porting opencbm to bare metal environment. But it's a lot of work and I don't think it's worth it (for me anyway).

On Fri, Oct 1, 2021 at 1:28 PM pkor @.***> wrote:

Wow dude. Just trying to put some ideas out there. Didn't think it would start a fight.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/randyrossi/bmc64/issues/191#issuecomment-932421950, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI3HKABCBFULQCET33BEBLUEXVSBANCNFSM5FFAYASQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Randy Rossi

rhester72 commented 3 years ago

Wow dude. Just trying to put some ideas out there. Didn't think it would start a fight.

Apologies, just trying to ward off the all-too-frequent "but I WANT it...WHY WON'T YOU DO IT?!?" that a large percentage of open source projects endure on a regular basis. :)

This one in particular has been asked and answered a LOT in the past, but I could have shown more patience - genuinely sorry for that.

cleverca22 commented 3 years ago

Well, for one thing, the 1541 sits on the IEC bus, and the bit-banging timing required is INCREDIBLY precise

couldnt the UART be abused for this? let me check the protocol details... edit: ah, it looks more like SPI or i2c on closer reading, and you may need SPI slave, which is more tricky, no hw support edit2: yeah, this looks reasonably complex, i would just use an rp2040 to make an adapter to plain serial, but i'm sure other usb adapters already exist edit3: on further look though, it may be possible to use SPI for this, if the clock is only ever coming from the c64 end

killr0y commented 3 years ago

If the CIA#2 could be offloaded to a microcontroller, would that be possible?

cleverca22 commented 3 years ago

https://cbm-pi1541.firebaseapp.com/ / https://www.c64-wiki.com/wiki/Pi1541

this is already doing the reverse with only a level shifter, the pi cpu is directly managing the timings to emulate a 1541

that implies that the cpu is plenty capable, even when running a 6502 emulator, because its emulating the 1541 cpu/firmware too!

huskeyw commented 3 years ago

Just my two cents.. A USB device that could connect to the drive and maybe just share data to the PI (even if it cashed it and presented like a flash drive. Thought) would be cool. I use the BCM64 board and now that I have learned how to use it, its very cool to have all of these machines on one keyboard.. accessing older floppies would be cool..