🚀 go-pugleaf

Johnny napisał(a):
> Korzystając z przerwania 21h możemy wyrzucić na ekran ciąg bajtów,
> którego adres umieszczamy w dx. Ciąg powinien kończyć się znakiem '$'.
> Można także umieścić 0dh,0ah dzięki czemu przejdziemy do nowej linii.
> 
> Czy coś takiego można łatwo osiągnąć przerwaniem 10h tak by nie
> przesuwać wskaźnika do nowego wiersza funkcją 2h tego przerwania?

 Tzn. przejście do nowej linii bez ah=2? Oczywiście, na co najmniej
dwa sposoby: ah=0eh (al=0a, al=0d), ah=13h (wyświetlanie napisów).

-- 
Pozdrawiam, Bogdan                                  (Linux i FreeDOS)
Kurs assemblera x86 (DOS i Linuks): http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Prawdziwy, bezpieczny komunikator:                   www.JabberPL.org

Bogdan (bogdro) napisał(a):
>  Tzn. przejście do nowej linii bez ah=2? Oczywiście, na co najmniej
> dwa sposoby: ah=0eh (al=0a, al=0d), ah=13h (wyświetlanie napisów).
> 

Z ah,2h. Tyle, że najpierw podawałam al=0dh a potem al=0ah. Taka jest
kolejność w ciągu dla int21h. Dlaczego tutaj jest inaczej?

-- 
Johnny

Johnny napisał(a):
> Bogdan (bogdro) napisał(a):
>>  Tzn. przejście do nowej linii bez ah=2? Oczywiście, na co najmniej
>> dwa sposoby: ah=0eh (al=0a, al=0d), ah=13h (wyświetlanie napisów).
>>
> 
> Z ah,2h.

Cytat:
" nie przesuwać wskaźnika do nowego wiersza funkcją 2h tego
 przerwania? "
Więc przyjąłem, że miało być jednak bez użycia funkcji ah=2.

> Tyle, że najpierw podawałam al=0dh a potem al=0ah. Taka jest
> kolejność w ciągu dla int21h. Dlaczego tutaj jest inaczej?

 Bo tak mi się napisało :) Nie ma różnicy.

 10=0a=LF to Line Feed, czyli przejście kursora do kolejnego wiersza,
ale nie na jego początek (po prostu wiersz niżej, do tej samej kolumny).

 13=0d=CR to Carriage Return, czyli przejście kursora na początek
bieżącego wiersza.

 CR+LF i LF+CR to po prostu dwie różne "drogi przesuwania się kursora
po prostokącie": w dół i lewo lub najpierw w lewo, a potem w dół.

-- 
Pozdrawiam, Bogdan                                  (Linux i FreeDOS)
Kurs assemblera x86 (DOS i Linuks): http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Prawdziwy, bezpieczny komunikator:                   www.JabberPL.org

Dzięki.

-- 
Johnny

Bogdan (bogdro) wrote:
> Johnny napisał(a):
>> Bogdan (bogdro) napisał(a):
>>>  Tzn. przejście do nowej linii bez ah=2? Oczywiście, na co najmniej
>>> dwa sposoby: ah=0eh (al=0a, al=0d), ah=13h (wyświetlanie napisów).
>>>
>> Z ah,2h.
> 
> Cytat:
> " nie przesuwać wskaźnika do nowego wiersza funkcją 2h tego
>  przerwania? "
> Więc przyjąłem, że miało być jednak bez użycia funkcji ah=2.
> 
>> Tyle, że najpierw podawałam al=0dh a potem al=0ah. Taka jest
>> kolejność w ciągu dla int21h. Dlaczego tutaj jest inaczej?
> 
>  Bo tak mi się napisało :) Nie ma różnicy.
> 

Jezeli piszesz tylko na ekranie to kolenosc nie ma znaczenia,
w przypadku zapisu do pliku musi to byc sekwencja "\r\n"
gdyz niektore programy moga miec trudnosci z interpretacja
tak zapisanego pliku.

-- 
Pozdrawiam
Lopez

Bogdan (bogdro) wrote:
>> Tyle, że najpierw podawałam al=0dh a potem al=0ah. Taka jest
>> kolejność w ciągu dla int21h. Dlaczego tutaj jest inaczej?
> 
>  Bo tak mi się napisało :) Nie ma różnicy.
> 
>  10=0a=LF to Line Feed, czyli przejście kursora do kolejnego wiersza,
> ale nie na jego początek (po prostu wiersz niżej, do tej samej kolumny).
> 
>  13=0d=CR to Carriage Return, czyli przejście kursora na początek
> bieżącego wiersza.
> 
>  CR+LF i LF+CR to po prostu dwie różne "drogi przesuwania się kursora
> po prostokącie": w dół i lewo lub najpierw w lewo, a potem w dół.

Ma znaczenie - ma być CR, a potem LF. Oczywiście ekranowi wszystko 
jedno, ale w niemal wszystkich inych urządzeniach to NIE JEST wszytko jedno.

