Menu
▾
▴
liquidfire-devel — Liquidfire's devel mail list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Lorrene C. N. V. <lo...@gm...> - 2004-09-01 20:39:00
|
Hi. -- Lorrene - http://lorrene.dotnode.com "Research is what I'm doing when I don't know what I'm doing." -- Wernher von Braun On Tue, 6 Jul 2004 18:55:14 -0300, Lucas Mendes <lu...@mi...> wrote: > > tested. > > regards! > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > Liquidfire-devel mailing list > Liq...@li... > https://lists.sourceforge.net/lists/listinfo/liquidfire-devel > |
|
From: Marcelo S. <ma...@he...> - 2004-07-08 16:57:25
|
eu estava analisando a questao dos devices, realmente o unix mesmo jah faz
uma interface similar ao que estamos pretendendo, embora ele mesmo nao a
torne padrao, por exemplo, para redes!
em qq unix vc pode tratar o frame buffer como um arquivo, no caso:
int fd=open("/dev/fb",O_RDWR);
read(fd,buffer,sizeof(buffer));
write(fd,buffer,sizeof(buffer));
ioctl(fd,&buffer,COMMAND);
close(fd);
uma API bem simples, nao eh ? eventualmente vc faz o truque do mmap(), q
nos podemos ter para *qualquer* io tb, ao menos no caso dos 68k:
char *p=mmap(fd, ... );
e entao temos o ponteiro *p para brincar direto na memoria de video:
p[y*fbwidth+x]=cor;
bem simples. mas a ethernet no unix nao sabe fazer isso, o q eu acho uma
burrice, eles criam uma nova API para o io de redes, por algum motivo
obscuro. talvez desenvolvendo, possamos compreender o porque, mas enfim, a
analogia seria:
int fd=open("/dev/eth0",O_RDWR);
read(fd,buffer,sizeof(buffer));
write(fd,buffer,sizeof(buffer));
ioctl(fd,&buffer,COMMAND);
close(fd);
nada muda neh. isso pode ser um driver q interfaceia a camada IP com o
dispositivo fisico, no lugar de /dev/eth0, podia ser /dev/ttyS0, etc. note
que ler e escrever com read/write pode assumir um buffer pequeno ou
grande, supomos que o buffer eh grande o suficiente para q read() leia de
fato um datagrama completo e write, de fato, escreva um datagrama
completo, nesse caso, buffer aponta realmente para um pacote IP, o
software q manipula isto esta fazendo isto na camada de pos-routing, quer
dizer, o pacote vai para a interface sem choro. o q entra, eh pre-routing,
usando uma conhecida analogia de um certo firewall q nao funciona muito
bem.
ah, mas e como o cara faz ppp ? nao eh ip-over-interface direto. de fato
nao sei, qdo vc abre uma /dev/eth0, esta disponivel o datagrama ethernet
de base, se vc abre uma /dev/ttyS0, esta disponivel comunicacao assincrona
caracter a caracter. num 68302, a /dev/ttyS0 eh muito inteligente, ao
ponto de dispor de HDLC e outros protocolos, mas nao ppp. entao sera q o
ppp deve ser uma atribuicao do dispositivo ou de uma camada extra ?
no caso de ser atribuicao do dispositivo:
struct INTERFACE config;
int fd=open("/dev/eth0",O_RDWR);
config.encapsulation=ENCAPSULATION_PPP;
ioctl(fd,&config,CONFIG);
a conexao ficaria:
IP router <-> device
a desvantagem eh q o engine ppp nao pode ser utilizado a nao ser em
interfaces, se o cara quiser usar um pipe para um sub-programa, eh dificil
fazer e teria q duplicar, criando um ppp na forma de uma app q funcione
com pipes gerais e nao apenas com devices :P
no caso de ser atribuicao de uma camada extra, eh possivel ter um daemon
que constroi os frames ppp, como um daemon generico:
struct PPPCONFIG config;
int fd=open("/dev/ppp",O_RDWR);
config.fd=open("/dev/ttyS0",O_RDWR);
config.dst.ip=0x7f000000;
ioctl(fd,&config,CONFIG);
read(fd,&buffer,sizeof(buffer));
write(fd,&buffer,sizeof(buffer));
close(fd);
neste caso vc linka o /dev/ttyS0 ao daemon ppp e depois o daemon ppp se
vira para gerenciar, ele, de fato, vc poderia linkar em qualquer especie
de fd, a conexao seria direta:
IP router <-> ppp daemon <-> device
uma vantagem de um daemon ppp:
IP router <-> ppp daemon <-> crypto engine <-> IP router
pq uma chamada ciclica ? simples, os packets daem do ip router para um
enlace ppp, q passa por um crypto engine, pode ser um ipsec, ou qq coisa
do genero. o resultado eh dado criptografado, q vai para o ip router
novamente, e este entrega para a saida real, q pode ser uma ethernet. do
ponto de vista logico, vc teria os devices e rotas:
0/0 gw /dev/eth0
192.168.0.0/16 gw /dev/ppp [crypto:200.200.200.1]
o ppp no caso funciona como um ppp over ethernet, mas com a camada extra
de criptografia, q eh um sub-processo conectado ao ppp e faz o seu
trabalho sem q o ppp se preocupe com isso.
apesar de parecer encher de camadas, devemos lembrar q tudo isso eh
paralelizado e bufferizado, criando uma especie de pipeline, assim,
durante o funcionamento normal do sistema, um device q recebe
continuamente packets, pode despachar para o daemon IP um volume continuo
de packets. se o daemon IP estiver ocupado, nao importa: ele vai entupindo
as queues! o daemon IP se vira e despacha os packets roteados para as
queues dos devices de saida.
imagine uma adaptacao de rate do tipo ethernet/10mbps <-> hdlc/64kbps,
embora os dados cheguem em bursts grandes pela ethernet, as queues seguram
a barra durante a entrada e saida do link hdlc ateh que ele consiga
despachar o trafego.
isso jah abre de cara a possibilidade do controle de trafego, uma vez q eh
possivel setar a interface para fazer descarte quando as queues estao
lotadas :)
uma vantagem q eu vejo dessa API, eh q generaliza tudo na forma de
syscalls padronizadas e tb recupera e tenta padronizar uma serie de APIs
do unix, em particular em cima de open/read/write/ioctl/close para nosso
sistema interprocesso. a economia eh imensa, no lugar de codificarmos
dezenas de APIs, fazemos apenas uma, generica, e que funciona bem.
outra coisa q ocorre eh que o daemon de fs seria responsavel, em parte,
pelo registro dos dispositivos. uma coisa q ocorre de fato no unix eh que
vc usa o fs para registrar as coisas!
o que liga o /dev/fb aos drivers do frame-buffer ? o unix de fato entende
apenas de numeros, mas o fs permite a aplicacao abrir o /dev/fb, puxar o
codigo do dispositivo e daih temos o registro do dispositivo, ou seja, o
fd do arquivo /dev/fb eh ligado no kernel ao numero de registro do
dispositivo.
no nosso caso, os daemons teriam q solicitar o registro do identificador e
o fs se encarregaria de ligar o path do open ao respectivo daemon, ou
seja, qdo o cara abre o /dev/fb, o fs le o registro, verifica as
permissoes e, estando ok, redireciona aquele fd para o daemon do
frame-buffer, por exemplo.
interessante q isto ocorre no unix, em certa escala, entao nao eh uma
ideia tao doida, soh estamos adaptando uma solucao monolitica para uma
solucao de microkernel, na pratica, o funcionamento nao precisa ser tao
diferente e tambem nao precisamos perder tempo codificando milhares de
APIs complexas (isto sera feito nos daemons, mas enfim).
outras opinioes ? (:
atenciosamente,
marcelo samsoniuk
|
|
From: Marcelo S. <ma...@he...> - 2004-07-08 05:31:08
|
On Mon, 7 Jun 2004, Lucas Mendes wrote:
>
> eu preciso rever os pinos das memorias SIMM de 72". pro lance do boot, seria
as memorias de 72 vias tem 32 bits, portanto sao 4 bytes (4 pinos CAS). e
algumas tem 1 RAS ou 2 RAS, q sao os bancos. basicamente, vc tem q pensar
q existem chips de 1Mbit, 4Mbit e 16Mbit, assim:
1Mbit x 4 bytes x 1 banco = 4MB
1Mbit x 4 bytes x 2 bancos = 8MB
4Mbit x 4 bytes x 1 banco = 16MB
1Mbit x 4 bytes x 2 bancos = 32MB
16Mbit x 4 bytes x 1 banco = 64MB
16Mbit x 4 bytes x 2 bancos = 128MB
sera q chegou a ter de 64 ou 128MB ? nunca vi. enfim, o q nos temos: 0
68306 gera 2 CAS e 2 RAS, entao temos opcoes: fazer tudo glue-less e
ignorar metade dos bytes, assim dos pentes de 4MB usariamos 2MB, dos
pentes de 8MB usariamos 4MB, etc. infelizmente o refresh eh do tipo
CAS-before-RAS e suponho q ele tem q acionar todos os pinos CAS e depois
todos os pinos RAS. fazendo glue-less, eh facil, mas perde metade da
memoria, pq o 68306 tem 16 bits de bus e a memoria fornece 32.
outra opcao seria ignorar memorias de 2 bancos e usar apenas um banco,
nesse caso, usaria RAS0 e RAS1 para ativar os sinais CAS da palavra alta
ou baixa da palavra longa d 32 bits. nesse caso, um pente de 4MB usaria os
4MB, mas um pente de 8MB usaria 4MB (pq nao ativa o segundo banco :).
situacao similar nos outros hehehe. claro q isso tb iria requerer algumas
portas logicas extras para fazer a selecao dos bytes, mas nada complexo.
outra solucao mais radical seria usar sram grande (1MB/banco) ou montar
um controlador dram capaz de gerar sinais suficientes, neste caso o limite
seria de 16MB/banco. eu simpatizo com memorias sram, mas certamente a
opcao mais acima, totalmente glue-less, pelo menos num primeiro instante,
seria a melhor de todas.
> mesmo interessante nao limitar as coisas em um setor, com o Intel. podemos
> puxar 2 paginas (8KB) de uma vez, que jah teria o codigo do trap #0 para acesso
> ao HD (KERNEL VFS basico - flexibilizando a opcao do sistema de arquivos do
> microkernel.. o FS nao estaria no KERNEL, mas num modulo separado e o KERNEL
> usaria o trap #0) e carregando o KERNEL para o topo do core. outro lance
questao basica: como o microkernel le o modulo de fs e driver de disco se
ele nao sabe fazer isto ? a unica solucao q eu vejo eh dar opcao de linkar
no codigo do microkernel o suporte a fs e alguns drivers basicos.
operacionalmente, nao haveria mudancas: eles rodariam como processos em
userland, mas estariam isentos de ter q viver no disco, embora possam ser
substituidos por outros processos! de qq forma, facilitaria a vida
totalmente, pq embora no boot o microkernel nao saiba acessar o disco, o
daemon q o faz jah estaria carregado na memoria, por estar linkado no
binario do proprio microkernel.
depois o cara abre o fs e puxa o resto.
> bastante interessante seriam os daemons multiplos, para hardware carente de IRQ;
> basicamente aquela nossa velha ideia de polling no IO, tipo um select. :)
fica legal, pe mesmo q seja totalmente sem hardware, ainda rolaria poling
em cima de uma multitarefa cooperativa, hahaha. soh q dae nao dah para
exigir muita coisa de desempenho do hardware, q vai ser xoxo :)
> contei a Lorrene sobre a possibilidade de uma multitarefa cooperativa por meio
> das funcoes write/read e descrevi a comunicacao interprocesso, as ideias sobre
> queueing e MM, se nao me engano. (nao me lembro se contei do MM para ela ou outra
> pessoa - Lorrene, se nao te descrevi, manda um mail que descrevo. eh bem
> interessante).
> a pilha de rede, como realmente te falei, tambem estara em um daemon 'NET', que
> tera acesso aos teletipos (a ethernet vai ser uma especie de TTY tambem) por
> meio de uma funcao FILE *fdevopen(char *device,char *mode) da libc, que usara
> uma system call DEVOPEN do KERNEL. como abaixo:
>
> FILE *eth=fdevopen("eth0","r+");
> if(!eth) {
> fprintf("Could NOT open the ethernet. Networkg disabled\n");
> return -1;
> }
> for(;;) {
> /* trata a rede como RAW SOCKET, acrescido das
> * facilidades das funcoes para tratamento de
> * arquivos.
> */
> }
a ideia eh essa, mas temos q dar uma discutida no COMO VAI FUNCIONAR ;)
> deu pra perceber que o ha um modulo no KERNEL que precisa registrar o dispositivo
> "eth0" e disponibilizar funcoes de write, read, lseek e close. ha 2
> possibildiades para a ethernet: uma eh fazer 'NET' escrever direto no dispositivo
> a outra eh que teriamos um outro daemon para gerenciar o fluxo de todas as
> ethernets disponiveis. pode ser uma boa ideia, jah que os discos ATA IDE tambem
> possuem um daemon 'IDE' alem do 'FS'. de qualquer maneira, mesmo tendo 20
> daemons para os drivers, somente 2 ou 3 estarao concorrendo pela CPU;
> os demais dormirao aguardando evento nos descritores.
> tambem te contei isso. soh repassando. :)
> o Stallman perguntou se da pra correr o HURD em cima do Liquid hehehe. mais tarde
> mando mail pra ele explicando que o Liquid nao eh um Mach e que teremos todos
> os daemons necessarios, fucionando de maneira proprietaria.
> a proposito, a lista 'Liquidfire-devel' esta fucionando novamente na
> sourceforge; vamos utiliza-la! melhor que ter que ficar adicionando endereco
> por endereco das pessoas aqui nos mails.
> eu tomei a liberdade de inscrever o ma...@mi... lah. :)
hahaha emulando a API do hurd, ateh corre neh ?
> #
> # o lance do 68306 seria algo bem simples, uma PCB bem basica, com
> # a eprom de inicializacao e uma porrada de conectores. para as duas
> # seriais, precisa de circuitos de conversao de tensao, mas q sao bem
> # basicos, bem pq em eh serial hi-speed. os sinais roteiam direto no
> # conector da dram de 72 vias e nem tem muito segredo, exceto por
> # algumas questoes relacionadas a auto-config da dram, q podemos usar
> # alguns bits das portas paralelas q o 68306 tem onchip para fazer
> # isso e selecionar automaticamente o size do pente de memoria.
> #
> # ateh aih eu garanto q funciona legal, mas soh temos um 68306 com duas
> # seriais, eprom de boot e dram. precisariamos de uns latches e algum
> # suporte de software para tentar uma IDE, q eu acho q nao h tao
> # problematica. por fim, eu acho q poderiamos colocar um conector de
> # expansao proprietario, talvez um VME16, q reflete os sinais de um 68k
> # padrao. pq isso ? simplesmente permite plugar outra placa, essa eh
> # a q eu acho q pode dar pepinos de timming e precisaria de mais debug,
> # nessa placa colocariamos ou IO 68k nativo ou um par de conectores ISA,
> # os quais tem q ser bufferizados com bastante latches e tb precisam de
> # logica extra para gerar sinais especiais ridiculos, por exemplo,
> # decodificar mapas de memoria, io, etc referentes ao bus ISA do PC, q
> # ainda de quebra requer uns waitstates para sincronizar seus 8MHz
> # padrao com os 16MHz do 68306.
> #
> # na pratica, uma placa flexivel e sem muito o q dar problema: tentamos
> # mover o problema para um conector de expansao q realmente vai dar
> # problema ateh o hardware realmente se sincronizar hehehe
> #
> # mas acho q o 68306 com eprom, seriais e IDE jah permite desenvolver
> # integralmente o sistema operacional! soh temos q achar uma forma de
> # contrabandear uns 68306 para o brasil hehehe
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Liquidfire-devel mailing list
> Liq...@li...
> https://lists.sourceforge.net/lists/listinfo/liquidfire-devel
>
|
|
From: Lucas M. <lu...@mi...> - 2004-07-07 06:24:22
|
eu preciso rever os pinos das memorias SIMM de 72". pro lance do boot, seria
mesmo interessante nao limitar as coisas em um setor, com o Intel. podemos
puxar 2 paginas (8KB) de uma vez, que jah teria o codigo do trap #0 para acesso
ao HD (KERNEL VFS basico - flexibilizando a opcao do sistema de arquivos do
microkernel.. o FS nao estaria no KERNEL, mas num modulo separado e o KERNEL
usaria o trap #0) e carregando o KERNEL para o topo do core. outro lance
bastante interessante seriam os daemons multiplos, para hardware carente de IRQ;
basicamente aquela nossa velha ideia de polling no IO, tipo um select. :)
contei a Lorrene sobre a possibilidade de uma multitarefa cooperativa por meio
das funcoes write/read e descrevi a comunicacao interprocesso, as ideias sobre
queueing e MM, se nao me engano. (nao me lembro se contei do MM para ela ou outra
pessoa - Lorrene, se nao te descrevi, manda um mail que descrevo. eh bem
interessante).
a pilha de rede, como realmente te falei, tambem estara em um daemon 'NET', que
tera acesso aos teletipos (a ethernet vai ser uma especie de TTY tambem) por
meio de uma funcao FILE *fdevopen(char *device,char *mode) da libc, que usara
uma system call DEVOPEN do KERNEL. como abaixo:
FILE *eth=fdevopen("eth0","r+");
if(!eth) {
fprintf("Could NOT open the ethernet. Networkg disabled\n");
return -1;
}
for(;;) {
/* trata a rede como RAW SOCKET, acrescido das
* facilidades das funcoes para tratamento de
* arquivos.
*/
}
deu pra perceber que o ha um modulo no KERNEL que precisa registrar o dispositivo
"eth0" e disponibilizar funcoes de write, read, lseek e close. ha 2
possibildiades para a ethernet: uma eh fazer 'NET' escrever direto no dispositivo
a outra eh que teriamos um outro daemon para gerenciar o fluxo de todas as
ethernets disponiveis. pode ser uma boa ideia, jah que os discos ATA IDE tambem
possuem um daemon 'IDE' alem do 'FS'. de qualquer maneira, mesmo tendo 20
daemons para os drivers, somente 2 ou 3 estarao concorrendo pela CPU;
os demais dormirao aguardando evento nos descritores.
tambem te contei isso. soh repassando. :)
o Stallman perguntou se da pra correr o HURD em cima do Liquid hehehe. mais tarde
mando mail pra ele explicando que o Liquid nao eh um Mach e que teremos todos
os daemons necessarios, fucionando de maneira proprietaria.
a proposito, a lista 'Liquidfire-devel' esta fucionando novamente na
sourceforge; vamos utiliza-la! melhor que ter que ficar adicionando endereco
por endereco das pessoas aqui nos mails.
eu tomei a liberdade de inscrever o ma...@mi... lah. :)
#
# o lance do 68306 seria algo bem simples, uma PCB bem basica, com
# a eprom de inicializacao e uma porrada de conectores. para as duas
# seriais, precisa de circuitos de conversao de tensao, mas q sao bem
# basicos, bem pq em eh serial hi-speed. os sinais roteiam direto no
# conector da dram de 72 vias e nem tem muito segredo, exceto por
# algumas questoes relacionadas a auto-config da dram, q podemos usar
# alguns bits das portas paralelas q o 68306 tem onchip para fazer
# isso e selecionar automaticamente o size do pente de memoria.
#
# ateh aih eu garanto q funciona legal, mas soh temos um 68306 com duas
# seriais, eprom de boot e dram. precisariamos de uns latches e algum
# suporte de software para tentar uma IDE, q eu acho q nao h tao
# problematica. por fim, eu acho q poderiamos colocar um conector de
# expansao proprietario, talvez um VME16, q reflete os sinais de um 68k
# padrao. pq isso ? simplesmente permite plugar outra placa, essa eh
# a q eu acho q pode dar pepinos de timming e precisaria de mais debug,
# nessa placa colocariamos ou IO 68k nativo ou um par de conectores ISA,
# os quais tem q ser bufferizados com bastante latches e tb precisam de
# logica extra para gerar sinais especiais ridiculos, por exemplo,
# decodificar mapas de memoria, io, etc referentes ao bus ISA do PC, q
# ainda de quebra requer uns waitstates para sincronizar seus 8MHz
# padrao com os 16MHz do 68306.
#
# na pratica, uma placa flexivel e sem muito o q dar problema: tentamos
# mover o problema para um conector de expansao q realmente vai dar
# problema ateh o hardware realmente se sincronizar hehehe
#
# mas acho q o 68306 com eprom, seriais e IDE jah permite desenvolver
# integralmente o sistema operacional! soh temos q achar uma forma de
# contrabandear uns 68306 para o brasil hehehe
|
|
From: Lucas M. <lu...@mi...> - 2004-07-06 22:00:54
|
tested. regards! |
|
From: Lucas M. <lm...@ne...> - 2003-05-13 19:37:56
|
no EZ, temos apenas um timer no IMR (0xfffff304) de INTC;
MTMR eh o bit 1.
jah no VZ temos 2 timers neh, e IMR tambem estah em 0xfffff304;
alem disso, MTMR1 se encontra no bit 1, e MTMR2 no bit 5.
o bir 5 de IMR do EZ estah reservado. :)
qual voce usou, MTMR1 ou 2?
--
o _ _ _
_o /\_ _ \\o (_)\__/o (_)
_< \_ _>(_) (_)/<_ \_| \ _|/' \/
(_)>(_) (_) (_) (_) (_)' _\o_
-+----------------+------------------------------------+-
| Lucas Mendes | http://sourceforge.net/users/esc2 |
-+-------------'| <lm...@ne...> |
---------------------------------------'
|
|
From: Marcelo S. <mar...@bs...> - 2003-05-11 06:23:03
|
rol/ror have just 3 bits in the counter field, then the valid range for imediate data is #1 up to #8, for other values, you must use a counter in a register: moveq #0xf,%d2 rol %d2,%d3 or two rol instructions: rol #8,%d3 rol #7,%d3 best regards, marcelo samsoniuk Lucas Mendes wrote: > > I got follow lines when I tried a gcc -c calls_test.s. > > calls_test.s:33: Error: operands mismatch -- statement `rol #0x0f,%d3' > ignored > *** Error code 1 > > Where is rol instruction in gcc? :) > > 68EC000 User's Manual techs ROL/ROR as; > > ROd Rx,Dy^1 /* (^1 is 1 in upcase) */ > ROd #<data>,Dy^1 > > What hell is Dy^1? I don't understad what is that, and there's no > anything about > in my 68040 User's Manual hardcopied. > > -- > o _ _ _ > _o /\_ _ \\o (_)\__/o (_) > _< \_ _>(_) (_)/<_ \_| \ _|/' \/ > (_)>(_) (_) (_) (_) (_)' _\o_ > -+----------------+------------------------------------+- > | Lucas Mendes | http://sourceforge.net/users/esc2 | > -+-------------'| <lm...@ne...> | > ---------------------------------------' > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Liquidfire-devel mailing list > Liq...@li... > https://lists.sourceforge.net/lists/listinfo/liquidfire-devel -- You cannot kill time without injuring eternity. |
|
From: Lucas M. <lm...@ne...> - 2003-05-11 05:18:43
|
I got follow lines when I tried a gcc -c calls_test.s.
calls_test.s:33: Error: operands mismatch -- statement `rol #0x0f,%d3'
ignored
*** Error code 1
Where is rol instruction in gcc? :)
68EC000 User's Manual techs ROL/ROR as;
ROd Rx,Dy^1 /* (^1 is 1 in upcase) */
ROd #<data>,Dy^1
What hell is Dy^1? I don't understad what is that, and there's no
anything about
in my 68040 User's Manual hardcopied.
--
o _ _ _
_o /\_ _ \\o (_)\__/o (_)
_< \_ _>(_) (_)/<_ \_| \ _|/' \/
(_)>(_) (_) (_) (_) (_)' _\o_
-+----------------+------------------------------------+-
| Lucas Mendes | http://sourceforge.net/users/esc2 |
-+-------------'| <lm...@ne...> |
---------------------------------------'
|
|
From: Lucas M. <lm...@ne...> - 2003-05-10 02:58:53
|
olah enfermeira! :D
--
o _ _ _
_o /\_ _ \\o (_)\__/o (_)
_< \_ _>(_) (_)/<_ \_| \ _|/' \/
(_)>(_) (_) (_) (_) (_)' _\o_
-+----------------+------------------------------------+-
| Lucas Mendes | http://sourceforge.net/users/esc2 |
-+-------------'| <lm...@ne...> |
---------------------------------------'
|
|
From: Lucas M. <lm...@ne...> - 2003-05-10 02:43:43
|
hi too all list members! :)
--
o _ _ _
_o /\_ _ \\o (_)\__/o (_)
_< \_ _>(_) (_)/<_ \_| \ _|/' \/
(_)>(_) (_) (_) (_) (_)' _\o_
-+----------------+------------------------------------+-
| Lucas Mendes | http://sourceforge.net/users/esc2 |
-+-------------'| <lm...@ne...> |
---------------------------------------'
|