AmlieEm versions - for DOS unless says otherwise
=================

0.01  2007/12/07

      More realistic serial handling implemented. The byte to be
      sent serially is snarfed after about 4000 cycles. This better
      matches the reality where you simply CANNOT send bytes as fast
      as you want. [~4000 cycles/byte is roughly 4000bps]

      Added a patch to reject byte value 255 sent to the ACIA. This
      byte seems to be turning up a lot now (faulty BIOS code?) and
      the patch is just a way of making it go away until I have time
      to track down the source of the problem.



0.01  2007/12/02

      Fixed really idiotic bug in memory decode which arose as the
      result of a recent optimisation of the memory handler code.
      Duh! Duh! Duh!

      When pressing a function key (1-6), the application system
      now 'highlights' the bracketed number for a short time to
      provide positive feedback on this.

      The application system now 'fakes' motor access according to
      the following output from VIA port B:
        bit 0 - Left motor direction (0 = forward, 1 = reverse)
        bit 1 - Left motor drive
        bit 2 - Right motor direction (as above)
        bit 3 - Right motor drive
      This system is designed to be used along with relay switches
      to drive two fairly simple cheap "rechargeable drill" motors.
      This is easier to implement than steppers and, while possibly
      slower, should provide a higher level of torque, perhaps
      sufficient to mount reasonable inclines, or to permit the use
      of larger battery packs (i.e. more weight).

      Fixed VIA bug where the binary maths with the DDR meant that
      outputs could not be written to the VIA. New algorithm, like,
      one that works! :-)

      The contents of the AppSys serial terminal are echoed to a
      remote serial device if connected (9600 baud, 8N1, RTS/CTS).
      At start, if CTS not asserted, serial will be disabled. Else
      serial will be used and data simply tossed if serial error.
      Keys pressed in serial terminal are treated as if they were
      pressed on the local keyboard, BUT ONLY IN APPSYS. None of
      this has any effect within Tracey.

      Note that the emulator pushes some additional information to
      the connected serial device as follows:
        When started, if serial available:
          Welcome to AmlieEm (vx.xxxx)!
        When entering Tracey:
          {CURRENTLY IN TRACE MODE - DO NOT SEND INPUT}
        When exiting Tracey (back to AppSys), the line above is
        cleared.
        When exiting, the above line is cleared, then:
          *********************************************
          *                                           *
          *  SESSION FINISHED -- AmlieEm has exited  *
          *                                           *
          *********************************************
          More info at http://www.heyrick.co.uk/amelie/

      All this serial port stuff has been designed to allow you to
      design and test serial output (in whatever form) using the
      actual serial device that you plan to associate with Amlie.
      In my case, it will be a lookee-likee Psion 3A organiser and
      the BIOS will output status to IT as IT can run for hours on
      two AA cells (instead of some memory-hungry LCD display plus
      all the crap that is necessary to actually get something to
      look at).
      Of course, we could FAR expand upon this my reversing the role
      and having Amlie's BIOS essentially work as a dumb terminal
      where it reports all status via the serial port (except for
      bump detection where it will stop the motors and then report
      to the serial port), and the attached serial device will work
      out what to do and send commands BACK to Amlie. In this case,
      a simple(ish) OPL program on the attached organiser could
      perform some really rather complex processing, plus have the
      benefit of being able to be tweaked and retranslated into a
      program "on site". I'll yack more about this approach on the
      website; however please note that it is EXTREMELY LIKELY that
      the initial (incomplete) BIOS will operate in EXACTLY this
      manner to allow the methodology of the control code to be
      designed in a high-level sense (with embedded 6502 code to
      follow).



0.01  2007/09/09

      Fixed a few small bugs in the VIA handling that arose as with
      extensions to the BIOS.



