sundayman napisał:

>> A jak chcesz rzeźbić to droga wolna - pisałem programy windowsowe,
>> okienkowe z rozmiarem po skompilowaniu 512-1024B. MASM jest do tego
>> bardzo wygodny.
>
> a ja pierszy program pisałem na kartce w assemblerze Z80, na "komputer"
> ZX81, który miał 1KB ramu, w czym połowa chyba na pamięć ekranu :)

Jaka tam połowa, prawie cała pamięć! Konkretnie 24 wiersze po 32 znaki,
to 768 bajtów. Tyle że tam była inteligentna organizacja pamięci obrazu
(uwzględniająca znak końca wiersza), więc dało się wcisnąć jakiś program
i coś przy tym wyświetlić.

> Tam się liczył każdy bajt - kto dziś pamięta takie rzeczy :)
> A dodatkowo ten komputer miał od tyłu postawioną suszarkę do włosów,
> która nie grzała, ale dmuchała zimnym powietrzem, bo miałem uwalony ULA,
> i bez tego po paru minutach się przegrzewał, i zawieszał wszystko w diabły.

Pewnie suszarka też była zepsuta i nigdzie w handlu uspołecnionym nie dało
się kupić nowej grzałki.

--
Jarek

do góry

sundayman napisał:

>> A jak chcesz rzeźbić to droga wolna - pisałem programy windowsowe,
>> okienkowe z rozmiarem po skompilowaniu 512-1024B. MASM jest do tego
>> bardzo wygodny.
>
> a ja pierszy program pisałem na kartce w assemblerze Z80, na "komputer"
> ZX81, który miał 1KB ramu, w czym połowa chyba na pamięć ekranu :)

Jaka tam połowa, prawie cała pamięć! Konkretnie 24 wiersze po 32 znaki,
to 768 bajtów. Tyle że tam była inteligentna organizacja pamięci obrazu
(uwzględniająca znak końca wiersza), więc dało się wcisnąć jakiś program
i coś przy tym wyświetlić.

> Tam się liczył każdy bajt - kto dziś pamięta takie rzeczy :)
> A dodatkowo ten komputer miał od tyłu postawioną suszarkę do włosów,
> która nie grzała, ale dmuchała zimnym powietrzem, bo miałem uwalony ULA,
> i bez tego po paru minutach się przegrzewał, i zawieszał wszystko w diabły.

Pewnie suszarka też była zepsuta i nigdzie w handlu uspołecznionym nie dało
się kupić nowej grzałki.

--
Jarek

do góry

On 07.03.2013 23:18, sundayman wrote:
>
>> A jak chcesz rzeźbić to droga wolna - pisałem programy windowsowe,
>> okienkowe z rozmiarem po skompilowaniu 512-1024B. MASM jest do tego
>> bardzo wygodny.
>
> a ja pierszy program pisałem na kartce w assemblerze Z80, na "komputer"
> ZX81, który miał 1KB ramu, w czym połowa chyba na pamięć ekranu :)

Pisałem na kartce w ramach laboratoriów na studiach jakieś 3 czy 4 lata
temu. A potem wklepywałem ten kod do pamięci ram za pomocą zestawu
przycisków.

>
> Tam się liczył każdy bajt - kto dziś pamięta takie rzeczy :)

A to uzasadnia, jakoś, ze dzisiaj, na x86 należy liczyć każdy bajt? Są
układy gdzie trzeba, chociaż szczerze mówiąc to nawet na attiny 2313
który ma 128B ram pisałem w C++.

> I - co, można było ?? Można !

I - co, można było?? Można!

--
Pozdrawiam
Michoo

do góry

On 07.03.2013 20:38, Anerys wrote:
>
> Użytkownik "sundayman" <s...@p...onet.pl> napisał w wiadomości
> news:khaafm$q0m$1@news.task.gda.pl...
>> Ale co by nie mówić, na nowszym komputerze render trwa krócej, a nie
>> dłużej i ostatecznie to właśnie jest finalnym kryterium.
>
> Owszem, tak jest. Ale jakby to dobrze obwąchać, to krócej... ale czy
> rzeczywiście o tyle krócej, ile relatywnie wzrosła moc sprzętu?
> Uważam, że jeśli moc maszyny wzrosła o 20%, to także o 20% wzrosnąć
> powinna szybkość renderu. A jestem niemal pewien, że wzrosła o 10, góóra
> 15...

Dane wzięte z d...? Bo pojawiły się zarówno nowe algorytmy jak i nowe
sposoby programowania (shader anyone?) które przyspieszenie dały nie
rzędu 20% a bardziej 200-2000%. (Kiedyś jedna klatka na kilka -
kilkadziesiąt sekund, teraz 30-40 klatek na sekundę dobrej jakościowo
grafiki na konsumenckim sprzęcie.)

--
Pozdrawiam
Michoo

do góry

Hello Michoo,

Thursday, March 7, 2013, 11:57:40 PM, you wrote:

