z80ptpt project
xesj.hu
Új témát nyitottam, ez már nem az emulátor témaköre, inkább ide írok.
Szóval írtam nektek hogy nincs határidő, de persze úgy terveztem az
egészet hogy 1 éven belül azért készen leszek. Ha jövő nyáron
lubickolok a Balatonban azért jó lenne azzal az érzéssel hogy kész
vagyok, működik :)
Túl sok időt tényleg nem tudok rá szánni, és a régi projectemet
elnézve (ami már fordított z80 forráskódot), nem úgy kell működnie a
fordítónak. Ott egyszerű volt a helyzet mert azt mondtam hogy egy z80
forrás sort szétszedtem a space-ek mentén (mint elválasztó karakter)
és megvolt a cimke, utasítás, operandus stb.
Most viszont nem mondhatom hogy a ";" karakter a megjegyzés kezdete
egészen a sor végéig hiszen lehet hogy az operandus tartalmaz ";"-t
egy stringen belül, ami nem a megjegyzés kezdete, vagy egy string
eleme a space így nem vágható a sor space-ek mentén elemekre. Gond egy
szál se, haladok, időm mint a tenger :)
Üdv, xesj.hu
Oravecz László
Túl sok időt tényleg nem tudok rá szánni, és a régi projectemet
elnézve (ami már fordított z80 forráskódot), nem úgy kell működnie a
fordítónak. Ott egyszerű volt a helyzet mert azt mondtam hogy egy z80
forrás sort szétszedtem a space-ek mentén (mint elválasztó karakter)
és megvolt a cimke, utasítás, operandus stb.
Most viszont nem mondhatom hogy a ";" karakter a megjegyzés kezdete
egészen a sor végéig hiszen lehet hogy az operandus tartalmaz ";"-t
egy stringen belül, ami nem a megjegyzés kezdete, vagy egy string
eleme a space így nem vágható a sor space-ek mentén elemekre. Gond egy
szál se, haladok, időm mint a tenger :)
Üdv, xesj.hu
--
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
xesj.hu
On aug. 23, 22:22, Oravecz László <laszlo.orav...@gmail.com> wrote:
> StreamTokenizer?
>
> 2011/8/23 xesj.hu <xesj...@gmail.com>
Oravecz László
xesj.hu
http://xesj.hu/z80/minta_v20110820.html
Üdv, xesj
On aug. 24, 18:01, Oravecz László <laszlo.orav...@gmail.com> wrote:
> Tudnál küldeni egy példa forrást? Nem kell működő programnak lennie, csak
> minta, hogy mit is kell fordítani
>
> L
>
Jozsef Laszlo
N�zem a p�lda forr�st �s gondolkodom k�zben. Az .env bevezet�s�t j�
�tletnek tartom, de tal�n
elker�lhet� lenne, kicsit az�rt idegenkedem t�le, mert ezt kv�zi akkor
ugye bele fogod dr�tozni
a ford�t�ba, teh�t nem lesz lehet�s�g m�dos�tani, �jat l�trehozni. Ezt
csak a ford�t� k�sz�t�je, teh�t
te tudod majd megtenni. J� lenne ezt a dolgot �ttolni a felhaszn�l�ra.
K�t dolgot javaslok az .env
helyett, ha lehet.
1. �n csin�ln�k valami karakter defini�l� utas�t�st, amivel a k�dban meg
lehetne mondani,
hogy az adott utf8 karaktert mire ford�tsa �t. Valahogy �gy: .chrdef "�"
= 160,20
ez azt mondan�, hogy mostant�l az "�" karaktert ezzel a k�t b�jttal kel
helyettes�teni, szerintem
egy sima b�jtsorozat defin�ci� mindenf�le k�dol�shoz j� lehet.
2. hogy ezeket a defin�ci�kat ne kelljen a forr�sban t�rolni, �n
bevezetn�m az .include assembler
utas�t�st, ami m�s forr�st bef�z a megadott forr�sba a c nyelvi
#include-hoz hasonl�an. �gy a g�p-specifikus
dolgokat le lehetne �rni egy k�ls� f�jlban, �s azt k�s�bb csak
include-olni kellene a forr�sba.
(az .include valami �sszer� m�lys�gig lehet rekurz�v)
Pl. a primo.inc f�jl tartalma
; definitions for Pirmo A64
&SCREEN .equ 65536-6144
.defchr "ďż˝" = 112
.defchr "ďż˝" = 123
stb...
�s k�s�bb a m�sik forr�sban:
.include "primo.inc"
ld hl,&SCREEN
Ezzel a .env-et ki tudod v�ltani, �s a felhaszn�l� is tudja edit�lni,
m�dos�tani, adott g�pt�pushoz l�trehozni.
Azaz t�bben is tudunk dolgozni rajta.
Szerintetek?
Joco
> Ilyesmit kell leford�tani, most ez a szabv�ny az elfogadott:
>
> http://xesj.hu/z80/minta_v20110820.html
>
> �dv, xesj
>
>
xesj.hu
Én továbbra is úgy gondolom hogy az ENV-cuccok be lesznek drótozva a
forrásba,
igaz ebbe csak én tudok belenyúlni (hacsak nem lesz nyílt a forrás),
de sajnos valóban
így van, a fejlesztő kezében összpontosul olyan dolog amit nem tud/
nincs lehetősége
másnak csinálni. Ha programhiba van, az is rajtam múlik kijavítom
e :))
Ez teljesen normális, ugyanúgy az emulátorokban lévő hibák javítása is
a fejlesztő kezében van,
kijavítja-e, és mikor ? Ugye hobby fejlesztésről beszélünk ???
Mivel a projectet nem fogom túlbonyolítani, nem lesz include-ra
lehetőség.
Azt ne felejtsük el hogy az "á" és bármi egyéb karakterből mindig 1
byte lesz hiszen
régi 8 bites gépekről van szó. Ha úgy gondoltad hogy az UTF-8
kódolással
a 160,20 kétbájtos kódot(pl. "á" betű) a 8 bites gépen 65-re
fordítsuk, az rendben van.
Inkább abban kellene majd segítség ha összeszedi valaki hogy egyes
gépeken,
az adott karaktereket mire fordítsuk, de ez még ráér a project végén,
és elképzelhető hogy én is könnyen összeszedem ezeket az infókat...
Üdv, xesj
On aug. 25, 12:52, Jozsef Laszlo <rbe...@gmail.com> wrote:
> Hali,
>
> N zem a p lda forr st s gondolkodom k zben. Az .env bevezet s t j
> tletnek tartom, de tal n
> elker lhet lenne, kicsit az rt idegenkedem t le, mert ezt kv zi akkor
> ugye bele fogod dr tozni
> a ford t ba, teh t nem lesz lehet s g m dos tani, jat l trehozni. Ezt
> csak a ford t k sz t je, teh t
> te tudod majd megtenni. J lenne ezt a dolgot ttolni a felhaszn l ra.
> K t dolgot javaslok az .env
> helyett, ha lehet.
>
> 1. n csin ln k valami karakter defini l utas t st, amivel a k dban meg
> lehetne mondani,
> hogy az adott utf8 karaktert mire ford tsa t. Valahogy gy: .chrdef " "
> = 160,20
> ez azt mondan , hogy mostant l az " " karaktert ezzel a k t b jttal kel
> helyettes teni, szerintem
> egy sima b jtsorozat defin ci mindenf le k dol shoz j lehet.
>
> 2. hogy ezeket a defin ci kat ne kelljen a forr sban t rolni, n
> bevezetn m az .include assembler
> utas t st, ami m s forr st bef z a megadott forr sba a c nyelvi
> #include-hoz hasonl an. gy a g p-specifikus
> dolgokat le lehetne rni egy k ls f jlban, s azt k s bb csak
> include-olni kellene a forr sba.
> (az .include valami sszer m lys gig lehet rekurz v)
>
> Pl. a primo.inc f jl tartalma
> ; definitions for Pirmo A64
> &SCREEN .equ 65536-6144
> .defchr " " = 123
>
> stb...
>
> s k s bb a m sik forr sban:
>
> .include "primo.inc"
>
> ld hl,&SCREEN
>
> Ezzel a .env-et ki tudod v ltani, s a felhaszn l is tudja edit lni,
> m dos tani, adott g pt pushoz l trehozni.
> Azaz t bben is tudunk dolgozni rajta.
>
> Szerintetek?
>
> Joco
>
>
>
>
>
>
>
> > Ilyesmit kell leford tani, most ez a szabv ny az elfogadott:
>
> >http://xesj.hu/z80/minta_v20110820.html
>
> > dv, xesj
Gábor Lénárt
> Pl. a primo.inc fájl tartalma
>
> ; definitions for Pirmo A64
> &SCREEN .equ 65536-6144
> .defchr "é" = 123
>
> stb...
>
> és később a másik forrásban:
>
> .include "primo.inc"
>
> ld hl,&SCREEN
>
> Ezzel a .env-et ki tudod váltani, és a felhasználó is tudja
> editálni, módosítani, adott géptípushoz létrehozni.
> Azaz többen is tudunk dolgozni rajta.
Ezt nagyon jo otletnek tartom! Foleg, mivel adott esetben lehet mas user
defined charset stb is, ami esetleg nem egyezik az eredetivel. Tovabba az
.include ertelme lehet user szinten is, hogy igy tobb reszre szabdalt
forrast lehet egyben kezelni, nem feltetlen "csak" az .env jellegu dolgok
miatt.
Sot, esetleg valaki hasznalhatna az assembler-t nem primo-s fejlesztesekre
is, ha az adott gep cpu-ja Z80 legalabbis.
xesj.hu
elkészítjük több géptípusra.
A géptípusok száma véges, sőt talán 10 alatt van így hamar véget fog
érni az elkészítésük, és innentől teljesen felesleges hogy a program
felhasználói foglalkozzanak (még include szinten sem), azzal hogy
milyen betű milyen értéknek feleljen meg. Ha majd a 28. Z80 assembly
programot írja az illető ideges lesz, miért kell ezzel a karakter
kódolás dologgal foglalkoznia, ahelyett hogy egy egyszerű ENV sort
adna meg.
Példa:
.ENV PROMO_A32
LD A,"á"
másképp fordul le mint
.ENV HT_1080Z
LD A,"á"
De ez nem elég, és az sem hogy include van-e. Ugyanis el kell
készíteni a különböző fájl formátumokat, a primo-nál PTP-t, a HT1080-
nál CAS-t, stb.
Amúgy az include-nak nem itt lenne értelme hanem ott, hogyha megírod a
képernyő törlését 5 sorban, és minden program ezzel indul akkor ne
kelljen már mindig a program elejére betenni. De ezt a funkciót nem
akarom megvalósítani, arról persze lehetne beszélgetni hogy ha KÉSZ a
program akkor miben lehetne TOVÁBBFEJLESZTENI. Abba a hibába nem
szabad beleesni hogy álmodunk és vállalunk mindent, aztán a végén egy
nagy felfújt lufi lesz ami meg sosem készül el :))
Üdv, xesj
Gábor Lénárt
> Nem teljesen értem amit mondasz. A .ENV-nek is az a lényege hogy
> elkészítjük több géptípusra.
> A géptípusok száma véges, sőt talán 10 alatt van így hamar véget fog
> érni az elkészítésük, és innentől teljesen felesleges hogy a program
> felhasználói foglalkozzanak (még include szinten sem), azzal hogy
> milyen betű milyen értéknek feleljen meg. Ha majd a 28. Z80 assembly
Imho ez egy hatalmas tevedes. En tobb geptipuson is hasznalok olyat, hogy
sajat charset, ugy, hogy nem is ott vannak esetleg az adott karakterek a
kodtablaban ahol a "hivatalos" ROM stb szerint lennie kene. Ez pedig ilyen
szempontbol "user szint", hiszen miert akarnad megkotni, hogy valaki ilyen
programot is irjon? A .chrdef es hasonlok pont azert lennenek jok, mert nem
kell belenyulni az assembler-be, azaz "user szinten" supportalva van ez a
dolog. Plusz eleve, maga az .ENV is ugye definial egy character encoding
tablat, tehat ugy is felfoghatod, hogy az .env kivalaszt egy ilyet, nekem
csak az tetszene, ha ezt szabadon lehetne akar karakterenkent is modositani
(.chrdef), akkor meg termeszetesen adodik, hogy maga az .ENV-szeru uzemmod
ugy mux, hogy pl include-ol egy "system header" file-t, amiben van egy rakas
.chrdef. Igy tobb legyet is lehet utni egy csapasra, es mas hasznos dolgokra
is alkalmas.
Tovabba a geptipusok vegessegevel azert vigyazz: van pl memoriabovitett
primo-m, ami ugye kisse osszver lett: tobb ram-ja van, de a ROM "mashol
gondolja" a videoramot mint ahova "kerult" a bovites soran :)
xesj.hu
a .ptp .cas stb formátumok.
De a compiler nem fordít egyből .z80-ból .ptp -t. Talán a debug
céljából is, és esetleg ha valaki
más átfordítót szeretne írni, mindig elkészül majd egy .mac formátum
is (machine code).
Ez vegyesen tartalmazza a gépi kódot és a forrást is, jól olvasható
forma pl:
D0C0 21 00 00 LD HL,0 ;megjegyzés
D0C3 C9 RET
Így ha valaki egy kitalált virtuális gép emulátort írna akkor annak
nem kell sem ptp és egyéb
formátumokkal bajlódnia, hanem egyből olvashatna .mac-et.
Tegyük fel hogy most 25 embernek jut eszébe hogy írna ilyen virtuális
gép emulátort, és
mind a 25 más karakterkódolást akarna használni. Na ez esetben
mondhatna csődöt az .ENV,
mert ugye azt nem gondolja senki komolyan hogy napi 3 új géptípusnak
írom meg a .ENV-jét :)
xesj.hu
Ha tényleg ilyen kutyulmányok vannak, és ezernyi ilyen géptípus, stb.
ROM módosítások, tényleg kezdem belátni hogy a userek kezébe kéne adni
a dolgot. Amúgy is az egész string dolog kavarta be a forráskód
elemzését.
Így tuti jól fog működni az
LD A,65
Végülis én döntök.
userek definiálnak
xesj.hu
String legyilkolva, kiszedtem a mintából is, nem téma.
http://xesj.hu/z80/minta.html
(Persze aki ettől ideges lesz az nyugtassa magát azzal, hogy a project
első verziójában nem lesz benne, a későbbi verziók majd esetleg
tartalmazhatják...)
Térjünk át a numerikus adatokra.
Van ugye a z80-ban egy ilyen szép utasításunk:
LD (IX+d),n
A kérdésem hogy mi írható a "d" és az "n" helyére. Ezt most ne úgy
értsétek hogy fogalmam sincs, hanem mi az ami nem tűnik logikai
bukfencnek ?
Természetesen megjegyzem mindegyik simán lefordítható gépi kódra ha
akarjuk, az 5. kivételével:
&example1 LD (IX+255),255 ; "d" nem azt sugallja ami történik,
logikailag nem tetszik, "n" rendben van
&example2 LD (IX-1),255 ; "d" így már ok, és ugyanaz a gépi kódja
mint az előzőnek, ez logikailag is rendben
&example3 LD (IX-128),-1 ; teljesen rendben
&example4 LD (IX-128),255 ; teljesen rendben, és ugyanaz a gépi
kódja mint a 3. példának
&example5 LD (IX-1),-129 ; teljesen FALSE a -129 akár "d", akár
"n" helyén áll
&example6 LD (IX+127),$fffe-$ffff ; korrekt, csak a végeredmény
számít, nem a kifejezés közbenső 2 byte-osai
Tehát a lényeg hogy szerintem "d" esetén a kifejezés végeredménye csak
a -128...127 tartományban,
"n" esetén viszont a kifejezés végeredménye a -128...255 tartományban
elfogadható.
Várom a véleményeteket.
Üdv, xesj
Jozsef Laszlo
Erről jut eszembe, a java az a nyelv, ahol nincsenek unsigned integer számok? Asszem annak idején ez is egy argumentum volt ellene nálam. Ha tévedek, bocs.
Joco
Sent from my iPod
xesj.hu
pl. BigInteger meg hasonlók, ha 1000000 számjegyű számokkal szeretnél
számolni, meg ilyenek. Meg jópofa dolgok ha pl. el szeretnéd
ugyanerről az 1000000 számjegyű számról dönteni hogy prímszám-e. stb.
Node ez itt nem egy java fórum !
Ugye az is egyértelmű mindenki számára hogy
LD HL,65535+1
kódot fordítási hibával dobom majd vissza ?
Mert onnantól kezdve hogy leírjuk hogy 65535+1 az egy számítástechnika
független matematikai kifejezés, és egyenlő 65536-tal, az meg ugye nem
fér be 2 byte-ba :) Amúgy a java-ban is ha 32 bites (int típus)
előjeles aritmetikával számolok az is "átfordul" ám, tehát vigyázni
kell.
Integer.MAX_VALUE + 1 = Integer.MIN_VALUE, ami már nem "normál/elvárt"
matematikai eredmény. Ezeket még átgondolom hogy csináljam majd hogy
korrekt legyen.
Megmondom nektek őszintén én is használtam már jópár programozási
nyelvet, nagygépes IBM 360 assembly-ben kezdtem programozni 14 évesen
középiskolában, és olvasgattam a commodore assembly-jét stb, de 2
olyan nyelvet ismerek a számítástechnikában amire 5-ös osztályzatot
adok:
- Java
- Z80 assembly
Engem csak ez a 2 nyelv hatott meg és imádom őket, és esetleg a C is
közéjük tartozhat még, a többiről ne is beszéljünk :)
Üdv, xesj
On aug. 26, 20:37, Jozsef Laszlo <rbe...@gmail.com> wrote:
> Kb egyetértek. Az ix/iy+d z80 specialitás, csak a kettes komplemens tartományt engedném. Egyéb esetben az utasítás által megkövetelt birhosszon valid számokat fogsdnám el. Egyébként a numerikus kifejezéseket 32 bites integer aritmetikával számolnám és csak a legvégén tenném be a 8 vagy 16 bites eredménybe.
>
> Erről jut eszembe, a java az a nyelv, ahol nincsenek unsigned integer számok? Asszem annak idején ez is egy argumentum volt ellene nálam. Ha tévedek, bocs.
>
> Joco
>
> Sent from my iPod
>
Gábor Lénárt
> Ugye az is egyértelmű mindenki számára hogy
> LD HL,65535+1
> kódot fordítási hibával dobom majd vissza ?
>
> Mert onnantól kezdve hogy leírjuk hogy 65535+1 az egy számítástechnika
> független matematikai kifejezés, és egyenlő 65536-tal, az meg ugye nem
> fér be 2 byte-ba :) Amúgy a java-ban is ha 32 bites (int típus)
Nem lehetne bevezetni ilyesmit?
LD HL, .LOWORD(&VALAMI+2)
Tehat, ha a &VALAMI (bar nekem a @ jobban bejonne & helyett, de ez mar
tenyleg csak kotekedes - bocsanat) erteke mondjuk 65535, akkor ugye kettot
hozzaadva egy word-be mar nem ferne bele. Amde, ha szandekosan akarunk
olyat, hogy csak a kifejezes also word-je erdekes, akkor a .LOWORD-el csak
az also word-jet kapjuk meg a kifejezesnek. Persze esetleg erdekes lehetne a
.HIWORD, illetve byte szinten a .LOBYTE es a .HIBYTE is (persze mas nevet is
lehetne adni, ez csak pelda volt: 65xx assemblerekben byte szinten szokas
a > es < jeleket is hasznalni ez utobbi celra, bar imho ez kisse szokatlan
lenne egy z80 assembler eseten ...)
> előjeles aritmetikával számolok az is "átfordul" ám, tehát vigyázni
> kell.
> Integer.MAX_VALUE + 1 = Integer.MIN_VALUE, ami már nem "normál/elvárt"
> matematikai eredmény. Ezeket még átgondolom hogy csináljam majd hogy
> korrekt legyen.
>
> Megmondom nektek őszintén én is használtam már jópár programozási
> nyelvet, nagygépes IBM 360 assembly-ben kezdtem programozni 14 évesen
> középiskolában, és olvasgattam a commodore assembly-jét stb, de 2
> olyan nyelvet ismerek a számítástechnikában amire 5-ös osztályzatot
> adok:
> - Java
> - Z80 assembly
Hat, imho az assembly-t a java-val osszehasonlitani nehez lenne :) Raadasul
egy adott CPU eseten szokasos szintaxis is neha valtozott, hiszen a CPU
szenten ertelmezheto gepi kod csak a "valtozatlan", akar teljesen mas
syntaxis is kitalalhato lenne assembly szinten. Ezt csak azert irom, mert
nem derult ki, mi tetszik neked fentebb: maga a Z80 un ISA szintja, vagy a
hozza krealt assembly syntaxis, amit akar modositani is lehetne a hw
szinttol fuggetlenul?
ISA szinten nekem a 65xx jobban bejon: amugy "primitivebb", de igy
egyszerubb es hatekonyabb is (azonos orajelre vetitive), egyes jellemzoi
mar-mar a RISC-re emlekeztetnek (persze ezt sokan tevesen emlitik meg:
messze nem RISC az, max csak "RISC-ebb" mint a Z80). De persze lehet, hogy
te nem errol beszelsz, hanem az assembly szintu syntaxisrol.
xesj.hu
.LOWORD és társai: sajnos nem vezetek ilyet be, már olyat sem hogy
zárójelezni lehessen egy kifejezést.
Z80/65xx: az utóbbinál ezek a címzések nem tetszettek: indexelt
indirekt, indirekt indexelt, meg hasonlók, most a nevük sem ugrik már
be, bár a polcomon valahol megvan a commodore64 assembly című könyv.
Persze ha ezt tanultam volna előszőr, lehet hogy ez lett volna az
alap. Mindenesetre az assembly-ben az a a szép hogy az ember tényleg
tudja egy utasítás mit csinál, kevésbé vannak homályos pontok,
inkompatibilitások, ékezet problémák stb. amivel manapság
találkozhatunk. Írj olyan javascriptet ami minden böngészön (1.0-
ásokon is) jól megy, és persze valami jó bonyolult dolgot csinál. Ja
és menjen a mobiltelefonok böngészőjében, és jól is nézzen ki a mini
képernyőkön stb... Értitek ? Szóval jó néha ez a retro, és nyomulni
assembly-ben.
Amiről még nem beszéltem, a megkötések a z80ptp-ben:
- egy sor hossza (a megjegyzést levágva belőle) max 100 karakter
lehet, ebbe bele kell férnie mindennek
LD HL,60000 ; jó megoldás
LD HL,1+1+1+1+1+1+1...60000-szer ; rossz megoldás, fordításkor
hibaüzenet
- cimke hossza maximum 17 karakter lehet, ebből 1. char = &, 2. char
betű, továbbiak A...Z 0...9 _
- numerikus kifejezések a kiértékelés közben sem "szállhatnak az
egekbe", a tagok maximum 2 byte-osak lehetnek
LD A,65535*65535*65535*65535*65535*65535*65535*65535*65535*0 ;rossz
megoldás, fordításkor hibaüzenet
LD HL,65536-1 ; rossz megoldás 65536 nem 2 byte-os
- decimális konstans előjellel maximum 6 karakteres lehet, pl: hibás:
-000023456
- bináris konstans előjellel maximum 18 karakteres lehet, pl: hibás: -
%01111111100000000
- hexa konstans előjellel maximum 6 karakteres lehet, pl: hibás: -
$0000F
Most ezek jutottak eszembe...
Üdv, xesj
Gábor Lénárt
On Sat, Aug 27, 2011 at 11:24:58PM -0700, xesj.hu wrote:
> Jó reggelt !
>
> .LOWORD és társai: sajnos nem vezetek ilyet be, már olyat sem hogy
> zárójelezni lehessen egy kifejezést.
Ok, az csak pelda volt, persze lehetne zarojel nelkul is. Bar, nyilvan a
feladat megoldhato, ha az assembler ismer pl "es" muveletet, hiszen
akkor pl a loword az nem mas mint xxx & $FFFF vagy hasonlo, es akkor a
kifejezes erteke garantaltan elfer 16 biten is akar.
>
> Z80/65xx: az utóbbinál ezek a címzések nem tetszettek: indexelt
> indirekt, indirekt indexelt, meg hasonlók, most a nevük sem ugrik már
> be, bár a polcomon valahol megvan a commodore64 assembly című könyv.
Hat a nevuket en sem feltetlen tudom (marmint a "hivatalos" nevuket), de
vegulis hasznalni kell, nem a nevet tudni :) Azert azt fontos megejegyezni,
hogy anno a memoriak sebessege a CPU sebessegevel osszemerheto volt (mara a
CPU sokkal gyorsabb, ennek koszonheto, hogy L1, L2, L3 .... cache-eket
hasznalunk stb), tehat akkoriban nem volt nagy "veszteseg" (vagy legalabbis
nem akkora mint ma), ha memoriara hivatkozott a CPU. Ellenben a CPU
integraltsaganak foka, az draga volt. Ezert pl 6502 (es rokonai) eseten
bevezetesre kerult a "zero page addressing", ahol a memoria elso 256 byte-ja
egy byte-al megcimzezheto. Ez sebessegeben es "feelingben" kb a "valodi" (16
bittel cimezheto) memoriaeleres es a register hasznalata koze esett, ezert
neha - pici tulzassal - szokas ugy is nevezni, hogy ez 256db register-t
biztositott, bar a "register backing store" ebben az esetben memoria, es nem
"valodi" CPU-ban implementalt register. Ha igy nezzuk, es megertjuk ennek a
lenyeget, a kor technikai szintjen, maris jobban ertheto, miert lett olyan a
65xx amilyen, maga kategoriajaban igen jo konstrukcio volt (ha jol remlik
egy "machine cycle" 6502 eseten fele olyan hosszu mint Z80-on, persze, ha
azonos orajel mellett nezzuk). Nu, ehhez jonnek azok a cimzesmodok, amik
foleg a zero page-hez kotehetoek, akkor maris jobban ertheto. Amugy, hogy
kisse Z80 specifikus legyen a tema es ne off-topic: ha jol remlik, a gameboy
CPU-ja is hasonlo: alapvetoen Z80, de par dolgot "kiirtottak" belole az
"igazi" Z80-hoz kepest, tovabba viszont ott is mintha implementaltak volna
valami ilyesmit, csak eppen a memoria utolso 256 byte-ja es nem az elso,
amit a ZP addressing megcimez.
> Persze ha ezt tanultam volna előszőr, lehet hogy ez lett volna az
> alap. Mindenesetre az assembly-ben az a a szép hogy az ember tényleg
> tudja egy utasítás mit csinál, kevésbé vannak homályos pontok,
> inkompatibilitások, ékezet problémák stb. amivel manapság
> találkozhatunk. Írj olyan javascriptet ami minden böngészön (1.0-
:) Ebben nem is akarok vitatkozni, en is igy gondolom :) Csupan azert
kerdeztelek, mert erdekesnek talaltam, hogy a Z80 assembly es a java
szerepel egyutt, mint ket kedvenc. :)
> ásokon is) jól megy, és persze valami jó bonyolult dolgot csinál. Ja
> és menjen a mobiltelefonok böngészőjében, és jól is nézzen ki a mini
> képernyőkön stb... Értitek ? Szóval jó néha ez a retro, és nyomulni
> assembly-ben.
Na ebben 100%-ban egyet ertek!
Amugy tobbszor emlitettem a cc65 assembler-et (ca65 a neve). Nekem az _A_
65xx cross assembler, rengeteg fejlett tulajdonosaggal, kulon linkerrel stb.
Csak ugye Z80-at nem tud. Anno en leveleztem az irojaval, hogy esetleg en
megcsinalnam (elvegre 65xx-hoz kotheto: foleg commodore gepeket ha nezzuk:
C128-ban van Z80 is, C64-hez meg legalabbis CP/M cartridge formajaban -
nekem is van). Csakhat sajna a pofam mindig nagyobb, mint a rendelkezesre
allo idom/energiam/stb mennyisege, szoval ebbol sem lett semmi :( Kerulo
megoldaskent irtam anno egy frontend-et, ami a Z80 cuccokat asm source-bol
atfordit pl .BYTE direktivakba, amit mar "megemeszt" a ca65, de ez nem eppen
egy "szep" megoldas ...
>
> Amiről még nem beszéltem, a megkötések a z80ptp-ben:
> - egy sor hossza (a megjegyzést levágva belőle) max 100 karakter
> lehet, ebbe bele kell férnie mindennek
> LD HL,60000 ; jó megoldás
> LD HL,1+1+1+1+1+1+1...60000-szer ; rossz megoldás, fordításkor
> hibaüzenet
>
> - cimke hossza maximum 17 karakter lehet, ebből 1. char = &, 2. char
> betű, továbbiak A...Z 0...9 _
Ez mondjuk erdekes, cimkek eseten (most tekintsunk el a & jeltol az elejen)
azert szokas kikotni, hogy az elso nem lehet szam, hogy el lehessen
kuloniteni egy szamot egy cimketol v hasonlo. Amde, ha kotelezove teszi az
ember prefix-kent a &-t a cimke elejen, akkor ez vilagosan latszik, tehat
akkor mi ertelme a & mogotti karakterre megkotni, hogy az csak beto lehet?
Plusz itt kisbetuket nem emlitesz, akkor csak nagybetu lehet a cimkeben?
Ennek sem latom sok ertelmet, a prefixalt megoldas lenyege pont az, hogy
egyertelmu a prefix utan, hogy ez egy cimke: nincs szukseg hat tovabbi
megkotesre, hogy pl csak nagybetu, maga a cimke elso karaktere nem lehet
szam, stb.
> - numerikus kifejezések a kiértékelés közben sem "szállhatnak az
> egekbe", a tagok maximum 2 byte-osak lehetnek
> LD A,65535*65535*65535*65535*65535*65535*65535*65535*65535*0 ;rossz
> megoldás, fordításkor hibaüzenet
> LD HL,65536-1 ; rossz megoldás 65536 nem 2 byte-os
Ja ertem, akkor az elso bekezdesnel foglaltak (.LOWORD stb), amirol
beszeltem, nem sok ertelme van. Bar imho, egyszerubb is lenne, ha maga a
kiertekeles soran az assembler-ben a java nativ tipusanak ertekkeszlete
megengedett lenne, es csak a vegso eredmenynek kell beleferine aztan abba,
amit az utasitas meghataroz (fentebb pl nyilvan 16 bitbe).
>
> - decimális konstans előjellel maximum 6 karakteres lehet, pl: hibás:
> -000023456
> - bináris konstans előjellel maximum 18 karakteres lehet, pl: hibás: -
> %01111111100000000
> - hexa konstans előjellel maximum 6 karakteres lehet, pl: hibás: -
> $0000F
>
> Most ezek jutottak eszembe...
>
> Üdv, xesj
>
xesj.hu
A cimkében igazad van, az & után nincs sok értelme a következő
karakterrek kötöszködni.
Persze így furcsának tűnik az &0 vagy &1 cimke lehetősége is, de nem
problémás, valóban legyen úgy hogy nem kötöm meg a 2. karaktert.
Természetesen lehet a forrást (és így a cimkét is) kis és nagybetűvel
is írni, a fordító nem lesz case sensitive, tulajdonképpen a forrást
nagybetűsre konvertálja és úgy kezd hozzá az értelmezéséhez.
Üdv, xesj
Gábor Lénárt
> Sz�p hossz� levelet �rt�l !
Jah, sorry ha untatott vkit :) Csak ugye ez a 8 bit tema nekem is (ahogy
sokan masnak errefele - gondolom) a kedvencem, es mindig bele tudok
feledkezni "kisse" ...
xesj.hu
No ez már tényleg hülyeség, de leírom:
Azt is kitaláltam hogy kell retro_z80_assemblyzni:
Végy egy szövegszerkesztőt, állítsd be a háttérszínt feketére, a
betűszínt szürkére (a fehér túl kontrasztos lenne).
A betűtípus legyen Lucida Console 14-es, így szép nagy betűink
lesznek. Na így kell írni a forrást.
Ez persze nem lesz megkötés a forráskód sikeres fordításához, de
higgyétek el így az igazi, bármely modern szövegszerkesztővel
dolgozhattok, de érzésre viszont olyan mint egy régi 8-bites gépen
szerkesztenénk a szöveget.
Üdv, xesj
Gábor Lénárt
Azt hittem az jon mar, hogy szabaly lesz: a cimkeket csak adott betutipussal
lehet irni, az alapjan ismeri fel :)
xesj.hu
A project halad :)
Kifejezéseket már ki tudok szedni az operandusokból és ezeket ki is
tudom értékelni. A szép a dologban hogy próbálok az osztályaimhoz
teszt osztályokat gyártani (JUNIT teszt keretrendszer), így egy
kiértékelőt meg lehet bombázni N darab teszt esettel aminek tudjuk a
kimenetelét, és megnézzük a várt eredményt adja-e vissza. Végülis
program tesztel programot. A kiértékeléshez postfix lengyel formát
használom, tök jó. Íme a teszt kifejezéseim amik jók, és amik rosszak
(&screen szimbólum 26624-nel lett definiálva):
List jo = Arrays.asList(
"1+23-4560/456", 14,
"-19999+23", -19976,
"$8764+%110", 34666,
"-%10011", -19,
"0*$1001+0*%1111111100000000*65535-&screen", -26624,
"-5+6*2-3", 4,
"$1*2+68/%100010", 4,
"-%1-%10-%100-%1000-%10000-%100000-%1000000-%10000000", -255,
"-2*3+4*7*0/23+$F0+$F-10*6/2", 219,
"-&screen/2/2/2/2/2/2/2/2/2/2/2", -13,
"-1*%001+&screen/2-8*$9", 13239,
"32760+4*2", 32768,
"$FF02+$FD", 65535
);
List<String> rossz = Arrays.asList(
"*23", "345+", "-19999999999999+23", "+", "1++2", "-65536", "65536",
"000001", "$$", "$1FFFF", "$1X", "HAHO", "12+&ezmi", "-32760-9"
);
Üdv, xesj.hu
xesj.hu
A z80ptp projectet átneveztem Zombi projectre, és el is készült a 0.1-
es verzió. Ez még nem tud Primo .ptp formátumot készíteni, de tud .mac
formátumot, amiben benne van a forráskód a lefordított gépi kóddal
együtt. Akinek kedve van megnézheti. Ma elkezdtem már a leírást is
megcsinálni a projecthez, itt megtaláltok mindent:
http://xesj.hu/zombi
Üdv, xesj.hu
xesj.hu
Ma megtörtént az áttörés :)
A Zombi 0.3 -as verzió már .ptp fájlt is elő tud állítani.
Kipróbáltam egy régi 1985-ben általam írt 160 utasítást tartalmazó Z80-
as programmal a Zombit, és az elkészült ptp-t szépen futtatta az
Ultimo emulátor.
Nagyon örültem hogy a 26 éves programom ismét működőképes,
újjáélesztettem.
És köszönet az emulátor íróknak is hogy ez lehetséges lett !
Itt minden infót megtaláltok:
http://xesj.hu/zombi
Jó próbálgatást, tesztelést, ha programhibát találtok mindenképp
szóljatok.
Üdv, xesj.hu
Majzik Istvan
Szia!
A projektről a Primo honlapra is tehetek egy ismertető oldalt?
Pl. készítenék a bal menüben egy Programok / Fejlesztés csoportot, és itt jelenne meg a Zombi
oldala, ahol belinkelhető lenne a projekt lapja.
Ha ez OK, akkor a legjobb lenne, ha írnál egy bemutató szöveget, amiben a Primo támogatása is kiemelhető.
Üdv.
Istvan
"xesj.hu" <xes...@gmail.com> írta:
xesj.hu
> A projektről a Primo honlapra is tehetek egy ismertető oldalt?
> Pl. készítenék a bal menüben egy Programok / Fejlesztés csoportot, és itt jelenne meg a Zombi
> oldala, ahol belinkelhető lenne a projekt lapja.
> Ha ez OK, akkor a legjobb lenne, ha írnál egy bemutató szöveget, amiben a Primo támogatása is kiemelhető.
Én erre a bemutató szövegre gondoltam:
-------------------------------------------------------------------
A Zombi project
A Zombi szoftver kifejlesztésének ötlete 2011 augusztusára tehető.
Mivel a Primo .ptp formátum adott volt, jó lett volna egy olyan
szoftver is, ami támogatja egy PC-s szövegszerkesztővel írt Z80
assembly forráskód átalakítását erre a formára. Egyrészt azért mert
lehet nálunk olyan régi program, mely nem magnószalagon maradt meg
(nálam pl. papíron), másrészt hogy az ezután írt programok kényelmesen
elkészíthetők legyenek egy PC-s szövegszerkesztővel, és gyorsan
futtathatók az emulátorokkal. Továbbá egymás között elég legyen az
olvasható Z80 forrást megosztani, a futtatására könnyen képesek
legyünk.
A project kezdetben a "z80ptp" nevet viselte, mivel eredetileg csak az
volt a cél hogy a Primo .ptp formáját támogassa. Nekem is Primo
számítógépem volt, erre fejlesztettem kisebb programokat az 1980-as
években, és jelenleg is ezeket az emulátorokat használom. Azonban ha
távolabbra tekintünk, és másokkal beszélgetünk, hamar rájövünk hogy
érdemes a hatókört kiterjeszteni más Z80 processzor alapú gépek
irányába. Így tehát a cél az lett hogy olyan formátumokat is
támogasson, melyek leírása hozzáférhető.
A project fő eleme a Z80 fordító, mely gépi kódra alakítja a forrást.
A szintaxis a Microkey Primo levelezőlistán résztvevő tagokkal közösen
lett kialakítva, de pár egyéb fejlettebb képesség nem került bele
például: makrók használata, include, stringek kezelése. Ezek
megvalósítása a fejlesztési időt jóval meghosszabbította volna, és
eredetileg én sem terveztem egy mindent tudó komplex fordítót.
A Zombiról további információkat a honlapján találhattok:
http://xesj.hu/zombi
Keresztes József (xesj.hu)
-------------------------------------------------------------
Majzik Istvan
Szia!
Köszönöm, fel is tettem a projektről az ismertetőt (ld. a bal oldali menüben: Programok / Fejlesztés / Zombi).
Üdv.
Istvan
"xesj.hu" <xes...@gmail.com> írta:
xesj.hu
> Szia!
> Köszönöm, fel is tettem a projektről az ismertetőt (ld. a bal oldali menüben: Programok / Fejlesztés / Zombi).
>
> Üdv.
> Istvan
Üdv, xesj.hu
xesj.hu
Nem akarom terhelni a listát a Zombi újabb verzióival,
tulajdonságaival hiszen a honlapján mindent megtaláltok,
pl. elkészült a HT1080Z .cas formátumának támogatása is.
Tehát a jövőben akit érdekel az úgyis figyeli a honlapját.
Inkább azt kérdezném tőletek, van aki kipróbálta már rajtam kívül ?
Mik a tapasztalatok ?
Üdv, xesj.hu
Viktor Varga
ü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/10/19 xesj.hu <xes...@gmail.com>:
Majzik Istvan
Szia!
A Primo példaprogramokkal próbálgattam, jól működik, kényelmesen lehet fordítani.
(Először a képújságot próbáltam, de nem néztem bele a forráskódba, így a 2 poke-ot az elején nem
csináltam meg, így persze nem is volt jó. De utána a forrás elejét elolvasva megtettem és rendbe jött.)
Papíron vannak HT gépi kódú programjaim, de azokat még nem írtam be.
Ehhez kapcsolódó kérdésem: A HT web lapra (ht.homeserver.hu) is lehetne egy olyan összefoglalót
kirakni a Zombi projektről, mint a Primo oldalra? Itt már van is egy Fejlesztés oldal, erre raknám rá.
Üdv.
Istvan
"xesj.hu" <xes...@gmail.com> írta:
Grósz Attila
�n m�g sajna nem estem neki, de a j� lenne, ha tudna Videoton TVC-t
is... :) (CAS, TTP)
A HomeLab-et nem is eml�tve, mert akkor m�r teljes lenne a spektrum.
Szerintem nem lehet t�l neh�z ezeket is hozz�adni, mert dokument�ltak a
form�tumok.
�dv,
Attila
On 19/10/2011 21:25, xesj.hu wrote:
> Sziasztok !
>
> Nem akarom terhelni a list�t a Zombi �jabb verzi�ival,
> tulajdons�gaival hiszen a honlapj�n mindent megtal�ltok,
> pl. elk�sz�lt a HT1080Z .cas form�tum�nak t�mogat�sa is.
> Teh�t a j�v�ben akit �rdekel az �gyis figyeli a honlapj�t.
> Ink�bb azt k�rdezn�m t�letek, van aki kipr�b�lta m�r rajtam k�v�l ?
> Mik a tapasztalatok ?
>
> �dv, xesj.hu
>
xesj.hu
Ok, felírtam a tervek közé a Videoton TVC és homelab formátumát.
Már nézegettem a ZX spectrumot is, de az nekem zavarosnak tűnik.
Rengeteg emulátor és millió fájlformátum...
Üdv, xesj.hu
On okt. 23, 21:39, Grósz Attila <gy...@freemail.hu> wrote:
> Szia!
>
> n m g sajna nem estem neki, de a j lenne, ha tudna Videoton TVC-t
> is... :) (CAS, TTP)
> A HomeLab-et nem is eml tve, mert akkor m r teljes lenne a spektrum.
>
> Szerintem nem lehet t l neh z ezeket is hozz adni, mert dokument ltak a
> form tumok.
> > Nem akarom terhelni a list t a Zombi jabb verzi ival,
> > tulajdons gaival hiszen a honlapj n mindent megtal ltok,
> > pl. elk sz lt a HT1080Z .cas form tum nak t mogat sa is.
> > Teh t a j v ben akit rdekel az gyis figyeli a honlapj t.
> > Ink bb azt k rdezn m t letek, van aki kipr b lta m r rajtam k v l ?
> > Mik a tapasztalatok ?
>
> > dv, xesj.hu
xesj.hu
Természetesen a HT1080Z oldalára is mehetne egy ugyanolyan
összefoglaló és link mint a Primo honlapon.
Szerinted írjam át a szövegét ? Nekem jó úgy is ahogy a primo oldalán
van.
Persze a jövőben majd lehet a TVC oldalára is stb.
Üdv, xesj.hu
On okt. 23, 10:34, Majzik Istvan <d...@freemail.hu> wrote:
> Szia!
>
> A Primo példaprogramokkal próbálgattam, jól működik, kényelmesen lehet fordítani.
> (Először a képújságot próbáltam, de nem néztem bele a forráskódba, így a 2 poke-ot az elején nem
> csináltam meg, így persze nem is volt jó. De utána a forrás elejét elolvasva megtettem és rendbe jött.)
>
> Papíron vannak HT gépi kódú programjaim, de azokat még nem írtam be.
> Ehhez kapcsolódó kérdésem: A HT web lapra (ht.homeserver.hu) is lehetne egy olyan összefoglalót
> kirakni a Zombi projektről, mint a Primo oldalra? Itt már van is egy Fejlesztés oldal, erre raknám rá.
>
> Üdv.
> Istvan
>
Jozsef Laszlo
Két formátumot javaslok, az egyik az .sna ha teljesen automatikus dolgot akarsz csinálni, az betöltés után indulhat is, illetve a .tap formátumot, ami meg a spectrum normál magnó blokkjainak leképezése. Ezeket szerintem minden emulátornak ismernie kell, és viszonylag egyszerûek.
Joco
J- Sent from my iPod
xesj.hu
A TVC-nek nézem a .cas formátumát.
A leírást itt megtaláltam:
http://tvc.homeserver.hu/html/konvertformatum.html
A problémám hogy nem igazán értem, de gondolom tudsz segíteni, látom a
TVC-hez is írtál emulátort.
Addig ok hogy 90-n tartományban jönnek a program adatbájtjai,
tetszőleges hosszúságban akor 40 kbyte is lehet itt egyben ugye ?
Node mi a betöltési címe ? És mi az indítási cím ? Vagy ezek valami
fix értékek ?
A primo, és ht1080z elég egyértelmű volt számomra ez nem.
Tudtok ebben segíteni, vagy van ahol részletesebben le van ez írva ?
Próbáltam az invazio.cas-t is értelmezni, de nem teljesen ok a dolog.
> n m g sajna nem estem neki, de a j lenne, ha tudna Videoton TVC-t
> is... :) (CAS, TTP)
> A HomeLab-et nem is eml tve, mert akkor m r teljes lenne a spektrum.
> Szerintem nem lehet t l neh z ezeket is hozz adni, mert dokument ltak a
> form tumok.
>
> > tulajdons gaival hiszen a honlapj n mindent megtal ltok,
> > pl. elk sz lt a HT1080Z .cas form tum nak t mogat sa is.
> > Teh t a j v ben akit rdekel az gyis figyeli a honlapj t.
> > Mik a tapasztalatok ?
>
> > dv, xesj.hu
Grósz Attila
Ink�bb priv�tban :)
M�r nem eml�xem :( De bem�solom a C forr�st ide, ami irt� nagy g�ny, de
tal�n r�j�ssz bel�le ;)
�ltal�ban m�k�dik az emuban, csak az a baj, hogy ez egy lemezes form�tum
alapvet�en, teh�t
norm�l esetben ezek diszkr�l t�lt�dnek be low level m�don (teh�t a
pontos met�dust a diszk OS
ROM rutinjaiban lehetne megkeresni). Az igazi kazett�s form�tum a TTP
lenne, ami szint�n dokument�lt
ha j�l r�mlik, igaz csak az �n emul�torom t�mogatja perpillanat (�gy
�rtem SW sincs nagyon ilyenben).
�dv,
Attila
unsigned char *memory_get_basic_start()
{
unsigned int basic_base = (ram[0x1721] << 8)|ram[0x1720];
return ram + basic_base;
}
#pragma pack(1)
struct cas_header_t {
unsigned char byte11h;
unsigned short block_nr;
unsigned short last_block_bytes;
unsigned char zeros1[123];
unsigned char byte80h;
unsigned char type81h;
unsigned short prgsize;
unsigned char autostart;
unsigned char zeros2[11];
};
#pragma pack()
static struct cas_header_t cas_hdr;
int cas_load_from_file(char *fname, unsigned char *basic_ram, int autorun)
{
FILE *cas;
unsigned char in, type;
unsigned short blocknumber;
unsigned short lastblockbytes;
unsigned short prgsize;
unsigned int i = 0;
unsigned char *endptr = memory_get_basic_end();
unsigned char *ram = get_ram_ptr();
unsigned int basic_ram_offset = (endptr - ram) & 0xFFFF;
cas = fopen( fname, "rb" );
if ( !cas )
return 0;
in = fgetc( cas );
if ( in != 0x11 ) {
fprintf(stderr,"Warning! Invalid CAS file header: %s!", fname);
}
fread( &blocknumber, sizeof(blocknumber), 1, cas);
fread( &lastblockbytes, sizeof(lastblockbytes), 1, cas);
fseek( cas, 0x81, SEEK_SET);
type = fgetc( cas );
fread( &prgsize, sizeof(prgsize), 1, cas);
fseek( cas, 0x90, SEEK_SET);
while ( !feof(cas) && i<0x10000 ) {
basic_ram[ i++ ] = fgetc( cas );
}
fclose( cas );
i =+ basic_ram_offset;
ram[0x1726] = i & 0xFF;
ram[0x1727] = i >> 8;
if (autorun)
machine_type_text("RUN\r");
return 1;
}
On 25/10/2011 12:41, xesj.hu wrote:
> Szia Attila !
>
> A TVC-nek n�zem a .cas form�tum�t.
> A le�r�st itt megtal�ltam:
> http://tvc.homeserver.hu/html/konvertformatum.html
> A probl�m�m hogy nem igaz�n �rtem, de gondolom tudsz seg�teni, l�tom a
> TVC-hez is �rt�l emul�tort.
>
> Addig ok hogy 90-n tartom�nyban j�nnek a program adatb�jtjai,
> tetsz�leges hossz�s�gban akor 40 kbyte is lehet itt egyben ugye ?
> Node mi a bet�lt�si c�me ? �s mi az ind�t�si c�m ? Vagy ezek valami
> fix �rt�kek ?
> A primo, �s ht1080z el�g egy�rtelm� volt sz�momra ez nem.
>
> Tudtok ebben seg�teni, vagy van ahol r�szletesebben le van ez �rva ?
> Pr�b�ltam az invazio.cas-t is �rtelmezni, de nem teljesen ok a dolog.
>
> �dv, xesj.hu
Grósz Attila
�dv mindenkinek ;)
Attila
Viktor Varga
a weboldalon egyébként a cas, a ttp-ről még hátra van a dolog.
ü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/10/25 Grósz Attila <gy...@freemail.hu>:
> Hát ez nem jött össze :D Rossz címre ment.
>
> üdv mindenkinek ;)
> Attila
>
> On 25/10/2011 21:40, Grósz Attila wrote:
>>
>> Hali!
>>
>> Inkább privátban :)
>>
>> Már nem emléxem :( De bemásolom a C forrást ide, ami irtó nagy gány, de
>> talán rájössz belőle ;)
>> Általában működik az emuban, csak az a baj, hogy ez egy lemezes formátum
>> alapvetően, tehát
>> normál esetben ezek diszkről töltődnek be low level módon (tehát a pontos
>> metódust a diszk OS
>> ROM rutinjaiban lehetne megkeresni). Az igazi kazettás formátum a TTP
>> lenne, ami szintán dokumentált
>> ha jól rémlik, igaz csak az én emulátorom támogatja perpillanat (úgy értem
>> SW sincs nagyon ilyenben).
>>
>> üdv,
>>> A TVC-nek nézem a .cas formátumát.
>>> A leírást itt megtaláltam:
>>> http://tvc.homeserver.hu/html/konvertformatum.html
>>> A problémám hogy nem igazán értem, de gondolom tudsz segíteni, látom a
>>> TVC-hez is írtál emulátort.
>>>
>>> Addig ok hogy 90-n tartományban jönnek a program adatbájtjai,
>>> tetszőleges hosszúságban akor 40 kbyte is lehet itt egyben ugye ?
>>> Node mi a betöltési címe ? És mi az indítási cím ? Vagy ezek valami
>>> fix értékek ?
>>> A primo, és ht1080z elég egyértelmű volt számomra ez nem.
>>>
>>> Tudtok ebben segíteni, vagy van ahol részletesebben le van ez írva ?
>>> Próbáltam az invazio.cas-t is értelmezni, de nem teljesen ok a dolog.
>>>
>>> Üdv, xesj.hu
>>>
>>> On okt. 23, 21:39, Grósz Attila<gy...@freemail.hu> wrote:
>>>>
>>>> Szia!
>>>>
>>>> n m g sajna nem estem neki, de a j lenne, ha tudna Videoton TVC-t
>>>> is... :) (CAS, TTP)
>>>> A HomeLab-et nem is eml tve, mert akkor m r teljes lenne a spektrum.
>>>>
>>>> Szerintem nem lehet t l neh z ezeket is hozz adni, mert dokument ltak a
>>>> form tumok.
>>>>
>>>> dv,
>>>> Attila
>>>>
>>>> On 19/10/2011 21:25, xesj.hu wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Sziasztok !
>>>>> Nem akarom terhelni a list t a Zombi jabb verzi ival,
>>>>> tulajdons gaival hiszen a honlapj n mindent megtal ltok,
>>>>> pl. elk sz lt a HT1080Z .cas form tum nak t mogat sa is.
>>>>> Teh t a j v ben akit rdekel az gyis figyeli a honlapj t.
>>>>> Ink bb azt k rdezn m t letek, van aki kipr b lta m r rajtam k v l ?
>>>>> Mik a tapasztalatok ?
>>>>> dv, xesj.hu
>>
>
Grósz Attila
> t�r�ljem az arch�vb�l, vagy maradhat?
>
> a weboldalon egy�bk�nt a cas, a ttp-r�l m�g h�tra van a dolog.
>
> �dv�zlettel/best regards: Varga Viktor
> ----
>
Dehogy, hagyd, nem kell t�r�lni. A TTP az semmi extra csak a TVC
magn�form�tuma a szinkronjelek
n�lk�l, ak�rcsak a PTP a Primo-n�l, illetve a HTP a HomeLab-n�l, innen a
n�vhasonls��g is, �s
a keresztapa meg Joc� volt (m�rmint a PTP-nek) :)
�dv,
Attila
Majzik Istvan
Köszönöm, ki is raktam az összefoglalót a HT web lapra a Fejlesztés oldalra.
Annyit tettem azért hozzá, hogy a HT 1080Z CAS formátumát is támogatja.
Üdv.
Istvan
"xesj.hu" <xes...@gmail.com> írta:
xesj.hu
Megnéztem, tökéletes.
Köszönöm hogy oda is kiraktad.
Üdv, xesj.hu
On okt. 28, 21:22, Majzik Istvan <d...@freemail.hu> wrote:
> Köszönöm, ki is raktam az összefoglalót a HT web lapra a Fejlesztés oldalra.
> Annyit tettem azért hozzá, hogy a HT 1080Z CAS formátumát is támogatja.
>
> Üdv.
> Istvan
>