TODO list for GXemul
====================

Some things, in no specific order, that I'd like to fix:
(Some items in this list are perhaps already fixed.)

-------------------------------------------------------------------------------

0.4.7.2 = maintenance + bugfixes

Tested:
  <li><a href="#netbsdpmaxinstall">NetBSD/pmax 5.0</a>
  <li><a href="#netbsdcatsinstall">NetBSD/cats 5.0</a>
  <li><a href="#netbsdcobaltinstall">NetBSD/cobalt 5.0</a>
  <li><a href="#netbsdevbmipsinstall">NetBSD/evbmips 5.0</a>
  <li><a href="#netbsdsgimips">NetBSD/sgimips 5.0</a>
  <li><a href="#openbsdlandiskinstall">OpenBSD/landisk 4.5</a>
  <li><a href="#openbsdmvme88kinstall">OpenBSD/mvme88k 4.5</a>

Didn't work:
  <li><a href="#netbsdmacppcinstall">NetBSD/macppc 5.0</a>  Some emulated PROM stuff not implemented yet
  <li><a href="#netbsdhpcmipsinstall">NetBSD/hpcmips 5.0</a>  PCMCIA problems
  <li><a href="#netbsdprepinstall">NetBSD/prep 5.0</a>  No disk controller

Not tested:
  <li><a href="#netbsdarcinstall">NetBSD/arc 4.0.1</a>
  <li><a href="#netbsdalgorinstall">NetBSD/algor 3.1</a>
  <li><a href="#netbsdevbarminstall">NetBSD/evbarm 2.1</a>
  <li><a href="#netbsdnetwinderinstall">NetBSD/netwinder 3.1</a>
  <li><a href="#netbsdpmppc">NetBSD/pmppc 3.1</a>
  <li><a href="#netbsdlandiskinstall">NetBSD/landisk 4.0.1</a>
  <li><a href="dreamcast.html#netbsd_generic_md">NetBSD/dreamcast 4.0</a>
  <li><a href="dreamcast.html#linux_live_cd">Linux/dreamcast</a>
  <li><a href="#openbsdpmaxinstall">OpenBSD/pmax 2.8-BETA</a>
  <li><a href="#openbsdcatsinstall">OpenBSD/cats 4.0</a>


0.5.x will be skipped (it was the C++ version that I never had time to write.)


Goals for 0.6.x:

  [ ]   Home page: move to sourceforge!
  	 [ ]  Remove personal references (from the old home page).
  	 [ ]  Go back to C-style c2html browsable tree.
  	 [ ]  How to deal with SVN?

  [ ]   Maybe remove some unused/nonworking devices/machines?

  [ ]   Make everything build with make -j X.
  
  [ ]	Overhaul of the device framework: break out memory busses! This
  	would (in the best case) allow a correct implementation of e.g. PCI,
  	and cache emulation! :-)  Ideal solution would be if all devices
  	were runtime attachable/removable, and if there was a fast path for
  	device access (virtual memory page => immediate device function call).


-------------------------------------------------------------------------------

To be translated prefetch:
	o)  ONLY do this when able to read directly from memory
	    pages, NOT when running via a slow device!

M88K:
	o)  MVME187:
		o)  disk bootblock boot
		o)  ethernet
	o)  PERFORMANCE!
	o)  cpu_dyntrans.c: MEMORY_USER_ACCESS implementation for M88K!
	    Currently, user memory accesses are not entered into the
	    translation caches, which result in extremely poor performance.
	    Also, the entire translation cache is thrown away on user/supervisor
	    mode switches, which (I guess) makes e.g. syscalls quite
	    expensive.
	o)  xmem: Set transaction registers!
	o)  CMMUs:
		o)  Translation invalidations, could be optimized.
		o)  Move initialization from dev_mvme187 to somewhere
		    more reasonable?
	o)  Instruction trace by using bits of ??IP control regs.
	o)  Breakpoints: How to indicate user space vs supervisor? (Also the
	    "dump" instruction and other things need this support.)
	o)  Instruction disassembly, and implementation:
		o)  See http://www.panggih.staff.ugm.ac.id/download/GCC/info/gcc.i5
		    for some strange cases of when "div" can fail (?)
		o)  Floating point stuff:
			+) Refactor all the fsub, fadd, fmul etc. They
			   are currently quite horribly redundant.
			+) Exceptions for overflow etc!
		o)  88110-specific instructions, e.g. "graphics" instructions