0.01  2007/09/06

      Updated to support 8K EPROMs instead; with fallback support
      for 4K images. 4K images will be loaded by being copied twice
      into the 8K space, as this is roughly how it would 'appear'
      to be in actual memory.

      Image loader ([I] in Tracey) will now attempt to load unusual
      size images to the END of the EPROM area (without any kind of
      duplication, unused EPROM space will by set to &FF) in order
      that, hopefully, smaller EPROM sizes (i.e. 2K) will be loaded
      correctly. Note that the initial start-up WILL NOT LOAD any
      images other than 4K and 8K.

      The Quick Save file version has been incremented to 2. It is
      possible to load (but not save) earlier version 1 files. The
      differences are:
                         Version 1     Version 2
         ACIA state      Not saved     Saved
         EPROM size      Assumed 4K    Assumed 8K
      Note that ALL EPROM images will be 8K from now onwards, as
      anything that isn't 8K will be fudged (refer to previous
      paragraphs for details).
      
      Quick Save file versions are now within the main code as a
      conditional compilation, version 'x' in DOS and '256-x' in
      RISC OS. Furthermore, the code will assume that any version
      number more than 16 out is for a different operating system
      and as such it will warn you of this. I chose '16' so we
      could include, say "128-up" and "128-down" if it was desired
      to plug in support for more operating systems that are not
      compatible with DOS or RISC OS (perhaps Linux assumes a 32 bit
      integer like RISC OS, but has DOS ordering? whatever...).

      The BIOS code was amended to 'echo' anything typed at the
      keyboard, and this showed up a bug in the ACIA emulation,
      namely that if interrupts were disabled at the point of the
      ACIA IRQ occurring, then this interrupt would become 'lost'.

      Altered the ACIA status reporting within Tracey to be a bit
      more concise. It will now correctly report whether or not a
      serial IRQ has occurred in ALL situations; plus it will also
      report the reason for the IRQ.

      IMPORTANT: With the supplied BIOS, you will probably NEVER
      be able to 'see' a byte-received IRQ because the number of
      byte-transmit IRQs for "Tick" will swamp you (unless you
      amend the BIOS?).
      You cannot attach a breakpoint to the RX handler code. Well,
      you obviously can... but since the ACIA's status register
      will already have been read, Tracey's status will not show
      any IRQ pending, only that the RX buffer is full.

      The undocumented "profile this computer" option has been
      moved to keypress [Z].

      You can now see the application screen (that stuff that is
      shown outside of Tracey) from WITHIN Tracey by pressing [V].
      You can also press [Alt]+[F5] (DOS only) to do the same
      thing if you're used to TurboC's keypress. :-)
      
      Code alterations to RISC OS version to remove most of the
      compiler warnings - there is only one now, and it's a complex
      line so I don't plan to insert casting to get rid of a single
      warning.
      
      Fixed DOS:delay() bug in RISC OS version.      
      Fixed CONIO:textattr() bugs in RISC OS version.      
      Fixed CONIO:normvideo() misunderstanding in RISC OS version.
      
      Also a few tidy-ups and such; with this updated code being
      merged back in to the DOS release.



0.01  2007/08/06

      Loading an EPROM image now does a proper, full, system reset.

      Various pokes and tweaks to the VIA code as a result of some
      issues uncovered by the BIOS code. Turns out it was 99% a fault
      in the BIOS, but a bug fixed is a bug less...

      Tiny change to the help display so it'll display (mostly) okay
      even if the date is too long. "6th August 2007" used to cause
      a spurious blank line as it was right on the limit. I wonder
      what'll happen with September? :-)



0.01  2007/08/04

      A build of this version for DOS.



0.01  2007/08/04 [RISC OS]

      Stuff happened to CONIO:
        Fixed the background colour problem.

        Some optimisations to 'puttext()' function.

        Now sets text windows, so the initial 'welcome' message
        and the red error reports work as expected.

        Handling for F1 to F8 (used by AppSys for 'bump' toggle).

        There are still a few outstanding quirks, but it is now a
        fairly close emulation of CONIO / CGA text.

      Now displays clock and latch (LEDs) status upon screen
      refresh.



0.01  2007/08/03 [RISC OS]

      Put together a version of CONIO that 'remembers' the screen
      so it is now possible to change between 'trace' and 'appsys'.
      There is a small bug in that the background colour is not
      correctly restored; however it is a fairly small thing.
      
      Note that as the system involves more work than simply
      writing to a buffer (as on the PC), the actual screen output
      is DISABLED while single-stepping. You will see a flicker as
      the screen is cleared and redrawn (this can't be optimised out
      without affecting how the PC code works).
            
      The Help display now works correctly.

      ESCape is now trapped. It doesn't do anything, but by a quirk
      it appears to insert ';' into the keyboard stream (probably a
      bug in CONIO). I have left this as-is because it often can be
      used to 'cancel' current operations, much like the ESCape key
      does on current DOS builds.

      The colours (in the "SetPalette" program) have been revamped to
      look and feel more like those of a real CGA card. In specific,
      'brown' is now brown; the colour tonality better matches the
      PC graphics adaptor colours.

      The "SetPalette" program now attempts to load up a 640x200
      mode on RiscPC-style hardware. It will first look for the 90Hz
      mode (definition supplied with !AmliEm), and if this is not
      found it will try any 640x200 mode (any refresh, though that
      supplied with RISC OS 3.70 is a 60Hz mode). If that fails,
      it will revert to the letterboxed MODE 46 that is used with
      the older (Archimedes-style) machines.

      
      
