Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[R IV]

Sent from my iPad

On Jan 28, 2024, at 5:29 PM, Darren Clark  wrote:



Minor correction. Any commands that get translated to an index higher than 0x13 
will return an invalid command, not crash the firmware.

This statement is incorrect: "I haven't looked for any other logic that would 
prevent this, but a command 0x13 to 0x2A (except 0x23), or 0x35 to 0x3F will 
select addresses past the jump table (author name and reset vector table) 
causing the firmware to crash and reset."

[F104][58 ][X   ]ASL B;B*2 - set pointer 
correctly for function table
[F105][C1 26  ][ &  ]CMP B #0x26  ;if command > 0x13 
branch to Command_FMT_Invalid
[F107][24 2E  ][$.  ]BCC Command_FMT_Invalid

The "I haven't looked..." part is true, I found it at F014 and F105. So the 
firmware does protect against invalid commands.


Darren Clark




On 1/28/24 12:40, Darren Clark wrote:

The part of the code that picks out the commands is a bit goofy, but I believe 
it's like this to maintain a standard command set across multiple drives with 
other added functionality.

There is a bit mask for the command, so we're only looking at the lower 6 bits 
(0x00 to 0x3F). Bit 6 and 7 (6 being bank select) is masked out of the command 
selection code. It'll require some more digging around to see where it is used.

Here is some of the logic:

If the command = 0x23 (line F0F5), make the command 0x09. This is the Drive 
Version Info command.

If the command > 0x30, subtract 0x22 from it.

That makes the following commands into index positions:
0x30 = 0x0E
0x31 = 0x0F
0x32 = 0x10
0x33 = 0x11
0x34 = 0x12

The end result is the command becomes the index of the jump table:

IndexCommandFunction

0x000x00;Command_FMT00_CreateDirectory
0x010x01;Command_FMT01_FileOpen
0x020x02;Command_FMT02_FileClose
0x030x03;Command_FMT03_FileRead
0x040x04;Command_FMT04_File_Write
0x050x05;Command_FMT05_FileDelete
0x060x06;Command_FMT06_DiskFormat
0x070x07;Command_FMT07_DriveStatus
0x080x08;Command_FMT_Invalid
0x090x23;Command_FMT23_DriveVersionInfo (SM Page 93)
0x0A0x0A;Command_FMT_Invalid
0x0B0x0B;Command_FMT_Invalid
0x0C0x0C;Command_FMT0C_DriveCondition
0x0D0x0D;Command_FMT0D_FileNameChange
0x0E0x30;Command_FMT30_SectorModeReadWrite
0x0F0x31;Command_FMT31_DriveMemorySet
0x100x32;Command_FMT32_DriveMemoryGet
0x110x33;Command_FMT33_SystemVersionInfo (SM Page 92)
0x120x34;Command_FMT34_ExecuteProgram

I haven't looked for any other logic that would prevent this, but a command 
0x13 to 0x2A (except 0x23), or 0x35 to 0x3F will select addresses past the jump 
table (author name and reset vector table) causing the firmware to crash and 
reset.

Also command 0x0F is the same as 0x31, so it returns the memory set return 
block 0x38. And looking at the table, there are several other overlapping 
commands: 0x0E, 0x10, 0x11, 0x12


The memory write commands set flags in the internal RAM, these need to still be 
deciphered.

There is also a block of code that reads a file off of a disk into the 2K 
external RAM and executes it.



On 1/28/24 10:45, Brian K. White wrote:
This is great for making the emulators and clients definitive instead of full 
of mysteries and "here we recite the words lest the gods be angry".

Can you see why command 0x11 works as a synonym for 0x33?
And why does 0x0F respond with the 0x38 return block?
When neither of those are commands. There are some other dupes like that too 
where an undocumented code results in some other response than the invalid code 
response.
It's like it's not checking the entire value but masking bits, and looking at 
fewer than all 8 bits, and multiple values can give the same bits.
Definitely bank 1 must work that way. A bunch of commands that all get one part 
of their meaning changed by adding 0x40, which is just flipping 1 bit on the 
normal command code.
IE 0x00 is dirent, 0x40 is dirent in bank 1.

