Emulátorok a Windows7-en
xesj.hu
Windows7-en próbálom a 3 emulátort. Az Ultimó tökéletesen működik,
viszont sem a Primoemu, sem az Os-primo nem hajlandó futni, mindkettő
azt üzeni hogy nem támogatott a full-screen mód. Találkoztatok már
ezzel a problémával ? Hogy lehetne rávenni az utóbbi 2 emulátort hogy
fussanak ?
Jelenleg a PTP fájl formátumot tanulmányozom, mert egy olyan Z80
compilert-t írok Java-ban, ami PTP formára konvertál, majd ezt lehetne
futtatni az emulátorokkal.
Üdv: xesj.hu
Viktor Varga
használ a windows 7.
üdvözlettel/best regards: Varga Viktor
----
Futtatható fájlok/Executable files:
Futtatható fájlt vagy azt tartalmazó zip állományt kérem átnevezve
küldjön, különben a víruskereső eltávolítja.
If you would like attach an executable file, please change the
extension of that file, elsewhere the virus scanner removes that file.
---
Jogi figyelmeztetés/Disclaimer:
A levél tartalma csak és kizárólag a címzettekre tartozik. Nem
engedélyezett ezen a címzetteken kívül bármilyen megtekintés vagy
továbbítás. Ha nem érintett, akkor kérem értesítse a küldőt, és
törölje az összes példányt.
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
2011/8/16 xesj.hu <xes...@gmail.com>:
> --
> Hozzászólás: microke...@googlegroups.com
> Leiratkozás: microkey-prim...@googlegroups.com
> Csoportoldal: http://groups.google.com/group/microkey-primo?hl=hu?hl=hu
> Weboldal: http://primo.homeserver.hu
Jozsef Laszlo
Igen, mind a kett�t �n �rtam, mind a kett�t DOS-ra :)
Win7 alatt nem ide�lis, de szerintem, ha felteszed a DOSBOX nev� progit,
azon bel�l
el kellene futniuk.
Egy�bk�nt �n is gondolkodom rajta, hogy j� lenne �sszedobni valami
windows kopatibilis
directx-es emul�tort, de meg�g�rni nem merem, mert annyi id�m most
nincs. Tal�n
valamikor.
joco
> mind a kett� er�sen dos cucc, sz�val azt kellene megn�zni, hogy mit is
> haszn�l a windows 7.
>
>
> �dv�zlettel/best regards: Varga Viktor
> ----
> Futtathat� f�jlok/Executable files:
> Futtathat� f�jlt vagy azt tartalmaz� zip �llom�nyt k�rem �tnevezve
> k�ldj�n, k�l�nben a v�ruskeres� elt�vol�tja.
> If you would like attach an executable file, please change the
> extension of that file, elsewhere the virus scanner removes that file.
> ---
> Jogi figyelmeztet�s/Disclaimer:
> A lev�l tartalma csak �s kiz�r�lag a c�mzettekre tartozik. Nem
> enged�lyezett ezen a c�mzetteken k�v�l b�rmilyen megtekint�s vagy
> tov�bb�t�s. Ha nem �rintett, akkor k�rem �rtes�tse a k�ld�t, �s
> t�r�lje az �sszes p�ld�nyt.
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
>
> 2011/8/16 xesj.hu<xes...@gmail.com>:
>> Sziasztok !
>>
>> Windows7-en pr�b�lom a 3 emul�tort. Az Ultim� t�k�letesen m�k�dik,
>> viszont sem a Primoemu, sem az Os-primo nem hajlandďż˝ futni, mindkettďż˝
>> azt �zeni hogy nem t�mogatott a full-screen m�d. Tal�lkoztatok m�r
>> ezzel a probl�m�val ? Hogy lehetne r�venni az ut�bbi 2 emul�tort hogy
>> fussanak ?
>>
>> Jelenleg a PTP f�jl form�tumot tanulm�nyozom, mert egy olyan Z80
>> compilert-t �rok Java-ban, ami PTP form�ra konvert�l, majd ezt lehetne
>> futtatni az emul�torokkal.
>>
>> �dv: xesj.hu
>>
>> --
>> Hozz�sz�l�s: microke...@googlegroups.com
>> Leiratkoz�s: microkey-prim...@googlegroups.com
xesj.hu
Bár nagyon lassan ismételgette vissza a képernyőn a karaktereket,
sokat nem kísérleteztem vele.
On aug. 16, 19:22, Jozsef Laszlo <rbe...@gmail.com> wrote:
> Hali,
>
> Igen, mind a kett t n rtam, mind a kett t DOS-ra :)
> Win7 alatt nem ide lis, de szerintem, ha felteszed a DOSBOX nev progit,
> azon bel l
> el kellene futniuk.
>
> Egy bk nt n is gondolkodom rajta, hogy j lenne sszedobni valami
> windows kopatibilis
> directx-es emul tort, de meg g rni nem merem, mert annyi id m most
> nincs. Tal n
> valamikor.
>
> joco
>
>
>
>
>
>
>
> > mind a kett er sen dos cucc, sz val azt kellene megn zni, hogy mit is
> > haszn l a windows 7.
>
> > dv zlettel/best regards: Varga Viktor
> > ----
> > Futtathat f jlok/Executable files:
> > Futtathat f jlt vagy azt tartalmaz zip llom nyt k rem tnevezve
> > k ldj n, k l nben a v ruskeres elt vol tja.
> > extension of that file, elsewhere the virus scanner removes that file.
> > ---
> > A lev l tartalma csak s kiz r lag a c mzettekre tartozik. Nem
> > enged lyezett ezen a c mzetteken k v l b rmilyen megtekint s vagy
> > tov bb t s. Ha nem rintett, akkor k rem rtes tse a k ld t, s
> > t r lje az sszes p ld nyt.
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
>
> >> Sziasztok !
>
> >> Windows7-en pr b lom a 3 emul tort. Az Ultim t k letesen m k dik,
> >> viszont sem a Primoemu, sem az Os-primo nem hajland futni, mindkett
> >> azt zeni hogy nem t mogatott a full-screen m d. Tal lkoztatok m r
> >> ezzel a probl m val ? Hogy lehetne r venni az ut bbi 2 emul tort hogy
> >> fussanak ?
>
> >> Jelenleg a PTP f jl form tumot tanulm nyozom, mert egy olyan Z80
> >> compilert-t rok Java-ban, ami PTP form ra konvert l, majd ezt lehetne
> >> futtatni az emul torokkal.
>
> >> dv: xesj.hu
>
> >> --
> >> Hozz sz l s: microke...@googlegroups.com
> >> Leiratkoz s: microkey-prim...@googlegroups.com
Grósz Attila
> Jelenleg a PTP f�jl form�tumot tanulm�nyozom, mert egy olyan Z80
> futtatni az emul�torokkal.
Ez cs�cs! Rem�lem kitartasz az elhat�roz�sod mellett. Ha lehet egy
javaslatom,
akkor r�gt�n k�tszeresen is "multiplatformm�" teszed a cuccost (a Java miatt
egy oldalr�l m�r az). Arra gondolok, hogy voltak m�s 8 bites magyar g�pek,
�s az azokra specifikus form�tumra is ki lehetne b�v�teni a progidat
majd esetleg,
pl. HT 1080Z, Videoton TVC, Homelab, ABC-80...
�dv,
Attila
xesj.hu
Már 2006-ban írtam egy Z80 assembly fordítót Java-ban, és egy futtató
virtuális gépet ami "Zee" névre halgatott (szintén Java-ban), de a Zee-
vel azért túlságosan nem voltam elégedett, bár futtatta a lefordított
gépi kódomat. Most az fogalmazódott meg bennem, miért ne egy Primo
emulátor legyen a futtató, konkrétan az Ultimóra gondolok mivel
Windows7 alatt ez működik kapásból. A Z80 compiler-en is szeretnék
változtatni mivel hiányoznak belőle dolgok, nincs benne EQU így tehát
nincsen igazán szimbólum kezelés, jó lenne ha ilyesmi működne:
screen: EQU 26624 ;A32-es gépen
sorhossz: EQU 32
LD HL,screen+1011b*sorhossz
Ahogy a PTP formátumot elnézem azzal kevesebb probléma lesz.
Mivel sok időm nekem sincs (más szoftverfejlesztésért fizetnek :) így
ez marad a szabadidőmre amikor ráérek és kedvem van. Meg persze kell
kitartás is, van olyan hobby projectem is ami pár éve tart de még csak
az adatmodellezésig jutott :))
Magamról annyit hogy én is egy Primo-val kezdtem ha jól emlékszem 1984-
ben, és imádtam Z80-ban programozni de semmilyen fordítóm nem volt így
szépen papírra irogattam a gépi kódokat majd lett belőle egy basic
betöltő. A legnagyobb hiba pedig az volt hogy egyszer a Petőfi
Csarnokban megszabadultam a géptől a bolhapiacon. Egy működő Commodore
C+4 -et pedig máig otthon őrzök, de ezt megörököltem valakitől.
Azt jó ötletnek tartom hogy más fájl formátumokat is lehetne támogatni
más gépekre. A primo-ra írt compiler-ekkel (pl. AMON) az a bajom hogy
a szövegszerkesztő része gyenge. Félreértés ne essék nem is várnám el
hogy megközelítsék egy mai szerkesztő képességeit, szerintem ilyen
pspad.exe jellegűt nem is lehetne primo-ra írni (hogy is működne a
CTRL-C/V ?). Egyetlen elfogadható módnak azt látom, hogy aki továbbra
is programozna Z80-ban az írja meg a forrást egy mai pc-s
szövegszerkesztővel, és fordítsa le a megfelelő emulátorok kívánt
formáira.
Üdv, xesj.hu
On aug. 18, 07:50, Grósz Attila <gy...@freemail.hu> wrote:
> On 16/08/2011 15:28, xesj.hu wrote:> Jelenleg a PTP f jl form tumot tanulm nyozom, mert egy olyan Z80
> > compilert-t rok Java-ban, ami PTP form ra konvert l, majd ezt lehetne
> > futtatni az emul torokkal.
>
> Ez cs cs! Rem lem kitartasz az elhat roz sod mellett. Ha lehet egy
> javaslatom,
> akkor r gt n k tszeresen is "multiplatformm " teszed a cuccost (a Java miatt
> egy oldalr l m r az). Arra gondolok, hogy voltak m s 8 bites magyar g pek,
> s az azokra specifikus form tumra is ki lehetne b v teni a progidat
> pl. HT 1080Z, Videoton TVC, Homelab, ABC-80...
>
> Attila
Jozsef Laszlo
Ha gondolod, adok p�r tan�csot, azt�n vagy megfogadod �ket, vagy nem. �n is
dolgoztam/dolgozom p�r ilyen scripting nyelven, �s van tapasztalatom benne.
Mivel �j ford�t�t csin�lsz, a nyelvi szab�lyokat te alak�tod ki, nem
kell igazodni
senkihez. �s persze nem kell feltal�lni a spanyol viaszt sem �jra, van
m�r el�g
ilyen nyelvecske. Sz�val ezek t�kr�ben a tan�csaim:
1. ink�bb prefixeket haszn�lk, mint postfixeket. Akkor m�r egy sz� legels�
karakter�b�l el tudod d�nteni, hogy mi is k�vetkezik.
pl. hexa jel�l�sre a 013eh alak helyett $013e - azaz a $ jel m�r
mutatja, hogy hexa sz�m j�n
ugyanezen elven: 11011b helyett pl %11011
2. az assembly direkt�v�kat is prefixeld, �gy k�nnyebb lesz �rtelmezni
�ket. pl table driven asm
a . jelet haszn�lja, szerintem �gy el�g j�
.org 10000
ld a,3
.defb 11,22,33
.end
3. �n sz�vem szerint a label-eket is prefixeln�m, akkor ott is k�nnyebb
fel�p�teni a lookup t�bl�kat.
pl. a : postfix helyett legyen ak�rmi, mondjuk @ (�tlet a turbo pascalb�l)
@c1
inc a
djnz @c1
Ez persze akkor igaz a v�ltoz�kra is, pl akkor m�r �gy: @valami .equ $1000
4. Z80 eset�ben amit minden eddigi ford�t�b�l hi�nyolok, az a nem
dokument�lt utas�t�sok kezel�se.
Mindenk�pp sz�ks�ges az xl xh regisztereket kezel� utas�t�sok, sll stb
megval�s�t�sa, a ford�t� ismerje
�ket
5. A kifejez�sek ki�rt�kel�s�t meg kell csin�lni norm�lisan, az el�g
gagyi, ha a kifejez�s m�veleteit
a megtal�l�s sorrendj�ben hajtja v�gre a ford�t�, meg nem is helyes
matematikailag. Ehhez haszn�ld
a lengyel (postfix) alakot, ha ismered, eln�z�st, ha nem, akkor van r�la
irodalom a neten.
6. Id�z�jelek tudj�k befoglalni egym�st. pl " 'helo' "
A " id�z�jel ismerje a C escape karakterket legal�bb \n \r \x00 stb
7. Makr�k megval�s�t�sa mindenk�pp sz�ks�ges.
Kb ennyi egy szuszra. Rem�lem seg�tenek a tan�csok.
sok sikert
Joco
> Sziasztok !
>
> M�r 2006-ban �rtam egy Z80 assembly ford�t�t Java-ban, �s egy futtat�
> virtu�lis g�pet ami "Zee" n�vre halgatott (szint�n Java-ban), de a Zee-
> vel az�rt t�ls�gosan nem voltam el�gedett, b�r futtatta a leford�tott
> g�pi k�domat. Most az fogalmaz�dott meg bennem, mi�rt ne egy Primo
> emul�tor legyen a futtat�, konkr�tan az Ultim�ra gondolok mivel
> Windows7 alatt ez m�k�dik kap�sb�l. A Z80 compiler-en is szeretn�k
> v�ltoztatni mivel hi�nyoznak bel�le dolgok, nincs benne EQU �gy teh�t
> nincsen igaz�n szimb�lum kezel�s, j� lenne ha ilyesmi m�k�dne:
>
> screen: EQU 26624 ;A32-es g�pen
> sorhossz: EQU 32
> LD HL,screen+1011b*sorhossz
>
> Ahogy a PTP form�tumot eln�zem azzal kevesebb probl�ma lesz.
> Mivel sok id�m nekem sincs (m�s szoftverfejleszt�s�rt fizetnek :) �gy
> ez marad a szabadid�mre amikor r��rek �s kedvem van. Meg persze kell
> kitart�s is, van olyan hobby projectem is ami p�r �ve tart de m�g csak
> az adatmodellez�sig jutott :))
>
> Magamr�l annyit hogy �n is egy Primo-val kezdtem ha j�l eml�kszem 1984-
> ben, �s im�dtam Z80-ban programozni de semmilyen ford�t�m nem volt �gy
> sz�pen pap�rra irogattam a g�pi k�dokat majd lett bel�le egy basic
> bet�lt�. A legnagyobb hiba pedig az volt hogy egyszer a Pet�fi
> Csarnokban megszabadultam a g�pt�l a bolhapiacon. Egy m�k�d� Commodore
> C+4 -et pedig m�ig otthon �rz�k, de ezt meg�r�k�ltem valakit�l.
>
> Azt j� �tletnek tartom hogy m�s f�jl form�tumokat is lehetne t�mogatni
> m�s g�pekre. A primo-ra �rt compiler-ekkel (pl. AMON) az a bajom hogy
> a sz�vegszerkeszt� r�sze gyenge. F�lre�rt�s ne ess�k nem is v�rn�m el
> hogy megk�zel�ts�k egy mai szerkeszt� k�pess�geit, szerintem ilyen
> pspad.exe jelleg�t nem is lehetne primo-ra �rni (hogy is m�k�dne a
> CTRL-C/V ?). Egyetlen elfogadhat� m�dnak azt l�tom, hogy aki tov�bbra
> is programozna Z80-ban az �rja meg a forr�st egy mai pc-s
> sz�vegszerkeszt�vel, �s ford�tsa le a megfelel� emul�torok k�v�nt
> form�ira.
>
> �dv, xesj.hu
József Keresztes
Nem vagyok benne biztos hogy így akarnám megírni a fordítót. A formára is adnék, nekem vizuálisan szebb a postfix,
a bináris adatot így lehetne használni: 1010b, a hexadecimnálist: FA0Bh formában, itt kötelezően csak kis "b" és kis "h" lenne írható.
Oktális adatot nem is akarok, soha nem is volt rá szükség. Gondolkodtam én is prefixeken, de nem tetszenek a @#%! prefixek.
A programot nagybetűkkel írjuk, a szimbólumok kötelezően kisbetűsek:
screen: EQU AB06h
LD HL,screen
cimke: NOP
JR cimke
A direktíváknak sem lenne prefixe, ORG, DS, DW, EQU, RUN lenne.
Nem definiált utasítások kezelése ??? SRL-lel találkoztam már, de SLL-lel nem.
A kifejezés kiértékelése természetesen matematikai alapúra tervezem vagyis 1+2*0 = 1
De itt csak +-*/ műveletek lennének zárójel nélkül !
Idézőjel és aposztróf nem is lenne, mert ugye hogy használnánk őket ? A leírt karakter ascii kódját jelentené ? Ez nem szabványos a különböző gépeken, ha nemcsak primo-ra készülnék fel.
Makrókat biztos nem tervezek.
Én ennyit tűzök ki célnak, ha ez összejön térben és időben én biztos boldog leszek :))
Azért köszi az észrevételeket.
xesj.hu
Hali,
Ha gondolod, adok pár tanácsot, aztán vagy megfogadod őket, vagy nem. Én is
dolgoztam/dolgozom pár ilyen scripting nyelven, és van tapasztalatom benne.
Mivel új fordítót csinálsz, a nyelvi szabályokat te alakítod ki, nem kell igazodni
senkihez. És persze nem kell feltalálni a spanyol viaszt sem újra, van már elég
ilyen nyelvecske. Szóval ezek tükrében a tanácsaim:
1. inkább prefixeket használk, mint postfixeket. Akkor már egy szó legelső
karakteréből el tudod dönteni, hogy mi is következik.
pl. hexa jelölésre a 013eh alak helyett $013e - azaz a $ jel már mutatja, hogy hexa szám jön
ugyanezen elven: 11011b helyett pl %11011
2. az assembly direktívákat is prefixeld, így könnyebb lesz értelmezni őket. pl table driven asm
a . jelet használja, szerintem így elég jó
.org 10000
ld a,3
.defb 11,22,33
.end
3. én szívem szerint a label-eket is prefixelném, akkor ott is könnyebb felépíteni a lookup táblákat.
pl. a : postfix helyett legyen akármi, mondjuk @ (ötlet a turbo pascalból)
@c1
inc a
djnz @c1
Ez persze akkor igaz a változókra is, pl akkor már így: @valami .equ $1000
4. Z80 esetében amit minden eddigi fordítóból hiányolok, az a nem dokumentált utasítások kezelése.
Mindenképp szükséges az xl xh regisztereket kezelő utasítások, sll stb megvalósítása, a fordító ismerje
őket
5. A kifejezések kiértékelését meg kell csinálni normálisan, az elég gagyi, ha a kifejezés műveleteit
a megtalálás sorrendjében hajtja végre a fordító, meg nem is helyes matematikailag. Ehhez használd
a lengyel (postfix) alakot, ha ismered, elnézést, ha nem, akkor van róla irodalom a neten.
6. Idézőjelek tudják befoglalni egymást. pl " 'helo' "
A " idézőjel ismerje a C escape karakterket legalább \n \r \x00 stb
7. Makrók megvalósítása mindenképp szükséges.
Kb ennyi egy szuszra. Remélem segítenek a tanácsok.
sok sikert
Joco
Sziasztok !
Már 2006-ban írtam egy Z80 assembly fordítót Java-ban, és egy futtató
virtuális gépet ami "Zee" névre halgatott (szintén Java-ban), de a Zee-
vel azért túlságosan nem voltam elégedett, bár futtatta a lefordított
gépi kódomat. Most az fogalmazódott meg bennem, miért ne egy Primo
emulátor legyen a futtató, konkrétan az Ultimóra gondolok mivel
Windows7 alatt ez működik kapásból. A Z80 compiler-en is szeretnék
változtatni mivel hiányoznak belőle dolgok, nincs benne EQU így tehát
nincsen igazán szimbólum kezelés, jó lenne ha ilyesmi működne:
screen: EQU 26624 ;A32-es gépen
sorhossz: EQU 32
LD HL,screen+1011b*sorhossz
Ahogy a PTP formátumot elnézem azzal kevesebb probléma lesz.
Mivel sok időm nekem sincs (más szoftverfejlesztésért fizetnek :) így
ez marad a szabadidőmre amikor ráérek és kedvem van. Meg persze kell
kitartás is, van olyan hobby projectem is ami pár éve tart de még csak
az adatmodellezésig jutott :))
Magamról annyit hogy én is egy Primo-val kezdtem ha jól emlékszem 1984-
ben, és imádtam Z80-ban programozni de semmilyen fordítóm nem volt így
szépen papírra irogattam a gépi kódokat majd lett belőle egy basic
betöltő. A legnagyobb hiba pedig az volt hogy egyszer a Petőfi
Csarnokban megszabadultam a géptől a bolhapiacon. Egy működő Commodore
C+4 -et pedig máig otthon őrzök, de ezt megörököltem valakitől.
Azt jó ötletnek tartom hogy más fájl formátumokat is lehetne támogatni
más gépekre. A primo-ra írt compiler-ekkel (pl. AMON) az a bajom hogy
a szövegszerkesztő része gyenge. Félreértés ne essék nem is várnám el
hogy megközelítsék egy mai szerkesztő képességeit, szerintem ilyen
pspad.exe jellegűt nem is lehetne primo-ra írni (hogy is működne a
CTRL-C/V ?). Egyetlen elfogadható módnak azt látom, hogy aki továbbra
is programozna Z80-ban az írja meg a forrást egy mai pc-s
szövegszerkesztővel, és fordítsa le a megfelelő emulátorok kívánt
formáira.
Üdv, xesj.hu
On aug. 18, 07:50, Grósz Attila<gy...@freemail.hu> wrote:
On 16/08/2011 15:28, xesj.hu wrote:> Jelenleg a PTP f jl form tumot tanulm nyozom, mert egy olyan Z80
compilert-t rok Java-ban, ami PTP form ra konvert l, majd ezt lehetneEz cs cs! Rem lem kitartasz az elhat roz sod mellett. Ha lehet egy
futtatni az emul torokkal.
javaslatom,
akkor r gt n k tszeresen is "multiplatformm " teszed a cuccost (a Java miatt
egy oldalr l m r az). Arra gondolok, hogy voltak m s 8 bites magyar g pek,
s az azokra specifikus form tumra is ki lehetne b v teni a progidat
majd esetleg,
pl. HT 1080Z, Videoton TVC, Homelab, ABC-80...
dv,
Attila
--
Hozzászólás: microkey-primo@googlegroups.com
Leiratkozás: microkey-primo+unsubscribe@googlegroups.com
Jozsef Laszlo
A te programod, te �rod, te d�nt�d el, hogyan. :)
A nem dokument�lt Z80 dolgokr�l mindent megtal�lsz itt:
http://www.z80.info/zip/z80-documented.pdf
"A programot nagybet�kkel �rjuk, a szimb�lumok k�telez�en kisbet�sek"
Te �gy �rod. N�lam pl el� nem fordulhat, hogy egy utas�t�st nagybet�vel �rok, szimb�lumokat ann�l ink�bb.
Sz�val ez nagyon �zl�s �s programoz�i megszok�s dolga, k�telez�v� �n nem tenn�k semmit. Legyen akkor
ink�bb case insensitive, �s akkor mindenkinek megfelel. Hidd el, van aki m�sk�pp szereti.
Ami pedig a text be�r�st illeti, igen �n ascii-ra gondoltam, a 32..127 tartom�ny ugye standard,
szerintem azt �rdemes lenne implement�lni. M�sk�l�nben m�g azt se tudod be�rni, hogy "hello world".
Sz�val m�g egyszer: te �rod, te hozod a szab�lyokat, de ha ez nem csak hobbi, hanem azt szeretn�d, hogy
m�s is haszn�lja, akkor szerintem p�r ember v�lem�ny�t �rdemes kik�rni. Erre egy ilyen lista
nagyon alkalmas.
Joco
Hi !
Nem vagyok benne biztos hogy �gy akarn�m meg�rni a ford�t�t. A form�ra is adn�k, nekem vizu�lisan szebb a postfix,
a bin�ris adatot �gy lehetne haszn�lni: 1010b, a hexadecimn�list: FA0Bh form�ban, itt k�telez�en csak kis "b" �s kis "h" lenne �rhat�.
Okt�lis adatot nem is akarok, soha nem is volt r� sz�ks�g. Gondolkodtam �n is prefixeken, de nem tetszenek a @#%! prefixek.
A programot nagybet�kkel �rjuk, a szimb�lumok k�telez�en kisbet�sek:
screen: EQU AB06h
LDďż˝ HL,screen
cimke: NOP
JR cimke
A direkt�v�knak sem lenne prefixe, ORG, DS, DW, EQU, RUN lenne.
Nem defini�lt utas�t�sok kezel�se ??? SRL-lel tal�lkoztam m�r, de SLL-lel nem.
A kifejez�s ki�rt�kel�se term�szetesen matematikai alap�ra tervezem vagyis 1+2*0 = 1
De itt csak +-*/ m�veletek lenn�nek z�r�jel n�lk�l !
Id�z�jel �s aposztr�f nem is lenne, mert ugye hogy haszn�ln�nk �ket ? A le�rt karakter ascii k�dj�t jelenten� ? Ez nem szabv�nyos a k�l�nb�z� g�peken, ha nemcsak primo-ra k�sz�ln�k fel.
Makr�kat biztos nem tervezek.
�n ennyit t�z�k ki c�lnak, ha ez �sszej�n t�rben �s id�ben �n biztos boldog leszek :))
Az�rt k�szi az �szrev�teleket.
xesj.hu
Ha gondolod, adok p�r tan�csot, azt�n vagy megfogadod �ket, vagy nem. �n is
dolgoztam/dolgozom p�r ilyen scripting nyelven, �s van tapasztalatom benne.
Mivel �j ford�t�t csin�lsz, a nyelvi szab�lyokat te alak�tod ki, nem kell igazodni
senkihez. �s persze nem kell feltal�lni a spanyol viaszt sem �jra, van m�r el�g
ilyen nyelvecske. Sz�val ezek t�kr�ben a tan�csaim:
1. ink�bb prefixeket haszn�lk, mint postfixeket. Akkor m�r egy sz� legels�
karakter�b�l el tudod d�nteni, hogy mi is k�vetkezik.
pl. hexa jel�l�sre a 013eh alak helyett $013e �- azaz a $ jel m�r mutatja, hogy hexa sz�m j�n
ugyanezen elven: �11011b helyett pl %11011
2. az assembly direkt�v�kat is prefixeld, �gy k�nnyebb lesz �rtelmezni �ket. pl table driven asm
a . jelet haszn�lja, szerintem �gy el�g j�
ďż˝ ďż˝.org 10000
� �ld a,3
� �.defb �11,22,33
ďż˝ ďż˝ .end
3. �n sz�vem szerint a label-eket �is prefixeln�m, akkor ott is k�nnyebb fel�p�teni a lookup t�bl�kat.
pl. a �: postfix helyett legyen ak�rmi, mondjuk @ �(�tlet a turbo pascalb�l)
ďż˝@c1
� � � �inc a
ďż˝ ďż˝ ďż˝ djnz @c1
Ez persze akkor igaz a v�ltoz�kra is, pl akkor m�r �gy: �@valami .equ $1000
4. Z80 eset�ben amit minden eddigi ford�t�b�l hi�nyolok, az a nem dokument�lt utas�t�sok kezel�se.
Mindenk�pp sz�ks�ges az xl xh regisztereket kezel� utas�t�sok, sll stb megval�s�t�sa, a ford�t� ismerje
�ket
5. A kifejez�sek ki�rt�kel�s�t meg kell csin�lni norm�lisan, az el�g gagyi, ha a kifejez�s m�veleteit
a megtal�l�s sorrendj�ben hajtja v�gre a ford�t�, meg nem is helyes matematikailag. Ehhez haszn�ld
a lengyel (postfix) alakot, ha ismered, eln�z�st, ha nem, akkor van r�la irodalom a neten.
6. Id�z�jelek tudj�k befoglalni egym�st. pl " 'helo' "
A " id�z�jel ismerje a C escape karakterket legal�bb \n \r \x00 stb
7. Makr�k megval�s�t�sa mindenk�pp sz�ks�ges.
Kb ennyi egy szuszra. Rem�lem seg�tenek a tan�csok.
sok sikert
Joco
Sziasztok !
M�r 2006-ban �rtam egy Z80 assembly ford�t�t Java-ban, �s egy futtat�
virtu�lis g�pet ami "Zee" n�vre halgatott (szint�n Java-ban), de a Zee-
vel az�rt t�ls�gosan nem voltam el�gedett, b�r futtatta a leford�tott
g�pi k�domat. Most az fogalmaz�dott meg bennem, mi�rt ne egy Primo
emul�tor legyen a futtat�, konkr�tan az Ultim�ra gondolok mivel
Windows7 alatt ez m�k�dik kap�sb�l. A Z80 compiler-en is szeretn�k
v�ltoztatni mivel hi�nyoznak bel�le dolgok, nincs benne EQU �gy teh�t
nincsen igaz�n szimb�lum kezel�s, j� lenne ha ilyesmi m�k�dne:
screen: � �EQU �26624 ;A32-es g�pen
sorhossz: �EQU �32
� � � � � �LD � HL,screen+1011b*sorhossz
Ahogy a PTP form�tumot eln�zem azzal kevesebb probl�ma lesz.
Mivel sok id�m nekem sincs (m�s szoftverfejleszt�s�rt fizetnek :) �gy
ez marad a szabadid�mre amikor r��rek �s kedvem van. Meg persze kell
kitart�s is, van olyan hobby projectem is ami p�r �ve tart de m�g csak
az adatmodellez�sig jutott :))
Magamr�l annyit hogy �n is egy Primo-val kezdtem ha j�l eml�kszem 1984-
ben, �s im�dtam Z80-ban programozni de semmilyen ford�t�m nem volt �gy
sz�pen pap�rra irogattam a g�pi k�dokat majd lett bel�le egy basic
bet�lt�. A legnagyobb hiba pedig az volt hogy egyszer a Pet�fi
Csarnokban megszabadultam a g�pt�l a bolhapiacon. Egy m�k�d� Commodore
C+4 -et pedig m�ig otthon �rz�k, de ezt meg�r�k�ltem valakit�l.
Azt j� �tletnek tartom hogy m�s f�jl form�tumokat is lehetne t�mogatni
m�s g�pekre. A primo-ra �rt compiler-ekkel (pl. AMON) az a bajom hogy
a sz�vegszerkeszt� r�sze gyenge. F�lre�rt�s ne ess�k nem is v�rn�m el
hogy megk�zel�ts�k egy mai szerkeszt� k�pess�geit, szerintem ilyen
pspad.exe jelleg�t nem is lehetne primo-ra �rni (hogy is m�k�dne a
CTRL-C/V ?). Egyetlen elfogadhat� m�dnak azt l�tom, hogy aki tov�bbra
is programozna Z80-ban az �rja meg a forr�st egy mai pc-s
sz�vegszerkeszt�vel, �s ford�tsa le a megfelel� emul�torok k�v�nt
form�ira.
�dv, xesj.hu
On aug. 18, 07:50, Gr�sz Attila<gy...@freemail.hu> �wrote:
On 16/08/2011 15:28, xesj.hu wrote:> �Jelenleg a PTP f jl form tumot tanulm nyozom, mert egy olyan Z80
compilert-t rok Java-ban, ami PTP form ra konvert l, majd ezt lehetneEz cs cs! Rem lem kitartasz az elhat roz sod mellett. Ha lehet egy
futtatni az emul torokkal.
javaslatom,
akkor r gt n k tszeresen is "multiplatformm " teszed a cuccost (a Java miatt
egy oldalr l m r az). Arra gondolok, hogy voltak m s 8 bites magyar g pek,
s az azokra specifikus form tumra is ki lehetne b v teni a progidat
majd esetleg,
pl. HT 1080Z, Videoton TVC, Homelab, ABC-80...
dv,
Attila
--
Csoportoldal: http://groups.google.com/group/microkey-primo?hl=hu?hl=hu
Weboldal: http://primo.homeserver.hu
--
Hozz�sz�l�s: microke...@googlegroups.com
Leiratkoz�s: microkey-prim...@googlegroups.com
Viktor Varga
> adnék, nekem vizuálisan szebb a postfix,
> a bináris adatot így lehetne használni: 1010b, a hexadecimnálist: FA0Bh
> formában, itt kötelezően csak kis "b" és kis "h" lenne írható.
nem akarok beleszólni, de nekem a %,$ szimaptikusabb, mert akkor már
előre tudom milyen szám van előttem, nem pedig a végén, hogy bazmeg,
ennek nem is 1000101 a bitmintája, hanem 11101010. :)
engem a német mondatokra emlékeztet az postfix, amikor már a 6. sorban
jársz, de ige még nincs. :)
> Oktális adatot nem is akarok, soha nem is volt rá szükség. Gondolkodtam én
> is prefixeken, de nem tetszenek a @#%! prefixek.
oktális az tényleg nem kellett még sosem sehova.
de alternatív megoldásként javasolhatom az értelmezését ennek is annak is?
> A programot nagybetűkkel írjuk, a szimbólumok kötelezően kisbetűsek:
>
> screen: EQU AB06h
> LD HL,screen
>
> cimke: NOP
> JR cimke
>
hát meg kell mondjam, assemblybe én még így sosem írtam kódot.
nem nyomunk shiftet ha nem kell, az plusz meló, és a label azért lett
mindig nagybetű, hogy észrevehető legyen. :)
> A direktíváknak sem lenne prefixe, ORG, DS, DW, EQU, RUN lenne.
én is úgy szoktam meg, hogy van prefix, így egy pontra keresve meg
tudom keresni az összes direktívát. viszont ha nagybetű ez is az is,
akkor nehéz lesz észrevenni.
én annak tudok örülni, ha syntax highligtos editorban editált színes
kód lefordul. :)
> Nem definiált utasítások kezelése ??? SRL-lel találkoztam már, de SLL-lel
> nem.
>
> A kifejezés kiértékelése természetesen matematikai alapúra tervezem vagyis
> 1+2*0 = 1
> De itt csak +-*/ műveletek lennének zárójel nélkül !
>
> Idézőjel és aposztróf nem is lenne, mert ugye hogy használnánk őket ? A
> leírt karakter ascii kódját jelentené ? Ez nem szabványos a különböző
> gépeken, ha nemcsak primo-ra készülnék fel.
hát csatlakozom, egy ascii string esetében nem árt, ha könnyen be tudom rakni...
> Makrókat biztos nem tervezek.
pedig az a királyság. :)
> Én ennyit tűzök ki célnak, ha ez összejön térben és időben én biztos boldog
> leszek :))
>
> Azért köszi az észrevételeket.
tudom saját projekt lesz, de ha király és sokan használják, ki tudja,
még kereskedelmi kód is kinőhet belőle. :)
csak ötletelés persze amit eddig mondtam, nem akarok beleszólni...
üdv: Viktor
Gábor Lénárt
> Hi !
>
> Nem vagyok benne biztos hogy így akarnám megírni a fordítót. A formára is
> adnék, nekem vizuálisan szebb a postfix,
> a bináris adatot így lehetne használni: 1010b, a hexadecimnálist: FA0Bh
> formában, itt kötelezően csak kis "b" és kis "h" lenne írható.
Amugy ha egy hexa szam A-F hexa digitekkel kezdodik, akkor altalaban a
legtobb assembler/compiler megkoveteli hogy irj ele egy nullat. Pont azert,
mert pl az FA0BH lehet egy cimke is, es nem tudod, hogy ez hexa szam-e! Ha
0-9 kezdodik akkor egyertelmu, mivel azzal label nem kezdodhet. Eppen ezert
sokkal normalisabb szerintem is a prefix hasznalat, ahogy sok CPU-nal ez igy
is van defaulte asm syntaxis (pl 65xx cpu-k, talan a motorole 68k is, stb)
> Oktális adatot nem is akarok, soha nem is volt rá szükség. Gondolkodtam én
> is prefixeken, de nem tetszenek a @#%! prefixek.
> A programot nagybetűkkel írjuk, a szimbólumok kötelezően kisbetűsek:
Ezt szerintem hulyeseg kikotni, mert stilusa valogatja, hogy ki hogy szokta
meg.
>
> screen: EQU AB06h
> LD HL,screen
>
> cimke: NOP
> JR cimke
>
> A direktíváknak sem lenne prefixe, ORG, DS, DW, EQU, RUN lenne.
Ez is hiba szerintem. Sok fejlett assembler, ami kulon ompiler/link pass-al
rendelkezik es kezel archive-okat, sajat object formatumot stb csinalja a
prefixes dolgot es valoszinu nem kezdok az alkotoi, lehet tanulni belole!
Erdemes megnezni pl a cc65 assembler-et, kulon linker config file-okkal,
sajat object formatummal, libekkel stb. Ha mar valaki fejlett dolgokat akar,
ez imho a minimum.
> > Hozzászólás: microkey-primo@googlegroups.**com<microke...@googlegroups.com>
> > Leiratkozás: microkey-primo+unsubscribe@**googlegroups.com<microkey-primo%2Bunsu...@googlegroups.com>
> > Csoportoldal: http://groups.google.com/**group/microkey-primo?hl=hu?hl=**
> > hu <http://groups.google.com/group/microkey-primo?hl=hu?hl=hu>
> > Weboldal: http://primo.homeserver.hu
> >
>
> --
> Hozzászólás: microke...@googlegroups.com
> Leiratkozás: microkey-prim...@googlegroups.com
xesj.hu
Előszőr is köszönöm a sok észrevételt !
A projectem csak hobby kategóriájú, semmikép sem lesz kereskedelmi és
egyéb, és elsősorban magam szórakoztatására készül :)
Természetesen az viszont alapvető hogy Ti is használhatjátok,
mindenképpen publikussá akarom tenni ha kész lesz.
Talán a lényeg a HOBBY szócskán van, itt más szempontok diktálnak mint
egy pénzes(munkahelyi projectnél), így talán jobban
megértitek miért gondolkodom ahogy gondolkodom, és egyáltalán miért
csinálom:
1. Nincs határidő
2. Én vagyok a megrendelő, a kivitelező, a főnök és a beosztott, a
felhasználó, és majdnem minden résztvevő, egy kis kiegészítéssel:
Mivel publikussá teszem, az nálam alapvető hogy a programhibákat
javítani kell. Tehát amit bevállalok hogy működik annak működnie kell.
Így tehát a program kevesebbet fog tudni mint szeretnétek, de azt
viszont megbízhatóan.
3. Sokkal kevesebb energiát tudok ráfordítani, mintha nyugdíjasként
itthon ücsörögnék, ugyanezért értelek meg titeket
hogy 1-2 emulátor még mindig DOS-ra van megírva, és nincs átírva.
Egy két dologra azért reagálnék a leírtakhoz kapcsolódva:
A prefixes dolgok továbbra sem tetszenek főleg ezek a @%$# és társai,
márpedig a kinézetre sokat adok:
cúnya: LD A,$F8/%1010+@VALUE
szebb: LD A,FFh/1010b+value
A szimbólumok és pl. hexa értékek, regiszter összekeveredésének
megakadályozására én szebbnek látom a nagy és kisbetű előírásokat.
Az 0FBH, FBH, HL, HL_, HL' közül hirtelenjében ránézve nem is látható
melyik szimbólum, hacsak nem vezetnénk be előtte
valami "csúnya" prefixet. Ezen is elmélkedtem már, nekem a kötelezően
kisbetűs szimbólum jön be:
0FBH, fbh, HL, hl_, HL' az előzőek szerint az én jelölésemmel.
A stringeken gondolkodtam a legtöbben, de egyelőre itt is azon az
állásponton vagyok hogy nem vezetem be őket.
Ugyanis ha le tudom írni a "hello world" -öt, akkor mekkora
félmegoldás, mert miért nem tudom az "árvíztűrő" -t ?
Ha pedig azt is le tudom írni akkor mi van az ékezetekkel ? Az már nem
szabványos, gépenként különböző lehet,
márpedig most nemcsak primo-ra tervezünk. Gondolkodtam hogy be lehetne
vezetni egy pseudo parancsot (environment), például
ENV primo
ENV ht1080z
és akkor tudhatná hogyan fordítsa az ékezetes karaktereket. Érdemes
lenne bevezetni valamit hogy a chr(255),
és egyéb karakterek is láthatók legyenek: "árvíztűrő\xFF\r\n". Aztán
vannak azok a karakterek amik vannak pc-n, tehát
a forrásba beírhatók, de egyik gépen van a másikon nincs stb...
(Sajnos) úgy döntöttem hogy nem foglalkozom string kezeléssel, jó
lenne, de nem vállalom be.
Mindenesetre ha észrevételetek van, nyugodtan írjatok, elképzelhető
hogy találok benne olyat amit érdemes lenne megvalósítanom,
de mint az elején mondtam HOBBY projectről van szó.
Amit én bénaságnak tartok ha úgy működik egy fordító hogy 2+3*5 = 25,
márpedig ilyen van az egyik primo füzetben.
Ugyanis akik megírták azoknak nem kellett volna bevállalni hogy
kiértékelik a kifejezést.
Pont ilyen okból nem lehet nálam zárójelezni hatványozni stb, mert nem
akarok ennek kiértékelésével foglakozni, nem akarok ebbe x időt
befektetni.
Marad a 4 alapművelet.
Pl. a forráskódot közelezően .z80 kiterjesztéssel kell készíteni, és
kötelezően UTF-8 -as fájl formátumban (dos vagy unix sorvég is
helyes).
Mert ha már sajnos egy text fájl nem tudja önmagáról leírni hogy
milyen kódolással kell őt kiolvasni (mint az XML),
akkor írjuk már elő hogy mi a kötelező kódolása, ne forduljon elő hogy
a program számlájára írjuk hogy béna mert nem jól
olvassa belőle az árvíztűrőt.
Egyelőre ennyit, így is hosszúra sikeredett a levelem, jó hétvégét !
Üdv: xesj.hu
Gábor Lénárt
> Egy két dologra azért reagálnék a leírtakhoz kapcsolódva:
> A prefixes dolgok továbbra sem tetszenek főleg ezek a @%$# és társai,
> márpedig a kinézetre sokat adok:
> cúnya: LD A,$F8/%1010+@VALUE
> szebb: LD A,FFh/1010b+value
Bocsi, en ezt pont forditva latom pl :)
>
> A szimbólumok és pl. hexa értékek, regiszter összekeveredésének
> megakadályozására én szebbnek látom a nagy és kisbetű előírásokat.
> Az 0FBH, FBH, HL, HL_, HL' közül hirtelenjében ránézve nem is látható
> melyik szimbólum, hacsak nem vezetnénk be előtte
> valami "csúnya" prefixet. Ezen is elmélkedtem már, nekem a kötelezően
Ugy latszik, ez izles kerdese, en a prefixes dolgokat latom szebbnek, de
voltakeppen mindenhol jelolni kell: csak az a kerdes, hogy az elejen vagy a
vegen :) A prefix-es megoldas amugy jobban is olvashato szerintem ember
szamara is, kvazi "azonnal latszik".
Plusz egy csomo gondot megold, amirol mar beszeltuk (nem keveredik egy label
pl ffh es egy hexa szam, nem kotelezo a kis/nagybetus iras, nem kell 0 elle,
hogy kivedjuk az ffh problemat, stb stb). Az egyetlen hatranya, amit
felhoztal, hogy "csunya", az viszont szubjektiv, meg az elozo okok mind
objektiv tenyezok.
Persze, ha te irod, neked fontosabb lehet a sajat igenyed, ez is ertheto!
> kisbetűs szimbólum jön be:
> 0FBH, fbh, HL, hl_, HL' az előzőek szerint az én jelölésemmel.
>
> A stringeken gondolkodtam a legtöbben, de egyelőre itt is azon az
> állásponton vagyok hogy nem vezetem be őket.
> Ugyanis ha le tudom írni a "hello world" -öt, akkor mekkora
> félmegoldás, mert miért nem tudom az "árvíztűrő" -t ?
> Ha pedig azt is le tudom írni akkor mi van az ékezetekkel ? Az már nem
> szabványos, gépenként különböző lehet,
> márpedig most nemcsak primo-ra tervezünk. Gondolkodtam hogy be lehetne
> vezetni egy pseudo parancsot (environment), például
> ENV primo
> ENV ht1080z
> és akkor tudhatná hogyan fordítsa az ékezetes karaktereket. Érdemes
Igen, de itt arra is figyelni kell, hogy mi a forras encoding, amiben az
assembly forras irodott! Mondjuk persze lehet feltetelezni, hogy az pl
mindig utf-8, es akkor abbol fordit a megfelelo kivalasztott "env"-re. Barf
en ezeknel a pseudo assembler keyword-oknel is fenntartom, hogy szebb, ha
meg vannak kulonboztetve, azaz .env es nem env, peldaul.
> Mert ha már sajnos egy text fájl nem tudja önmagáról leírni hogy
> milyen kódolással kell őt kiolvasni (mint az XML),
> akkor írjuk már elő hogy mi a kötelező kódolása, ne forduljon elő hogy
> a program számlájára írjuk hogy béna mert nem jól
> olvassa belőle az árvíztűrőt.
Na igen, erre irtam, hogy imho ha mar cross-assembler pl (PC-n fut nem a
target gepen), akkor erdemes, a PC OS-ek kozt elterjedt "kozos nevezot"
hanszalni, ez meg szerintem az utf-8. Az assembler futasakor az olyan utf-8
szekvenciak, amelyek nem fordithatoak le, hibat okoznak, igy kijon az is, ha
valaki valami mas encoding-ot akar hasznalni pl agybeteg windows-xyzw stb
hulyesegeket.
xesj.hu
HÁT LEGYEN ! Tegnap míg néztem a repülőket a Duna partján és az ország
tortáját ettem, gondolkodtam :)
Mindenki prefixet preferál, string kezelést szeretne, kis/nagybetű
választást, beadom a derekam, íme akkor én is átprogramoztam az
agyamat (vagy túl nagyot robbant egy tűzijáták eleme a fejem felett),
íme akkor az általam is támogatott augusztus 20 verzió:
http://xesj.hu/z80/minta_v20110820.html
A string kezelésnél remélem érthető a \-ek használata, és valóban
a .ENV mint környzet határozhatja meg milyen byte legyen a "őű§ß¤÷×"
stb karakterekből, vagy pedig az adott pc-s karakter, nem értelmezhető
az emulált hardveren (=fordításnál hibaüzenet). S persze ha már egy
hexa jelölése $FA akkor stringként "\$FA".
Amiben továbbra is ellenállok:
- Csak azért sem lesz oktális konstans (számomra értelmetlen ez a 3-
bites vacakolás, akkor miért nincs pl. 2 bitre ???)
- Makró kezelést sem építek be
Remélem így közelebb kerültünk egymás elképzeléseihez, várom a további
észrevételeket.
Egyikőtök írta a kifejezés kiértékeléshez a "lengyel logikát".
Hallottam már róla, de sosem alkalmaztam még, ennek is utánanéztem,
elég érdekes. Persze nálam nem lehet zárójelezni a kifejezéseknél, így
egyszerűbb a dolog.
Üdv, xesj
Viktor Varga
> - Csak azért sem lesz oktális konstans (számomra értelmetlen ez a 3-
> bites vacakolás, akkor miért nincs pl. 2 bitre ???)
Egyetértek.
Egyébként valaki látott már helyzetet, ahol van értelme?
A linux jogosultságokat most hagyjuk ki. Bárhol valaki használt
programozás során oktális számkoat?
Jozsef Laszlo
ld a,"x" ; helytelen (??)
ld a,"xx" helytelen
ld a,'x' ; helyes
ld hl,"nem jo"
ld hl,"jo"
Talán érthetô, mire gondolok. Plusz bekavar még, ha utf8 esetében a két karakterhez több, mint két bájt kell.
Joco
Sent from my iPod
Grósz Attila
> Sziasztok !
>
> �me akkor az �ltalam is t�mogatott augusztus 20 verzi�:
>
> http://xesj.hu/z80/minta_v20110820.html
Ha esetleg nagyon belelend�ln�l, csin�lhatn� hozz� egy IDE-t is :)
�n elkezdtem anno egyet C#-ban (igaz MOS/CSG 6502-es assemblerre), de
nem fejeztem be. Be
lehetett neki konfigur�lni vagy 5-6 f�le assemblert.
Istenigaz�b�l rengeteg k�sz komponens van ezekhez a .NET iz�khez, b�r �n
nem igaz�n
haszn�ltam/szerettem sosem.
Aprop� miben �rod a cuccost?
�dv,
Attila
xesj.hu
Természetesen ha van DS akkor van karakter is, csak annyi a különbség
hogy erre nem akarok bevezetni szimpla aposztrófot, marad az idézőjel:
LD A,"á"
Itt egyértelmű hogy csak 1 karakter írható.
LD A,"á"-1
is helyes, hiszen numerikus kifejezés részeként a karakter értéke az
ascii kódja.
Eddig rendben is van, ami probléma:
LD HL,"ab"
Mi kerül H-ba ? "a" vagy "b" ? Low-high byte probléma !
Ugyanis egy DS "abc" szépen egymás után rakja le a byte-okat:
asc('a'), asc('b'), asc('c')
Egy DS "ab" hasonlóan: asc('a'), asc('b')
Ha az LD HL,"ab" -t is hasonlóra veszem akkor a H regiszter-be a "b"
kerül (LOW,HIGH)
Viszont
LD HL,"ab"-0
Egy numerikus kifejezés itt már az "a" betű ascii kódjának kell
bekerülnie a H-ba.
Egyelőre az ilyen anomáliák miatt úgy gondoltam a DS-ben írható
bármekkora string,
a többi helyen viszont csak 1 karakter írható, és az egyenlő a
karakter ascii kódjával.
Tehát LD HL,"ab" fordítási hibát okoz.
Üdv, xesj
On aug. 21, 21:20, Jozsef Laszlo <rbe...@gmail.com> wrote:
> Egy apró észrevételem lenne. Ha lesznek stringek, akkor lenni kell karaktereknek is, máskülönben inkonzisztens lesz a kiértékelés. Ahol a fordító egy bájtot vár, nem szabad karakterláncot megadni. Ahol pedig 16 bites számot, ott max két karakteres szöveget. Pl
>
> ld a,"x" ; helytelen (??)
> ld a,"xx" helytelen
> ld a,'x' ; helyes
>
> ld hl,"nem jo"
> ld hl,"jo"
>
> Talán érthetô, mire gondolok. Plusz bekavar még, ha utf8 esetében a két karakterhez több, mint két bájt kell.
>
> Joco
>
> Sent from my iPod
>
xesj.hu
java -jar z80ptp.jar d:\tmp\minta.z80 ptp cas
De ha csak így indítod:
java -jar z80ptp.jar
akkor feljön egy grafikus felület, file választó gombbal és checkbox-
okkal hogy milyen formátumot kérsz (ptp, cas, ...)
Amúgy a project nevére valami jót kell kitalálni, és mivel nem csak
ptp támogatásra készülünk a z80ptp sem teljesen korrekt.
Mivel van PRimo, ULTimo, lehetne Zimo is, de a névválasztással nem
kell sietni, ez ráér a legvégén is.
On aug. 21, 21:44, Grósz Attila <gy...@freemail.hu> wrote:
> On 21/08/2011 16:58, xesj.hu wrote:> Sziasztok !
>
>
> >http://xesj.hu/z80/minta_v20110820.html
>
> Ha esetleg nagyon belelend ln l, csin lhatn hozz egy IDE-t is :)
> nem fejeztem be. Be
>
> Istenigaz b l rengeteg k sz komponens van ezekhez a .NET iz khez, b r n
> nem igaz n
> haszn ltam/szerettem sosem.
>
> Aprop miben rod a cuccost?
>
> dv,
> Attila
Gábor Lénárt
> > Amiben tov�bbra is ellen�llok:
> > - Csak az�rt sem lesz okt�lis konstans (sz�momra �rtelmetlen ez a 3-
> > bites vacakol�s, akkor mi�rt nincs pl. 2 bitre ???)
>
> Egyet�rtek.
> Egy�bk�nt valaki l�tott m�r helyzetet, ahol van �rtelme?
> A linux jogosults�gokat most hagyjuk ki. B�rhol valaki haszn�lt
> programoz�s sor�n okt�lis sz�mkoat?
Nagygepes hagyomanyai vannak. Imho hasznalata manapsag jelentosen korlatos,
altalaban char constansok megadasnal szokas idonkent hasznalni, mas
"normalis" pelda nem is jut az eszembe (a "linux" - helyesebben unix -
jogosultsagokat persze mas modon is meg lehet adni, meg sok koze amugy se
lenne egy olyan assembler eseten, ahol a target machine nem futtat semmifele
unix-ot :)