Given the KERLT101 boot program that is on the internal LTWIN.po image, disassemble it. It will be interesting to know what the boot program is doing.

Given the ProDOS image that is on ROM cartridges (and the internal LTWIN.po image), pick out the slot 6 driver and disassemble it. It's likely a close stand-in for the Disk II driver, but instead talks to the cartridge slot hardware.

Given the ProDOS image that is on the internal LTWIN.po image, disassemble the PRODOS file - or at least the differences between that and stock. The slot 6 driver is already called out as a separate item, so either skip it or do it all and claim victory for both issues. :-) The effect of inserting two cartridges is that by the time you get to ProDOS on one of them, the internal LTWIN volume is gone, replaced by "drive" 1. So there is some shuffling going on - getting to the bottom of that is of interest. I imagine it is happening within PRODOS itself, and not the KERLT101 boot program... but that remains to be seen.

Within the formatter of the GUI (KERLT101), there is the ability to format a disk as either DOS 3.3 or ProDOS. I imagine the DOS 3.3 is going to need to be some kind of shimmed version with ProDOS-like hooks because there isn't an IWM controller for the 256-block RAM disk. And it's a bit of a chicken-and-egg situation in that we don't have the ability to run ADTPro and have this DOS 3.3 disk online at the same time... so what are they laying down on the RAM disk when formatting as DOS 3.3?

Edit: the disk image was extracted by having the DOS-formatted RAM disk mounted, booting into ProDOS-based BASIC as usual (rather than booting the DOS RAM disk), and then bootstrapping ADTPro. From there, ADTPro was happy to push the DOS RAM disk over the wire.

I was looking to see what the TLC has in terms of ID bytes.

The usual suspects ($FBB3, $FB1E, $FBC0, $FBDD, $FBBF) are identical to an Enhanced Apple IIe.

I compared the F8 ROM with Enhanced IIe and here's the diff - offsets relative to $F800

< 00000280  c0 d8 20 bf c6 ad f3 03  49 a5 cd f4 03 d0 17 ad  |.. .....I.......|
---
> 00000280  c0 d8 20 3a ff ad f3 03  49 a5 cd f4 03 d0 17 ad  |.. :....I.......|
44,46c44,46
< 000002b0  03 ca d0 f7 a9 c6 4c 35  c6 a2 05 bd 00 02 29 df  |......L5......).|
< 000002c0  dd cf fa d0 08 ca 10 f3  ee f4 03 80 95 38 60 cc  |.............8`.|
< 000002d0  d4 d7 c9 ce 8d ea ea 20  8e fd a9 45 85 40 a9 00  |....... ...E.@..|
---
> 000002b0  03 ca d0 f7 a9 c8 86 00  85 01 a0 05 c6 01 a5 01  |................|
> 000002c0  c9 c0 f0 d7 8d f8 07 b1  00 d9 01 fb d0 ec 88 88  |................|
> 000002d0  10 f5 6c 00 00 00 00 20  8e fd a9 45 85 40 a9 00  |..l.... ...E.@..|

Quick disassembly shows a couple calls into $C600 space that are different. But usefully, this sequence looks suspicious:

FACF- CC D4 D7 C9 CE 8D EA EA

It's ASCII with high bits set, "LTWIN" plus carriage return. IIRC, that's the magic sequence equivalent to BYE to return to the TLC GUI? The routine before it is doing a comparison with the input buffer.

Anyway, those "LTWIN\r" bytes can probably be treated as effective ID bytes for the TLC.

The hybrid joystick/audio ADTPro bootstrap loader is 128 bytes long - the poor soul that wants to do joystick bitbanging bootstrapping for themselves needs to type it all into the TLC monitor with a truly awful keyboard. Can you get my monstrosity down to 50% of its initial size? I bet so...

It has the following constraints:

1. It needs to clear the screen sometime during initialization or operation (no, you can't send $20s to the screen via joystick)
2. It needs to print a greeting message of two characters: "HI" somewhere on the screen
3. It needs to put a throbber (or any visually changing indication) on the screen to indicate data movement - there’s no requirement to keep the screen clear once the process starts
4. It needs to work (cycle counting is paramount in bitbanging)
5. No error checking of any kind is required, but see constraint 4, above

The "protocol" on the wire is that it waits for a "T" byte ($54), once seeing that it then receives two bytes as a length (MSB, LSB), then continues to read bytes and save them to memory starting at $800 until the length is satisfied. When done, it jumps to $800.

My code makes use of uninitialized variable space that doesn't need to be included in the payload the user needs to type in. They are all in 16-bit space, so you can save space already by using zero page instead! First optimization is on me. :-)

My initial shot at this is over in the ADTPro repo here, and currently satisfies all of the constraints (and goes the extra mile to check for some RS-232 framing errors):
https://github.com/ADTPro/adtpro/blob/tlc-grub/src/client/prodos/serial/grub2/grub2joy.asm
Comment density is about 50%, so hopefully that will help with context.