Closed david-schmidt closed 10 years ago
Could be. I saw the output and said "Ship it!"
On Jun 5, 2014, at 2:12 PM, david-schmidt notifications@github.com wrote:
Maybe it's just the test program implementation - but it's leaving the /// in an inconsistent columnar state. Maybe it just needs a viewport reset at the end.
— Reply to this email directly or view it on GitHub.
Maybe I can get off my duff and contribute.
What's your GitHub ID? GitHub isn't so bad if you use the command line version. Just one more step than svn.
Dave...
On Jun 5, 2014, at 3:51 PM, david-schmidt notifications@github.com wrote:
Maybe I can get off my duff and contribute.
— Reply to this email directly or view it on GitHub.
Errr... I think it's david-schmidt.
Yep, I was setting the viewport back to 40x24. Doesn't work too well on the ///. I adjusted the viewport routine to reset to full screen when width or height is 0
Cool. I was thinking an alternate implementation would be to exit after cout(1) (if height|width were 0) which could reset viewport to whatever it was previously, potentially to 40 or 80. But if the slow driver-based screen I/O is ever replaced (heh heh) explicit setting to 80 would still be required.
For the basic Standard Library, I'm looking for a very low-functionality baseline that should do something roughly equivalent on all platforms. Even having a viewport function is a stretch - It may make sense to move any screen handling more sophisticated than puts to a real library with proper per-platform implementation. The memory constraints are very tight on the Apple II, so something may have to get sacrificed.
I'm with ya - and that's exactly what stopped me from going nuts with the library. No room on the ][. It's liberating to be on the /// - so much room, and a device driver strategy that actually makes sense.
Maybe it's just the test program implementation - but it's leaving the /// in an inconsistent columnar state. Maybe it just needs a viewport reset at the end.