How to optimize the following... — ZXNet «code.zx»

From Max Melnikov To All 16 March 2001

Hello to you, All. The procedure is written for ROM, it only spoils the screen :) The font is a third of the screen. Subject: ; ;**************************************************************** ; PROCEDURE FOR PRINTING 64 CHARACTERS IN CTPOKE ; DE - FROM WHERE ; BC - HOW MUCH ; #01 - CMEHA ATPIBUTA ; #0D - END OF CTPOKI ; #16 - CMEHA PRINTING POSITION ; ALL CODES LESS THAN #18 ARE IGNORED ; (I.E. NOT PRINTED). ; YL - COLOR ; YH - LITERA ; XL - X ; XH - Y ;------------------------------ ; Uses registers: AF ; IY ; IX ; DE ; B.C. ; HL' ; DE' ; BC' ; It doesn’t matter how it works, the main thing is only on registers!!! FONT EQU #3800 PRN LD A,(DE) CP#01 JR Z,S_COLOR CP#0D JR Z,P_3 CP #16 JR Z,S_COORD CP#18 JP C,P_5 ;------------------------------ P1 LD HY,A EXX LD SP,M_SP_1 CALL PRN_1 M_001 EXX LD A,LX INC A CP #40 JR NZ,P_1 P_4 INC DE DEC B.C. LD A,B OR C RET Z LD A,(DE) CP#0D JR NZ,P_4 P_3 LD A,HX INC A CP#18 JR NZ,P_2 XOR A P_2 LD HX,A XOR A P_1 LD LX,A P_5 INC DE DEC BC LD A,B OR C RET Z JR PRN ;------------------------------ S_COLOR INC DE DEC BC LD A,B OR C RET Z LD A,(DE) LD LY,A S_1 JR P_5 ;------------------------------ S_COORD INC DE DEC BC LD A,B OR C RET Z LD A,(DE) LD HX,A INC DE DEC BC LD A,B OR C RET Z LD A,(DE) LD LX,A JR P_5 ;------------------------------ ; HX - Y ; LX - X ; HY - LITERA ; LY - COLOR ; PRN_1 LD H,FONT/256 LD A,HX LD L,A LD A,LX SRL A OR (HL) INC H LD B,(HL) INC H LD D,(HL) LD E,A COLOR LD A,LY LD (DE),A LD D,B LITERA LD A,HY LD L,A LD H,FONT/256 LD A,LX LD B,8 AND 1 JR NZ,LIT_1 LIT_0 LD A,(DE) AND %00001111 LD C,A LD A,(HL) AND %11110000 OR C LD (DE),A INC D INC H DJNZ LIT_0 RET LIT_1 LD A,(DE) AND %11110000 LD C,A LD A,(HL) AND %00001111 OR C LD(DE),A INC D INC H DJNZ LIT_1 E_PRN RET ;---------------------------------------------------------------- ; And these are the return addresses, the stack moves along them :) M_SP_1 DEFW M_001 Sincerely, Max Melnikov... aka HighLander... aka Uncle Maximka... · ·· ---·.[LIMP BIZKIT].∙.[PRODIGY].∙.[METALLICA].∙.[GIRLS].∙.[BEER].·-- -···

From Kirill Frolov To Max Melnikov 18 March 2001

