# HG changeset patch
# User Michael Spacefalcon <msokolov@ivan.Harhan.ORG>
# Date 1366847379 0
# Node ID 3443b1b08af499607000f7a8accd7680c85a0253
# Parent  e0ce45f043c0e1aee34597095b93775ec7efe5e9
boot ROM re: starting to unravel the serial command handling
messed up earlier with some var locations: the darned offsets were decimal

diff -r e0ce45f043c0 -r 3443b1b08af4 bootrom.disasm
--- a/bootrom.disasm	Wed Apr 24 22:48:12 2013 +0000
+++ b/bootrom.disasm	Wed Apr 24 23:49:39 2013 +0000
@@ -90,6 +90,9 @@
      114:	eb000513 	bl	0x1568		; IND_CALL
      118:	eafffffe 	b	0x118
 
+; This routine handles the '<i' command - it initializes the vars
+; starting at 800518.  It is called with R0=0x800518.
+
      11c:	e3a0c004 	mov	r12, #4	; 0x4
      120:	e5c0c000 	strb	r12, [r0]
      124:	e3a0c000 	mov	r12, #0	; 0x0
@@ -99,30 +102,35 @@
      134:	e5c0c018 	strb	r12, [r0, #24]
      138:	e12fff1e 	bx	lr
 
+; This routine at 0x13c apparently generates the serial response messages
+; back to the host, using the buffer at 80010C as its scratchpad.
+; The argument in R0 encodes what type of message to generate:
+
      13c:	e92d4000 	stmdb	sp!, {lr}
      140:	e1a0c000 	mov	r12, r0
-     144:	e59f0cc0 	ldr	r0, [pc, #3264]	; 0xe0c
+     144:	e59f0cc0 	ldr	r0, =0x80010C	; via 0xe0c
      148:	e3a0103e 	mov	r1, #62	; 0x3e
      14c:	e5c01000 	strb	r1, [r0]
      150:	e35c0009 	cmp	r12, #9	; 0x9
      154:	88bd8000 	ldmhiia	sp!, {pc}
      158:	e28f1000 	add	r1, pc, #0	; 0x0
      15c:	e791f10c 	ldr	pc, [r1, r12, lsl #2]
-     160:	000002ac 	andeq	r0, r0, r12, lsr #5
-     164:	00000280 	andeq	r0, r0, r0, lsl #5
-     168:	00000264 	andeq	r0, r0, r4, ror #4
-     16c:	00000248 	andeq	r0, r0, r8, asr #4
-     170:	00000224 	andeq	r0, r0, r4, lsr #4
-     174:	00000200 	andeq	r0, r0, r0, lsl #4
-     178:	000001dc 	ldreqd	r0, [r0], -r12
-     17c:	000001c0 	andeq	r0, r0, r0, asr #3
-     180:	000001a4 	andeq	r0, r0, r4, lsr #3
-     184:	00000188 	andeq	r0, r0, r8, lsl #3
-
-     188:	e3a0c042 	mov	r12, #66	; 0x42
+; switch table, absolute addresses
+     160:	000002ac
+     164:	00000280
+     168:	00000264
+     16c:	00000248
+     170:	00000224
+     174:	00000200
+     178:	000001dc
+     17c:	000001c0
+     180:	000001a4
+     184:	00000188
+; case 9:
+     188:	e3a0c042 	mov	r12, #66	; 0x42 'B'
      18c:	e5c0c001 	strb	r12, [r0, #1]
      190:	e3a01002 	mov	r1, #2	; 0x2
-     194:	e59fcc74 	ldr	r12, [pc, #3188]	; 0xe10
+     194:	e59fcc74 	ldr	r12, =0x800520	; via 0xe10
      198:	e5dc2000 	ldrb	r2, [r12]
      19c:	eb000458 	bl	0x1304
      1a0:	e8bd8000 	ldmia	sp!, {pc}
@@ -225,11 +233,11 @@
 ;   01 = got 'i'
 ;   02 = got 'p', 9 additional bytes received, a bunch of vars filled
 ;   03 = got 'w', the rest of the command read into the buffer at
-;		  80010C, the flag at 80053C set
+;		  80010C, the flag at 800530 set
 ;   04 = got 'c', 1 additional byte received, extended to a half-word
-;		  and written to 80052C
+;		  and written to 800526
 ;   05 = got 'a'
-;   06 = got 'b', 4 bytes written to 800538
+;   06 = got 'b', 4 bytes written to 80052C
 
      2c8:	e92d4ff0 	stmdb	sp!, {r4, r5, r6, r7, r8, r9, r10, r11, lr}
      2cc:	e24dd004 	sub	sp, sp, #4	; 0x4
@@ -258,7 +266,7 @@
      328:	e25cc007 	subs	r12, r12, #7	; 0x7	'w'
      32c:	1a0000fc 	bne	0x724
 ; got 'w'
-; R4=0x800518, byte at 80053C used for something, init to 0
+; R4=0x800518, byte at 800530 used for something, init to 0
      330:	e5c45018 	strb	r5, [r4, #24]
      334:	e3a0a000 	mov	r10, #0	; 0x0
      338:	e3a06000 	mov	r6, #0	; 0x0
@@ -635,7 +643,7 @@
 
      8b4:	e92d4070 	stmdb	sp!, {r4, r5, r6, lr}
      8b8:	e24dd008 	sub	sp, sp, #8	; 0x8
-     8bc:	e59f4560 	ldr	r4, [pc, #1376]	; 0xe24
+     8bc:	e59f4560 	ldr	r4, =0x800108	; via 0xe24
      8c0:	e5d4c000 	ldrb	r12, [r4]
      8c4:	e25cc001 	subs	r12, r12, #1	; 0x1
      8c8:	0a000102 	beq	0xcd8
@@ -898,6 +906,7 @@
      ccc:	e3a0c002 	mov	r12, #2	; 0x2
      cd0:	e5c4c000 	strb	r12, [r4]
      cd4:	ea000048 	b	0xdfc
+; in the initial state, with [800108]==1, control comes here
      cd8:	e250c001 	subs	r12, r0, #1	; 0x1
      cdc:	0a000040 	beq	0xde4
      ce0:	e25cc001 	subs	r12, r12, #1	; 0x1
@@ -965,7 +974,8 @@
      dd8:	e3a0c002 	mov	r12, #2	; 0x2
      ddc:	e5c4c000 	strb	r12, [r4]
      de0:	ea000005 	b	0xdfc
-     de4:	e59f0018 	ldr	r0, [pc, #24]	; 0xe04
+; response to '<i' is handled here
+     de4:	e59f0018 	ldr	r0, =0x800518	; via 0xe04
      de8:	ebfffccb 	bl	0x11c
      dec:	e3a00000 	mov	r0, #0	; 0x0
      df0:	ebfffcd1 	bl	0x13c
diff -r e0ce45f043c0 -r 3443b1b08af4 bootrom.notes
--- a/bootrom.notes	Wed Apr 24 22:48:12 2013 +0000
+++ b/bootrom.notes	Wed Apr 24 23:49:39 2013 +0000
@@ -90,9 +90,15 @@
 800108: byte initialized to 0x01
 80010C: all bytes of a '<w' command after these two command chars
 	are stored starting here
+	this buffer is also used for other scratchpad functions: <p
+	command bytes, all response messages
 80050B: the above buffer ends here
 
+The group of vars starting at 800518 may have been envisioned
+as a struct - see the routine at 0x11c:
+
 800518:	byte variable receives the first parameter byte after '<p'
+	init to 04 by '<i'
 80051C: 32-bit var set by the '<p' command
 800520: byte variable filled every time the 0xfb4 routine is called
 	holds the ID of the UART on which '<' came in, or FF if none
@@ -101,15 +107,19 @@
 800524: byte variable filled every time the 0xfb4 routine is called
 	filled with a copy of 800534
 800525:	byte var set by the '<p' command
+800526: 16-bit var init to 0 by 0x11c ('<i' handler)
+	byte following the '<c' command is extended to a half-word and
+	written here
+800528: 16-bit var init to 0 by 0x11c ('<i' handler)
 
-80052C: byte following the '<c' command is extended to a half-word and
-	written here
+80052C:	32-bit var init to 0 by 0x11c ('<i' handler)
+	word holds the argument of the '<b' command
+800530: byte indicates validity of the received '<w' command:
+	0 means valid, 1 means something bad
+	init to 0 by 0x11c
 
 800534: byte initialized to 0x00, then may be set to 1 by the 0xfb4
 	routine if it selects /1 clock mode.
-800538: word holds the argument of the '<b' command
-80053C: byte indicates validity of the received '<w' command:
-	0 means valid, 1 means something bad
 
 8005C0: appears to be the intended low address (bottom) of the stack
 80074C: top of the stack (initial value loaded into SP)