0.01  2007/07/03

      Memory subsystem now allows (and does not fault) attempts to
      access the FINAL byte of each 1024 byte block within the
      possible memory allocation (which is 16K). This may be used to
      allow firmware to 'probe' for how much memory is actually
      installed.
      Note that the implementation *may* be buggy - it *appears* to
      work, but I have not given it much testing.

      Pressing function keys F1 to F6 set the appropriate "bump"
      sense bits in the VIA (port A), plus sets CA1 to cause an
      interrupt...



0.01  2007/07/02

      Now correctly redraws Tracey display after forcing an emulator
      reset.

      Tracey now displays the ACIA status, but note that you cannot
      (currently) modify this status from within Tracey as you can
      with the VIA. What you can do is choose to 'unlink' the serial
      system, which will set DCD and DSR both to be 'high' (no modem
      carrier signal, modem not ready - essentially "not connected").

      ACIA code now obeys our DTR to enable and disable comms, as
      well as DCD/DSR for cable connected, or not.

      With regards the ACIA, for development it may be useful to
      write a serial transmit routine that will attempt to send data
      and toss it away if send fails; so you can embed status reports
      in the firmware, such as "BUMP FL" for "font left bump sensor
      has been triggered". These will show up on-screen...

      Displaying a list of breakpoints will now also list breaks on
      event. Note that you can only list SEVEN assigned breakpoints
      (out of the 16 possible) when you have break-on-events,
      otherwise you can list the first NINE breakpoints.



0.01  2007/05/26

      Fixed colour oddity bug. The "latch.c" source was including
      conio by the RISC OS method:
        #include "conio.h"
      instead of the version required on DOS:
        #include <conio.h>
      so while it was linking to the TurboC++ libraries, it was using
      colour constants which differ from DOS due to implementation
      variations.
      [in case you didn't know, the "quoted" include means the file
       to be included is in the same place as the sources, while the
       <bracketed> include means it's a supplied library component
       (usually residing someplace within the compiler)]
      All fixed and restored to normal.



0.01  2007/05/25 [RISC OS / DOS]

      Numerous changes to the code in order to support a successful
      compilation under RISC OS (and also with lcc). Different
      compilers are finickety about different things - the RISC OS
      (ex-Acorn/ex-Norcroft) 26/32 neutral compiler FREAKED over my
      abuse of the '\' line continuation character in a number of
      places where it shouldn't have been, where lcc and TurboC++ did
      not complain. Added a few tweaks along the way.
      Interestingly, using the '\' to break a long textual output
      across several lines\r\n\
      like this\r\n\
      failed with the RISC OS compiler - I wonder if this is maybe
      a small glitch in the compiler? Whatever...

      Now uses #define constants for ALL filenames, so we don't send
      poor RISC OS to try to handle a filename like "QUICK.SAV". For
      those not used to RISC OS, the direct equivalent to a DOS
      filename would be "QUICK\SAV" (i.e. "SAV" in the non-existent
      directory "QUICK").

      Interesting quirk: Upon recompiling the DOS version from the
      RISC OS version (of the DOS version...), it appears that the
      latch output is somehow 'inverted'. I'm not sure what
      information has been sent to the display to cause this to
      occur. For now, I've manually altered the colour codes so it
      looks correct on-screen.

      RISC OS: Additions/changes to the "conio" emulation to provide:
                 1. Bug-fix for wherex() and wherey().
                 2. cprintf() is now it's own function so that we can
                    clip out LFs - the TurboC++ conio wants newlines
                    to be CRLF, RISC OS doesn't do it the same way;
                    so we call OS_NewLine for CR and ignore LF.
                 3. getch() expanded to handle the control (0,x) key
                    presses that we are interested in - so Alt-T will
                    now return you to Tracey, and cursors/PageUp,Down
                    now work!