>>> Ale co by nie mówić, na nowszym komputerze render trwa krócej, a nie
>>> dłużej i ostatecznie to właśnie jest finalnym kryterium.
>> Owszem, tak jest. Ale jakby to dobrze obwąchać, to krócej... ale czy
>> rzeczywiście o tyle krócej, ile relatywnie wzrosła moc sprzętu?
>> Uważam, że jeśli moc maszyny wzrosła o 20%, to także o 20% wzrosnąć
>> powinna szybkość renderu. A jestem niemal pewien, że wzrosła o 10, góóra
>> 15...
> Dane wzięte z d...? Bo pojawiły się zarówno nowe algorytmy jak i nowe
> sposoby programowania (shader anyone?) które przyspieszenie dały nie
> rzędu 20% a bardziej 200-2000%. (Kiedyś jedna klatka na kilka -
> kilkadziesiąt sekund, teraz 30-40 klatek na sekundę dobrej jakościowo
> grafiki na konsumenckim sprzęcie.)

http://pclab.pl/news52453.html 4.5 Tflops, 2688 rdzeni, 7.1 mld
tranzystorów. Vsync do 80fps.

Nie trzeba do tego elektrowni - ledwie 250W pobiera.

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

> Dane wzięte z d...? Bo pojawiły się zarówno nowe algorytmy jak i nowe
> sposoby programowania (shader anyone?) które przyspieszenie dały nie
> rzędu 20% a bardziej 200-2000%. (Kiedyś jedna klatka na kilka -
> kilkadziesiąt sekund, teraz 30-40 klatek na sekundę dobrej jakościowo
> grafiki na konsumenckim sprzęcie.)

lepiej panie rezyseze :)
A taki octane render, który śmiga prawie real-time (wykorzystuje kartę z
CUDA) - super sprawa.

do góry

On 2013-03-07 22:47, Michał Baszyński wrote:
[...]
> a co powiesz na to:
> http://microcontroller.com/news/Zilog_Z8051.asp
> ?
A co powiesz na to (z tego samego newsa): "Last year NXP exited the 8051
market". :-D

Jedni wychodzą a inni wchodzą. :-D MCS-51 to chyba jest obecnie nisza i
tym samym dobre miejsce dla mniejszych kompanii. Poza tym siła ludzkich
przyzwyczajeń i strach przed nowym jest ogromna. Np. ostatnio wymieniłem
moim starszym tuner TV-SAT na nowszy (HD). No i teraz dociera do mnie
marudzenie że pilot ma inny rozkład klawiszy, że memu na ekranie jest
inne itp. duperele. :-D Więc chętni na '51 też jeszcze długo będą i do
tego zapewne nie tylko z powodów czysto ekonomicznych. :-D

do góry

Am 07.03.13 23:18, schrieb sundayman:

>> A jak chcesz rzeźbić to droga wolna - pisałem programy windowsowe,
>> okienkowe z rozmiarem po skompilowaniu 512-1024B. MASM jest do tego
>> bardzo wygodny.
>
> a ja pierszy program pisałem na kartce w assemblerze Z80, na "komputer"
> ZX81, który miał 1KB ramu, w czym połowa chyba na pamięć ekranu :)

Ktos pamieta programy w assemblerze umieszczane w szostej stronie
(0x600, a potem jakze czeste X=USR(1536)) pamieci na malym Atari? :-D

> Tam się liczył każdy bajt - kto dziś pamięta takie rzeczy :)

Ci ktorzy musza programowac ATtiny11

do góry

On 2013-03-07 13:47, DJ wrote:
> On 2013-03-07 13:35:38 +0100, JDX <j...@o...pl> said:
>
>> On 2013-03-07 11:11, DJ wrote:
>> [...]
>>> Generowanie potrzeby na pierdołki - jest głupie, choć potem zyskowne.
>> No jak jest zyskowne to IMO jest mądre.
>
> Zysk jest kryterium mądrości...?
W tym kontekście jak najbardziej. Przecież celem działania każdego
przedsiębiorstwa jest przynoszenie zysku jego właścicielom. I jeśli
"generowanie potrzeb" takie zyski przynosi/zwiększa to jest tym samym
mądrym (racjonalnym) działaniem.

>> Głupi są ci, którzy dają się na
>> takie ściemy nabrać. :-D
>
> Czyli w skrócie:
> Kali kraść krowa, być dobrze.
> Kalemu ukraść krowa, być źle.
Hę? Ale so chodzi?

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:khb6av$fgv$1@mx1.internetia.pl...

>> Tam się liczył każdy bajt - kto dziś pamięta takie rzeczy :)
>
> A to uzasadnia, jakoś, ze dzisiaj, na x86 należy liczyć każdy bajt? Są
> układy gdzie trzeba, chociaż szczerze mówiąc to nawet na attiny 2313 który
> ma 128B ram pisałem w C++.
>
Stwierdzenie "tam się liczył każdy bajt" + hasło 128B zawsze mi się kojarzy
z zastosowanym przez nas rozwiązaniem w picco-GALu (1992 - może ktoś jeszcze
pamięta to urządzenie).
128bajtów RAMu 8751 starczało na program (FORTH), 2 stosy danych dla tego
programu i stos procesora.
Jedna z pierwszych instrukcji programu ustalała miejsce podziału tej pamięci
na 2 części. W jednej program (już załadowany i w trakcie interpretacji) i
stos danych do programowania EEPROMu, GALa (zazwyczaj zamazujący już
wykonaną część programu). W drugiej rosnące na przeciwko siebie stos danych
sterujących przebiegiem programu i stos procesora. Dane sterujące stopniowo
się "zużywały", a z kolei każde zagłębienie pętli programu powodowało wzrost
stosu procesora o 2 bajty.
P.G.

do góry