MIPS:
	o)  Nicer MIPS status bits in register dumps.
	o)  Floating point exception correctness.
	o)  Fix this? Triggered by NetBSD/sgimips? Hm:
		to_be_translated(): TODO: unimplemented instruction:
		000000000065102c: 00200800 (d)  rot_00  at,zr,0
	o)  Some more work on opcodes.
		x) MIPS64 revision 2.
			o)  Find out which actual CPUs implement the rev2 ISA!
			o)  DINS, DINSM, DINSU etc
			o)  DROTR32 and similar MIPS64 rev 2 instructions,
			    which have a rotation bit which differs from
			    previous ISAs.
		x) _MAYBE_ TX79 and R5900 actually differ in their
		   opcodes? Check this carefully!
	o)  Dyntrans: Count register updates are probably not 100% correct yet.
	o)  (Re)implement 128-bit loads/stores for R5900.
	o)  Coprocessor 1x (i.e. 3) should cause cp1 exceptions, not 3?
		(See http://lists.gnu.org/archive/html/qemu-devel/2007-05/msg00005.html)
	o)  R4000 and others:
		x)  watchhi/watchlo exceptions, and other exception
		    handling details
	o)  MIPS 5K* have 42 physical address bits, not 40/44?
	o)  R10000 and others:  (R12000, R14000 ?)
		x)  The code before the line
			/*  reg[COP0_PAGEMASK] = cpu->cd.mips.coproc[0]->tlbs[0].mask & PAGEMASK_MASK;  */
		    in cpu_mips.c is not correct for R10000 according to
		    Lemote's Godson patches for GXemul. TODO: Go through all
		    register definitions according to http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/hdwr/bks/SGI_Developer/books/R10K_UM/sgi_html/t5.Ver.2.0.book_263.html#HEADING334
		    and make sure everything works with R10000.
		    Then test with OpenBSD/sgi?
		x)  Entry LO mask (as above).
		x)  memory space, exceptions, ...
		x)  use cop0 framemask for tlb lookups
		    (http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/hdwr/bks/SGI_Developer/books/R10K_UM/sgi_html/t5.Ver.2.0.book_284.html)
	o)  Playstation 2 with NetBSD? Perhaps USB keyboard is a big step
	    on the way to running the whole OS. (?)

SuperH:
	x)  Auto-generation of loads/stores! This should get rid of at least
	    the endianness check in each load/store.
	x)  Experiment with whether or not correct ITLB emulation is
	    actually needed. (20070522: I'm turning it off today.)
	x)  SH4 interrupt controller:
		x)  MASKING should be possible!
	x)  SH4 UBC (0xff200000)
	x)  SH4 DMA (0xffa00000): non-dreamcast-PVR modes
	x)  Store queues can copy 32 bytes at a time, there's no need to
	    copy individual 32-bit words. (Performance improvement.)
	    (Except that e.g. the Dreamcast TA currently receives using
	    32-bit words... hm)
	x)  SH4 BSC (Bus State Controller)
	x)  Instruction tracing should include symbols for branch targets,
	    and so on, to make the output more human readable.
	x)  SH3-specific devices: Pretty much everything!
	x)  NetBSD/evbsh3, hpcsh! Linux?
	x)  Floating point speed!
	x)  Floating point exception correctness.
		E.g. fipr and the other "geometric" instructions should
		throw an exception if the "precision" bit is wrong
		(since the geometric instructions loose precision).
		See the manual about this!
	x)  Exceptions for unaligned load/stores. OpenBSD/landisk uses
	    this mechanism for its reboot code (machine_reset).

