Modified TOS to remove resolutions limitation

[Smonson]

I've patched TOS 1.4 UK to allow selecting any resolution from the Desktop Preferences.

This is probably only useful with the HDMI mod at this stage, since a monitor cable can only either be connected to the RGB lines or the mono-out pin at a time.

This screencast shows it running under Hatari, but neither Hatari or Steem can display the low-res modes properly when set up to present a high-res monitor to the machine, so the display is bitplane'd. But it seems to be working. Excuse the flashing lights on the right side, apparently it's a problem with my Nvidia drivers.

I have no way to program the ROM image into a real machine yet. Should work fine, though.

tos14uk-res-mod.gif

[Icky]

Nice!

This will be a great feature for the HDMI Shifter mod. Having a rock solid screen via HDMI without switching cables is a utopia.

[PhilC]

Nice modification, will have to see if I can test that the next few days

[Smonson]

Nice modification, will have to see if I can test that the next few days

I just realised it doesn't seem to work if it thinks a colour monitor is plugged in - I probably missed a code path somewhere. You might need to ground the mono-detect pin. I'll fix that eventually.

It's been fun disassembling TOS 1.4 (I think I got about 5% of it done). It really is as godawful as everyone says.

[PhilC]

I can imagine, C disassembled to 68000 is no fun.

[Smonson]

It's worse than you think! Instead of using the standard "BSR" or "JSR" instruction to call a subroutine, 603 commonly-used functions are built into the line-f exception handler. By executing an invalid opcode, the vector is triggered and the opcode is inspected to find out which function is meant to be called. It saves up to 4 bytes depending on how far away the caller is.

But then they had to get rid of that brain-fart when they started porting it to 68020 which uses those opcodes for floating point instructions, and I assume they then did some celebratory breakdancing.

[Tomswork]

Smonson that is a work of code art


Tom

[thorsten.otto]

603 commonly-used functions are built into the line-f exception handler.

604 actually. But some addresses are duplicate. And the Line-F handler also serves another purpose: to replace the epilogue of most functions. That saves 6 bytes in most of them. And that was the whole purpose of this handler, because the alcyon compiler that was in use was too braindamaged, they ran out of space in the 192k ROMs.
BTW, for 438 functions of them, i could tell you their purpose, and what's their corresponding name in TOS 2.06 ;)

[Smonson]

604 actually. But some addresses are duplicate. And the Line-F handler also serves another purpose: to replace the epilogue of most functions. That saves 6 bytes in most of them. And that was the whole purpose of this handler, because the alcyon compiler that was in use was too braindamaged, they ran out of space in the 192k ROMs.
BTW, for 438 functions of them, i could tell you their purpose, and what's their corresponding name in TOS 2.06 ;)

I neglected to count the 0th - classic off-by-one error :)

Thorsten, I've referred to your TOS306 codebase to decypher many of the functions and datastructures in 1.4. Thank you for making your work available.

I knew there was something going on with the epilogue because some of the functions end abruptly with another line-f opcode. I haven't yet followed those trails all the way to the end. But it makes sense.

[exxos]

I thought the mono_det pin had to be used as it resets the machine. I don't think its possible to simply change resolution as the VDI has to be restarted. I assume that pin forces TOS to reboot. The only way I thought it could work is to enable high res in the menu, then have it flip a bit in a register to set the mono_det pin to simulate the mono monitor being plugged in. In may be wrong, but that's how I think it works.