Press RESET immediately, Max! MM> The procedure is written for ROM, it only damages the screen :) MM> Font - a third of the screen. MM> Subject: What immediately catches your eye: 1. Why length in BC if you can have an end-of-line marker? 2. If the lines are static and are in ROM, then see point 1 one more time. And if not, then why do we need a program without RAM? 3. A 2kb font is too bold, 1kb is enough. 4. If the lines are static, why recalculate the coordinates? to the address on the screen - enter the address right away! 5. Why unnecessary length checks if point 2 is true? 6. Throw out CALL, check for 0x18 too. 7. I WANT TO SLEEP! |-( MM> ----=====..[ Nonsense all of the following]..=====---- Exactly. MM> LIT_0 LD A,(DE) MM> AND %00001111 MM> LD C,A MM> LD A,(HL) MM> AND %11110000 MM> OR C MM> LD (DE),A ld a, (de) xor (hl) and 0x0f xor (hl) ld (hl), a 3 bytes and 8 clock cycles difference! Moreover, if the font is 2kb, then you can use the mask for the byte from the font: ld a, (de)and 0x0f or(hl); hl=font, de=screen ld (de), a And this is already 4 bytes and 15 cycles of difference is already too much! Would you like Windows? write!

From Aleksandr Majorov To Max Melnikov 19 March 2001

Hello Max! 16 Mar 01 22:46, Max Melnikov -> All: [skipped] MM> The procedure is written for PZ, it only spoils the screen :) And also nerves, reading this raw material :)) MM> Font - a third of the screen. In the sense of "fast font" ;) [skipped] MM> ; PROCEDURE FOR PRINTING 64 CHARACTERS IN CTPOKE MM> ; DE - FROM MM> ; BC - CKOLKO MM> ; #01 - CMEHA ATPIBUTA MM> ; #0D - END OF CTPOKI MM> ; #16 - CMEHA PRINTING POSITION So what kind of “end of line” does #0D mean? I found the current “line feed”, but that’s it - nitpicking :) To begin with, here's a question - does _this_ even work? And then...I had vague doubts... (c) that this must be buggy. Now I'll show you: [skipped] MM> PRN LD A,(DE) [skipped] MM> P1 LD HY,A MM> EXX MM> LD SP,M_SP_1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MM> CALL PRN_1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MM> M_001 EXX MM> LD A,LX MM> INC A MM> CP #40 MM> JR NZ,P_1 MM> P_4 INC DE MM> DEC BC MM> LD A,B MM> OR C MM> RET Z Now attention is the question. WHERE will we return on this RET? Because in the “stack table” there is the following: MM> ;-------------------------------------------------------------- MM> ; And these are the return addresses, the stack moves along them :) MM> M_SP_1 DEFW M_001 And when trying to RET, we will take as the address that be before M_SP_1, and this is the code... And now about the subject. Question - what is this printer? I mean, this is printing any system messages? AKA a monitor-debugger built into ROM? I can advise using ASCIIZ strings - i.e. you don't keep in [BC] the length of the line, and you define a certain character as “end of line”. For example, the symbol #00 means "that's it, khan - the line is over." Again, I don’t understand - if this is a “system print”, then why check the line end counter when reading parameters "change of attribute" and "change of print position"? IMHO it can be thrown out there. And do the only check for code #00 in the reading cycle "next character". Off the top of my head - 10-15 bytes will save you at least.And in other cases (not “system printing”) too You can use a line ending character. And probably Do not watch for the end of the line when taking parameters. What else - you have some "unprintable" characters - why the hell? If this is a “system print”, then these characters will definitely not be there. If it’s ordinary, well, maybe a person wants to bring out specific ones symbols... IMHO let everything be printed! We save more bytes. Alexand

From Max Melnikov To Kirill Frolov 19 March 2001

