Search found 606 matches
- Sun Jan 29, 2017 3:46 pm
- Forum: Calculator Hacking/Modding Discussions
- Topic: FONTCHARACTER Reference - compatibility, sets
- Replies: 26
- Views: 86753
Re: FONTCHARACTER Reference - compatibility, sets
Well, it looks like MB_strcpy doesn't use the result of MB_ByteCount. So anyway, yeah, that looks null-terminated. MB_ByteCount is called inside of MB_strcpy again. Well actually, the syscall I have here (OS 2.05, fx-9860GII-2) uses a cmp/gt , so it is < 0xLLFF (where 0xLL is the leading character)...
- Sun Jan 29, 2017 9:26 am
- Forum: Calculator Hacking/Modding Discussions
- Topic: FONTCHARACTER Reference - compatibility, sets
- Replies: 26
- Views: 86753
Re: FONTCHARACTER Reference - compatibility, sets
First thing I saw was that the byte was read after the string was copied, so the length of the string looks unused (which means if they are stripped, this won't have any effect... unless some other syscalls use them?). I did not find any reference to the length-nibble. The length of an OpCodeString...
- Sat Jan 28, 2017 6:21 pm
- Forum: Tutorials & Code Snippets
- Topic: Some hints concerning the G1S-type
- Replies: 14
- Views: 38914
Re: Some hints concerning the G1S-type
- if I understood well, different types have different indexes (like, there is an enumeration for sectors, one for directories and one for files). Does that mean the dirref/dirnum should in fact be understood as the parent node, where the high two bytes are for the type (numeration to use and the n...
- Sat Jan 28, 2017 4:42 pm
- Forum: Tutorials & Code Snippets
- Topic: Some hints concerning the G1S-type
- Replies: 14
- Views: 38914
Re: Some hints concerning the G1S-type
PS: Btw, here is my current understanding of the SMEM/G1S. "The list has 0x800 entries, and occupies the two first sectors (or maybe * just one, but it looks like data storage starts at sector 3). Entries with * a type being 0xFFFF should not be read". As long as the first sector is not e...
- Thu Jan 26, 2017 6:38 am
- Forum: Calculator Hacking/Modding Discussions
- Topic: Serial communications
- Replies: 19
- Views: 71038
Re: Serial communications
I use SetupComm( Handle, $8000, 0 ); SetCommState( Handle, DCB ); with DCB (0x1C, 0x2580, 0x1011, 0, 0x4000, 0x1000, 8, 0, 2, 17, 19, 0, 0, 0, 0) or (0x1C, 0x2580, 0x1011, 0, 0x4000, 0x1000, 8, 0, 0, 17, 19, 0, 0, 0, 0) SetCommTimeOuts( Handle, CTO ); with CTO (0xFFFFFFFF, 0, 0, 0, 0) as preparing s...
- Sun Jan 22, 2017 10:03 pm
- Forum: Calculator Hacking/Modding Discussions
- Topic: Serial communications
- Replies: 19
- Views: 71038
Re: Serial communications
Hm, it seems that even with those settings, I can't communicate with the calculator. (it's writing ok, but it is not reading, so I assume what I wrote just disappeared) Do you have a serial monitor to verify, what you are sending arrives properly? A receiving add-in would do. Is there other setting...
- Sun Jan 22, 2017 3:17 pm
- Forum: Calculator Hacking/Modding Discussions
- Topic: Serial communications
- Replies: 19
- Views: 71038
Re: Serial communications
The OSes use no parity and two stop bits. I use one stop bit, when communicating, because the probability of line faults is very low. The "no parity"-setting is mandatory. After I sent the first check packet successfully with 9600 baud I switch over to 115 kBaud. The protocol with USB and ...
- Sat Jan 21, 2017 5:43 pm
- Forum: Calculator Hacking/Modding Discussions
- Topic: FONTCHARACTER Reference - compatibility, sets
- Replies: 26
- Views: 86753
Re: FONTCHARACTER Reference - compatibility, sets
Neither OS 1.05 nor OS 1.05AU has E7-opcodes.
Try
for (int minor = 0; minor <= 255; minor++) {
instead of
for (int minor = 0; minor < 255; minor++) {
Try
for (int minor = 0; minor <= 255; minor++) {
instead of
for (int minor = 0; minor < 255; minor++) {
- Sat Jan 21, 2017 7:56 am
- Forum: Calculator Hacking/Modding Discussions
- Topic: FONTCHARACTER Reference - compatibility, sets
- Replies: 26
- Views: 86753
Re: FONTCHARACTER Reference - compatibility, sets
Fine. So that is unravelled, too.cakeisalie5 wrote:EDIT: Using what I've manually decoded, I guessed the flags (first byte's high nibble) were:
- 0x04: appended newline
- 0x08: appended space
- Fri Jan 20, 2017 10:43 pm
- Forum: Calculator Hacking/Modding Discussions
- Topic: FONTCHARACTER Reference - compatibility, sets
- Replies: 26
- Views: 86753
Re: FONTCHARACTER Reference - compatibility, sets
And if I understand well, the second dword is the flags of the entry. What I don't understand is that in your example, the size of the element is the high nibble of the first byte of the flags, where here, it looks like it is the lowest nibble. Also, the characters looks deformed: for 0x0E, it shou...