0.01  2007/05/12

      ACIA now pushes serial bytes transmitted to AppSys for display
      (i.e. as a dumb terminal); and keypresses are sent to the
      ACIA as bytes received.
      I'm not sure if the (basic) ACIA emulation is 'correct' as the
      BIOS does not yet support serial operations.
      
      Not bothered with emulating RTS/CTS/DTR/XON-XOFF and all the
      rest of it - simply ACIA<->AppSys and always connected.



0.01  2007/05/10

      Started basic ACIA emulation. Yeah, it took a few months to get
      around to this. I've other stuff on the go, like VeroDes... :-)



0.01  2006/11/06

      Lots of minor tidy-ups to the display output while reviewing
      the code, added additional notes and comments into the code
      itself.
      Amended the BIOS code to whizz through the LEDs (so you can
      see something is happening).
      Also, the cursor is no longer on-screen when in AppSys (i.e.
      not Tracey) mode.

      AppSys no longer supports the '?' keypress for a cycle count.
      You can ONLY press Alt-T to return to trace mode. All other
      keypresses are provided to the serial port.
      AppSys now reads to see if there is a keypress by directly
      examining the DOS data area to see if the keyboard buffer
      head and tail pointers match. This is not a terribly nice
      (or future-proof) way to do it, but it is a heck of a lot
      quicker than calling kbhit() - perhaps by calling the DOS
      function dispatch (INT 0x21,0xB)? The difference? The DOS way
      supports STDIN while we read ONLY from the keyboard. This is
      not seen as a problem as using AmlieEm via piped input is not
      considered to be terribly useful.

      I'm not going to do the serial implementation tonight. I'm
      cold and there's nothing good on TV tonight, so I think I'll
      go to bed with a hot chocolate and a good book...



0.01  2006/04/30

      VIA supports setting bits of the inputs, as if an external
      'event' happened. Triggers IRQ in CAx/CBx set to TRUE, if it is
      desired according to IER state.

      The "AppSys" module now draws a screen display. It doesn't do a
      lot, but you've something to look at.

      The '?' key, when NOT in Tracey, will report where PC is and
      the current cycle count. The cycle count is now printed pretty
      (in the form xx,xxx,xxx) and you will also be informed of the
      current emulation 'time' from processor start. This reflects
      Amlie's concept of time.
      On my 466MHz laptop, 30 seconds real time equates to around 18
      seconds emulation time. There is no support to limiting time on
      faster machines - a 2GHz+ machine may well run the emulation
      extremely quickly.
      Note that this may give a different speed figure than the 'V'
      key within Tracey. This is because Tracey uses specific fixed
      code to determine the average emulated processor speed, while
      this actually counts clock cycles for what has been executed.
      The value will wrap and report negative numbers after exactly
      2,147,483,647 cycles. This represents about 18 minutes of
      emulated time.

      In an emulated minute, or some 120,000,000 cycles, the AppSys
      is polled between 12,000 and 16,000 times. In case you're
      wondering...

      Your system may experience a noticeable lag when running
      AmlieEm (mine does, but perhaps that's Windows98?). If this is
      the case, and you'd like to speed things up without quitting
      AmlieEm - simply go into Tracey and do something where it will
      wait for a keypress from you. An example is pressing 'H' for
      the help screen.
      I suspect that this is because the DOS emulation may use screen
      output and keyboard input events as positions to defer to the
      rest of the operating system, and when we aren't doing that,
      Windows gets less of a look-in so things appear to slow down.
      Well, that's my theory. It fits in with observable behaviour,
      thus it is probably entirely wrong. :-)



0.01  2006/04/29

      Now reminds you of the correct keypress if you try pressing 'Q'
      to quit, then answer No as you don't want to trigger an IRQ!

      Extended the help screen.

      Started the "Application System Display" routines.



