Forum unknown
· Telecommunications
#cocomm
15 messages in this thread
No problem. The reason no one has done that is beacause the console device
does not maintain the text is ascii mode (because the people who wrote it
can't think their way out of a BCPL bag) and you'd have to figure out what
is on screen by bit-bonging. There is a utility in the DLs that uses
pattern recognition called "Snipit" that allows cut and paste….
hmmmm….. wonder if that guy could be convinced into doing a print screen?
Anyone know who he is? I have long since thrown out the docs, if there were
any with it. As for CoComm, sure. –Ben–
Bit recognition works fine, as long as you use the default font.
Once beyond that…you'd have to do the comparison between the bits on
screen with the font file and then save the ASCII character. What's really
needed is for the text routines to also write the ASCII character to
non-displayed character mapped 'screen'. We all know how slow the text
routines are right now…imagine how much they'd slow down if they also had
to keep this 2nd memory area updatted including scrolling, clearing, cursor
positioning and which window and/or screen was in front. In other words, a
major can of worms.
If you think the Amiga is slow at text – don't get near an ST. The Amiga
is blinding compared to that pig.
Henry,
Oh…believe me I know about the slowness in the ST…working on the
now defunct paperclip…we had all kinds of 'fun' trying to get it sped up.
Dan did most of the work, but even using the line-a routines, it was still slow
(no blitter).
Things like early telecomm programs on the Amiga had problems with text
speed since the authors used 'get a character from the buffer and print it to
the screen' routines. They quickly learned that the proper way to go was 'get
all the characters in the buffer and print them to the screen' routines. That
sped things up significantly.
Don
A GEM window can't even handle 1200 baud without serious patching – but I
guess you know that. 🙂
A GEM window can't even handle 1200 baud without serious patching – but I
guess you know that. 🙂
Henry,
Oh…believe me I know about the slowness in the ST…working on the
now defunct paperclip…we had all kinds of 'fun' trying to get it sped up.
Dan did most of the work, but even using the line-a routines, it was still slow
(no blitter).
Things like early telecomm programs on the Amiga had problems with text
speed since the authors used 'get a character from the buffer and print it to
the screen' routines. They quickly learned that the proper way to go was 'get
all the characters in the buffer and print them to the screen' routines. That
sped things up significantly.
Don
If you think the Amiga is slow at text – don't get near an ST. The Amiga
is blinding compared to that pig.
You, or anyone else, give me the source for a current, working console
driver, and I'll make it work – and faster than the current driver, too, I
bet. Handing 80×24 characters is _nothing_ compared to handling a complete
bit map as well. For screen dumping, all you need are the character codes,
anyway – which are being generated alla time. The console driver needs to
work differently… not just have text handling pasted on top of it's
current, badly thought out code. You need to manipuate the text – and then
display it. That way you could have an (efficient) screen display that has
some history in a realistic context – ascii, that is. Currently, no matter
what font is in use, the font is in memory, right? ROM or RAM, what's the
difference? Bit recognition seems like an _awfully_ poor way to go, (tho
cute) for performance. I want a console that is 80×24, period. WAAAHHHH!
–Ben–
What's so *&@*&#$^% magic about 80×24? I want 132×50!! Now what are you gonna
do?
What's so *&@*&#$^% magic about 80×24? I want 132×50!! Now what are you gonna
do?
You, or anyone else, give me the source for a current, working console
driver, and I'll make it work – and faster than the current driver, too, I
bet. Handing 80×24 characters is _nothing_ compared to handling a complete
bit map as well. For screen dumping, all you need are the character codes,
anyway – which are being generated alla time. The console driver needs to
work differently… not just have text handling pasted on top of it's
current, badly thought out code. You need to manipuate the text – and then
display it. That way you could have an (efficient) screen display that has
some history in a realistic context – ascii, that is. Currently, no matter
what font is in use, the font is in memory, right? ROM or RAM, what's the
difference? Bit recognition seems like an _awfully_ poor way to go, (tho
cute) for performance. I want a console that is 80×24, period. WAAAHHHH!
–Ben–
Bit recognition works fine, as long as you use the default font.
Once beyond that…you'd have to do the comparison between the bits on
screen with the font file and then save the ASCII character. What's really
needed is for the text routines to also write the ASCII character to
non-displayed character mapped 'screen'. We all know how slow the text
routines are right now…imagine how much they'd slow down if they also had
to keep this 2nd memory area updatted including scrolling, clearing, cursor
positioning and which window and/or screen was in front. In other words, a
major can of worms.