On a Commodore 64 or Commodore 128, the upper four bits of the data bus will be left
floating when reading color memory. On my vintage Commodore 128, floating data bits would generally read as high, but on the Commodore 64 they would be more likely to report whatever value had been last output to the data bus. Because CPU cycles alternate with display data ...
I haven’t done this but I believe you could instigate a DMA transfer via the 2MHz ‘tube’ interface and write the image directly into RAM. That would require additional hardware but no modifications to the machine itself.
For the ZX Spectrum:
Sorted by amount of non standard modern equipment needed (less to more):
A smartphone with SpeccyTape (IOS, unfortunately, now unmaintained and not available for 64 bit devices) or PlayZX (Android) and a stereo to mono cable.
TZXDuino / TAPDuino: hobbyst grade gadget (built and sold in several places) that essentially does the same as ...
This is a wiki answer, so please amend with additional solutions, or improve the ones below:
CPC Tape Software
Tape images are normally downloaded as a .cdt file, the same file format as the Spectrum .tzx tape format. Though these do not contain any sound data, they can be played back on an Android or iOS phone, using an app such as 'PlayZX' or 'Speccy Tape'....
One thing that can give emulators away (not reliably, but it might be good enough in practice) is how undefined the results are when you do something that is supposed to yield an undefined result. One thing that comes to mind is what you read from a bus when there is actually nothing writing to it, or using hardware in a way that is known to cause glitches ...
Wouldn't it defy the purpose of an emulator, designed to mimic a machine as perfect as possible, if it can be detected? In general, every detectable difference must be considered a bug one would expect to be removed ASAP.
Some programs notice if they are run on a real C64 or an emulator.
It would be great if you could add some examples. Especially with ...
In general, no there is no reliable way to detect an emulator (if it's any good). Especially if it's actively developed.
The trick that worked yesterday probably don't tomorrow as emulation improves. Also, exploiting margins like ghost signals on floating bus lines may just lead to false positives as well, as there were quite a few differences between C64 ...
Any time the CPU writes to memory, it writes to RAM or I/O. Your example will zero out all the RAM, but also will zero any I/O locations. That's going to have the effect of disabling sprites, setting their colour to black, turning any sound off, etc etc. It might send a zero byte to the serial port or something as well, I'm a little hazy on exactly ...
It is not strictly true that "all works fine" for ML programs with a standard BASIC header starting at $0800 vice $0801. The idea of the BASIC header is that your program is easily loaded and then started using the "RUN" command:
LOAD"MYPROG",8 REM NOTE ABSENCE OF ",1"
If you move the header one-byte down to $0800,...
With the last edit it seams as if it could be not about blowing up a char, but filling 6 char definitions located in sequence in into 6 sprites, again located in sequence. As before, it's just a guess due the rather unclear wording.
A routine to copy one char into one sprite (pre cleaned) might look like this:
; Generic subroutiene to ...
If you want a straight up copy, then what about reading the char's bitmap first, and then writing it to the sprite?
cpch: lda (chptr),y
Something like that?
I still have no idea what the question is really about. So what follows is a wild guess from what the OP posted in question, edits and comments as well as what I think he could be about:
Blowing Up an 8x8 Char Into a 24x21 Sprite
[I have no idea if this is right, but I can't believe it's just about copying, as that would be way too simple]
A character is ...