0.01  2005/11/02

      Breakpoints can now be set on an event:
        * When the IRQ vector is about to be taken
        * When a RTI instruction is about to be executed
        * same for RTS
        * and NOP
        * and branch/JMP
      This may be used for:
        * Debugging IRQ code; can be called at point of IRQ vectoring
        * Debugging code after IRQ, can be called as RTI would happen
        * Stepping through subroutines, RTS by RTS
        * Judicious debugging, simply drop in NOPs and break-on-NOP!
        * Branches that don't seem quite correct, break on branch/JMP
      Note the following:
        IRQ vector = IRQ vector
        RTI = RTI
        RTS = RTS
        NOP = NOP
        branch/JMP = BCC, BCS, BEQ, BMI, BNE, BPL, BVC, BVS, JMP, JSR

      Additionally, note that we DO NOT support the use of BRK to
      enter debugging mode. This is because it is quite safe to leave
      the odd NOP or two in EPROMed code, you'll just waste one byte
      and two cycles. On the OTHER hand, forgetting a BRK would
      require your IRQ handler to be BRK aware, as it sets the B flag
      and calls an IRQ... Therefore Amlie is designed to use NOP as
      the generic debugging entry point.

      The QuickSave format has changed, don't load older files with
      this version of AmlieEm.

      WARNING: If you set up breakpoints on address, and you modify
      code directly (byte by byte within AmlieEm), please DO NOT
      save an image of the EPROM area until you have cleared all of
      the breakpoints. The breakpoint system works by replacing
      specific instructions with a call into the break handler; and
      you could (inadvertently) be saving these dummy instructions
      thinking you are saving the correct EPROM image. Note that
      Tracey's disassembly will show you what is SUPPOSED to be
      there, not what actually is - you'll see this disparity if you
      compare the disassembly with the memory dump in the lower
      window.

      Alterations to the breakpoint system, and also fixed that
      weirdness where Tracey was called BEFORE the instruction fetch
      (didn't make much difference in behaviour, it was just
      illogical).

      Implemented the latch at &A300. Displays in Tracey as four
      boxes, either dull mute (if off) or bright'n'bold (if on).



0.01  2005/11/01

      Fixed a rather horrid bug in aborting into Tracey where Tracey
      was updating the CPU's PC value to the source of the error. In
      actuality, the CPU's PC was supposed to be updating Tracey's
      value of PC (used for the disassembly). This explains why an
      IRQ would throw you to the reset vector and/or you'd crash out
      with "stack overrun" errors. Duh much!

      Recoded the VIA core to use a centralised struct "via" instead
      of separate structs for each part of the VIA. This makes it
      loads easier to pass values to/from Tracey.

      Tracey updated to display the VIA's port bits with bit 7 given
      *FIRST*. I would like to blame that can of 7.8 beer, but I
      think the real reason is generic cluelessness on my part...

      Tracey can now poke around the VIA. The new keypress is 'P' for
      Poke. For the ports, you can set all or clear all bits or set
      the status of individual bits. For the control registers, you
      can set the value of the register. Note that Tracey does NOT
      provide you with much help here, if you wish to set bit 4 of
      the PCR, it is hoped/expected that you'll have a 6522 datasheet
      to hand as well as a binary calculator (if you can't do it in
      your head).

      New 'undocumented' tracing mode. Called "unrolled repeat", it
      is pretty much like holding down Enter (i.e. the code runs
      repeatedly but you stay within Tracey). The only difference is
      that Tracey only looks for keypresses every ~128 cycles so
      things run faster because we don't have the overheads of the
      astonishingly lethargic kbhit() command! On the other hand, we
      do have a nearly-complete screen update (we don't do the back
      or the boxes) after each instruction; though I feel that it
      STILL runs faster than kbhit()!
      The keypress? 'U' for [U]nrolled repeat!

      The QuickSave format has changed, don't load older files with
      this version of AmlieEm.



0.01  2005/10/31  **HAPPY HALLOWEEN**

      Linked in the VIA core, and implemented Timer1. Tracey can now
      report on the status of the VIA. Fixed a few bugettes in the
      Timer1 implementation (namely weirdness to do with bitfields
      returning '0' or '-1' instead of '0' and '1'!).

      Numerous minor changes to Tracey's screen handling, i.e. the
      prompt bar no longer whizzes off the right side of the display
      when blanking. Also the "report box" forces a complete redraw
      of the screen, to get rid of it!

      Undocumented keypress 'Q' will allow you to force a processor
      IRQ. This is undocumented as forcing an IRQ can be a potential
      problem if no IRQ handler has been set up. Note, also, that a
      side effect of this is to enable processor interrupts.
      [undocumented, yes; but I'm sure most of you will find it when
       you try pressing 'Q' to get outta Tracey/AmlieEm!]

      If you are pulled into Tracey as a result of the eTR opcode
      (unofficial opcode to invoke Tracey from code), then Tracey will
      automatically advance PC to the next instruction. The normal
      behaviour of "invalid instructions" is to stop at the
      instruction concerned.