Ah speaking of "we don't know why we do this but we must recite the words here" 
there are a few things exactly like that.

The service manual describes a routine it calls "reset drive status" on pg 102. 
It's just using mem_write to write 3 bytes at 3 addresses but doesn't explain 
what they do.
write 0xFF to 0x0084
write 0x0F to 0x0096
write 0x0F to 0x0094

And with dl2 I have captured TS-DOS doing exactly that sequence.

The tpdd2 backup.ba also does something similar but not the 
same, just before each each cache commit (write cache to disk):
write 0x00 to 0x0083
write 0x00 to 0x0096

To be clear it never does the other 3 bytes, it just does these 2 before each 
cache write-to-disk.
https://trs80stuff.net/tpdd/tpdd2_boot_disk_backup_log_hex.txt
...
17/08/2016 20:03:01.667 [M100] - 5A 5A 31 04 01 00 83 00 46
17/08/2016 20:03:01.671 [TPDD] - 

Re: [M100] Tandy Portable Disk Drive 2 - firmware dumping and reverse engineering

[R IV]

E

Sent from my iPad

On Jan 28, 2024, at 5:29 PM, Darren Clark  wrote:



Minor correction. Any commands that get translated to an index higher than 0x13 
will return an invalid command, not crash the firmware.

This statement is incorrect: "I haven't looked for any other logic that would 
prevent this, but a command 0x13 to 0x2A (except 0x23), or 0x35 to 0x3F will 
select addresses past the jump table (author name and reset vector table) 
causing the firmware to crash and reset."

[F104][58 ][X   ]ASL B;B*2 - set pointer 
correctly for function table
[F105][C1 26  ][ &  ]CMP B #0x26  ;if command > 0x13 
branch to Command_FMT_Invalid
[F107][24 2E  ][$.  ]BCC Command_FMT_Invalid

The "I haven't looked..." part is true, I found it at F014 and F105. So the 
firmware does protect against invalid commands.


Darren Clark




On 1/28/24 12:40, Darren Clark wrote:

The part of the code that picks out the commands is a bit goofy, but I believe 
it's like this to maintain a standard command set across multiple drives with 
other added functionality.

There is a bit mask for the command, so we're only looking at the lower 6 bits 
(0x00 to 0x3F). Bit 6 and 7 (6 being bank select) is masked out of the command 
selection code. It'll require some more digging around to see where it is used.

Here is some of the logic:

If the command = 0x23 (line F0F5), make the command 0x09. This is the Drive 
Version Info command.

If the command > 0x30, subtract 0x22 from it.

That makes the following commands into index positions:
0x30 = 0x0E
0x31 = 0x0F
0x32 = 0x10
0x33 = 0x11
0x34 = 0x12

The end result is the command becomes the index of the jump table:

IndexCommandFunction

0x000x00;Command_FMT00_CreateDirectory
0x010x01;Command_FMT01_FileOpen
0x020x02;Command_FMT02_FileClose
0x030x03;Command_FMT03_FileRead
0x040x04;Command_FMT04_File_Write
0x050x05;Command_FMT05_FileDelete
0x060x06;Command_FMT06_DiskFormat
0x070x07;Command_FMT07_DriveStatus
0x080x08;Command_FMT_Invalid
0x090x23;Command_FMT23_DriveVersionInfo (SM Page 93)
0x0A0x0A;Command_FMT_Invalid
0x0B0x0B;Command_FMT_Invalid
0x0C0x0C;Command_FMT0C_DriveCondition
0x0D0x0D;Command_FMT0D_FileNameChange
0x0E0x30;Command_FMT30_SectorModeReadWrite
0x0F0x31;Command_FMT31_DriveMemorySet
0x100x32;Command_FMT32_DriveMemoryGet
0x110x33;Command_FMT33_SystemVersionInfo (SM Page 92)
0x120x34;Command_FMT34_ExecuteProgram

