Re: Emulator discrepancies (was DMA'ing in Commodore 64 for developing purposes.)

19 de junio de 2022 21:27, "smf" <smf_at_null.net> escribió:

> Your device needs to be able to get on and off the bus based on the
> signals on the port, you can't just use gpio to read it and then pass
> the data back to the pc and have it then send a command to change it.
> 
> That part has to be done locally on your device, probably a gal.
> 
> Do you think you know enough, to be able to implement this? Or is it
> just a random question?

I just was playing with slajerek's C64/65XE/NES Debugger and saw the ability it has to change on the fly contents of memory and hence registers of the C64, and thought that it could be done by hardware.

Freezers (cartridges I mean) did that: stopped the processor and could read and modify the memory. But the CPU of the computer was still used for that, so you couldn't actually "stop" the CPU but the code it was running, and make it run the code in the cartridge to copy/save or monitor the computer memory.

Then there was the accelerator cartridges, that included a CPU, and that's where I think the things start to get interesting. most of them used a 65816, and others a 6502 running at a higher speed, but none of them achieved 100% compatibility or stability. But they proved that a different CPU could use the main memory of the C64 -- just like the CP/M cartridge did.

There is a special case: The Turbo Chameleon 64 shows in the 7.5.3 section of its user manual how to read memory from the cartridge and save it to a file in your PC via USB cable and their own program for that, for examination or modification. In this case, the manual continues just reading this file from your PC and writing it back to the C64 memory. Not realtime, but close.

So with the amount of hardware development done throught the years, with people creating different enhacements, expansions and substitutions for things C64, I'm intrigued why someone hasn't come with this idea of having something interfacing the C64 with a PC in realtime by using DMA.

For me, it's just as "simple" as asking the 6510 to stop running, taking control of the memory in sync with the VIC-II and reading/writing it, and then releasing the 6510 to continue with what it was doing.

And I say "simple" because the concept seems not to be something not possible. In fact, the C64 seems to have been designed for that: being controlled from the outside (again, the CP/M cartridge).

Why the expansion port is populated with a dot clock source, a phi2 clock source, a DMA line to tell he CPU to stop, a BA signal, the very same the VIC-II uses to freeze the 6510 with the AEC pin, a IRQ signal, and the complete system bus in the expansion port? For the computer resources to be controlled by an external "entity".

So as told previously, an external MCU could do the job. And while writing this it came to my mind that two models of the ones WDC in particular could do it:

The w65c265s (mounted in the w65c265sxb sbc) and the W65C816i1M16SA (mounted in the MyMensch Rev. B sbc). Both have a 65816 core and a full, not "interlaced" or multiplexed system bus, that could be used to map the complete 64K of RAM, not windowed and just as the 6510 sees it, in one of the address banks of the 65816. There are also extra pins that can be used to manage the control lines that stop the CPU. I really think it can be done, easy for those SBC designers that already have completed successfully their own projects.

A ROM could be developed to run inside the MCU, so in one hand the MCU could access the C64 memory and in the other hand could be listening to commands coming from a serial port connected to a PC.

And the best is that the ROM is programmed by using 6502 code. I know that for seasoned programmers this can be done in an afternoon by reusing code from other projects.

And that's the complete story of all of this.

From that point, things like full motion video by DMA'ing complete frames before the VIC-II reads them (or just "beam racing" them on the fly), or complex sprites manipulation, or poking the SID registers at high speed so better sound effects or sampled sounds could be achieved, it's a matter of time. 

  
> On 19/06/2022 00:21, tokafondo_at_tokafondo.name wrote:
> 
>> I'm sure it is, because the transfers between that board and a PC are
>> done by USB. And the software controlling it is python based.
>> So maybe as previously said, a way could be have a man in the middle, injecting DMA transfer those
>> 24+4 lines, while receiving command from a PC.
>> 
>> Would any of those RaspBerry, its clones or similars, or ATMega based MCUs, do the trick?
>> 
>>> Regards,
>>> Michau