Forum unknown
· Telecommunications
#comm/vt100/printscreen
15 messages in this thread
Still Don, the PC has a standard equipment a print screen key, and as I believe
control print also. There may be some real complications here, but I would
suggest that someone, preferably CBM do it. It should not require a graphic
dump to print text (note that in Online! right now I have no full graphics
ability, so what's the problem – it is probably doing just what you described).
Ron
Ron,
You sure do have the full graphics ability….are you using the
original disk (copy there of that is) or have you moved the files onto another
disk? If so, did you move all the fonts also?
There is a MAJOR difference in the way the IBM handles text and the way
the Amiga handles text. That major difference is why it's very easy to do a
text dump on an IBM and not on the Amiga. You can do graphic dumps on an IBM
(vs text dumps) and they take as long as a graphic dump on an Amiga.
Normal IBM graphics are character graphics, not bit mapped graphics.
They have graphic characters for corners, t's, x's, horizontal and vertical
lines and the like. When the IBM prints a character to the screen, what it
really does is place the character itself in memory in an array. The IBM
screen handler looks at this array every vertical interupt and creates the
screen by grabbing a bit pattern out of ROM and placing it into the video
memory area. If you did a dump of the array, it would look exactly like normal
text…because it is a normal character array.
If you did a dump of the screen memory…it would look like garbage
because it is the bit patterns. A Print-Screen on the IBM only prints the
array…not the bit patterns. This has advantages of being able to do this,
but disadvantages of not being able to use multiple fonts.
Also, the IBM isn't a windowed environment…that makes a major
difference also.
Don
I understadn, but if Online! and others handle text in a window or screen the
way they do, without graphics, they must be maintaining a rolling memory of
what goes thru in text form already, so what's so hard about a print screen
function or a control print function? Even with a 5 point font for 132 width
that shouldn't be too hard to handle, using th e printer device.
Ron
Ron,
View buffer
Print buffer
Both menu options…haven't you used them?
Don
Ron,
View buffer
Print buffer
Both menu options…haven't you used them?
Don
I understadn, but if Online! and others handle text in a window or screen the
way they do, without graphics, they must be maintaining a rolling memory of
what goes thru in text form already, so what's so hard about a print screen
function or a control print function? Even with a 5 point font for 132 width
that shouldn't be too hard to handle, using th e printer device.
Ron
No – it just means that for their ONE window, they kept a text record. Look at
MS-BASIC on the Inferior Barf Machine; scroll the cursor right up thru the
text. niiiice. That capability should be in _each_ conwindow. Screens and
windows, that's part of the problem with this discussion. What we're talking
about is a print-conwindow. nothing more, nothing less. And that capability
would be trivial to implement, if you had source. <looking around expectantly>
–Ben–
Ben,
Actualy, ALL they keep is the text record. The video display card
reads that text record and does the visual thingie.
Don
I understand that – that's because they aren't (generally) rendering; and when
they ARE rendering (320×200 mode, fer instance) they're doing a complete
simulation of what the console would have done anyway, so it all works well. In
our case, we send text (ASCII) to the system as well… then, thru a software
interface, it's converted to bitoids, just like the IBM in graphics mode. We
don't keep anymore around than they do – less, in fact. In graphics mode, they
have the bit patterns, AND they have the text (in the BIOS map) so they can
mess with it – and we can't. They don't try and read the bitmap, because they
don't _have_ to – someone thought about it (probably one of the few things they
_ever_ thought about) and decided it was a lot more reasonable to keep a text
map around for after-the-fact use. And again, I say – they were right. –Ben–
Ben,
I agree, if talking about a single console, with no windowing support,
they were right. Again, my concern about doing the same thing for the
Amiga…is the windowing envrionment.
IF we can built a text map (and text only…since that's what the vast
majority of users want on a print screen…and GraphicDump takes care of those
that want it all) that has all the attributes of the current screen you are
looking at…then it should be done.
I would also agree to your idea of each window having it's own text
map, where you click on the window, and then hit the hot-key to print screen
and you get the text only from that particular window…full 80×24 (or
whatever).
Don
Ben,
I agree, if talking about a single console, with no windowing support,
they were right. Again, my concern about doing the same thing for the
Amiga…is the windowing envrionment.
IF we can built a text map (and text only…since that's what the vast
majority of users want on a print screen…and GraphicDump takes care of those
that want it all) that has all the attributes of the current screen you are
looking at…then it should be done.
I would also agree to your idea of each window having it's own text
map, where you click on the window, and then hit the hot-key to print screen
and you get the text only from that particular window…full 80×24 (or
whatever).
Don
I understand that – that's because they aren't (generally) rendering; and when
they ARE rendering (320×200 mode, fer instance) they're doing a complete
simulation of what the console would have done anyway, so it all works well. In
our case, we send text (ASCII) to the system as well… then, thru a software
interface, it's converted to bitoids, just like the IBM in graphics mode. We
don't keep anymore around than they do – less, in fact. In graphics mode, they
have the bit patterns, AND they have the text (in the BIOS map) so they can
mess with it – and we can't. They don't try and read the bitmap, because they
don't _have_ to – someone thought about it (probably one of the few things they
_ever_ thought about) and decided it was a lot more reasonable to keep a text
map around for after-the-fact use. And again, I say – they were right. –Ben–
Ben,
Actualy, ALL they keep is the text record. The video display card
reads that text record and does the visual thingie.
Don
No – it just means that for their ONE window, they kept a text record. Look at
MS-BASIC on the Inferior Barf Machine; scroll the cursor right up thru the
text. niiiice. That capability should be in _each_ conwindow. Screens and
windows, that's part of the problem with this discussion. What we're talking
about is a print-conwindow. nothing more, nothing less. And that capability
would be trivial to implement, if you had source. <looking around expectantly>
–Ben–
Ron,
You sure do have the full graphics ability….are you using the
original disk (copy there of that is) or have you moved the files onto another
disk? If so, did you move all the fonts also?
There is a MAJOR difference in the way the IBM handles text and the way
the Amiga handles text. That major difference is why it's very easy to do a
text dump on an IBM and not on the Amiga. You can do graphic dumps on an IBM
(vs text dumps) and they take as long as a graphic dump on an Amiga.
Normal IBM graphics are character graphics, not bit mapped graphics.
They have graphic characters for corners, t's, x's, horizontal and vertical
lines and the like. When the IBM prints a character to the screen, what it
really does is place the character itself in memory in an array. The IBM
screen handler looks at this array every vertical interupt and creates the
screen by grabbing a bit pattern out of ROM and placing it into the video
memory area. If you did a dump of the array, it would look exactly like normal
text…because it is a normal character array.
If you did a dump of the screen memory…it would look like garbage
because it is the bit patterns. A Print-Screen on the IBM only prints the
array…not the bit patterns. This has advantages of being able to do this,
but disadvantages of not being able to use multiple fonts.
Also, the IBM isn't a windowed environment…that makes a major
difference also.
Don