20 de junio de 2022 16:20, silverdr_at_srebrnysen.com escribió: >> On 2022-06-20, at 14:51, tokafondo_at_tokafondo.name wrote: >> >> 20 de junio de 2022 13:43, silverdr_at_srebrnysen.com escribió: >> >> On 2022-06-18, at 20:04, smf <smf_at_null.net> wrote: >> >> I suspect you'd need some kind of programmable logic (like a cpld or >> fpga) to cope with the timing requirements, plus some kind of >> microcontroller with built in usb/ethernet/wifi etc to talk to act as a >> bridge between the pc and the cpld. >>> Right. Something like this, maybe (all you mentioned included) ? >>> >>> https://cld.silverdr.com/s/zwa8322K2drLCym >>> >>> ;-) >> >> What's this?? > > The thing you started the thread about ;-) See below: > Ok, I see now. Thanks. I forgot you mentioned that. And what happened, or it's happening with it? >> On 2022-06-15, at 12:25, silverdr_at_srebrnysen.com wrote: >> >>> [...] >>> I was thinking if a system could be created to freeze a Commodore 64 and DMA'ing code/data at >>> desired memory locations and then unfreeze it, so it could be tested in the real machine in real >>> time. >>> >>> People tend to program by using emulators and once it's working there, burn to an easyflash or save >>> to a whatever disk or tape file and then run in the machine, many times finding mostly with VIC-II >>> dark magic that what worked beautifully in the emulator doesn't do it in the real machine. >>> >>> Can it be done? >> >> Yes, it can. The "CodeRacer"[*] does this and a lot more. >> >> * - Vapourware so far due to chipageddon but protos are there ;-) > > Picture is actually of one of the dev-prototypes we managed to build before the chipageddon began. > > -- > SD!Received on 2022-06-20 18:01:43
Archive generated by hypermail 2.3.0.