Forum unknown
· Programming
_CXD22
9 messages in this thread
No! Stop! The _CD22 routine has to do with the multiply you had in that code,
but if you link with 'lc.lib', your code size will go up astronomically.
Instead of linking differently, write an in-line 'for()' or 'while' to do the
multiply with addition instead. I think you'll be happier with the result.
Also, I'm collecting printer drivers for the AMICUS public domain library.
Will your driver be PD? If so, I'd love to spread the source and executable
around, so more drivers will get written.
i think it was the "%" operator he used, actually.
–Scotty
i think it was the "%" operator he used, actually.
–Scotty
Actually, _CXD is a divide ( it's the modulo ), _CXM's are multiplies. I don't
think the code would grow that much by including the library, so long as you
don't have the startup file ( which brings in the world ). As far as I know,
just bringing in _CXD would add maybe 100-400 bytes.
Actually, _CXD is a divide ( it's the modulo ), _CXM's are multiplies. I don't
think the code would grow that much by including the library, so long as you
don't have the startup file ( which brings in the world ). As far as I know,
just bringing in _CXD would add maybe 100-400 bytes.
John, I am writing the Epson LQ-800 driver. I already uploaded a driver for
the Epson LQ-800 in the Utilities Data Library here on the Amiga Forum. It
is P.D. and you may download it and use it for AMICUS. The driver I uploaded
uses 8-pin double density graphics mode with programs such as DPaint. I am
now trying to figure out how to get 24-pin graphics. So far, I have been
successful in getting printer to enter 24-pin triple density graphics mode.
I am now trying to figure out how to triple the amount of graphics data that
programs such as DPaint generates (data has to be tripled and bits have to be
shifted somehow). Any ideas? By the way, including lc.lib did not increase
my program size that much. When c.o is used in the linking process, then the
program size increases dramatically! – Fred –
You need to convert 8 bits of data into 24, probably something like this:
00110101 becomes…
000000111111000111000111
I'm going to present a fast way to do it, in C, but I'm not going to run my
example through the C compiler and it will probably have some serious
problems — I just can't seem to develop any liking for C. But here goes…
I hope you can salvage it to the point of usability:
long expand24(b)
unsigned char b;
{
short twelve[16]={00000,00007,00070,00077,00700,00707,00770,00777,
07000,07007,07070,07077,07700,07707,07770,07777};
/* octal is convenient because we're making 1 bit into 3 — just change the
binary representation of the numbers 0..15 by replacing "1" with "7". /*
return(((twelve[b>>4])<<12) | (twelve[b & 0xF]));
}
Hmmm… that wasn't so bad after all, but I refuse to run it through Aztec
to find out what I did wrong… then I'd have to spend 20 minutes hitting
myself… – Bela
You need to convert 8 bits of data into 24, probably something like this:
00110101 becomes…
000000111111000111000111
I'm going to present a fast way to do it, in C, but I'm not going to run my
example through the C compiler and it will probably have some serious
problems — I just can't seem to develop any liking for C. But here goes…
I hope you can salvage it to the point of usability:
long expand24(b)
unsigned char b;
{
short twelve[16]={00000,00007,00070,00077,00700,00707,00770,00777,
07000,07007,07070,07077,07700,07707,07770,07777};
/* octal is convenient because we're making 1 bit into 3 — just change the
binary representation of the numbers 0..15 by replacing "1" with "7". /*
return(((twelve[b>>4])<<12) | (twelve[b & 0xF]));
}
Hmmm… that wasn't so bad after all, but I refuse to run it through Aztec
to find out what I did wrong… then I'd have to spend 20 minutes hitting
myself… – Bela
John, I am writing the Epson LQ-800 driver. I already uploaded a driver for
the Epson LQ-800 in the Utilities Data Library here on the Amiga Forum. It
is P.D. and you may download it and use it for AMICUS. The driver I uploaded
uses 8-pin double density graphics mode with programs such as DPaint. I am
now trying to figure out how to get 24-pin graphics. So far, I have been
successful in getting printer to enter 24-pin triple density graphics mode.
I am now trying to figure out how to triple the amount of graphics data that
programs such as DPaint generates (data has to be tripled and bits have to be
shifted somehow). Any ideas? By the way, including lc.lib did not increase
my program size that much. When c.o is used in the linking process, then the
program size increases dramatically! – Fred –