Re: PC as 1541

Gábor Lénárt <lgb@lgb.hu> 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[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
instruction.

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

-ik

       Message was sent through the cbm-hackers mailing list