Dreamcast:
	x)  Try to make the ROM from my real Dreamcast boot.
	x)  PVR:  Lots of stuff. See dev_pvr.c.
		x)  DMA to non-0x10000000
		x)  Textures...
		x)  Make it fast! if possible
	x)  G2 DMA
	x)  SPU: Sound emulation (ARM cpu).
	x)  LAN adapter (dev_mb8696x.c).  NetBSD root-on-nfs.
	x)  Better GDROM support
	x)  Modem
	x)  PCI bridge/bus?
	x)  Maple bus:
		x)  Correct controller input
		x)  Mouse input
	x)  Software emulation of BIOS calls:
		x)  GD-ROM emulation: Use the GDROM device.
		x)  Use the VGA font as a fake ROM font. (Better than
		    nothing.)
	x)  Make as many as possible of the KOS examples run!
	x)  More homebrew demos/games.
	x)  VME processor emulation? "(Sanyo LC8670 "Potato")" according to
	    Wikipedia, LC86K87 according to Comstedt's page. See
	    http://www.maushammer.com/vmu.html for a good description of
	    the differences between LC86104C and the one used in the VME.

Alpha:
	x)  OSF1 PALcode, Virtual memory support.
	x)  PALcode replacement! PAL1E etc opcodes...?
	x)  Interrupt/exception/trap handling.
	x)  Floating point exception correctness.
	x)  More work on bootup memory and register contents.
	x)  More Alpha machine types, so it could work with
	    OpenBSD, FreeBSD, and Linux too?

SPARC (both the ISA and the machines):
	o)  Implement Adress space identifiers; load/stores etc.
	o)  Exception/trap/interrupt handling.
	o)  Save/restore register windows etc! Both v9 and pre-v9!
	o)  Finish the subcc and addcc flag computation code.
	o)  Add more registers (floating point, control regs etc)
	o)  Disassemly of some more instructions?
	o)  Are sll etc 32-bit sign-extending or zero-extending?
	o)  Floating point exception correctness.
	o)  SPARC v8, v7 etc?
	o)  More machine modes and devices.

POWER/PowerPC:
	x)  Fix DECR timer speed, so it matches the host.
	x)  NetBSD/prep 3.x triggers a possible bug in the emulator:
	    <wdc_exec_command(0xd005e514,0xd60cdd30,0,8,..)>
	      <ata_get_xfer(0,0xd60cdd30,0,8,..)>
	        <0x26c550(&ata_xfer_pool,2,0,8,..)>
	        <0x35c71c(0x3f27000,0,52,8,..)>
	      <ata_exec_xfer(0xd005e4c8,0x3f27000,0,13,..)>
	        <atastart(0xd005e4c8,0x3f27000,0,13,..)>
	          <__wdccommand_start(0xd005e4c8,0x3f27000,0,13,..)>
	            <bsw1(&prep_isa_io_space_tag,0x800001f6,0,176,..)>
		[ wdc: write to SDH: 0xb0 (sectorsize 2, lba=1, drive 1, head 0) ]
	            <wdcwait(0xd005e4c8,72,64,0xbb8,..)>
	              <0x198120(0xd005e4c8,72,64,0xbb8,..)>
	                <bsr1(&prep_isa_io_space_tag,0,0,0xbb8,..)>
	                <delay(100,0,0,0xbb8,..)>
	    Note: <bsr1(&prep_isa_io_space_tag,0,0,0xbb8,..)>
	x)  PPC optimizations; instr combs
	x)  64-bit stuff: either Linux on G5, or perhaps some hobbyist
		version of AIX? (if there exists such a thing)
	x)  macppc: adb controller; keyboard (for framebuffer mode)
	x)  make OpenBSD/macppc work (PCI controller stuff)
	x)  Floating point exception correctness.
	x)  Alignment exceptions.

