Date   : Mon, 08 Aug 1994 09:52:05 EST
From   : Stephen Quan <quan@...>
Subject: decoding the files i sent you.

> I would have included your message but Pine would have stuck the ROMs on 
> the end!
> 
> Thanks for the ROM images, but I have a bit of a problem... being a 
> non-unix sort of a person I haven't much of a clue of how to get them 
> out! Sorry to be a pest but could I have some basic instructions?

Ok, you need to extra each file individually and save it with a
temporary name.  For instance with os.bbc save it as os.uu.  In
the end you should have a whole bunch of .uu files in your directory
which start with a 'begin 644' line and end with a line containing 'end'.

Then you simply type 'uudecode file.uu'.  I will be sending you a
DOS version of UUDECODE.COM at the end of this mail.

> I've written wee notes about what else you said...
> 
> Re LODSB vs LAHF - don't worry about questioning my logic! The only way 
> programs progress is by having their logic questioned. I never really 
> meant that my way was the "correct" way and yours wasn't; we've really 
> just chosen different ways of going about things. BTW, how *do* you 
> handle the flags?

Ok, what I have done (at it is in operation now).  Is design not 1 emulator
but 16 emulators.  In other words, I have 16 256-branching loops and so
forth.  Each emulator for every combination of N,V,Z and C.  I have called
my emulators N0V0Z0C0 .... N1V1Z1C1.  For instance, say if I had to
implement SEC for one of my emulators, e.g.

   N0V0Z0C0_SEC:
     jmp N0V0Z0C1

For more complex instructions :

   N0V0Z0C0_INX:
     inc cl              (or whatever register that holds X)
     js  N1V0Z0C0
     jnz N0V0Z0C0
     jmp N0V0Z1C0

So you see, I am really using the PC's status registers after all.

> Re screen mode handling - Great idea! How are you planning on handling 
> this? I have a PC assembler program which will transfer a MODE 0 PC 
> screen directly onto a PC VGA screen at >25 frames/second (using all of 
> my processor power). I'm really not sure what the best way of handling 
> the screen is. Are you trapping all screen writes or transferring the 
> whole lot now and again? I'd be interested to see someone else's view on 
> this. The only two I have heard about are both spectrum emulators and 
> both the authors found it quicker to copy the whole screen. Any thoughts? 
> I'm really open to either idea. Copying the whole screen slows down the 
> machine a lot every so often; trapping writes slows it down a little for 
> every write instruction.

What I have decided to do here is, I maintain a variable that counts the
number of simulated instruction cycles that have occured.  e.g. I think
INX takes 2 cycles, so what I would have there is

    /* INX */
       add    dl,2      (or whatever register you used for the clock)

With recent testing, I have found that 1 video scanline is drawn per
64 NOP instructions (or 128 cycles).  A very convenient number.  So
elsewhere in my code, I have (crudely approximated here)

    /* 6845??? */
      test  dl,dl
      js    6845 

> I think we certainly should be able to work together on bits of this. Are 
> you thinking of selling the finished product? I am considering (if I 
> finish it) writing to schools here in the UK to see if there is a demand 
> from those of them who upgraded to PCs. Being a poor student I could 
> always do with some cash...

:-)  Originally no.  It depends on how good it is.  I think I might
make the emulator public domain (actually), but retain the source code.
I don't know.  I still haven't decided on this point.  By the way, I
think some of the stuff in this article is useful, so I will be spawning
threads that contain a repeat of stuff in this article.
-- 
Stephen Quan (quan@...                 ), SysAdmin, Analyst/Programmer.
Centre for Spatial Information Studies, University of Tasmania, Hobart.
GPO BOX 252C, Australia, 7001.  Local Tel: (002) 202898 Fax: (002) 240282
International Callers use +6102 instead of (002).