Bernard napisał(a):
> Bogdan (bogdro) wrote:
> >> Tyle, że najpierw podawałam al=0dh a potem al=0ah. Taka jest
> >> kolejność w ciągu dla int21h. Dlaczego tutaj jest inaczej?
> >
> >  Bo tak mi się napisało :) Nie ma różnicy.
> >
> >  10=0a=LF to Line Feed, czyli przejście kursora do kolejnego wiersza,
> > ale nie na jego początek (po prostu wiersz niżej, do tej samej kolumny).
> >
> >  13=0d=CR to Carriage Return, czyli przejście kursora na początek
> > bieżącego wiersza.
> >
> >  CR+LF i LF+CR to po prostu dwie różne "drogi przesuwania się kursora
> > po prostokącie": w dół i lewo lub najpierw w lewo, a potem w dół.
>
> Ma znaczenie - ma być CR, a potem LF. Oczywiście ekranowi wszystko
> jedno, ale w niemal wszystkich inych urządzeniach to NIE JEST wszytko jedno.

Tak zupełnie z ciekawości... :]
Jakie "inne urządzenia" masz na myśli?

Pozdrawiam

Matuzalem wrote:
> Bernard napisał(a):
>>>  Bo tak mi się napisało :) Nie ma różnicy.
>>>
>>>  10=0a=LF to Line Feed, czyli przejście kursora do kolejnego wiersza,
>>> ale nie na jego początek (po prostu wiersz niżej, do tej samej kolumny).
>>>
>>>  13=0d=CR to Carriage Return, czyli przejście kursora na początek
>>> bieżącego wiersza.
>>>
>>>  CR+LF i LF+CR to po prostu dwie różne "drogi przesuwania się kursora
>>> po prostokącie": w dół i lewo lub najpierw w lewo, a potem w dół.
>> Ma znaczenie - ma być CR, a potem LF. Oczywiście ekranowi wszystko
>> jedno, ale w niemal wszystkich inych urządzeniach to NIE JEST wszytko jedno.
> 
> Tak zupełnie z ciekawości... :]
> Jakie "inne urządzenia" masz na myśli?

Wszelkie urządzenia, które były projektowane z myślą o radzeniu sobie z 
trzema możliwymi sekwencjami końca wiersza: CR, LF albo CR+LF. Taka 
drukarka (ew. program do konwersji plików) domyśla się, że CR, to w 
rzeczywistości CR+LF, podobnie jak samo LF. Jak zobaczy LF, to zrobi 
CR+LF, potem zobaczy LF i znów zrobi CR+LF - wydruk będzie miał co drugą 
linię pustą. żaden normalny projektant drukarki nie wpadnie na to, żer 
ktoś mógłby używać swojej własnej, niestandardowej sekwencji końca wiersza.

Niezależnie od powyższego, dobrym zwyczajem jest trzymanie się 
standardów, a tu mamy trzy standardy (DOS/Windows, Mac, Unix). Czwartego 
(LF+CR) nie ma.

> Wszelkie urządzenia, które były projektowane z myślą o radzeniu sobie
> z trzema możliwymi sekwencjami końca wiersza: CR, LF albo CR+LF. Taka
> drukarka (ew. program do konwersji plików) domyśla się, że CR, to w
> rzeczywistości CR+LF, podobnie jak samo LF. Jak zobaczy LF, to zrobi
> CR+LF, potem zobaczy LF i znów zrobi CR+LF - wydruk będzie miał co
> drugą linię pustą.

To znaczy, że ta drukarka się standardu nie trzyma. Znaczenie CR i LF jest 
jasno określone, i pierwotne przeznaczenie było właśnie dla drukarek.

Aż przeprowadziłem test: hp959c, USB.

plik wyglądał tak:

1111111111<LF>
2222222222<CR>
3333333333<CR><LF>
4444444444<LF><CR>
5555555555

wydruk wyglądał tak:

1111111111
33333333332222222222
4444444444
5555555555

czyli: LF obniża, CR wraca, CRLF i LFCR robią to samo. Tak powinna się 
drukarka zachowywać, inne zachowanie jest niestandardowe.

IMHO koniec wiersza powinien być crlf, pomysły makówkowy i uniksowy są bez 
sensu (choćby potrzebna jest konwersja przy wysyłaniu na drukarkę...)


-- 
Azarien