PReP:
	x)  Clock time! ("Bad battery blah blah")

Algor:
	o)  Other models than the P5064?
	o)  PCI interrupts... needed for stuff like the tlp NIC?

BeBox:
	o)  Interrupts. There seems to be a problem with WDC interrupts
	    "after a short while", although a few interrupts get through?
	o)  Perhaps find a copy of BeOS and try it?

Malta:
	o)  The Linux/Malta kernel at people.debian.org/~ths/qemu/malta/
	    almost works:
		./gxemul -x -o 'rd_start=0x80800000 rd_size=10000000 init=/bin/sh' -C 4KEc
		  -e malta 0x80800000:people.debian.org/~ths/qemu/malta/initrd.gz 
		  people.debian.org/~ths/qemu/malta/vmlinux
	    (Remove "init=/bin/sh" to boot into the Debian installer.)
	    There are at least two things that need to be fixed:
		1. PCI IDE; make Linux oops.
		2. Implement the NIC.

SGI O2:
	Play around with the SGI O2 PROM image again, from the real O2.

	0.3.7: Ok, starts up with graphics (_IF_ the cache detection is skipped)

	20051112: Ok with graphics
	20051127: Ok
	20051201: Ok			<-- Somewhere between 20051201 and 20051203
	20051203: Not work.		    I apparently lost the graphical boot
	20051211: Does NOT work.

	0.3.8: Boots but switches to serial console ("could not open console") (also with
	       cache detection skipped manually)
	0.4.0: The cache detection breakpoint is not triggered :(

HPCmips:
	x)  Mouse/pad support! :)
	x)  A NIC? (As a PCMCIA device?)

ARM:
	o)  See netwinder_reset() in NetBSD; the current "an internal error
	    occured" message after reboot/halt is too ugly.
	o)  Generic ARM "wait"-like instruction?
	o)  try to get netbsd/evbarm 3.x or 4.x running (iq80321)
	o)  netbsd/iyonix? the i80321 device currently tells netbsd that
	    RAM starts at 0xa0000000, but that is perhaps not correct for the
	    iyonix.
	o)  make the xscale counter registers (ccnt) work
	o)  make the ata controller usable for FreeBSD!
	o)  Debian/cats crashes because of unimplemented coproc stuff.
	    fix this?

M32R:
	o)  Everything.
	o)  /home/debug/emul/m32r/linux-2.6.14.6-20060127-revE.root/boot/vmlinux-2.6.14.6-20060127-revE

Test machines:
	o)  dev_fb 2D acceleration functions, to make dev_fb useful for
	    simple graphical OSes:
		x) block fill and copy
		x) draw characters (from the built-in font)?
	o)  dev_fb input device? mouse pointer coordinates and buttons
		(allow changes in these to cause interrupts as well?)
	o)  Redefine the halt() function so that it stops "sometimes
	    soon", i.e. usage in demo code should be:
		for (;;) {
			halt();
		}
	o)  More demos/examples.

Debugger:
	o)  How does SMP debugging work? Does it simply use "threads"?
	    What if the guest OS (running on an emulated SMP machine)
	    has a usertask running, with userland threads?
	o)  Count reads/writes to memory areas, for statistics and breakpoints!
	    (Don't insert those pages into the fast load/store lookup tables,
	    or course.)
	o)  Try to make the debugger more modular and, if possible, reentrant!
	o)  Memory dumps should be able to dump both physical and
	    virtual emulated memory.
	o)  Evaluate expressions within []? That would allow stuff like
	    cpu[x] where x is an expression.
	o)  "pc = pc + 4" doesn't work! Bug. Should work. ("pc=pc+4" works.)
	o)  Settings:
		x)  Special handlers for Write!
			+)  MIPS coproc regs
			+)  Alpha/MIPS/SPARC zero registers
			+)  x86 64/32/16-bit registers
		x)  Value formatter for resulting output.
	o)  Call stack display (back-trace) of emulated programs.
	o)  Nicer looking output of register dumps, floating point registers,
	    etc. Warn about weird/invalid register contents.
	o)  Ctrl-C doesn't enter the debugger on some OSes (HP-UX?)...