Hello, Kirill Frolov. · ·· ---·.[ Local time 15:49 ].·-- -··· · ·· ---·.[ Kirill Frolov and Max Melnikov ].·-- -··· · ·· ---·.[ Discussing How to optimize the following... ].·-- -··· MM>> The procedure is written for ROM, it only damages the screen :) MM>> Font - a third of the screen. MM>> Subject: KF> Immediately catches your eye: KF> 1. Why length in BC if you can have an end-of-line marker? Lines of different lengths, marker #0D, different numbers of lines at a time. B in principle you might think. KF> 2. If the lines are static and are in ROM, then see point 1 KF> again. And if not, then why do you need a program without RAM? The procedure works on registers because of the memory test that uses it, and then everyone who is not too lazy uses it :) KF> 3. A 2kb font is too bold, 1kb is enough. ASCII encoding (completely, as needed) KF> 4. If the lines are static, why recalculate the coordinates KF> to the address on the screen - enter the address right away! It’s possible (with coordinates more clearly, but slower) KF> 5. Why unnecessary length checks if point 2 is true? KF> 6. Throw out CALL, check for 0x18 too. KF> 7. I WANT TO SLEEP! |-( I'm not surprised, I want it too... MM>> ----=====..[ Nonsense all of the following]..=====---- KF> Exactly. Well, that was by the way... MM>> LIT_0 LD A,(DE) MM>> AND %00001111 MM>> LD C,A MM>> LD A,(HL) MM>> AND %11110000 MM>> OR C MM>> LD (DE),A KF> ld a, (de) KF> xor (hl) KF> and 0x0f KF> xor (hl) KF> ld (hl), a ^^---probably DE here? KF> 3 bytes and 8 clock cycles of difference! I agree, and register C is not involved... KF> Moreover, if the font is 2kb, then you can use a mask for a byte from the font KF> score: KF> ld a, (de) KF> and 0x0f KF> or (hl) ; hl=font, de=screen KF> ld (de), aIt won’t work, it will spoil the neighboring letter (font - there are two identical ones in a familiar place letters). KF> And this is already 4 bytes and 15 cycles of difference is already too much! You should KF> write Windows! No, I won’t write Windows, I’m not BG... Sincerely, Max Melnikov... aka HighLander... aka Uncle Maximka... .·∙.■▀■▄■...[ProDiGy]...[LImp BiZkiT]...[GirlS]...[MetaLlicA]...■▀■▄■.∙·. `∙..∙·---──·─//─..[MW4]...[UnrEAl TouRNameNt]...[KiSh]..─/─·──---·∙..∙'

From Max Melnikov To Aleksandr Majorov 19 March 2001