Bernard napisał(a):
> Matuzalem wrote:
> > Bernard napisał(a):
> >>>  Bo tak mi się napisało :) Nie ma różnicy.
> >>>
> >>>  10=0a=LF to Line Feed, czyli przejście kursora do kolejnego wiersza,
> >>> ale nie na jego początek (po prostu wiersz niżej, do tej samej kolumny).
> >>>
> >>>  13=0d=CR to Carriage Return, czyli przejście kursora na początek
> >>> bieżącego wiersza.
> >>>
> >>>  CR+LF i LF+CR to po prostu dwie różne "drogi przesuwania się kursora
> >>> po prostokącie": w dół i lewo lub najpierw w lewo, a potem w dół.
> >> Ma znaczenie - ma być CR, a potem LF. Oczywiście ekranowi wszystko
> >> jedno, ale w niemal wszystkich inych urządzeniach to NIE JEST wszytko jedno.
> >
> > Tak zupełnie z ciekawości... :]
> > Jakie "inne urządzenia" masz na myśli?
>
> Wszelkie urządzenia, które były projektowane z myślą o radzeniu sobie z
> trzema możliwymi sekwencjami końca wiersza: CR, LF albo CR+LF. Taka
> drukarka (ew. program do konwersji plików) domyśla się, że CR, to w
> rzeczywistości CR+LF, podobnie jak samo LF. Jak zobaczy LF, to zrobi
> CR+LF, potem zobaczy LF i znów zrobi CR+LF - wydruk będzie miał co drugą
> linię pustą. żaden normalny projektant drukarki nie wpadnie na to, żer
> ktoś mógłby używać swojej własnej, niestandardowej sekwencji końca wiersza.
>
> Niezależnie od powyższego, dobrym zwyczajem jest trzymanie się
> standardów, a tu mamy trzy standardy (DOS/Windows, Mac, Unix). Czwartego
> (LF+CR) nie ma.

A to wyniki mojego testu - bezpośredniego wysłania znaków - na
drukarce Canon BJC-240 LPT:

wysłany ciąg:
0dh, 0ah, "CR", 0dh, "LF", 0ah, "CR LF", 0dh, 0ah, "LF CR", 0ah, 0dh,
"CR CR", 0dh, 0dh, "LF LF", 0ah, 0ah, "CR CR LF", 0dh, 0dh, 0ah, "LF LF
CR", 0ah, 0ah, 0dh

troszeczke bardziej przejrzyście :P ):
0dh,
0ah,
"CR", 0dh,
"LF", 0ah,
"CR LF", 0dh, 0ah,
"LF CR", 0ah, 0dh,
"CR CR", 0dh, 0dh,
"LF LF", 0ah, 0ah,
"CR CR LF", 0dh, 0dh, 0ah,
"LF LF CR", 0ah, 0ah, 0dh

wynik (po wydrukowaniu):

---- - oznacza koniec/początek strony

------------------------------


CR/LF ; CR nałożyło się na LF
CR LF
LF CR
CR CR/LF LF ; CR CR nałożyło się na LF LF

CR CR LF
LF LF CR
------------------------------

Jak widać, drukarce obojętne jest co jest pierwsze CR/LF.

Pozdrawiam

Wiktor S. wrote:
>> Wszelkie urządzenia, które były projektowane z myślą o radzeniu sobie
>> z trzema możliwymi sekwencjami końca wiersza: CR, LF albo CR+LF. Taka
>> drukarka (ew. program do konwersji plików) domyśla się, że CR, to w
>> rzeczywistości CR+LF, podobnie jak samo LF. Jak zobaczy LF, to zrobi
>> CR+LF, potem zobaczy LF i znów zrobi CR+LF - wydruk będzie miał co
>> drugą linię pustą.
> 
> To znaczy, że ta drukarka się standardu nie trzyma. Znaczenie CR i LF 
> jest jasno określone, i pierwotne przeznaczenie było właśnie dla drukarek.

Zgaadza się. A potem pojawili się tacy, co zaczęli na końcu wiersza 
pisać coś innego niż para CR+LF, a wtedy producenci drukarek musieli 
wymyślić, co z tym fantem zrobić
> 
> Aż przeprowadziłem test: hp959c, USB.
> 
> plik wyglądał tak:
> 
> 1111111111<LF>
> 2222222222<CR>
> 3333333333<CR><LF>
> 4444444444<LF><CR>
> 5555555555
> 
> wydruk wyglądał tak:
> 
> 1111111111
> 33333333332222222222
> 4444444444
> 5555555555
> 
> czyli: LF obniża, CR wraca, CRLF i LFCR robią to samo. Tak powinna się 
> drukarka zachowywać, inne zachowanie jest niestandardowe.

Tak powinna się zachowywać drukarka, która nie jest przystosowana do 
pracy pod Unixem lub MacOSem i tysiącem dziwacznych programów 
działających na różnych urządzeniach.

Ponieważ jednak klienci życzą sobie, żeby drukarki działały pod UNixem 
lub z dziwnymi programami, drukarki są wyposażone w możliwość pracy z 
innym niż standardowy koniec wiersza. Robi się to tak, że drukarka 
"domyśla się" CR przed samotnym LF i LF po samotnym CR. Przy CR+LF nie 
domyśla się nic, bo nie musi. Jak zobaczy LF i CR, to LF jest zamieniane 
w CR+LF, a CR - w drugie CR+LF - i mamy pusty wiersz.

> IMHO koniec wiersza powinien być crlf, pomysły makówkowy i uniksowy są 
> bez sensu (choćby potrzebna jest konwersja przy wysyłaniu na drukarkę...)

