Re: PC as 1541

From: Ingo Korb <>
Date: Sat, 30 Apr 2011 15:46:12 +0200
Message-ID: <>
Gábor Lénárt <> 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?

> * 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[1] 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

[1] 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.


       Message was sent through the cbm-hackers mailing list
Received on 2011-04-30 15:00:13

Archive generated by hypermail 2.2.0.