diff --git a/20150422.html b/20150422.html
new file mode 100644
index 0000000..4caba3a
--- /dev/null
+++ b/20150422.html
@@ -0,0 +1,82 @@
+
+
20150422 - Source-Less Programming : 2
+
+
+Continuing with what will either be an insanely great or amazingly stupid project...
+
+Making slow progress with bits of free-time after work, far enough thinking through the full editor design to continue building. Decided to ditch 64-bit long mode for 32-bit protected mode. Not planning on using the CPU for much other than driving more parallel friendly hardware... so this is mostly a question of limiting complexity.
+Don't need 16 registers and the REX prefix is too ugly for me to waste time on any more.
+The 32-bit mode uses much more friendly mov reg,[imm32] absolute addressing,
+also with ability to use [EBP+imm32] without an SIB byte (another thing I mostly avoid).
+Unfortunately still need relative addresses for branching.
+32-bit protected mode thankfully doesn't require page tables unlike 64-bit long mode.
+Can still pad out instructions to 32-bits via reduntant segment selectors.
+
+Source-Less Analog to Compile-Time Math?
+
+Compile-time math is mostly for the purpose of self-documenting code:
+"const uint32_t willForgetHowICameUpWithThisNumber = startHere + 16 * sizeof(lemons);".
+The source-less analog is to write out the instructions to compute the value,
+execute that code at edit time, then have anotations
+for 32-bit data words which automatically pull from the result when building 32-bit words for opcode immediates for the new binary image.
+
+Reduced Register Usage Via Self Modifying Code
+
+Sure, kills the trace cache in two ways, what do I care.
+Sometimes the easist way to do something complex is to
+just modify the opcode immediates before calling into the function...
+
+
+What Will Annotations Look Like?
+
+The plan so far is for the editor to display a grid of 8x8 32-bit words.
+Each word is colored according to a tag annotation
+{data, absolute address, relative address, pull value}.
+Each word has two extra associated annotations {LABEL, NOTE}.
+Both are 5 6-bit character strings.
+Words in grid get drawn showing {LABEL, HEX VALUE, NOTE} as follows,
+
+
+LABEL
+00000000
+NOTE
+
+The LABEL provides a name for an address in memory (data or branch address).
+Words tagged with absolute or relative addresses or pull value show in the NOTE field
+the LABEL of the memory address they reference.
+Words tagged with data use NOTE to describe the opcode, or the immediate value.
+Editor when inserting a NOTE can grab the data value from other words
+with the same NOTE (so only need to manually assemble an opcode once).
+Edit-time insert new words, delete words, and move blocks of words,
+all just relink the entire edit copy of the binary image.
+ESC key updates a version number in the edit copy,
+which the excuting copy sees triggering it to replace itself
+with the edit copy.
+
+
+Boot Strapping
+
+I'm bootstrapping the editor in NASM in a way that I'll be able
+to see and edit later at run-time.
+This is a time consuming process to get started
+because instead of using NASM to assemble code,
+I need to manually write the machine code to get the 32-bit padded opcodes.
+Once enough of the editor is ready,
+I need a very tiny IDE/PATA driver to be able to store to the disk image.
+Then I can finish the rest of the editor in the editor.
+Then I'll also be self hosted outside the emulator
+and running directly on an old PC with a non-USB keyboard,
+but with a proper PCIe slot...
+
+
+
+
+
+
+
+
+
+
+
+
+Annotation Encoding
+
+Refined from last post, two 32-bit annotation words per binary image word,
+
+FEDCBA9876543210FEDCBA9876543210
+================================
+00EEEEEEDDDDDDCCCCCCBBBBBBAAAAAA - LABEL : 5 6-bit chr string ABCDE
+
+FEDCBA9876543210FEDCBA9876543210
+================================
+..............................00 - DAT : hex data
+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA01 - GET : get word from address A*4
+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA02 - ABS : absolute address to A*4
+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA03 - REL : relative address to A*4
+
+Going to switch to just 2 lines per word displayed in the editor,
+Only DAT annotations show hex value, other types show LABEL of referenced address
+in the place of the hex value. So no need for an extra note.
+In practice will be using some amount of binary image memory to build up
+a dictionary of DAT words representing all the common somewhat forth like opcodes,
+then GET words in the editor to build up source.
+
+Need to redo the bootloader from floppy to harddrive usage,
+and switch even the bootloader's 16-bit x86 code to 32-bit aligned
+LABEL'ed stuff so the final editor can edit the bootloader.
+Prior was avoiding manually assembling the 16-bit x86 code in the boot loader,
+but might as well ditch NASM and use something else to bootstrap everything.
+
+
+
+
+
+
+Still attempting to fully vet the design
+before the bootstrap reboot...
+
+DAT words in the edit image need to maintain
+their source address in the live image
+This way on reload the live data can be copied over,
+and persistent data gets saved to disk.
+DAT annotations no longer have 30 bits of free space,
+instead they have a live address.
+When live address is zero. then DAT words
+won't maintain live data.
+This way read-only data can be self-repairing
+(as long as the annotations don't get modified).
+Going to use a different color for read-only DAT words.
+New persistent data DAT words
+will reference their edit-image hex value
+before reload (then get updated to the live address).
+
+
+REL words always get changed on reload (self repairing).
+No need to keep the live address.
+REL is only used for relative branching x86 opcodes.
+Don't expect to have any run-time (non-edit-time)
+self-modifying of relative branch addresses.
+Given that branching to a relative branch opcode immedate
+is not useful, the LABEL of a REL word is only useful
+as a comment.
+
+
+GET words also get changed on reload (self repairing).
+GET is only designed for opcodes and labeled constants.
+GET words will often be LABELed as a named branch/call target.
+Been thinking about removing GET, and instead making a new
+self-annotating word (display searches for a LABELed DAT
+word with the same image value, then displays the
+LABEL instead of HEX).
+This opens up the implicit possibility of mis-annotations.
+Would be rare for opcodes given they are large 32-bit values.
+But for annotating things like data structure immediate offsets,
+this will be a problem
+(4 is the second word offset in any structure).
+
+
+ABS words always get changed on reload (self repairing).
+ABS words are targets for self-modifying code/data,
+so they also need LABELs.
+Reset on reload presents a problem in that
+ABS cannot be used to setup persistent data
+unless that persistent data is constant
+or only built/changed in the editor.
+But this limitation makes sense in the context
+that ABS addresses in live data structures
+can get invalidated by moving stuff around in memory.
+The purpose of ABS is edit-time relinking.
+
+
+
+