42 characters

Press RESET immediately, All! 10 Mar 03 00:47, Ilya Kudryavcev wrote to Serge Zhavoronkoff: SZ>> No one has a subroutine lying around for displaying 40-42 characters in SZ>> line ? IK> and from a font of 2048 kilos, it makes 8192 bytes. Well, expanded IK> also doesn’t look like twenty bytes :) And who thinks about packaged (in what other way?) fonts, occupying less than 2048 bytes? This is for placement in ROM. Probably crunch is not suitable for packaging, and I would like to unpack on the fly, without using a large amount of RAM. * Originally in ZX.SPECTRUM *Crossposted in CODE.ZX

Hello Kirill! 10 Mar 03 07:52, Kirill Frolov -> All: [skipped] IK>> and from a font of 2048 kilos, it makes 8192 bytes. Hy and expanded IK>> also doesn’t look like twenty bytes :) KF> And who thinks about the packaged ones (in what other way?) KF> fonts that occupy less than 2048 bytes? This is for placement in ROM. KF> Hrust is probably not suitable for packaging, but I would like it KF> unpack on the fly, without using a large amount of RAM. Well, IMHO one of the options is not to use the “fast font”. In this case, you can reduce the font size by not using unnecessary characters. The same font in Speck's ROM weighs 768 bytes (if it's not glitchy). The output speed obviously drops, but it will drop with any packaging. Moreover, a “regular font” will be much faster than a packaged one. Alexand

Hello Kirill! March 10, 2003 (it was 07:52 then) Kirill Frolov in his letter to All wrote: KF> What do you think about packaged (in what other way?) KF> fonts that occupy less than 2048 bytes? This is for placement in ROM. KF> Hrust is probably not suitable for packaging, but I would like it KF> unpack on the fly, without using a large amount of RAM. And if you cut off the upper and lower parts of the sign, they are practically not are used, many viewers save on clock cycles, you can also save in memory... So we get 6 * 256 = 1536 bytes, IMHO not bad. In principle, you can save money by traversing matching characters, for example Many Russian and Latin characters are identical in style. But in this case it is necessary to form a table of 256 bytes so that it points to location of the symbol image, she can eat almost everything saved memory. Best regards, Dmitry

Press RESET immediately, Dmitry! 11 Mar 03 08:42, Dmitry Mikhalchenkov wrote to Kirill Frolov: KF>> What do you think about packaged ones (in what other way?) KF>> fonts that occupy less than 2048 bytes? This is for placement in KF>> ROM. Hrust is probably not suitable for packaging, and I would like it KF>> unpack on the fly, without using a large amount of RAM. DM> And if you cut off the upper and lower parts of the sign, they are practically the same DM> are not used, many viewers save on clock cycles, you can also DM> save on memory too... Savings at the expense of quality. Moreover, if the brake output is in ROM procedures You can still tolerate the clumsy letters... I wouldn’t do that. "q" characters "p", "_" use the bottom row of the matrix, the characters "^" and "~" use the top line. And then there are pseudographics... DM> So we get 6 * 256 = 1536 bytes, IMHO not bad. A 6x8 font does not use two vertical rows in the matrix. 8*2*256/8bit=512 bytes saving. But fonts need to be stored rotated 90 degrees form. DM> In principle, you can save money on bypassing matching characters, soYou can save a lot by compressing the font with something like Huffman. But time It takes a lot to unpack. :-(

Hello Kirill! March 12, 2003 (it was 00:10 then) Kirill Frolov in his letter to Dmitry Mikhalchenkov wrote: KF> Savings at the expense of quality. Moreover, if the brake output is in ROM KF> procedures can still be tolerated, but clumsy letters... I wouldn’t do that KF> do. The symbols "q", "p", "_" use the bottom row of the matrix KF> characters "^" and "~" uses the top line. And there is also KF> pseudographics... Well why? For example, in many viewers, 42 characters are normally drawn The fonts cannot be called clumsy at all, even though they are 6 lines high. IMHO, it’s our job to offer - yours to refuse :) DM>> So we get 6 * 256 = 1536 bytes, IMHO not bad. KF> The 6x8 font does not use two vertical rows in the matrix. KF> 8*2*256/8bit=512 bytes saving. But fonts need to be stored rotated KF> at 90 degrees view. Why turn it over? You can move the next symbol onto these two rows, this way we can save on every fourth character (256 / 4) x 8 = 512 bytes. The same ones, in case of their coup... As for the shift, it’s still impossible to display a 6 pixel character without scrolling.Other methods, IMHO, will not be very economical, because if we succeed symbols with matrices of uneven volume, then we will need to either spend time to calculate the address of the required matrix, or build a plate, which is also not acceptable in this case... Did you write that a small buffer can be used when unpacking? It's small which one? Is 2 kilos a lot? And if during initialization you unpack the font into RAM and then use it? Best regards, Dmitry