Gábor Lénárt <firstname.lastname@example.org> writes: > Btw, what came into my mind yesterday: what will happen if someone write an > emulator which emulates the hardware of an 1541 by software, and I use that > to run the content of a real CBM DOS ROM, etc. It would be quite compatible > then, even with fastloaders or whatever I can imagine ... Since the original > CBM DOS can be run on the "emulated" (but seems to be original from the > point of view of DOS) hardware. You mean something like open1541? http://www.xcore.com/projects/open1541 > * Is a regular uC fast enough to do this emulation at the speed of a real > 1541 (CPU emulation, etc)? Random data point: I benchmarked a not-that-well written, access-accurate 6502 emulation running the C64 reset sequence from $fce2 to $e5cd at roughly 2.25 times real-time on a 100MHz LPC1768. It still has the potential for quite a few optimizations, e.g. by not fetching the full 6502 state into ARM registers for every instruction.  access-accurate: Simulates every memory access a 6502 would do, making it 100% real-time cycle accurate would probably be possible by delaying in those accesses if the WCET between accesses is low enough (not tested) > * It would need to put disk image to somewhere and as far as I can see, it > must be in low-level format (GCR, whatever ...). It requires "some" > memory, which is more than most uC provides (the image itself could be > read/written through USB for example). I guess it's about 200K of memory, Track changes are a relatively slow operation, if your storage medium allows random access and is fast enough you can get away with just storing a single track in ram. > optinally switch off emulating delayes caused by the mechanical parts > since I guess CBM DOS won't be too happy (I don't know if waiting for > events are done with mostly 'hard wired' delay periods or it really > checks status of various signals all the time to see if something happened > or not yet) It's both - e.g. seek operations use hardcoded delays, waiting for a sector while on the target track depends on the time until the sector header is found. It would probably be simple to add a "bypass" that immediately skips to the correct sector header for the standard Dos rom, but anything that searches for sector headers "manually" wouldn't benefit from that - this includes many of the better fast loaders. -ik Message was sent through the cbm-hackers mailing listReceived on 2011-04-30 15:00:13
Archive generated by hypermail 2.2.0.