One of the more absurd programs I've put together, this demo uses fake6502 by miker00lz, compiled with cc65, to emulate a 6502. The emulated 6502 remaps NES internal RAM to $7000 and a portion of $6000+ (that cc65 uses) to $7800. This emulated 6502 boots from the ROM's own reset vector, which in turn causes it to also begin emulating a 6502. But one of the emulated instances soon crashes, because it lacks the self-awareness required to relocate the RAM dynamically.
Audio output is updated (by XOR) with the lower 7-bits of the address during reads, and the data bus during writes.
cc65 version
(seconds)
00~01 - clearing RAM (1kB)
02~11 - code is running (cc65 is loading initialized data)
12~12 - program goes into the weeds
13~29 - BRK dancing
30 - emulated program seemingly rolls over and restarts
edit: updated and added cpu2.zip, which includes the demo built with the new vbcc6502 compiler.
vbcc6502 version
(seconds)
00~05 - polling $2002?
06~06 - clearing NES RAM (2kB)
07~13 - loading initialized data
13+ - emulated CPU is stuck in an infinite loop
listen to a 6502 emulate a 6502 emulating a 6502
Moderator: Moderators
Re: listen to a 6502 emulate a 6502 emulating a 6502
Not bad. A possible workaround for the problem might be a Playchoice10-style fix: Emulating an additional Z80 processor, then the emulated Z80 could simply reset the emulated 6502 when sensing the execution of BRK opcodes on the crashed 6502 (you may need expansion RAM for the Z80 memory).