Re: Floppy Emulator



I see you have gotten an impressive collection of answers that missed
what the problem actually is, so I'd better jump in.

Either you have a bug in your floppy emulation code or (much less
likely) you are booting from a bad disk image. The Model III TRSDOS
boot sector does *not* begin with a RST 38H. The bytes after that look
correct, as far as I looked, but the presence of the extra garbage byte
shifts all the good bytes forward by one byte, so the code doesn't do
what it's supposed to. It's close, because the JR instructions are
relative addressed, but of course all the CALL instructions are absolute
addressed, so their targets are shifted one byte forward and they end up
landing at code that was supposed to one address lower -- which is
usually the RET from the previous subroutine!

A bit of advice: You seem to be debugging in too big a jump here.
Instead of going all the way to disassembling the code at 4300H and
checking if it made sense, you should have simply compared it against the
contents of that sector on the floppy disk image you were using. That
would have shown the bug right away.

Another technique that may be useful is to compare implementation and/or
results against a known working emulator, of which there is no shortage.
xtrs source code is available on my web page, for instance. Also, some
of the existing emulators (including xtrs) have built-in debuggers with
disassemblers, so you can set breakpoints and check what the results
should be at various points. In this case setting a breakpoint at 4300
in xtrs was enlightening.

--Tim


On 30 Jun 2005 11:02:06 -0700, "Matt" <mchamilton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> Hi All -
>
> I'm working on creating a Model III (hopefully soon Model I & 4)
> emulator. It's written in C# and I hope it will be portable between
> dotNet and Mono.
>
> Everything is coming along great (Z80 passes ZEXALL; sound works;
> integrated assembler / disassembler / z80 internals report / etc) but
> I've run into a problem emulating the floppy controller that I hope
> someone can help with.
>
> When I load in the bootstrap sector (track 0 / sector 0 *or* 1) it
> always seems to give nonsensical results. For example, using trsdos
> (tdos13d.dsk on Ira's trs-80.com site), and look at 4300H immediately
> after the sector is loaded, I see:
>
> 4300 RST 38 ; not sure why but doesn't seem to hurt anything
> 4301 CP 11 ; isn't this the directory marker?
> 4303 LD A, D0 ; OK, this makes sense, reset the FDC
> 4305 OUT F0
> 4307 LD HL, 0002
> 430A LD (43EA), HL ; What's the point of this?
> 430D XOR A
> 430E LD (43EC), A ; Or this?
> 4311 CALL 433E ; 433E is just a RET
> 4314 CP 01 ; Why bother, we know A has 0x00
> 4316 JR Z, 0C [4324] ; 4324 calls the 433E and RETs
> 4318 CP 02 ; A still is just 0x00
> 431A JR NZ, {4303} ; Continuous loop if we get here
> 431C CALL 433E ; We sure like CALL / RET, don't we?
> 431F CALL 4335 ; 4335 seems to be in the middle of an
> instruction. If we go there we get IN CD, makes no sense
> 4322 JP (HL) ; JP (0002)???
> 4323 RST 38 ; Why?
>
> It goes on. There seems to be stuff that makes sense, like this snip:
>
> 4383 LD BC, 00F3
> 4386 LD A, 81
> 4388 OUT F4
> 438A LD D, A
> 438B LD HL, 43B7
> 4391 LD A, C3
> 4393 LD (4049), A
> 4396 DI
> 4397 LD A, C0
> 4399 OUT E4
> 439B LD E, 02
> 439D LD HL, 4D00
> 43A0 LD A, 84
> 43A2 OUT F0
> 43A4 CALL 43E0
> 43A7 IN F0
> 43A9 AND E
> 43AA JR Z, {43A7}
> 43AC INI
> 43AE LD A, D
> 43AF OR 40
> 43B1 OUT F4
> 43B3 INI
>
> but even this breaks down later.
>
> I've looked at dozens of disk images, in JV3 and DMK, and no
> combination of anything seems to make sense here. I know I must be
> missing something simple, but I'm stuck at this point.
>
> Anyone have any insights? I've scoured all the Mysteries books, the rom
> disassemblies, the FDC documentation, etc etc.
>
> TIA for your help.
>
> - Matt
>


--
Tim Mann usenet@xxxxxxxxxxxx http://tim-mann.org/
.



Relevant Pages

  • Re: how important is an emulator to an embedded engineer?
    ... If you are strapped for resources, an emulator ... The emulator itself may have hardware and/or software/firmware ... understand the design, the technology and the behaviours of the ... If you suspect a bug, write a short, concise test ...
    (comp.arch.embedded)
  • Re: Emulator Crash
    ... >the emulator on many other desktop machines. ... So I'm wary of claiming innocence just because a bug ... >- The emulator causing this is the Pocket PC emulator that comes with Pocket ...
    (microsoft.public.pocketpc.developer)
  • Re: Bug in TreeView
    ... The bug still occurs after applying SP2. ... Just add the cab file as an existing item to your solution in VS. ... Then it is copied during deployment to the emulator and you just have to ... The Fullpath of the SelectedNode shows a message ...
    (microsoft.public.dotnet.framework.compactframework)
  • "Cannot save file" error in eVC++
    ... I have a PocketPC 2003 device, but I'm compiling under eVC++ 3.0. ... Yesterday I was working on a game and ran into the eVC++ bug. ... reported an error copying the debug x86 version to the emulator. ... currently open CPP file, I get a dialog that states: ...
    (microsoft.public.pocketpc.developer)