Dyntrans:
	x)  For 32-bit emulation modes, that have emulated TLBs: tlbindex
	    arrays of mapped pages? Things to think about:
		x)  Only 32-bit mode! (64-bit => too much code)
		x)  One array for global pages, and one array _PER ASID_,
		    for those archs that support that. On M88K, there should
		    be one array for userspace, and one for supervisor, etc.
		x)  Larger-than-4K-pages must fill several bits in the array.
		x)  No TLB search will be necessary.
		x)  Total host space used, for 4 KB pages: 1 MB per table,
		    i.e. 65 MB for 32-bit MIPS, 2 MB for M88K, if one byte
		    is used as the tlb index.
		x)  (The index is actually +1, so that 0 means no hit.)
	x)  "Merge" the cur_physpage and cur_ic_page variables/pointers to
	    one? I.e. change cur_ic_page to cur_physpage.ic_page or something.
	x)  Instruction combination collisions? How to avoid easily...
	x)  superh -- no hostpage for e.g. 0x8c000000. devices as ram!
	x)  Think about how to do both SHmedia and SHcompact in a reasonable
	    way! (Or AMD64 long/protected/real, for that matter.)
	x)  68K emulation; think about how to do variable instruction
	    lengths across page boundaries.
	x)  Dyntrans with valgrind-inspired memory checker. (In memory_rw,
	    it would be reasonably simple to add; in each individual fast
	    load/store routine = a lot more work, and it would become
	    kludgy very fast.)
	x)  Dyntrans with SMP... lots of work to be done here.
	x)  Dyntrans with cache emulation... lots of work here as well.
	x)  Remove the concept of base RAM completely; it would be more
	    generic to allow RAM devices to be used "anywhere".
	o)  dev_mp doesn't work well with dyntrans yet
	o)  In general, IPIs, CAS, LL/SC etc must be made to work with dyntrans
	x)  Redesign/rethink the delay slot mechanism used for e.g. MIPS,
		so that it caches a translation (that is, an instruction
		word and the instr_call it was translated to the last
		time), so that it doesn't need to do slow
		to_be_translated for each end of page?
	x)  Program Counter statistics:
		Per machine? What about SMP? All data to the same file?
		A debugger command should be possible to use to enable/
		disable statistics gathering.
		Configuration file option!
	x)  Breakpoints:
		o) Physical vs virtual addresses!
		o) 32-bit vs 64-bit sign extension for MIPS, and others?
	x)  INVALIDATION should cause translations in _all_ cpus to be
	    invalidated, e.g. on a write to a write-protected page
	    (containing code)
	x)  16-bit encodings? (MIPS16, ARM Thumb, etc)
	x)  Lots of other stuff: see src/cpus/README_DYNTRANS
	x)  Native code generation backends... think carefully about this.

Simple Valgrind-like checks?
	o)  Mark every address with bits which tell whether or not the address
	    has been written to.
	o)  What should happen when programs are loaded?  Text/data, bss (zero
	    filled). But stack space and heap is uninitialized.
	o)  Uninitialized local variables:
		A load from a place on the stack which has not previously
		been stored to => warning. Increasing the stack pointer using
		any available means should reset the memory to uninitialized.
	o)  If calls to malloc() and free() can be intercepted:
		o)  Access to a memory area after free() => warning.
		o)  Memory returned by malloc() is marked as not-initialized.
		o)  Non-passive, but good to have: Change the argument
		    given to malloc, to return a slightly larger memory
		    area, i.e.  margin_before + size + margin_after,
		    and return the pointer  + margin_before.
		    Any access to the margin_before or _after space results
		    in warnings. (free() must be modified to free the
		    actually allocated address.)

