In a previous post, I got Unicode text rendering, complete with line breaking, emojis and a pile of other stuff working, that means we can show message threads.
Now we need to refactor that out into some thing more usable, and add the missing bits. Like being able to type a message, hit send, have a functional scroll-bar etc.
Then we'll have almost an entire working SMS system, sans talking to the actual cellular module -- which I really should finally hook up and test.
Let's start with refactoring this stuff out into smsscreens.c
I'd also like proper working scroll bars. After a bit of thought, I decided to use H640 multi-colour sprites that are full height (the VIC-IV in the MEGA65 lets you change the height of sprites, so that you don't need to use a multiplexer). That way I can have one colour for the background of the scroll area, and another for the foreground.
Done this way, the scroll bar implementation becomes embarrassingly simple:
char draw_scrollbar(unsigned char sprite_num,
unsigned int start,
unsigned int end,
unsigned int total)
{
unsigned char first;
unsigned char last;
unsigned long temp;
if (!total) total=1;
if (start>total) start=0;
if (end>total) end=total;
temp = start<<8;
temp /= total;
first = temp;
temp = end<<8;
temp /= total;
last = temp;
lfill(0xf100 + (sprite_num*0x300), 0x55, 0x300);
lfill(0xf100 + (sprite_num*0x300) + first*3, 0xAA, (last-first+1)*3);
return 0;
}
So let's now implement simple scrolling through the message thread using the cursor keys, and show the current scroll region... And it works :) The main issue is that it's quite slow to draw at the moment, because I haven't optimised anything. That's totally fine for now.
And a video showing just how slow it is:
Okay, so that's the display of the messages working. Next stop is letting you type and edit a message. I'm not going to allow up and down cursor keys to navigate the message draft: Those will still scroll the thread up and down. Left and right we will make work, though. And any general key press will do what it should. Backspace will work. RETURN will be for send. For simplicity, we'll probably just always show the message edit box at the bottom. For now, I'll make it black on light grey, so that it's easy to tell apart from the message thread above.
Unicode entry (e.g., for emoji) is something that I have yet to solve. It's all a bit complicated because we can only have 512 unique glyphs on the screen at a time, because of our limited glyph buffer size. What I might end up doing later is having an emoji/special character entry button that hides the SMS thread display, and just has an emoji/unicode point chooser, and when you select one, it passes it back to the editor that called it. That will probably be a separate helper program, because of the code size it will entail. It's also not on the critical path for demonstrating core functionality, so I'm not going to let myself be distracted by it.
Okay, so let's add this message drafting box. Ah, that reminds me: the way I draw multi-line strings like this, I can't tell it to fill a certain number of lines. So I'll just make it take the space it needs, and it will grow as required, and trigger a re-draw of the whole screen if the number of lines in the message draft change. I'm also not yet sure how I'll handle the cursor. I might make it a special dummy character in the string (possibly just a | character, since it looks sufficiently cursor-ish).
Well, I continue to be pleased with the architecture I've laid down for this. It's not perfect, as we have those things I've describe above that we'll need to do. Nonetheless, I've been able to quickly plumb in the ability to do simple message drafting, complete with cursor key navigation, backspace, and because it's a C64-type machine, shift+HOME clears the message draft.
In short, we have all the ingredients ready, right up to the point where we need to add the message to the thread to simulate sending it, and then also send it to the cellular modem.
To finish that off, I'll need a routine to write to a record in the D81 from on native hardware. That shouldn't be too hard. Then we can try to actually plumb it into the cellular communications stuff.
To test the saving and restoring of SMS drafts, I've added the bit of code necessary to read any saved draft, still using our horrible but adequate hack of using a | character as the cursor:
// Read last record in disk to get any saved draft
read_record_by_id(0,USABLE_SECTORS_PER_DISK -1, buffers.textbox.draft);
buffers.textbox.draft_len = strlen(buffers.textbox.draft);
buffers.textbox.draft_cursor_position = strlen(buffers.textbox.draft) - 1;
// Reposition cursor to first '|' character in the draft
// XXX - We really need a better solution than using | as the cursor, but it works for now
for(position = 0; position<buffers.textbox.draft_len; position++) {
if (buffers.textbox.draft[position]=='|') {
buffers.textbox.draft_cursor_position = position;
break;
}
}
Then all we need to do is to write that record back whenever we modify the draft message:
// Update saved draft in the D81
write_record_by_id(0,USABLE_SECTORS_PER_DISK -1, buffers.textbox.draft);
That should be all we need, once I have a working write_sector() routine. Which I think I have implemented now, but the draft message is notably not being restored when I re-run the program. So something is going wrong.
The FDC busy flag strobes when requesting the write, so it seems like it should be working. I've also confirmed that the buffer contents looks correct as it's being written.
Okay, I can actually confirm that it's being written to the sector on the D81. So why isn't it being loaded properly when the SMS thread is loaded? The read sector call is failing is the reason. So why is it failing? We know it works in the general case? Is our record number too high, causing an invalid read?
Found the problem -- I wasn't mounting the disk image before reading the message draft :) With that fixed, it now retrieves the draft message on start-up. Nice!
So in principle, I should be able to now implement the "send message" function of hitting return by:
1. Building an "outgoing" SMS message.
2. Allocating the next free record and writing it to it.
3. Shifting the scroll position in the thread to the new end of the thread.
4. Clear the draft message.
5. Redraw the thread.
We'll ignore what to do if the message thread is over-filled, and just silently fail.
The good news is that we have all the functions we need to do this already, as this is just replicating what the import utility does when populating these message threads.
So let's start with forming the outgoing SMS message and logging it. It turns out that the sms_log() function does both 1 and 2. All it needs is the phone number the message is being sent to. It's a little inefficient, in that it does the search for the contact that matches the phone number, instead of just slotting it into the current contact. I might refactor that out, both for speed, and to stop messages being logged against the wrong contact if multiple contacts have the same phone number.
Hmm... the program is crashing now. I wonder if I haven't stomped over some RAM somewhere. I've had this before, where CC65 compiled programs go wonky on me when I hit memory limits.
I really have been using CC65 for this out of habit, but perhaps this is time to try one of the other MEGA65 supported compilers. Like LLVM-MOS.
I built and installed llvm-mos like this:
$ git clone https://github.com/llvm-mos/llvm-mos.git
$ cd llvm-mos
$ cmake -C clang/cmake/caches/MOS.cmake -G Ninja -S llvm -B build
$ cd build
$ ninja
$ cd ..
$ ninja -C build install-distribution
$ cd ..
$ git clone https://github.com/llvm-mos/llvm-mos-sdk.git
$ cd llvm-mos-sdk
$ mkdir build && cd build
$ cmake -G Ninja .. -DCMAKE_INSTALL_PREFIX=/usr/local # or $HOME/opt/llvm-mos
$ sudo ninja install
With that I should be able to use the same build setup as in GRAZE.
I've got it compiling now, but it's not working correctly, so I have to go through and debug whatever issues the switch to LLVM have caused. On the plus side, with optimisation enabled, the LLVM compiled program is only about 30KB, which is a significant improvement on CC65 -- even if I suspect it's mostly link-time optimisation, i.e., leaving out functions that don't ever get called. But if it still makes the difference between works and doesn't work, then that's fine by me.
This comes back to a recurring problem that I have with debugging this kind of thing: If the error occurs within nested function calls, then I initially can only detect the outer most error, which is probably just because some inner thing failed. When I'm cross-compiling, I have a fatal() macro that reports the failure tree. But for native builds I don't have that doing anything useful, because the screen gets all messed up, and because the code takes up space. But with LLVM, we have a bit more space available to us again.
We do have the serial monitor interface available to us, though. Or even just dumping stuff into RAM somewhere magic for later extraction. The MEGAphone software doesn't use the AtticRAM at all, so I could just dump stuff up there, if it's too tricky to push the messages over the serial monitor interface.
And now I'm pulling my hair out, because LLVM is generating incorrect code for the usleep() function and/or the function for writing strings to the serial UART monitor interface when I use it with -Oz, -O1, -O2 -O3. And it's failing in different ways.
So I think a lot of the problem is that mos-llvm assumes the Z register always contains zero. But then it gets set in places, and it doesn't realise what's happened. Or perhaps somewhat equivalently it is using LDA ($zp) instructions that on the MEGA65 are actually LDA ($zp),Z, without realising.
Found the problem there: I was corrupting Z in another routine, which I've fixed.
But even after that, some stuff is output incorrectly from the mega65_uart_printhex() routine -- but only if I use stack storage for the hex string in that routine. The problem is that the pointer it's using for the stack is pointing to $FFFB, i.e., under the KERNAL, and so it reads rubbish out, instead of the correct data.
That happens because the stack pointer is stored at $02 and $03, and something is causing a null pointer to be written to, thus overwriting the stack pointer. Not cool.
Something to do with the shared resources helper assembly is borking things. I'm not sure why just yet, because it has an allocation for the 5 bytes it uses, so they shouldn't be at $0000.
Yup, for some reason the address is resolving to $0000. Found the problem: the extern declaration for the _shres_regs area was as a pointer, and thus dereferncing the stored data, yielding $0000.
With that fixed, I can now see the failure points:
src/telephony/contacts.c:45:mount_contact_qso():0x03
src/telephony/contacts.c:58:mount_contact_qso():0x0A
src/telephony/contacts.c:60:mount_contact_qso():0x08
src/telephony/records.c:146:read_record_by_id():0x03
src/telephony/contacts.c:40:mount_contact_qso():0x01
src/telephony/contacts.c:41:mount_contact_qso():0x02
src/telephony/contacts.c:45:mount_contact_qso():0x03
src/telephony/contacts.c:51:mount_contact_qso():0x05
src/telephony/contacts.c:54:mount_contact_qso():0x06
src/telephony/contacts.c:58:mount_contact_qso():0x0A
src/telephony/contacts.c:60:mount_contact_qso():0x08
src/telephony/records.c:170:write_record_by_id():0x04
src/telephony/records.c:179:write_record_by_id():0x03
First is top of the list. So I'll start investigating those.
The first one was actually a debug thing I'd put in place. The second one is a file not found error when mounting the D81. This happens because the pointer to the filename is somehow winding up as a null pointer. Possibly because something upstream has messed with a null pointer. I _really_ don't like the SP being at $02-$03 in ZP with LLVM, as even the smallest null pointer dereference write will smash it, and make it hard to track down the root cause. Logged an issue: https://github.com/llvm-mos/llvm-mos/issues/505
Anyway, I tracked the problem down. I hadn't converted the CC65 to LLVM calling convention for the assembly helper routine. Now I'm back to it displaying the message thread for the contact :)
That said, it's still reporting some failures. I'm now thinking I'd like to be able to get stack back-traces working, to make debugging even easier. After an hour or so of mucking about, I have it working as well as I can without having to load a line-by-line symbol table:
src/telephony/contacts.c:41:mount_contact_qso():0x02
Backtrace (most recent call first):
[02] 0x312A mount_contact_qso+0x00C5, SP=0xD000
[01] 0x10DB main+0x0660, SP=0xD000
[00] 0x0A89 main+0x000E, SP=0xD000
This is running entirely on the MEGA65, with this output via serial monitor UART interface.
I can then make a utility that works out the exact line that those function offsets correspond to, should the need arise. But just having a general idea of the position of the call within the calling function should be enough.
I'm actually really happy with this. Actually, that statement really undersells just how happy I am to have access to stack back-traces in my code at reasonable cost.
I think it has the potential to be handy to lots of other folks, so I've documented it in a blog post of its own.
Okay, so let's get back to debugging our actual bugs...
The problem now is that it's not mounting contact conversations properly. Or perhaps it's doing it correctly once, but not on subsequent attempts.
Yes, it's succeeding on the first attempt, but not on a subsequent call.
What's strange is it looks like the HYPPO chdir() call succeeded. i.e., that the problem is somewhere in the processing of the return value. There is no HYPPO DOS error code set, which further supports this hypothesis.
Looks like the chddirroot() call isn't working. The problem was that the LLVM fileio.s didn't have the fix to chdirroot() that I had done a while back for CC65.
Now I'm finally back to having the SMS conversation thread displaying. But there is something funny where some of the messages are only having their first line displayed, instead of all lines of the message.
Also pressing the INST/DEL key crashes it, instead of editing the draft SMS message. And now it's completely screwing up on start. Seems like Z register containing rubbish again. I've now added code to force Z = #$00 on startup, and it's getting further, but it looks like it's not loading the unicode glyphs any more.
So what weird thing is going on now?
Looks like the shared resource loader is loading the same empty glyph for every character. Which in turn is because it thinks that the font it's loading from is of zero length. So let's get to the bottom of this.
The magic string detection is failing. The SD card sector seems to be read correctly, and the magic_string buffer contains the right values, so how on earth is it failing?
The problem is that &magic_string[i] resolves to $002A, not the real address.
It turns out that LLVM doesn't seem to be calling it's own __copy_zp_data() function during initialisation prior to entering main() _and_ the linker decided that it would be better to relocate the magic_string down there in to ZP. It makes no sense, but that's what was happening.
With that fixed, it's looking less bad, at least while I had debug code in there -- it was even loading glyphs, although only the first row of text in a message was displaying.
Now it's back to the program crashing with Z=$F7 after I removed the debug code while I was figuring that ZP initialisation stuff out.
To figure out what's causing that, I've added an NMI catcher that shows the backtrace, like this:
NMI/BRK triggered.
Backtrace (most recent call first):
[04] 0x0A7E nmi_catcher+0x0001, SP=0xD000
[03] 0x4260 calc_break_points+0x0163, SP=0xD000
[02] 0x4205 calc_break_points+0x0108, SP=0xD000
[01] 0x1131 main+0x06A1, SP=0xD000
[00] 0xD000 __ashlhi3+0x772B, SP=0x41FF
Now that's a way faster way to get to the heart of the problem :)
The code to add this was simple, too:
void nmi_catcher(void)
{
mega65_uart_print("NMI/BRK triggered.\n");
dump_backtrace();
while(1) continue;
}
...
// Install NMI/BRK catcher
POKE(0x0316,(uint8_t)&nmi_catcher);
POKE(0x0317,((uint16_t)&nmi_catcher)>>8);
POKE(0x0318,(uint8_t)&nmi_catcher);
POKE(0x0319,((uint16_t)&nmi_catcher)>>8);
POKE(0xFFFE,(uint8_t)&nmi_catcher);
POKE(0xFFFF,((uint16_t)&nmi_catcher)>>8);
The fact that our function instrumentation is keeping track of the function entry and exit apart from the stack makes this quite robust.
Anyway, let's find out where this is all going west inside calc_break_points().
The double-call for it is the result of in-lining, I think.
Anyway, with a bit more work, I have my NMI catcher showing the symbol and offset, and PC value of where it happened:
>>> NMI/BRK triggered.
A:9E X:84 Y:05 P:B1 S:E8
BRK source @ 0x4717 calc_break_points+0x04F5
Backtrace (most recent call first):
[03] 0x29A0 nmi_catcher+0x009E, SP=0xD000
[02] 0x43A8 calc_break_points+0x0186, SP=0xD000
[01] 0x111E main+0x06A1, SP=0xD000
[00] 0x0DD0 main+0x0353, SP=0x1E57
With that, I can disassemble and see what's going on:
,00004700 64 05 STZ $05
,00004702 64 06 STZ $06
,00004704 86 07 STX $07
,00004706 A6 1A LDX $1A
,00004708 86 08 STX $08
,0000470A 64 09 STZ $09
,0000470C A6 1B LDX $1B
,0000470E 86 0A STX $0A
,00004710 A6 1A LDX $1A
,00004712 86 0B STX $0B
,00004714 A2 84 LDX #$84
,00004716 0A ASL
,00004717 00 D0 BRK $D0
,00004719 75 57 ADC $57,X
,0000471B 00 D0 BRK $D0
,0000471D 86 04 STX $04
And look at that, there _is_ a BRK instruction in the middle of the instruction stream. What on earth is it doing there?
Yup, something is bonkers here. If I use this on the ELF object:
llvm-objdump -drS --no-show-raw-insn --print-imm-hex bin65/unicode-font-test.llvm.prg.elf
I can see this:
; lcopy((unsigned long)buffers.textbox.break_costs,0x1A000L,RECORD_DATA_SIZE);
46fe: stz $4 ; 0xe004 <__heap_start+0x43d8>
4700: stz $5 ; 0xe005 <__heap_start+0x43d9>
4702: stz $6 ; 0xe006 <__heap_start+0x43da>
4704: stx $7 ; 0xe007 <__heap_start+0x43db>
4706: ldx $1a ; 0xe01a <__heap_start+0x43ee>
4708: stx $8 ; 0xe008 <__heap_start+0x43dc>
470a: stz $9 ; 0xe009 <__heap_start+0x43dd>
470c: ldx $1b ; 0xe01b <__heap_start+0x43ef>
470e: stx $a ; 0xe00a <__heap_start+0x43de>
4710: ldx $1a ; 0xe01a <__heap_start+0x43ee>
4712: stx $b ; 0xe00b <__heap_start+0x43df>
4714: ldx #$84
4716: lda #$32
4718: jsr $5775 <lcopy>
; CHECKPOINT("post string_render_analyse");
471b: ldx #$25
471d: stx $4 ; 0xe004 <__heap_start+0x43d8>
Let's focus on the bit that's broken:
,00004712 86 0B STX $0B
,00004714 A2 84 LDX #$84
,00004716 0A ASL
,00004717 00 D0 BRK $D0
,00004719 75 57 ADC $57,X
vs
4712: stx $b ; 0xe00b <__heap_start+0x43df>
4714: ldx #$84
4716: lda #$32
4718: jsr $5775 <lcopy>
Ah -- when I load it, but haven't yet run it, it's okay:
,00004712 86 0B STX $0B
,00004714 A2 84 LDX #$84
,00004716 A9 32 LDA #$32
,00004718 20 75 57 JSR $5775
,0000471B A2 B3 LDX #$B3
,0000471D 86 04 STX $04
,0000471F A2 5D LDX #$5D
So we're somehow overwriting this bit of code. That explains why the behaviour is so random.
Let's stick a watch on $4717 and see what's to blame for corrupting it.
Bingo -- we've found it:
w4717
.t0
.!
PC A X Y Z B SP MAPH MAPL LAST-OP In P P-FLAGS RGP uS IO ws h RECA8LHC
247B 0A 97 02 F7 00 01F2 0000 0000 A507 00 21 ..E....C ...P 15 - 00 - .....lh.
,0777247B A4 09 LDY $09
.D2470
,00002470 08 PHP
,00002471 85 05 STA $05
,00002473 A9 00 LDA #$00
,00002475 A0 02 LDY #$02
,00002477 91 04 STA ($04),Y
,00002479 A5 07 LDA $07
,0000247B A4 09 LDY $09
,0000247D 91 04 STA ($04),Y
,0000247F 18 CLC
,00002480 A5 08 LDA $08
,00002482 69 02 ADC #$02
,00002484 85 07 STA $07
,00002486 A5 06 LDA $06
,00002488 69 00 ADC #$00
,0000248A 5A PHY
,0000248B A4 07 LDY $07
.m4
:00000004:1547470A1501004C0000000400000000
So why does the ZP vector at $04-$05 point there? And where is this bit of code?
Okay, so this is a bit embarrassing: It's in the trace-back logging code. In particular here:
; callstack[depth] = (struct frame){ call_site, &__stack };
2457: lda $40 ; 0x6040 <__bss_size+0x2f24>
2459: asl
245a: rol $6 ; 0x6006 <__bss_size+0x2eea>
245c: asl
245d: sta $4 ; 0x6004 <__bss_size+0x2ee8>
245f: rol $6 ; 0x6006 <__bss_size+0x2eea>
2461: lda #$15
2463: clc
2464: adc $4 ; 0x6004 <__bss_size+0x2ee8>
2466: tay
2467: lda #$6b
2469: adc $6 ; 0x6006 <__bss_size+0x2eea>
246b: sta $6 ; 0x6006 <__bss_size+0x2eea>
246d: sty $4 ; 0x6004 <__bss_size+0x2ee8>
246f: sty $8 ; 0x6008 <__bss_size+0x2eec>
2471: sta $5 ; 0x6005 <__bss_size+0x2ee9>
2473: lda #$0
2475: ldy #$2
2477: sta ($4),y ; 0x6004 <__bss_size+0x2ee8>
2479: lda $7 ; 0x6007 <__bss_size+0x2eeb>
247b: ldy $9 ; 0x6009 <__bss_size+0x2eed>
247d: sta ($4),y ; 0x6004 <__bss_size+0x2ee8>
And again, the root cause is that Z has somehow got itself = $F7.
Where on earth is that coming from? It's all the side-effect of Z not being zero on initial entry, which causes all sorts of things to go wrong in the initial pre-main() routines, and then thereafter.
I was able to force it to be cleared by adding this to hal_asm_llvm.s:
;; Ensure Z is cleared on entry
.section .init.000,"ax",@progbits
ldz #0
cld ; Because I'm really paranoid
With that all in place, it draws the display more or less properly again. But if I try to edit the message, it still crashes-- but it does yield a stack back-trace at least for part of that problem. So I can investigate and fix that, and see what else remains broken:
src/telephony/records.c:144:read_record_by_id():0x01
Backtrace (most recent call first):
[02] 0x30C9 write_record_by_id+0x000E, SP=0xD000
[01] 0x1AFE main+0x107E, SP=0xD000
[00] 0x0A9A main+0x001A, SP=0xD000
src/telephony/records.c:75:append_field():0x01
Backtrace (most recent call first):
[04] 0x2DDE append_field+0x018E, SP=0xD000
[03] 0x1DEE main+0x136E, SP=0xD000
[02] 0x1C84 main+0x1204, SP=0xD000
[01] 0x1AFE main+0x107E, SP=0xD000
[00] 0x0A9A main+0x001A, SP=0xD000
Okay, I'm ready to move forward again after a bunch of further diversions, and logging the odd issue against mos-llvm, and implementing a VHDL-based memory write-protection scheme to detect memory corruption bugs earlier.
I also had to re-provision the SD card files, because the SMS thread got corrupted during all of the above.
So now I have it at the point where it _looks_ like sendin an SMS works, except that after sending it doesn't show up in the thread. Either it's not being written to the thread, or the message count in the thread is not being updated.
It looks like the problem is happening during the index update. Disabling that temporarily, I can now have an SMS message get stored into the message thread, and they display:
I need to fix the removal of the cursor before they get stored. And then also track down the reason why it messes up when updating the index.
Okay, I have the cursor hiding working now (although there are still some subtle bugs with cursor handling). I've added instrumentation that lets me see which sectors of which disk image are being written to -- complete with the path and name of the disk image:
DEBUG: BAM sector before allocation
0000: 0 0 FF FF 07 00 00 00 00 00 00 00 00 00 00 00 ................
DEBUG: BAM sector after allocation
0000: 0 0 FF FF 0F 00 00 00 00 00 00 00 00 00 00 00 ................
Image in drive 00 is /PHONE/THREADS/0/0/0/3/MESSAGES.D8
DEBUG: Writing sector data beginning with
0000: 0 0 FF FF 0F 00 00 00 00 00 00 00 00 00 00 00 ................
Allocated record 003 for new SMS message
DEBUG: BAM sector read back after
0000: 0 0 FF FF 0F 00 00 00 00 00 00 00 00 00 00 00 ................
Image in drive 00 is /PHONE/THREADS/0/0/0/3/MESSAGES.D8
DEBUG: Writing sector data beginning with
0000: 0 27 00 00 06 0D 2B 39 39 39 32 36 37 35 3 34 .'....+99926754
Image in drive 0 is /PHONE/THREADS/0/0/0/3/MESSAGES.D8
DEBUG: Writing sector data beginning with
0000: 0 0 FF FF 07 00 00 00 00 00 00 00 00 00 00 00 ................
Image in drive 0 is /PHONE/THREADS/0/0/0/3/MESSAGES.D8
DEBUG: Writing sector data beginning with
0000: 0 03 00 00 06 0D 2B 39 39 39 32 36 37 35 3 34 ......+99926754
Image in drive 0 is /PHONE/THREADS/0/0/0/3/MESSAGES.D8
DEBUG: Writing sector data beginning with
...
With this, I can see that for some reason, the indexing code thinks that it's writing always to the MESSAGES.D81 (I need to fix that trimming from the filename displayed), even when updating the index. That would absolutely cause the kind of problem that we're seeing. So time to add some more instrumenting. I am so glad that I have the instrumentation stuff setup now.
Okay, found a big bug in write_sector: It was always selecting drive 0.
I'd like to optimise the indexing code, so that we only modify index sectors that have changed, since writing is much slower than reading. Ideally we would use freezer-style multi-sector writes to speed things further, but we don't have that implemented in the HAL yet. More the point, because we are accessing via the FDC emulation, multi-sector writes aren't actually possible. So that'll have to go on the back-burner.
But what I can do in the meantime is add a busy indication with an hour-glass sprite. Except I've decided to go with a 1 TON "wait". I may even add an IRQ routine to animate it, so that the weight seems to drop continuously while "weighting". Okay, so it's tacky. But it puts everything in place for a much better wait indication. Anyone who's eyeballs are bleeding at what I have created is invited to submit alternate artwork for consideration. This what you have to improve upon:
So now the problem I have is that the text box for the SMS message drafting is not being consistently drawn, and when it is, it's with a different height. First check is to see whether the flag to draw it is actually being seen.
Okay, so with a bit of debug output, we can see that it's being asked to be drawn, but the number of lines to be drawn is varying all over the place:
with_edit_box_P = 01, textbox.line_count = 00
with_edit_box_P = 01, textbox.line_count = 04
with_edit_box_P = 01, textbox.line_count = 04
with_edit_box_P = 01, textbox.line_count = 04
with_edit_box_P = 01, textbox.line_count = 04
with_edit_box_P = 01, textbox.line_count = 04
with_edit_box_P = 01, textbox.line_count = 01
with_edit_box_P = 01, textbox.line_count = 01
with_edit_box_P = 01, textbox.line_count = 02
with_edit_box_P = 01, textbox.line_count = 02
with_edit_box_P = 01, textbox.line_count = 04
with_edit_box_P = 01, textbox.line_count = 04
with_edit_box_P = 01, textbox.line_count = 02
Why? The draft message itself is empty. And that's the problem: If it's zero bytes long, then it returns failure. I've fixed that to instead show that it should still show a single line in that case. The empty draft now has constant vertical space reserved on the screen, but if the string is empty, then that line still doesn't get shown. I can live with that, because it should never happen, because we should always have a cursor character in there.
This then feeds back to the other bugs affecting the whole cursor thing, because there are a bunch of them.
This current one we can deal with by saying that if we have a string without a cursor marker, that we should add one to the end.
Also, if a string has more than one cursor marker, we should get rid of it.
Right now we use a | character to approximate a cursor. But we should probably go past that now, and use something better. Possibly a width trimmed reverse space. We could then enable the hardware blink attribute on it, to make it a proper blinking cursor.
We do need a way to represent the cursor in the string. I'd rather not use a >0x7f value, because then we have to worry about UTF8 encoding stuff. But we can use a low value <0x20, that normally wouldn't get displayed. Like 0x01, for example, and then just replace that with a cursor when we encounter it.
Okay, so I've implemented this, and we even now have a nice blinking cursor. But if the cursor isn't at the end of the message, then when it gets reloaded, the cursor isn't there, and one of the characters next to where the cursor was gets munched. So I guess I'm handling the cursor finding thing wrong. So, time for more serial monitor debug messages!
That's all fixed now, too.
So I think the last thing I'd like to deal with for now is to allow deleting messages, so that I don't clog up the message threads with all my testing. This shouldn't be too hard: all I need to do is to deallocate the record in the BAM, and then update the index. I can probably do this in two steps, by first zeroing out the message we're deleting, and pretending to index it. That will update the index. Then I just need to deallocate the BAM bit. But first, I need to key combo for it. I'm going to use SHIFT+DEL, since it's easy.
The more complex case is deleting messages that aren't at the end of the conversation. I'm not updating the index when that happens, because the routine for reindexing a whole disk is currently embarrassingly slow on real hardware (of the order of an hour!). But I don't need the index stuff right now, since searching isn't on the critical path.
So I think that's probably everything we need here for the moment. Time to get contact list and dialpad working, and then hook it up to the cellular modem and actually do some telephony!
No comments:
Post a Comment