Oczywiście z pierwszą częścią zdania nie sposób się nie zgodzić, ale 
druga nie wytrzymuje konfrontacji z rzeczywistością. Tak się składa, że 
kiedyś pisałem oprogramowanie do współpracy z drukarkami, a potem 
konstruowałem drukarki, w tym również tworzyłem ich firmware. Dlatego 
wielbicieli sekwencji LF+CR najchętniej bym odstrzelił.

Bernard napisał(a):
> Tak się składa, że kiedyś pisałem oprogramowanie do współpracy z drukarkami, a
> potem konstruowałem drukarki, w tym również tworzyłem ich firmware.
> Dlatego wielbicieli sekwencji LF+CR najchętniej bym odstrzelił.

ooo..

a czy mógłyś się podzielić informacjami jakie to oprogramowanie (a
raczej w czmy pisane i na jakie platformy, np. z czego korzystałeś
tworząc je... itp.).
Co masz na myśli: "potem konstruowałem drukarki", tzn. robiłeś je
(w sensie płytki drukowane, śrubeczki:P itd.) ??
Jeśli tak, to mógłyś napisać choć ogólnie jak to wygląda "od
kuchni"?

Dzięki wielkie i sorry, że tak męcze ucho, ale po prostu z
ciekawości :]

Pozdrawiam

> 1111111111<LF>
> 2222222222<CR>
> 3333333333<CR><LF>
> 4444444444<LF><CR>
> 5555555555


U mnie w notatniku plik zrobiony wg. powyższego wzoru wygląda
jn. (oczywiście zamiast<LF>, czy <CR> są "kwadraciki", ale nie dadzą
się w takiej postaci przekopiować do OE):

1111111111<LF>2222222222<CR>3333333333
4444444444<LF><CR>5555555555

Mój Lexmark Z615 wydrukował to dokładnie tak jak widać w notepadzie
(zamiast opisowej postaci LF i CR są "kwadraciki").

-- 
Remek

Remek napisał(a):
> > 1111111111<LF>
> > 2222222222<CR>
> > 3333333333<CR><LF>
> > 4444444444<LF><CR>
> > 5555555555
>
>
> U mnie w notatniku plik zrobiony wg. powyższego wzoru wygląda
> jn. (oczywiście zamiast<LF>, czy <CR> są "kwadraciki", ale nie dadzą
> się w takiej postaci przekopiować do OE):
>
> 1111111111<LF>2222222222<CR>3333333333
> 4444444444<LF><CR>5555555555

a gdzie test na <CR><LF> :P...

> Mój Lexmark Z615 wydrukował to dokładnie tak jak widać w notepadzie
> (zamiast opisowej postaci LF i CR są "kwadraciki").
> 
> -- 
> Remek

Pozdrawiam

Remek napisał(a):
> > 1111111111<LF>
> > 2222222222<CR>
> > 3333333333<CR><LF>
> > 4444444444<LF><CR>
> > 5555555555
>
>
> U mnie w notatniku plik zrobiony wg. powyższego wzoru wygląda
> jn. (oczywiście zamiast<LF>, czy <CR> są "kwadraciki", ale nie dadzą
> się w takiej postaci przekopiować do OE):
>
> 1111111111<LF>2222222222<CR>3333333333
> 4444444444<LF><CR>5555555555
>
> Mój Lexmark Z615 wydrukował to dokładnie tak jak widać w notepadzie
> (zamiast opisowej postaci LF i CR są "kwadraciki").
>
> --
> Remek

Dziwne, drukarki której ja użyłem to prawie "zabytek", a nie
wydrukował "kwadracików" i do tego <LF><CR>/<CR><LF> nie miało
różnicy ( post z testem... ) wydrukował tak jak się spodziewałem.
Widać każdy inaczej wdraża "standardy"... :]

Pozdrawiam

Jeszcze dla pewności dorzucam hexowy zrzut pliku (połamałem
go na potrzeby OE, w rzeczywistości jest to jeden ciąg):

313131313131313131310A
323232323232323232320D
333333333333333333330D0A
343434343434343434340A0D
353535353535353535350D0A

-- 
Remek

> a gdzie test na <CR><LF> :P...

W notepadzie nie widać prawidłowo (dla DOS/Windows) zastosowanego
ciągu "białych" znaków w takiej postaci jakbyś chciał, ale on jest.
Wystarczy dobrze patrzeć. Jest to przełamanie wiersza i rozpoczęcie
pisania kolejnych znaków w nowej linii. Wrzucam Ci w następnym poście
zrzut w hex.

-- 
Remek

> Dziwne, drukarki której ja użyłem to prawie "zabytek",

I to chyba przyczyna nieprawidłowego (moim zdaniem) i
nielogicznego zinterpretowania pliku.

> Widać każdy inaczej wdraża "standardy"... :]