Better CD Image file support:
	x)  Support CD formats that contain more than 1 track, e.g.
	    CDI files (?). These can then contain a mixture of e.g. sound
	    and data tracks, and booting from an ISO filesystem path
	    would boot from [by default] the first data track.
	    (This would make sense for e.g. Dreamcast CD images, or
	    possibly other live-CD formats.)

Networking:
	x)  Redesign of the networking subsystem, at least the NAT translation
		part. The current way of allowing raw ethernet frames to be
		transfered to/from the emulator via UDP should probably be
		extended to allow the frames to be transmitted other ways as
		well.
	x)  Also adding support for connecting ttys (either to xterms, or to
		pipes/sockets etc, or even to PPP->NAT or SLIP->NAT :-).
	x)  Documentation updates (!) are very important, making it easier to
		use the (already existing) network emulation features.
	x)  Fix performance problems caused by only allowing a
	    single TCP packet to be unacked.
	x)  Don't hardcode offsets into packets!
	x)  Test with lower than 100 max tcp/udp connections,
	    to make sure that reuse works!
	x)  Make OpenBSD work better as a guest OS!
	x)  DHCP? Debian doesn't actually send DHCP packets, even
		though it claims to? So it is hard to test.
	x)  Multiple networks per emulation, and let different
	    NICs in machines connect to different networks.
	x)  Support VDE (vde.sf.net)? Easiest/cleanest (before a
	    redesign of the network framework has been done) is
	    probably to connect it using the current (udp) solution.
	x)  Allow SLIP connections, possibly PPP, in addition to
	    ethernet?

Cache simulation:
	o)  Command line flags for:
		o)  CPU endianness?
		o)  Cache sizes? (multiple levels)
	o)  Separate from the CPU concept, so that multi-core CPUs sharing
	    e.g. a L2 cache can be simulated (?)
	o)  Instruction cache emulation is easiest (if separate from the
	    data cache); similar hack as the S;I; hack in cpu_dyntrans.c.
	    NOTE: if the architecture has a delay slot, then an instruction
	    slot can actually be executed as 2 instructions.
	o)  Data cache emulation = harder; each arch's load/store routines
	    must include support? running one instruction at a time and
	    having a cpu-dependant lookup function for each instruction
	    is another option (easier to implement, but very very slow).

Documentation:
	x)  Update the documentation regarding the testmachine interrupts.
	x)  Note about sandboxing/security:
		Not all emulated instructions fail in the way they would
		do on real hardware (e.g. a userspace program writing to
		a system register might work in GXemul, but it would
		fail on real hardware).  Sandbox = contain from the
		host OS. But the emulated programs will run "less
		securely".
	x)  Try NetBSD/arc 4.x! (It seems to work with disk images!)
	x)  NetBSD/pmax 4 install instructions: xterm instead of vt100!
	x)  Rewrite the section about experimental devices, after the
	    framebuffer acceleration has been implemented, and demos
	    written. (Symbolic names instead of numbers; example
	    use cases, etc. Mention demo files that use the various
	    features?)
	x)  "a very simple linear framebuffer device (for graphics output)"
	    under "which machines does gxemul emulate" ==> better
	    description?

The Device subsystem:
	x)  allow devices to be moved and/or changed in size (down to a
	    minimum size, etc, or up to a max size); if there is a collision,
	    return false. It is up to the caller to handle this situation!
	x)  NOTE: Translations must be invalidated, both for
	    registering new devices, and for moving existing ones.
	    cpu->invalidate translation caches, for all CPUs that
	    are connected to a specific memory.

PCI:
	x)  Pretty much everything related to runtime configuration, device
	    slots, interrupts, etc must be redesigned/cleaned up. The current
	    code is very hardcoded and ugly.
	o)  Allow cards to be added/removed during runtime more easily.
	o)  Allow cards to be enabled/disabled (i/o ports, etc, like
	    NetBSD needs for disk controller detection).
	o)  Allow devices to be moved in memory during runtime.
	o)  Interrupts per PCI slot, etc. (A-D).
	o)  PCI interrupt controller logic... very hard to get right,
	    because these differ a lot from one machine to the next.
	x)  last write was ffffffff ==> fix this, it should be used
	    together with a mask to get the correct bits. also, not ALL
	    bits are size bits! (lowest 4 vs lowest 2?)
	x)  add support for address fixups
	x)  generalize the interrupt routing stuff (lines etc)

