| name | what-shorter |
|---|---|
| description | Restate your immediately preceding answer far more simply — core point only, in short plain-English sentences in the spirit of ASD-STE100. Use ONLY when the user explicitly asks for it by typing or mentioning /what-shorter. |
I'm having trouble understanding your previous answer. Try restating just the core point (of each paragraph) using simpler english, similar to ASD-STE100. I'll ask follow-up question if it is too short or unclear.
Consider this example interchange between Claude and I:
- Composition. I recommend option 1 — one personality, two windows. 0x0003 takes 4 = fantasy-Mega-Drive; 0x007F keeps its meaning and reuses personality 3's DaxApuSms state (not a second copy, and not reimplemented); the YM gets 0x4000..0x4003. It keeps "a personality is a machine", both windows stay literal, and vgmplay transcribes byte-for-byte (0x50→0x007F, 0x52 aa dd→0x4000/0x4001, 0x53→0x4002/0x4003). Option 2's orthogonal axes buy combinations no machine had, at the price of a second system register, a second reset story and a general two-chip mixer — and the render stage has to learn to sum two chips anyway under any option, so option 2's supposed advantage isn't one. The real cost of option 1 is honest and small: daxapu_mode_window() becomes plural (or the Genesis declares "no shadowable window", which is truthful per finding 2).
re 1 composition. this prose is difficult to understand. try restating in 2 or 3 sentences using ASD-STE100, then I'll ask for more details if needed
- Composition (ASD-STE100)
The Mega Drive has two sound chips. Make one new personality with the value 4. This personality decodes two address windows: 0x007F for the PSG, and 0x4000 to 0x4003 for the FM chip. The PSG uses the code of personality 3 — do not write that chip again.
That's clearly an improvement, but a human probably would have asked:
"The Sega Genesis has two sound chips, one of which we've already implemented (when we worked on the Sega Master System). Should we re-use the code?".
Even better.
The key lesson: "Should we re-use the code?" is easily understood. However, it is ambiguous without context. Hone in on that foundation (the easily understood question) and package it with enough context to disambiguate it.
Err on the side of simplifying and shedding tangential details, even if the revised version feels too simplified. It is likely that the oversimplification will allow me to re-read and understand the details in your original response, at which point I'll have the full picture.