Standardem dla drukarki musi (powinna) być obsługa najróżniejszych
programów, z których trzeba drukować wyniki pracy. Z notepada drukuje
się chyba najmniej, za to wiele z Word'a, Excel'a, programów
graficznych rastrowych i wektorowych, oraz jeszcze setki innych, które
trudno wymieniać. Reasumując - drukarka musi "rozumieć" format pliku
danego programu i umieć przenieść go na papier tak jak jest widziany w
danym programie. A nie są to tylko znaki drukarskie w ASCII, ale wiele
elementów formatowania, znaków specjalnych i innych "utrudnień".

W związku z powyższym uważam, że moja drukarka zachowała się
prawidłowo.

-- 
Remek

Remek napisał(a):
> > Dziwne, drukarki której ja użyłem to prawie "zabytek",
>
> I to chyba przyczyna nieprawidłowego (moim zdaniem) i
> nielogicznego zinterpretowania pliku.

Dla mnie jest to bardziej logiczne - przynajmniej, nie mam
"kwadracików" tylko nowe wiersze.

> > Widać każdy inaczej wdraża "standardy"... :]
>
> Standardem dla drukarki musi (powinna) być obsługa najróżniejszych
> programów, z których trzeba drukować wyniki pracy. Z notepada drukuje
> się chyba najmniej, za to wiele z Word'a, Excel'a, programów

Nie wiem, czy zauważyłeś, ale ja nie korzystałem z żadnych
"edytorów", tylko wysłałem raw ciąg bezpośrednio do drukarki...

> graficznych rastrowych i wektorowych, oraz jeszcze setki innych, które
> trudno wymieniać.

To jest co innego...

> Reasumując - drukarka musi

Drukarka na pewno musi drukować... :]

> "rozumieć" format pliku danego programu i umieć przenieść go na papier tak
>  jak jest widziany w danym programie.

rozumieć format? tzn. zinterpretować go?
Nie słyszałem o drukarce która by "rozumiała" to co drukuje...
Drukarka nie rozrużnia zdjęcia, od czystego tekstu.
Jeśli już ma coś "rozumieć" to pewne sygnały które oznajmiają
np. koniec/początek strony, nowy wiersz - w skrócie znaki białe (no
i może jakieś specyficzne dla danego modelu)
Grafika to nic innego jak piksele == również tekst...

> A nie są to tylko znaki drukarskie w ASCII, ale wiele elementów
> formatowania, znaków specjalnych i innych "utrudnień".

Zapewniam Cię, drukarka nie musi znać chińskiego,
aby drukować tekst w tym języku. :)

> W związku z powyższym uważam, że moja drukarka zachowała się
> prawidłowo.

nie tylko twoja... (choć jak już pisałem, wole nie mieć
"kwadracików"... :P )


Pozdrawiam

Matuzalem wrote:
> Bernard napisał(a):
>> Tak się składa, że kiedyś pisałem oprogramowanie do współpracy z drukarkami, a
>> potem konstruowałem drukarki, w tym również tworzyłem ich firmware.
>> Dlatego wielbicieli sekwencji LF+CR najchętniej bym odstrzelił.
> 
> ooo..
> 
> a czy mógłyś się podzielić informacjami jakie to oprogramowanie (a
> raczej w czmy pisane i na jakie platformy, np. z czego korzystałeś
> tworząc je... itp.).

Dawno to było, w epoce DOSa, a programy były za przeproszeniem 
rezydentne i modyfikowały strumień danych wysyłany na drukarkę, 
dokładając i zmieniając różne rzeczy w tym, co wysyłały programy 
użytkowe. Pisane w asemblerze oczywiście.

> Co masz na myśli: "potem konstruowałem drukarki", tzn. robiłeś je
> (w sensie płytki drukowane, śrubeczki:P itd.) ??
> Jeśli tak, to mógłyś napisać choć ogólnie jak to wygląda "od
> kuchni"?

Elektronika, firmware, w sumie kupa roboty. Sam mechanizm był gotowy 
(termiczny). Akurat w tym przypadku nie robiłem całej elektroniki ani 
projektu płytki, a tylko część "logiczną" - mikrokontroler i połączenia 
w bezpośrednim sąsiedztwie. Firmware robiłem trzy razy - dwa razy w 
asemblerze, później w C. Dość istotną rzeczą było m.in. obsługiwanie 
wszystkich trzech sekwencji końca wiersza.

>> Widać każdy inaczej wdraża "standardy"... :]
>
> Standardem dla drukarki musi (powinna) być obsługa najróżniejszych
> programów, z których trzeba drukować wyniki pracy.

Standardem dla drukarki jest nie obsługa takich czy innych programów, bo 
ktoś sobie wymyślił inne dzielenie niż CRLF, a kodowanie ASCII, w którym 
znaczenie CR i LF jest określone, i tak powinny one być interpretowane.


-- 
Azarien