Clocks and timers:
	x)  Fix the PowerPC DECR interrupt speed! (MacPPC and PReP speed, etc.)
	x)  DON'T HARDCODE 100 HZ IN cpu_mips_coproc.c!
	x)  NetWinder timeofday is incorrect! Huh? grep -R for ta_rtc_read in
	    NetBSD sources; it doesn't seem to be initialized _AT ALL_?!
	x)  Cobalt TOD is incorrect!
	x)  Go through all other machines, one by one, and fix them.

Config file parser:
	o)  Rewrite it from scratch!
	o)  Usage of any expression available through the debugger
	o)  Allow interrupt controllers to be added! and interrupts
	    to be used in more ways than before
	o)  Support for running debugger commands (like the -c
	    command line option)

Floating point layer:
	o)  make it common enough to be used by _all_ emulation modes
	o)  implement correct error/exception handling and rounding modes
	o)  implement more helper functions (i.e. add, sub, mul...)
	o)  non-IEEE modes (i.e. x86)?

Userland emulation:
	x)  Try to prefix "/emul/mips/" or similar to all filenames,
	    and only if that fails, try the given filename.
            Read this setting from an environment variable, and only
            if there is none, fall back to hardcoded string.
	x)  File descriptor (0,1,2) assumptions? Find and fix these?
	x)  Dynamic linking!
	x)  Lots of stuff; freebsd, netbsd, linux, ... syscalls.
	x)  Initial register/stack contents (environment, command line args).
	x)  Return value (from main).
	x)  mmap emulation layer
	x)  errno emulation layer
	x)  ioctl emulation layer for all devices :-[
	x)  struct conversions for many syscalls

Sound:
	x)  generic sound framework
	x)  add one or more sound cards as devices; add a testmachine
	    sound card first?
	x)  Dreamcast sound? Generic PCI sound cards?

ASC SCSI controller:
	x)  NetBSD/arc 2.0 uses the ASC controller in a way which GXemul
	    cannot yet handle. (NetBSD 1.6.2 works ok.) (Possibly a problem
	    in NetBSD itself, http://mail-index.netbsd.org/source-changes/
	    2005/11/06/0024.html suggests that.)
	    NetBSD 4.x seems to work? :)

Caches / memory hierarchies: (this is mostly MIPS-specific)
	o)  src/memory*.c: Implement correct cache emulation for
	    all CPU types. (currently only R2000/R3000 is implemented)
	    (per CPU, multiple levels should be possible, associativity etc!)
	o)  R2000/R3000 isn't _100%_ correct, just almost correct :)
	o)  Move the -S (fill mem with random) functionality into the
	    memory.c subsystem, not machine.c or wherever it is now
	o)  ECC stuff, simulation of memory errors?  (Machine dependent)
	o)  More than 4GB of emulated RAM, when run on a 32-bit host?
	    (using manual swap-out of blocks to disk, ugly)
	o)  A global command line option should be used to turn
	    cache emulation on or off. When off, caches should be
	    faked like they are right now. When on, caches and
	    memory latencies should be emulated as correctly as
	    possible.

File/disk/symbol handling:
	o)  Make sure that disks can be added/removed during runtime!
	    (Perhaps this needs a reasonably large re-write.)
	o)  Remove some of the complexity in file format guessing, for
		Ultrix kernels that are actually disk images?
	o)  Remove temporary files (/tmp/gxemul.blahblah) if loading fails
	    for some reason (unrecognized file, etc).
	o)  Better handling of tape files	
	o)  Read function argument count and types from binaries? (ELF?)
	o)  Better demangling of C++ names. Note: GNU's C++ differs from e.g.
	    Microsoft's C++, so multiple schemes must be possible. See
	    URL at top of src/symbol_demangle.c for more info.