0.01  2005/07/06

      Now Tracey only redraws the actual information when performing
      single-stepping, instead of refreshing the entire screen. This
      greatly reduces flicker - but note that the 'active' screen is
      not redrawn properly, and any output to the active screen may
      corrupt Tracey's display. However, since the chances of this are
      few and far between (remember - single-stepping only executes
      one instruction at a time), it was considered much more
      beneficial to make the screen more responsive and less flickery.
      At any rate, the '?' key will force a screen refresh.

      Attempts to increase keyboard auto-repeat rate (for faster
      single-stepping, etc), but this only works under bare DOS; if
      you are running under Windows, you will need to alter the
      repeat rate in Control Panel -> Keyboard.



0.01  2005/03/21

      VIA emulation core. Untested, as yet. :-)



0.01  2005/03/08

      Major reworking of Tracey's internals. More efficient, and also
      more modular.

      More status messages.

      Better error handling of 'unusual' conditions.

      Now won't panic if you try to disassemble or dump invalid
      memory, it'll just return &00 each time. This may be important
      as the BIOS could try detecting available RAM by writing a
      specific value to each page, and then seeing if it can be read
      back or not.

      You can use Page Up and Page Down to move up and down the dumped
      memory.

      While idling within Tracey, a clock will be displayed at the top
      right corner. Useful for those long hacking sessions where you
      want to be sure to refill your coffee mug every half hour...

      Undocumented keypress '.' will display Amlie's memory map.