Bernard napisał(a):
> Matuzalem wrote:
> > Bernard napisał(a):
> >> Tak się składa, że kiedyś pisałem oprogramowanie do współpracy z drukarkami, a
> >> potem konstruowałem drukarki, w tym również tworzyłem ich firmware.
> >> Dlatego wielbicieli sekwencji LF+CR najchętniej bym odstrzelił.
> >
> > ooo..
> >
> > a czy mógłyś się podzielić informacjami jakie to oprogramowanie (a
> > raczej w czmy pisane i na jakie platformy, np. z czego korzystałeś
> > tworząc je... itp.).
>
> Dawno to było, w epoce DOSa, a programy były za przeproszeniem
> rezydentne i modyfikowały strumień danych wysyłany na drukarkę,
> dokładając i zmieniając różne rzeczy w tym, co wysyłały programy
> użytkowe. Pisane w asemblerze oczywiście.

Pewnie igłówki? (czy może plujki już też...?)

> > Co masz na myśli: "potem konstruowałem drukarki", tzn. robiłeś je
> > (w sensie płytki drukowane, śrubeczki:P itd.) ??
> > Jeśli tak, to mógłyś napisać choć ogólnie jak to wygląda "od
> > kuchni"?
>
> Elektronika, firmware, w sumie kupa roboty. Sam mechanizm był gotowy

A ile (mniej-więcej) zajmowało zrobienie jednego w pełni
działającego egzemplarza...?

> (termiczny). Akurat w tym przypadku nie robiłem całej elektroniki ani
> projektu płytki, a tylko część "logiczną" - mikrokontroler i połączenia

mikrokontroler (PIC, AVR, ..., ?), a w czym je programowałeś...? (tym
razem nie chodzi mi o język tylko o soft)

> w bezpośrednim sąsiedztwie. Firmware robiłem trzy razy - dwa razy w
> asemblerze, później w C.

A pod jakimi platformami...?

> Dość istotną rzeczą było m.in. obsługiwanie wszystkich trzech
> sekwencji końca wiersza.

Dzięki...


Pozdrawiam

Matuzalem wrote:
>> Dawno to było, w epoce DOSa, a programy były za przeproszeniem
>> rezydentne i modyfikowały strumień danych wysyłany na drukarkę,
>> dokładając i zmieniając różne rzeczy w tym, co wysyłały programy
>> użytkowe. Pisane w asemblerze oczywiście.
> 
> Pewnie igłówki? (czy może plujki już też...?)

Igłowe, atramentowe, laserowe.

>> Elektronika, firmware, w sumie kupa roboty. Sam mechanizm był gotowy
> 
> A ile (mniej-więcej) zajmowało zrobienie jednego w pełni
> działającego egzemplarza...?

Ja nie robiłem działających egzemplarzy :) Całość prac projektowych 
zajmowała około roku.

>> (termiczny). Akurat w tym przypadku nie robiłem całej elektroniki ani
>> projektu płytki, a tylko część "logiczną" - mikrokontroler i połączenia
> 
> mikrokontroler (PIC, AVR, ..., ?), a w czym je programowałeś...? (tym
> razem nie chodzi mi o język tylko o soft)

Najpierw 51, potem jedno 16-bitowe dziwadło, ostatnio H8 i ARM. PIC się 
do takich rzeczy nie nadaje, AVR ndawałby się 15 lat temu, kiedy nie 
było tanich i dobrych uC 16- i 32-bitowych. Przy obecnych cenach i 
możliwościach nie widzę sensu walki z ośmiobitowcami - Atmelowski ARM z 
64K Flash i 16K RAM zaczyna się od 3.5 Euro.

>> w bezpośrednim sąsiedztwie. Firmware robiłem trzy razy - dwa razy w
>> asemblerze, później w C.
> 
> A pod jakimi platformami...?

Takimi, jakie były dostępne - to i tak bez znaczenia, bo całe poważne 
uruchamianie było na żywym sprzęcie w czasie rzeczywistym, czyli bez 
debuggerów. W takimprzypadku środowisko niewiele może pomóc albo 
zaszodzić. Dawniej był to jakiś przyzwoity edytor i make.

Bernard napisał(a):
> Matuzalem wrote:
> >> Dawno to było, w epoce DOSa, a programy były za przeproszeniem
> >> rezydentne i modyfikowały strumień danych wysyłany na drukarkę,
> >> dokładając i zmieniając różne rzeczy w tym, co wysyłały programy
> >> użytkowe. Pisane w asemblerze oczywiście.
> >
> > Pewnie igłówki? (czy może plujki już też...?)
>
> Igłowe, atramentowe, laserowe.

A jakie złącza ? (LPT, USB, ..., ?)

> >> Elektronika, firmware, w sumie kupa roboty. Sam mechanizm był gotowy
> >
> > A ile (mniej-więcej) zajmowało zrobienie jednego w pełni
> > działającego egzemplarza...?
>
> Ja nie robiłem działających egzemplarzy :)

hehe

> Całość prac projektowych zajmowała około roku.

wow około rok :]