Userland ABI emulation:
	o)  see src/useremul.c

Better framebuffer and X-windows functionality:
	o)  Do a complete rewrite of the framebuffer/console stuff, so that:
		1)  It does not rely on X11 specifically.
		2)  It is possible to interact with emulated framebuffers
		    and consoles "remotely", e.g. via a web page which
		    controls multiple virtualized machines.
		3)  It is possible to run on (hypothetical) non-X11
		    graphics systems.
	o)  Generalize the update_x1y1x2y2 stuff to an extend-region()
	    function...
	o)  -Yx sometimes causes crashes.
	o)  Simple device access to framebuffer_blockcopyfill() etc,
	    and text output (using the built-in fonts), for dev_fb.
	o)  CLEAN UP the ugly event code
	o)  Mouse clicks can be "missed" in the current system; this is
	    not good. They should be put on a stack of some kind.
	o)  More 2D and 3D framebuffer acceleration.
	o)  Non-resizable windows?  Or choose scaledown depending
		on size (and center the image, with a black border).
	o)  Different scaledown on different windows?
	o)  Non-integral scale-up? (E.g. 640x480 -> 1024x768)
	o)  Switch scaledown during runtime? (Ala CTRL-ALT-plus/minus)
	o)  Bug reported by Elijah Rutschman on MacOS with weird
	    keys (F5 = cursor down?).
	o)  Keyboard and mouse events:
		x)  Do this for more machines than just DECstation
		x)  more X11 cursor keycodes
		x)  Keys like CTRL, ALT, SHIFT do not get through
		    by themselves (these are necessary for example
		    to change the font of an xterm in X in the
		    emulator)
	o)  Generalize the framebuffer stuff by moving _ALL_ X11
		specific code to a separate module.

C++:
	o)  SLOWLY try to convert the code from C to C++. What will this
	    achieve? Well, one of the absolutely biggest problems in
	    GXemul so far (in C) is that it has not been written in a
	    way which would allow the following things:

		x)  Adding and removing devices during runtime.
		    This is hindered by the fact that the C code is
		    written in a "construct only" kind of way, with no
		    "destructors". It will be much easier to achieve this
		    in C++ than having to rewrite EVERYTHING in C to
		    use destructors.

		x)  Serializing/deserializing a snapshot of the entire
		    emulation to a file (which in the long run would
		    allow things like "live migration").
		    This will be much easier in C++ than in C.

		x)  Allowing multiple _DIFFERENT_ CPU architectures per
		    machine, and different cache configurations and
		    busses.
		    Also possible with C, but will be easier with C++.
		    (Already tried some of it in the experimental C++
		    branch.)
		    Example: Dreamcast has both an SH4 and an ARM cpu.

		x)  Controlled abort, when something fails. The C code
		    right now is unable to use somthing similar to
		    "exceptions", which would be good to abort emulation
		    e.g. when something unimplemented is attempted.

	    But for the future, it would also allow the code to be
	    more easily maintained. Hopefully some of the template magic
	    (which currently consists of programs creating temporary
	    C files which are compiled into the program) can be replaced
	    by native C++ templates instead.

Release checklist:
	README
	RELEASE NOTES
	Send SVN dump to Sourceforge
	Tarball creation
	Sourceforge file release
	Home page update: version numbers
	Home page News page update
	#GXemul (version number in topic)
	gxemul-users mail
	Freshmeat
	Wikipedia page (version number and date)
	Send mail to package maintainers (if they are not subscribed
		to the mailing list(s))
	If new arch:
		Wikipedia page
		Linux-MIPS wiki page
		Ohloh description page
		gavare.se main page
		GXemul web main page
		CV
	Graph: Release timeline (date on x axis, including release numbers,
		and comments for major new features).


-------------------------------------------------------------------------------