0.01  2005/03/07

      Breakpoints can now be removed individually.

      New option to list the breakpoints. It'll list the first nine.

      Fixed error in on-screen disassembly where 'breakpoint'
      instructions would be 'seen' as single-byte instructions.

      Undocumented extension. If you use the '`' key, you can Quick
      Load and Quick Save the entire state of the emulation (which
      includes Tracey's displays, breakpoints, CPU registers...). This
      allows you to 'save' a session and return to it later.



0.01  2005/03/05

      Added more info to the help screen.

      Pressing '?' now briefly says to press 'H' for help... The '?'
      key redraws the screen, but it is logical that the user might
      think to try it for help.
      The reason why '?' was chosen for redraw is because it is (was?)
      a keypress commonly used on bulletin board services.

      Allocated screen space for VIA and ACIA status.

      Loading data into memory now implemented; though note that it
      will ONLY permit data to be loaded into actual RAM area. The
      default 'base' address is &0400 as the 1K block between &0400
      and &07FF is 'spare' and could be used for downloading code.

      Because you cannot ^Break to enter Tracy while in Borland's IDE,
      I have added Alt-T as a way to get back into Tracy.



0.01  2005/03/04

      Fixed up the flawed timing system (press 'V') with code that
      works. Take the results with a slight pinch of salt as time is
      'spent' converting/comparing the clock ticks. Additionally the
      clock ticks at something bizarre like 18.7 times per second...
      For what it is worth, my 466MHz Celeron machine (in a single
      tasking DOS session) achieves about 66% speed compared to a 2MHz
      6502. The emulation is vanilla C; heavy use of in-line macros
      and assembler would be required to bump up the speed - neither
      of which I have plans to do, by the way...

      As I am now using a machine with a display that works, I have
      redesigned the screen layout to show much more at the one time.
      Yup, I'm now using a 466MHz Celeron machine, instead of that
      25MHz 486 craptop...
      [it WAS a 25MHz 486SX, but I found a 25MHz 486DX and put that
       in and it worked... wasn't noticably faster though... oh well!]



0.01  2004/07/27

      Added a few missing instructions to Tracy's disassembly.

      Added (undocumented) instruction &5B to call Tracy.

      Created (using 6502asm) "opcodes.img" which is a listing of
      ALL of the 6502 instructions, in ALL applicable addressing
      modes. You aren't supposed to run it, use it for testing AmEm.



0.01  2004/07/15

      Fixed bug with addressing mode display in Tracy. It now shows
      the correct mode.

      Added Cursor Up and Cursor Down to step around the disassembly.

      You can now (also) use Alt-X and Alt-F4 (Windows style) to 
      bring up the "Exit?" prompt.

      Some additional code commenting added.



0.01  2004/07/10

      Wrote the speed test routines.

      kbhit() is horribly crufty - does it wait 1us to see if the
      keyboard controller has anything to say? Main loop now only
      looks at the keyboard every 10240 cycles - roughly every half
      second on my 25MHz 486.



0.01  2004/07/09

      Breakpoint system added. Now you can 'add' up to sixteen
      breakpoints. You can't remove them individually right now,
      but you can remove them all at once.
      Updated Tracy's disassembler to show breakpoints in red and
      to show the correct instruction instead of the breakpoint.

      Tracy's display redraw rationalised to reduce flicker. It will
      ALWAYS flicker when single-stepping as we're actually leaving
      Tracy and returning, but for simple stuff like changing a flag,
      we don't need a total redraw!

      Errors no longer call abort(). Instead PC is twiddled back to
      the problem instruction and Tracy is called.

      These stack overflow crashes are annoying - finally traced it
      to a fault within "memory.c". The addressing scheme is rather 
      simplistic. It is SUPPOSED to be seen as:
         &0000 - &17FF   RAM (2K)
         &A000 - &A0FF   VIA
         &A100 - &A1FF   ACIA
         &A200 - &A2FF   Unallocated
         &A300 - &A3FF   Latch
         &F000 - &FFFF   EPROM (4K)
      Our memory decoding ACTUALLY gives us:
         &0000 - &3FFF   RAM (16K)
         &4000 - &9FFF   Unaddressable (24K)
         &A000 - &A0FF   VIA
         &A100 - &A1FF   ACIA
         &A200 - &A2FF   Unallocated
         &A300 - &A3FF   Latch
         &A400 - &BFFF   Other I/O devices (7K)
         &C000 - &FFFF   EPROM (16K)
      This is the 'real' memory map of Amelie. Note that in the real
      hardware there may be 'side effects', such as the first byte of
      RAM being at &0000, &1800, and possibly &3000... This is NOT
      supported in this emulation, and writes outside of the strict
      confines of the memory allocations WILL be faulted.

      Tracy can now update any (legal) memory location, even within 
      ROM - but you'll be asked to confirm this just so you know you
      are doing the impossible! :-)

      Memory handling now returns more errors - writes to ROM are
      faulted, byte read/writes to I/O devices are allowed but word
      read/writes are faulted, etc.

      Swapped byte order for words written to the stack. This is
      probably not of much importance but it allows us to be 
      'correct'.
      Likewise, JSR return addresses are saved minus one as they are
      supposed to be.



0.01  2004/07/08

      Tracy now dumps to disc, fills memory (but it crashes a lot
      with stack overflow). You can also exit from Tracy and let
      AMEM run 'full speed'.
      ^Break handler implemented to return to Tracy at any time.

      In these versions, ESC will do the same (as TurboC uses ^Break
      to return to TurboC!) - but don't rely upon this.

      Calculation of relative addresses fixed.



0.01  2004/07/07

      Put together a tracing system (Tracy) that displays a 
      disassembly, memory, registers, flags - etc. Pressing RETURN
      will step through instruction by instruction.

      Tracy can also alter memory, jump to locations, reset the
      processor, and reload the EPROM image.

      Version set to v0.01 as it now sorta behaves like it should.



0.00  2004/07/06

      First compile in Borland TurboC. Spent much of the time having
      to insert "unsigned int" so it didn't do really stupid things!

      It now claims to execute the EPROM code, but crashes nastily 
      (it seems the EPROM code's offsets are wrong - how did this
      happen? it was assembled within !65Host!)
      The display, a scrolling morass, is awful. I'll HAVE to fix
      this.



0.00  2004/07/05

      What was I thinking!? Vectors used to load in the address and
      call JMP. Stupid, stupid, stupid. Now the vector address is
      pushed directly into PC!

      Addressing mode handler rewritten to sort out the word order.

      Dispatch routine rewritten in C for use with DOS compiler; to
      be honest I wrote a little program to read the assembler code
      and make it into a C switch statement. No doubt it'll be
      horribly inefficient - too bad, it is a 25MHz 486 in my laptop
      so it'll always appear to run in slow motion!



0.00  2004/07/04

      Second half of instruction set written.

      Emulator opcodes added, along with reset/IRQ/FIQ.



0.00  2004/07/03

      First half of the instruction set complete, ADC to LDY. Note
      that no BCD support is provided - it'll return an error.



0.00  2004/07/02

      Instruction 'fetch' loop. ARM code to read addressing mode and
      cycle count from table.
      6502 'core' written, currently empty functions.
      ARM code to dispatch instructions, plus a "paranoid" option to
      make it more APCSish.



0.00  2004/07/01

      Began AMEM project. Wrote simple memory decoding and read/write
      routines.