> >> (termiczny). Akurat w tym przypadku nie robiłem całej elektroniki ani
> >> projektu płytki, a tylko część "logiczną" - mikrokontroler i połączenia
> >
> > mikrokontroler (PIC, AVR, ..., ?), a w czym je programowałeś...? (tym
> > razem nie chodzi mi o język tylko o soft)
>
> Najpierw 51, potem jedno 16-bitowe dziwadło, ostatnio H8 i ARM. PIC się
> do takich rzeczy nie nadaje, AVR ndawałby się 15 lat temu, kiedy nie
> było tanich i dobrych uC 16- i 32-bitowych. Przy obecnych cenach i
> możliwościach nie widzę sensu walki z ośmiobitowcami - Atmelowski ARM z
> 64K Flash i 16K RAM zaczyna się od 3.5 Euro.

A programatory własnej roboty, czy zakupione...?

> >> w bezpośrednim sąsiedztwie. Firmware robiłem trzy razy - dwa razy w
> >> asemblerze, później w C.
> >
> > A pod jakimi platformami...?
>
> Takimi, jakie były dostępne - to i tak bez znaczenia, bo całe poważne
> uruchamianie było na żywym sprzęcie w czasie rzeczywistym, czyli bez
> debuggerów. W takimprzypadku środowisko niewiele może pomóc albo
> zaszodzić. Dawniej był to jakiś przyzwoity edytor i make.

Dzięki...

Pozdrawiam

Matuzalem wrote:
> Bernard napisał(a):
>> Matuzalem wrote:
>>>> Dawno to było, w epoce DOSa, a programy były za przeproszeniem
>>>> rezydentne i modyfikowały strumień danych wysyłany na drukarkę,
>>>> dokładając i zmieniając różne rzeczy w tym, co wysyłały programy
>>>> użytkowe. Pisane w asemblerze oczywiście.
>>> Pewnie igłówki? (czy może plujki już też...?)
>> Igłowe, atramentowe, laserowe.
> 
> A jakie złącza ? (LPT, USB, ..., ?)

Wtedy to było tylko Centronics, natomiast drukarki, które projektowałem, 
pracowały na RS232 (później był też projekt z USB).

>> Najpierw 51, potem jedno 16-bitowe dziwadło, ostatnio H8 i ARM. PIC się
>> do takich rzeczy nie nadaje, AVR ndawałby się 15 lat temu, kiedy nie
>> było tanich i dobrych uC 16- i 32-bitowych. Przy obecnych cenach i
>> możliwościach nie widzę sensu walki z ośmiobitowcami - Atmelowski ARM z
>> 64K Flash i 16K RAM zaczyna się od 3.5 Euro.
> 
> A programatory własnej roboty, czy zakupione...?

Do nowych kości na ogół nie trzeba programatorów - mają zwykle jakiś 
bootloader.
Dawniej używaliśmy programatorów za pierwszym razem - potem sprawę 
załatwiał własny bootloader (dopóki kolejna nowa wersja jeszcze działała ;))

> Nie wiem, czy zauważyłeś, ale ja nie korzystałem z żadnych
"edytorów", tylko wysłałem raw ciąg bezpośrednio do drukarki

Tak pomyślałem chwilę później po wysłaniu postu, ale to nie
zmienia faktu, że trzeba to zrobić jakimś programem i w jakimś
systemie operacyjnym, od których zależy format danych wysyłanych
do drukarki. Ale dajmy temu spokój, bo ja mniej więcej wiem o co
chodzi.

> Nie słyszałem o drukarce która by "rozumiała" to co drukuje...

O wielu sprawach pewnie jeszcze nie słyszałeś, co nie oznacza, że
ich nie ma. Każdy sprzęt cyfrowy takim jak PC i peryferia składa się
ze sprzętu i oprogramowania umożliwiającego właśnie coś w rodzaju
"wzajemnego porozumienia".

> Zapewniam Cię, drukarka nie musi znać chińskiego,
> aby drukować tekst w tym języku.

To też wiem i nie musisz silić się na dowcipy. Za mało jeszcze umiesz.

-- 
Remek

Bernard napisał(a):
> Matuzalem wrote:
> > Bernard napisał(a):
> >> Matuzalem wrote:
> >>>> Dawno to było, w epoce DOSa, a programy były za przeproszeniem
> >>>> rezydentne i modyfikowały strumień danych wysyłany na drukarkę,
> >>>> dokładając i zmieniając różne rzeczy w tym, co wysyłały programy
> >>>> użytkowe. Pisane w asemblerze oczywiście.
> >>> Pewnie igłówki? (czy może plujki już też...?)
> >> Igłowe, atramentowe, laserowe.
> >
> > A jakie złącza ? (LPT, USB, ..., ?)
>
> Wtedy to było tylko Centronics, natomiast drukarki, które projektowałem,
> pracowały na RS232 (później był też projekt z USB).

A z jakiej dokumentacji korzystaliście aby np. obsłużyć USB ?
(Platform SDK, DDK, ..., ?)