I haven't looked for any other logic that would prevent this, but a command 
0x13 to 0x2A (except 0x23), or 0x35 to 0x3F will select addresses past the jump 
table (author name and reset vector table) causing the firmware to crash and 
reset.

Also command 0x0F is the same as 0x31, so it returns the memory set return 
block 0x38. And looking at the table, there are several other overlapping 
commands: 0x0E, 0x10, 0x11, 0x12


The memory write commands set flags in the internal RAM, these need to still be 
deciphered.

There is also a block of code that reads a file off of a disk into the 2K 
external RAM and executes it.



On 1/28/24 10:45, Brian K. White wrote:
This is great for making the emulators and clients definitive instead of full 
of mysteries and "here we recite the words lest the gods be angry".

Can you see why command 0x11 works as a synonym for 0x33?
And why does 0x0F respond with the 0x38 return block?
When neither of those are commands. There are some other dupes like that too 
where an undocumented code results in some other response than the invalid code 
response.
It's like it's not checking the entire value but masking bits, and looking at 
fewer than all 8 bits, and multiple values can give the same bits.
Definitely bank 1 must work that way. A bunch of commands that all get one part 
of their meaning changed by adding 0x40, which is just flipping 1 bit on the 
normal command code.
IE 0x00 is dirent, 0x40 is dirent in bank 1.

Ah speaking of "we don't know why we do this but we must recite the words here" 
there are a few things exactly like that.

The service manual describes a routine it calls "reset drive status" on pg 102. 
It's just using mem_write to write 3 bytes at 3 addresses but doesn't explain 
what they do.
write 0xFF to 0x0084
write 0x0F to 0x0096
write 0x0F to 0x0094

And with dl2 I have captured TS-DOS doing exactly that sequence.

The tpdd2 backup.ba also does something similar but not the 
same, just before each each cache commit (write cache to disk):
write 0x00 to 0x0083
write 0x00 to 0x0096

To be clear it never does the other 3 bytes, it just does these 2 before each 
cache write-to-disk.
https://trs80stuff.net/tpdd/tpdd2_boot_disk_backup_log_hex.txt
...
17/08/2016 20:03:01.667 [M100] - 5A 5A 31 04 01 00 83 00 46
17/08/2016 20:03:01.671 [TPDD] - 

Re: [M100] Model T clock doubler

[R IV]

Sent from my iPad

On Nov 22, 2023, at 11:00 PM, Joshua O'Keefe  wrote:


On Nov 22, 2023, at 9:01 PM, MikeS  wrote:

MVT100 Windows application???

I think that's referring to this program:

Club100 Member Upload 
Library
club100.org
[X]

To quote Steve: "This is a Windows program that is serial-fed terminal emulator 
specifically modified to match the M100 screen output. It enables an 80x24 
terminal screen. Compiled on Windows 10 using Visual Studio, based on .NET 4.8. 
Program is very early and possibly quite buggy"

Re: [M100] New 10-line game (David Plass)

[R IV]

Sent from my iPad

On Mar 13, 2023, at 5:25 PM, Jason White  wrote:

 I have just loaded and tried out Bounce. I love it! I think I am going to add 
a few lines though to add a play again option, and probably a sound after each 
miss.

There are a few other breakout type fames for the 100, but this one is the best 
I’ve tried!

Thanks for making and sharing it!

J White


Sent from Yahoo Mail for iPhone

Re: [M100] Low battery , crashes wipe the memory of both M102/M200

[R IV]

Sent from my iPad

On Feb 6, 2023, at 1:33 PM, Cedric Amand  wrote:



I’d like to eliminate the possibility that my ram has problems ; may it be on 
my m200 or my m102 ; is there a small basic or ml program somewhere that would 
to a meaningful test ( I could probably draft a simple one but it would 
probably not be very thorough )

All in all my m102 is much more stable than my m200 so if there is a ram 
problem behind that ; it’s more on my m200 .

I’d like to be sure once and for all