Hello, Aleksandr Majorov. · ·· ---·.[ Local time 16:17 ].·-- -··· · ·· ---·.[ Aleksandr Majorov and Max Melnikov ].·-- -··· · ·· ---·.[ Discussing How to optimize the following... ].·-- -··· MM>> The procedure is written for PZY, it only spoils the screen :) AM> And also nerves, reading this raw material :)) Anything can happen... MM>> Font - a third of the screen. AM> In the sense of "fast font" ;) He's the one AM> [skipped] MM>> ; PROCEDURE FOR PRINTING 64 CHARACTERS IN CTPOKE MM>> ; DE - FROM MM>> ; BC - CKOLKO MM>> ; #01 - CMEHA ATPIBUTA MM>> ; #0D - END OF CTPOKI MM>> ; #16 - CMEHA PRINTING POSITION AM> So what kind of “end of line” does #0D mean? AM> I found the current “line feed”, well that’s just nitpicking :) I wrote the comments for myself, as usual :) AM> First, here's the question - does _does_ even work? AM> And then...I had vague doubts... (c) that this should AM> glitch. Now I'll show you: It works, I’ll explain now: AM> [skipped] MM>> PRN LD A,(DE) AM> [поскипано] MM>> P1 LD HY,A MM>> EXX MM>> LD SP,M_SP_1 AM> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ В оpигинале у меня этой стpоки нет, стек выставляется pаньше... MM>> CALL PRN_1 AM> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MM>> M_001 EXX MM>> LD A,LX MM>> INC A MM>> CP #40 MM>> JR NZ,P_1 MM>> P_4 INC DE MM>> DEC BC MM>> LD A,B MM>> OR C MM>> RET Z AM> Тепеpь внимание - вопpос. КУДА мы веpнемся по этомy RET? AM> Ибо в "таблице стека" есть тока вот: MM>> ;--------------------------------------------------------------- MM>> ; А это адpеса возвpатов, по ним пеpемещается стек :) MM>> M_SP_1 DEFW M_001 AM> И пpи попытке RET мы возмемь в качестве адpеса то, что AM> to be up to M_SP_1, and this is the code... In the calling ppog, here are the adpesa rewards, _pealnye_ (label M_014 - command after CALL PRN_1): ;------------------------------------------------------- ; And these are the return addresses on which the stack is moved :) M_SP_1 DEFW M_001,M_002 M_SP_2 DEFW M_003,M_004 M_SP_3 DEFW M_005,M_006 M_SP_4 DEFW M_007,M_008 M_SP_5 DEFW M_009,M_010 M_SP_6 DEFW M_011,M_012 DEFW M_013 M_SP_7 DEFW M_025 M_SP_8 DEFW M_014,M_015,M_016,M_017 DEFW M_018 DEFW M_014,M_015,M_016,M_017 DEFW M_019 DEFW M_014,M_015,M_016,M_017 DEFW M_020 DEFW M_014,M_015,M_016,M_017 DEFW M_021 DEFW M_014,M_015,M_016,M_017 DEFW M_022 DEFW M_014,M_015,M_016,M_017 DEFW M_023 DEFW M_014,M_015,M_016,M_017 DEFW M_024 M_SP_9 DEFW M_032,M_014,M_015,M_016,M_017 DEFW M_026 DEFW M_033,M_014,M_015,M_016,M_017 DEFW M_027 DEFW M_014,M_015,M_016,M_017 DEFW M_028 DEFW M_014,M_015,M_016,M_017 DEFW M_029 DEFW M_013 M_SP_10 DEFW M_030 DEFW M_013 M_SP_11 DEFW M_031 DEFW M_013 M_SP_12 DEFW M_034 AM> And now about the subject. AM> Voppos - this printer is what? In a sense is a p/p print AM> any system messages? AKA a monitor-debugger built into ROM? Almost, there's also a memory test... I got acquainted with the rest, therefore: [bite] Sincerely, Max Melnikov... aka HighLander... aka Uncle Maximka... .·∙.■▀■▄■...[ProDiGy]...[LImp BiZkiT]...[GirlS]...[MetaLlicA]...■▀■▄■.∙·. `∙..∙·---──·─//─..[MW4]...[UnrEAl TouRNameNt]...[KiSh]..─/─·──---·∙..∙'

From Kirill Frolov To Max Melnikov 20 March 2001

Press RESET immediately, Max! 19 Mar 01 15:49, Max Melnikov wrote to Kirill Frolov: KF>> Immediately catches your eye: KF>> 1. Why length in BC if you can have an end-of-line marker? MM> Lines of different lengths, marker #0D, lines at a time - miscellaneous MM> quantity. In principle, you can think. Make 0 or FF as the end of the line. Character with code FF instead of zero sometimes must be used because 0 can be used to indicate coordinates or color of displayed characters. KF>> 3. A 2kb font is too bold, 1kb is enough. MM> ASCII encoding (completely, as needed) A 4x8 dot font with 256 characters takes up exactly 1kb. See the letter from Mikhail Zharov in this echo - an example was given there not a bad "printer". KF>> 4. If the lines are static, why recalculate the coordinates KF>> to the address on the screen - enter the address right away! MM> Possible (with coordinates more visually, but slower) Why do you need visibility? In assembler to convert coordinates to addresses use macros. MM>>> LIT_0 LD A,(DE) MM>>> AND %00001111 MM>>> LD C,A MM>>> LD A,(HL) MM>>> AND %11110000 MM>>> OR C MM>>> LD (DE),A KF>> ld a, (de) KF>> xor (hl) KF>> and 0x0f KF>> xor (hl) KF>> ld (hl), a MM> ^^---probably DE here? No. Here it is HL. In DE there is a font, in HL there is a screen. KF>> Moreover, if the font is 2kb, then you can use a mask for a byte from KF>> fill font: KF>> ld a, (de) KF>> and 0x0f KF>> or (hl) ; hl=font, de=screen KF>> ld (de), a MM> It won’t work, it will spoil the adjacent letter (font - there are two in the familiar place MM> identical letters). I slowed down. I tore out a piece from a 2-font printing machine.