> >> Najpierw 51, potem jedno 16-bitowe dziwadło, ostatnio H8 i ARM. PIC się
> >> do takich rzeczy nie nadaje, AVR ndawałby się 15 lat temu, kiedy nie
> >> było tanich i dobrych uC 16- i 32-bitowych. Przy obecnych cenach i
> >> możliwościach nie widzę sensu walki z ośmiobitowcami - Atmelowski ARM z
> >> 64K Flash i 16K RAM zaczyna się od 3.5 Euro.
> >
> > A programatory własnej roboty, czy zakupione...?
>
> Do nowych kości na ogół nie trzeba programatorów - mają zwykle jakiś
> bootloader.

bootloader?

> Dawniej używaliśmy programatorów za pierwszym razem - potem sprawę
> załatwiał własny bootloader (dopóki kolejna nowa wersja jeszcze działała ;))

Pozdrawiam

Matuzalem wrote:
>> Wtedy to było tylko Centronics, natomiast drukarki, które projektowałem,
>> pracowały na RS232 (później był też projekt z USB).
> 
> A z jakiej dokumentacji korzystaliście aby np. obsłużyć USB ?
> (Platform SDK, DDK, ..., ?)

Z tej, która zawierała odpowiedzi na interesujące nas kwestie :) 
Standardy USB, SDK, DDK.

>> Do nowych kości na ogół nie trzeba programatorów - mają zwykle jakiś
>> bootloader.
> 
> bootloader?

Program zapisany w pamięCi ROM, który umożliwia załadowanie programu np. 
przez łącze szeregowe lub USB do pamięci Flash mikrokontrolera.

Bernard napisał(a):
> Matuzalem wrote:
> >> Wtedy to było tylko Centronics, natomiast drukarki, które projektowałem,
> >> pracowały na RS232 (później był też projekt z USB).
> >
> > A z jakiej dokumentacji korzystaliście aby np. obsłużyć USB ?
> > (Platform SDK, DDK, ..., ?)
>
> Z tej, która zawierała odpowiedzi na interesujące nas kwestie :)
> Standardy USB, SDK, DDK.
>
> >> Do nowych kości na ogół nie trzeba programatorów - mają zwykle jakiś
> >> bootloader.
> >
> > bootloader?
>
> Program zapisany w pamięCi ROM, który umożliwia załadowanie programu np.
> przez łącze szeregowe lub USB do pamięci Flash mikrokontrolera.

Ok wielkie dzięki za odpowiedzi...

Pozdrawiam

Remek napisał(a):
> > Nie wiem, czy zauważyłeś, ale ja nie korzystałem z żadnych
> "edytorów", tylko wysłałem raw ciąg bezpośrednio do drukarki
>
> Tak pomyślałem chwilę później po wysłaniu postu, ale to nie
> zmienia faktu, że trzeba to zrobić jakimś programem i w jakimś
> systemie operacyjnym, od których zależy format danych wysyłanych
> do drukarki.

jakimś programem?
jakimś systemie operacyjnym...?
co by było mało, to od nich zależy format danych wysyłanych do
drukarki...?

jejku skąd to wziąłeś...

> Ale dajmy temu spokój, bo ja mniej więcej wiem o co chodzi.

Zagadzam się. Mniej czy więcej? :P

> > Nie słyszałem o drukarce która by "rozumiała" to co drukuje...
>
> O wielu sprawach pewnie jeszcze nie słyszałeś, co nie oznacza, że
> ich nie ma.

Zgadza się...

> Każdy sprzęt cyfrowy takim jak PC i peryferia składa się
> ze sprzętu i oprogramowania umożliwiającego właśnie coś w rodzaju
> "wzajemnego porozumienia".

Dla ścisłości: one nie porozumiewają się wzajemnie, tylko
wymieniają dane. Widze, że już nie użyłeś słowa "rozumieją"...
prawda, że to duża rużnica... (rozumieć, a porozumiewać się...)

> > Zapewniam Cię, drukarka nie musi znać chińskiego,
> > aby drukować tekst w tym języku.
>
> To też wiem i nie musisz silić się na dowcipy.

Ależ ja się na nic nie sile to Ty to stwierdziłeś, ja tylko
powtórzyłem...

> Za mało jeszcze umiesz.

Znowu piszesz to samo co pare wierszy wcześniej...  tak oj tak mało
:] 

Pozdrawiam

> Znowu piszesz to samo co pare wierszy wcześniej

Widzisz. Normalny kulturalny człowiek potrafi dyskutować
i wymieniać poglądy nie próbując rozmówcy ośmieszać, czy
poniżać. I wcale nie znaczy to, że obaj muszą mieć rację.
Zdarza się, że ktoś nie ma racji, pomylił się. Ludzka rzecz.
Ale Ty tego nie potrafisz, ponieważ prezentujesz bardzo
niską kulturę bycia. Nie warto z Tobą rozmawiać. Jeszcze
gdybyś był ekspertem w asemblerze, to można było by wiele
ścierpieć, ale Ty masz bardzo jeszcze mgliste pojęcie o tym
co piszesz. Choć to nieznmiernie rzadko zdarza się na tej
grupie ja nie mam zamiaru więcej czytać Twoich wypocin.

Plonk!

-- 
Remek