Hi,
On Wed, 13 Jul 2022 at 00:22, Steve Nickolas wrote:
> On Tue, 12 Jul 2022, Aitor Santamaría wrote:
> (I think the PC Convertible is, in fact, the only reason there's even an
> option - it supports loadable charsets, but only in 8x8, so installing a
> full charset, 8x8+8x14+8x16, would be a
On Tue, 12 Jul 2022, Aitor Santamaría wrote:
Once solved the "legal issues", one way to go could be to enrich DISPLAY
instead of making a new driver. DISPLAY is organised as having
"sub-drivers":
DISPLAY CON = (EGA,437,2)
where "EGA" is used to select the sub-driver, 437 is to declare the
Hello Steve,
On Tue, 12 Jul 2022 at 12:19, Steve Nickolas wrote:
> I've been working on this for my own project, and it's only useful for the
> rare CGA or Tandy users out there (which is probably why MS-DOS 6
> relegated it to the Supplemental disk and PC DOS 6 removed it).
>
> GRAFTABL hooks
On at 2022-07-12 21:59 +0200, C. Masloch wrote:
On at 2022-07-12 15:45 -0400, Steve Nickolas wrote:
The new "new2F":
new2F: cmp ah, 0xB0 ; is it ours?
je .2
.1: jmp 0:0
.2: cmp al, 1
ja .1 ; >1 -
On Tue, 12 Jul 2022, C. Masloch wrote:
On at 2022-07-12 15:45 -0400, Steve Nickolas wrote:
I haven't uploaded a copy of the new source anywhere yet - it'll
probably be in the next DOSLITE source batch along with my work on a few
other DOS commands, but I don't want to replace the copy I've
On at 2022-07-12 15:45 -0400, Steve Nickolas wrote:
I haven't uploaded a copy of the new source anywhere yet - it'll
probably be in the next DOSLITE source batch along with my work on a few
other DOS commands, but I don't want to replace the copy I've already
uploaded, and DOSLITE isn't ready
On Tue, 12 Jul 2022, C. Masloch wrote:
Your technique is the default way to do this, most TSRs ever written did
it that way. The SMC is just a small optimisation over it.
Codegolfing is good, when done right. :D
If you really want to continue to use the free software release of
Microsoft's
I haven't uploaded a copy of the new source anywhere yet - it'll probably
be in the next DOSLITE source batch along with my work on a few other DOS
commands, but I don't want to replace the copy I've already uploaded, and
DOSLITE isn't ready to go onto anything like github or gitlab yet.
As I
On at 2022-07-12 15:15 -0400, Steve Nickolas wrote:
You do not use an IBM Interrupt Sharing Protocol (IISP) [11] header
for your interrupt hook. Therefore, you could optimise this part a
bit, from:
old2F: dd 0x
...
.1: jmp far [cs:old2F]
Into this:
.1: jmp
On Tue, 12 Jul 2022, C. Masloch wrote:
(Only replied-to portions copied)
Further, you calculate the size of the PSP block to keep resident by using
test, add, and shifts:
mov dx, trans ; Allow everything preceding the
test dx, 0x000F ;
On at 2022-07-12 20:01 +0200, Jose Senna wrote:
Bret Johnson said:
> The way it works is to make a "copy" of
> itself at the top of conventional memory,
> terminates itself (using a normal DOS
> terminate process, which includes deleting
> the original PSP), and then continues
>
Hi list,
On at 2022-07-12 16:29 +, Bret Johnson wrote:
For TSR's, there are additional things you can do to reduce memory. You can
look at the source code for my PRTSCR program (available at
http://bretjohnson.us) that uses a BUNCH of tricks. For example, it doesn't
even use the DOS
Hello Steve Nickolas,
I suppose I could step on zero page (PSP) but I don't know how safe that
is. The graphics table is written at CS:0100-04FF (this could be why
Microsoft's version is incompatible with mine, while mine is compatible
with Microsoft's).
The command line buffer starting at
Bret Johnson said:
> The way it works is to make a "copy" of
> itself at the top of conventional memory,
> terminates itself (using a normal DOS
> terminate process, which includes deleting
> the original PSP), and then continues
> running from the "copy". The "copy" decides
> where the
On Wed, 13 Jul 2022, TK Chia wrote:
Hello Bret Johnson,
[me:]
GRAFTABL basically just needs to install a 1024-byte glyph table
somewhere in conventional memory, and point the int 0x1f vector at it.
(The glyph table can then be used to display "extended ASCII" characters
in a CGA graphics
On Wed, 13 Jul 2022, TK Chia wrote:
Well, this is GRAFTABL we are discussing here, so it probably does
qualify as one of the "simplest TSRs". :-)
GRAFTABL basically just needs to install a 1024-byte glyph table
somewhere in conventional memory, and point the int 0x1f vector at it.
(The glyph
Hello Bret Johnson,
[me:]
GRAFTABL basically just needs to install a 1024-byte glyph table
somewhere in conventional memory, and point the int 0x1f vector at it.
(The glyph table can then be used to display "extended ASCII" characters
in a CGA graphics mode.) There is no need to even install
Hello Bret Johnson,
[Steve Nickolas:]
Stack allocation could be implicit. Don't know how NASM is handling
this, as I wouldn't touch that one with a barge pole... ;-)
Check the list file when assembling this..
In TSR's, the stack is NEVER implicit. It is something you must explicitly
> Stack allocation could be implicit. Don't know how NASM is handling
> this, as I wouldn't touch that one with a barge pole... ;-)
> Check the list file when assembling this..
In TSR's, the stack is NEVER implicit. It is something you must explicitly
handle somewhere in the TSR. For all but
For TSR's, there are additional things you can do to reduce memory. You can
look at the source code for my PRTSCR program (available at
http://bretjohnson.us) that uses a BUNCH of tricks. For example, it doesn't
even use the DOS TSR interrupt.
The way it works is to make a "copy" of itself
On 7/12/2022 9:13 AM, Steve Nickolas wrote:
On Tue, 12 Jul 2022, Ralf Quint wrote:
On 7/12/2022 3:01 AM, Steve Nickolas wrote:
For some reason I don't understand (me am n00b) the footprint is 144
bytes larger than the MS-DOS 5/6 version, but the binary is smaller.
Most commonly, these
On Tue, 12 Jul 2022, Ralf Quint wrote:
On 7/12/2022 3:01 AM, Steve Nickolas wrote:
For some reason I don't understand (me am n00b) the footprint is 144 bytes
larger than the MS-DOS 5/6 version, but the binary is smaller.
Most commonly, these kind of things are due to a different amount
On 7/12/2022 3:01 AM, Steve Nickolas wrote:
For some reason I don't understand (me am n00b) the footprint is 144
bytes larger than the MS-DOS 5/6 version, but the binary is smaller.
Most commonly, these kind of things are due to a different amount of
stack or other dynamic memory being
On Tue, 12 Jul 2022, Jerome Shidel wrote:
I haven’t looked at the code for either. But, there are some things in
general to consider with TSRs.
I would assume the memory footprint difference may be related to
optimization of the executables layout and data storage. Basically, when
you
Hi,
> On Jul 12, 2022, at 6:19 AM, Steve Nickolas wrote:
> [..]
> For some reason I don't understand (me am n00b) the footprint is 144 bytes
> larger than the MS-DOS 5/6 version, but the binary is smaller.
I haven’t looked at the code for either. But, there are some things in general
to
I've been working on this for my own project, and it's only useful for the
rare CGA or Tandy users out there (which is probably why MS-DOS 6
relegated it to the Supplemental disk and PC DOS 6 removed it).
GRAFTABL hooks INT1F to provide the upper half of the charset in graphics
mode on a CGA
26 matches
Mail list logo
