Welcome, Guest. Please login or register.


Author Topic: EXOS 2.3 tovább fejlesztése (Read 32748 times)

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13523
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
    • http://enterprise.iko.hu/
Re: EXOS 2.3 tovább fejlesztése
« Reply #15 on: 2010.May.08. 17:02:49 »
Quote
Érdemes kipróbálni ezt a rövid programot, amely egy idõ után lefagy:
Nem is kell túl sok idõ hozzá...

Ha berakunk egy poke 56,201-et az elejére, akkor nem fagy le.

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13523
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
    • http://enterprise.iko.hu/
Re: EXOS 2.3 tovább fejlesztése
« Reply #16 on: 2010.May.08. 20:28:32 »
Na csináltam egy EI vadász scriptet :-)
Code: [Select]
  clearBreakPoints()
for i = 0, 0xFFFF do
  setBreakPoint(4, i, 2)
end

function breakPointCallback(t, a, v)
  if t == 3 then
return true
  end
  if  readMemory(getPC()) ~= 0xFB then
      return false
  end
  return true
end

Így kiderült, hogy az 1-es szegmensben az E9DD címen van egy EI, ez a TAPE periféria kezelõben van. Ha ezt aljas módon likvidáljuk, akkor úgy tûnik az alapgépes konfig nem fagy le. Viszont ha elkezdünk további ROM-okat adni a rendszerhez, akkor újabb EI seregek jelennel meg (némelyik az EXOS használatával, mint pl a DISK periféria felvétele).
Tehát a megoldás valószínüleg egy jól elhelyezett DI lesz a reset rutinban...

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13523
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
    • http://enterprise.iko.hu/
Re: EXOS 2.3 tovább fejlesztése
« Reply #17 on: 2010.May.08. 22:48:34 »
Úgy tûnik meg is van  :ds_icon_cheesygrin:
Eredetiben így néz ki:
Code: ZiLOG Z80 Assembler
  1.                 DI
  2.                 LD   HL,0000
  3.                 LD   (BFF8),HL
  4.                 LD   (003D),HL
  5.                 LD   (BFED),HL
  6.                 XOR  A
  7.                 LD   (0056),A
  8.                 LD   A,C
  9.                 ADD  A,A
  10.                 JP   C,C000
  11.                 ADD  A,A
  12.                 PUSH AF
  13.                 CALL C,C7D8
  14.                 POP  AF
  15.                 CALL NZ,C23A
  16.                 LD   A,0FBH
  17.                 LD   (0056),A
  18.                 XOR   A
  19.                 LD   (BF79),A
  20.                 LD   H,C9
  21.                 POP   BC
  22.                 JP   C46C
  23.  
A C23A rutin az amire 10-es vagy 20-as jelzõ esetén ráfut innen tér vissza gyakran engedélyezett megszakítással.
A C46C-n lévõ visszatérési rutinban pedig intenzíven el kezdi piszkálni a veremmutatót, így érthetõ miért száll el, ha befut egy megszakítás...
Szerencsére elfelejtettek spórolni, így akad egy felesleges bájt, ami helyére befér a DI, így néz ki módosítva:
Code: ZiLOG Z80 Assembler
  1.                 DI
  2.                 XOR   A
  3.                 LD   H,A
  4.                 LD   L,A
  5.                 LD   (BFF8),HL
  6.                 LD   (003D),HL
  7.                 LD   (BFED),HL
  8.                 LD   (0056),A
  9.                 LD   A,C
  10.                 ADD  A,A
  11.                 JP   C,C000
  12.                 ADD  A,A
  13.                 PUSH AF
  14.                 CALL C,C7D8
  15.                 POP  AF
  16.                 CALL NZ,C23A
  17.                 DI
  18.                 LD   A,0FBH
  19.                 LD   (0056),A
  20.                 XOR   A
  21.                 LD   (BF79),A
  22.                 LD   H,C9
  23.                 POP   BC
  24.                 JP   C46C
  25.  

Quote
EXOS 2.32 Smiley
Legyen :-)
De azért meg csináltam a javítást a 2.0 és 2.1-en is :-)

De nem teljesen csak az EXOS volt a hibás, úgy tûnik az ASMON 1.5 ROM tud még EXOS 0 fagyást okozni... remélhetõleg az már annak a ROM-nak az egyéni hibája, nem újabb EXOS bug...
Rakás más ROM-mal együtt nem volt fagyás.

Teszteljétek!

A csomagban benne van az idõközben kifejlesztett cartridge-os verziója is a gyorstesztnek, azok számára akik nem akarják megbontani a gépet. Így a hibajavításokon kívül a többi funkció mûködik így is.


« Last Edit: 2010.May.08. 22:57:51 by Zozosoft »

Offline Lacika

  • EP addict
  • *
  • Posts: 2930
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
    • http://www.ep128.hu
Re: EXOS 2.3 tovább fejlesztése
« Reply #18 on: 2010.May.08. 23:13:27 »
Ezzel a rejtélyes hibával szerintem időnki mindenkivel találkozott... Szerencsére nagyon nem volt zavaró, nem tulajdonítottunk neki jelentőséget.
Mindenesetre jó, hogy újabb hiba lett javítva! :ds_icon_cheesygrin:
És még egy tipp: ha jól tudom, a BASIC-ba egyetlen byte-ot kell átírni, hogy a GOTO működjön parancssorban?

Még az órajel detektáló - órabeállító rutint kellene belerakni.
Apropó! A jelenlegi EXOS-okban mi a 191-es port alapértelmezése? Ha esetleg bekapcsolt memóriavárakozás, akkor azt érdemes lenne kikapcsolni, a mai emulátoros világban.
« Last Edit: 2010.May.08. 23:43:17 by Lacika »

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13523
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
    • http://enterprise.iko.hu/
Re: EXOS 2.3 tovább fejlesztése
« Reply #19 on: 2010.May.08. 23:57:13 »
A jelenlegi EXOS-okban mi a 191-es port alapértelmezése? Ha esetleg bekapcsolt memóriavárakozás, akkor azt érdemes lenne kikapcsolni, a mai emulátoros világban.
Ugyanaz mint gyárilag. Ha letiltjuk akkor lehet, hogy pár játék gyorsabb lesz a megszokottnál.

Offline Ferro73

  • EP lover
  • *
  • Posts: 765
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 2.0.0.9 Firefox 2.0.0.9
    • View Profile
Re: EXOS 2.3 tovább fejlesztése
« Reply #20 on: 2010.May.09. 07:54:26 »
Ugyanaz mint gyárilag. Ha letiltjuk akkor lehet, hogy pár játék gyorsabb lesz a megszokottnál.
Azt nem kellene megváltoztatni mert ha valaki ROM ba tölti és igzi gépben probálná nem 100%, hogy müködne.
Esetleg rom megjegyzésnek "csak emu" vagy " EXOSv2x.ROM /E "

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux 64 bit (Suse) Linux 64 bit (Suse)
  • Browser:
  • Firefox 3.5.4 Firefox 3.5.4
    • View Profile
Re: EXOS 2.3 tovább fejlesztése
« Reply #21 on: 2010.May.09. 20:57:42 »
De nem teljesen csak az EXOS volt a hibás, úgy tûnik az ASMON 1.5 ROM tud még EXOS 0 fagyást okozni... remélhetõleg az már annak a ROM-nak az egyéni hibája, nem újabb EXOS bug...
Rakás más ROM-mal együtt nem volt fagyás.

:smt041

Az ASMON ROM-ot akkor (feltéve, hogy nem sikerül azt is kijavítani :)) érdemes lenne eltávolítani az emulátor konfigurációkból, kivéve természetesen azokat, amelyeknek "TASMON" van a nevében ? Vagy csak az ASMON indításakor okozhat fagyást, és nem bármilyen programból végzett EXOS 0 hívásnál ?

Ugyanaz mint gyárilag. Ha letiltjuk akkor lehet, hogy pár játék gyorsabb lesz a megszokottnál.

Az emulátor EXOS 2.3-as konfigurációiban le van tiltva a várakozás. Először azt hittem, az új EXOS verziók tiltják le, de kiderült, hogy csak az EXOS 2.3x ROM-okat betöltve nem így van. Úgy látszik, valójában a TPT.ROM miatt lesz 0Ch a várakozási mód - lehet, hogy ennek sem kellene alapértelmezés szerint a konfigurációkban lenni (már csak azért sem, mert a turbós és tömörített magnós mentést teszi alapértelmezetté, ami nem kompatibilis az EXOS eredeti TAPE: betöltőjével) ?

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13523
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
    • http://enterprise.iko.hu/
Re: EXOS 2.3 tovább fejlesztése
« Reply #22 on: 2010.May.11. 23:15:22 »
Az ASMON ROM-ot akkor (feltéve, hogy nem sikerül azt is kijavítani :))
Kijavítva :-)

A hibát Puskás Zsolt (õt ismeri valaki?) követte el, amikor a Gyányi Sanyi gyorstesztjét beépítette az eredeti ASMON ROM üres területére. Ebben a nehézség az, hogy az EXOS-nál kétféle ROM kezdet lehet, ami nem kompatibilis egymással:
- TEST_ROM az elsõ 8 bájton, rögtön a szöveg után indul a program
- EXOS_ROM az elsõ 8 bájton, utána 16 bites cím a perifériának, majd csak ez után indul a program.
Nem gondolták az Intelligent Software-nál, hogy kellhet majd mindkét funkció is egyazon ROM-ban :-(
(De ha megnézitek a cartridge-os gyorsteszt verziómat, látható, hogy némi trükkel megoldható :) )
Ráadásul az ASMON INC/DEC-cel vált szegmensszámot, nem XOR-al, így nem cserélhetõek fel a szegmensei. Viszont hely a második szegmensben volt...
Így azt a megoldást választotta, hogy a ROM elejei lettek megcserélve, majd az ott belépõ program átlapozza magát a másik szegmensre, a TEST ROM programmal nincs is gond, mert az DI alatt fut...
Az EXOS ROM belépési program így néz ki az átvariálás után:
Code: ZiLOG Z80 Assembler
  1.   C00A  DB B2        IN    A, (B2)
  2.   C00C  08           EX    AF, AF'
  3.   C00D  DB B3        IN    A, (B3)
  4.   C00F  D3 B2        OUT   (B2), A
  5.   C011  C3 14 80     JP    8014
  6.   8014  3D           DEC   A
  7.   8015  D3 B3        OUT   (B3), A
  8.   8017  C3 F0 FF     JP    FFF0
  9.  
  10.   FFF0  08           EX    AF, AF'
  11.   FFF1  D3 B2        OUT   (B2), A
  12.   FFF3  79           LD    A, C
  13.   FFF4  C3 0B C0     JP    C00B
  14.   C00B  C3 CD DB     JP    DBCD

Itt már látható is a hiba: ideiglenesen kilapozza a rendszerszegmenst a második lapról, pedig ilyenkor oda mutat a veremmutató, így ha ezen pár pillanatban fut be a megszakítás, kész a fagyás!

Quote
Vagy csak az ASMON indításakor okozhat fagyást, és nem bármilyen programból végzett EXOS 0 hívásnál ?
Bármikor okozhat fagyást, amikor körbe vannak hívva az EXOS ROM-ok. Így belegondolva emlékszem pár HELP lista fagyásra is...

A hibát okozó lapozás amúgy teljesen felesleges, nem kell elugrani azért a 3-as lapról, hogy kicseréljük az ott futó program alatt a szegmenst.
Ime a javítás:
Code: ZiLOG Z80 Assembler
  1.   C00A  C3 EB FF     JP    FFEB
  2.  
  3.   FFEB  DB B3        IN    A, (B3)
  4.   FFED  3D           DEC   A
  5.   FFEE  D3 B3        OUT   (B3), A
  6.   FFF0  79           LD    A, C
  7.   FFF1  C3 CD DB     JP    DBCD
Kicsit egyszerûsítettem is a kódon: JP-re való ugrás helyett akár ugorhatunk egybõl a célba is :-) mindezzel spóroltunk pár mikroszekundum végrehajtási idõt  :ds_icon_cheesygrin:

Quote
Úgy látszik, valójában a TPT.ROM miatt lesz 0Ch a várakozási mód - lehet, hogy ennek sem kellene alapértelmezés szerint a konfigurációkban lenni (már csak azért sem, mert a turbós és tömörített magnós mentést teszi alapértelmezetté, ami nem kompatibilis az EXOS eredeti TAPE: betöltõjével) ?
TPT forráskódunk van, így nincs akadálya más alapértelmezésû változat fordításának.

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13523
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6 Firefox 3.6
    • View Profile
    • http://enterprise.iko.hu/
Re: EXOS 2.3 tovább fejlesztése
« Reply #23 on: 2010.May.24. 13:48:36 »
A játékokban nem mûködne, mert indításkor fix 0Ch értéket írnak a portra,
Azért nem mindegyik. Amúgy meg a nagy EXOS kompatibilis betöltõ készítõ mozgalomban ezt is el lehetne intézni :-)

Quote
Ezen kívül a BFh port (mint a NICK összes és a DAVE I/O portjainak a többsége :() csak írható, tehát arra sincs lehetõség, hogy egy program csak a memória várakozást tiltsa le a hanggenerátor frekvencia változatlanul hagyása mellett. Ehhez még külön EXOS változót is kellene létrehozni.
Erre gondoltam én is, pl lehetne likvidálni a trükkös védelmet, akkor kapuk egy szabad bájtot, ahova elférne az új változó.

Ami kérdéses, hogy hogyan lehetne megoldani legjobban az órajelváltozás figyelését?
Az alapverzió az lenne, hogy pl a WP 2.6 inicializálási rutinjába beletenni egy mérést, így akkor reset rutin lefutása után helyes lenne a hangfrekvencia.
De még jobb lenne állandó megfigyelés, valami olyanra gondoltam, hogy egy periféria (pl a RAMDISK megõrzéshez létrehozott RDISK) ráül a videó és az 1 Hz-es megszakításra, és számolgatja õket, és ha egy 1Hz-es megszakítás alatt túl sok vagy túl kevés videó megszakítás volt, akkor változott az órajel, és ehhez korrigálni kell a hangfrekvenciát.

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13523
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6 Firefox 3.6
    • View Profile
    • http://enterprise.iko.hu/
Re: EXOS 2.3 tovább fejlesztése
« Reply #24 on: 2010.May.24. 13:59:29 »
Egyébként ha már a megszakításoknál tartunk: úgy tûnik van még egy bug az EXOS-ban.
Turbos gépen is lehet érzékelni, de igazán akkor jön elõ, ha ALT-W-vel nyomunk egy padlógázt az emulátoron. Ekkor nem lehet gépelni, mert egy pillanatnyi gombnyomásból lesz vagy 50 karakter...
Viszont a leírás szerint a videómegszakítást használja a KEYBOARD, az viszont nem gyorsul a turboval! Akkor miért is változik a billentyûzet sebessége?

Szintén érdekes a kurzor õrült villogás, igaz az annyira nem zavaró, csak poén :-)

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux 64 bit (Suse) Linux 64 bit (Suse)
  • Browser:
  • Firefox 3.5.4 Firefox 3.5.4
    • View Profile
Re: EXOS 2.3 tovább fejlesztése
« Reply #25 on: 2010.May.24. 14:33:08 »
Egyébként ha már a megszakításoknál tartunk: úgy tûnik van még egy bug az EXOS-ban.
Turbos gépen is lehet érzékelni, de igazán akkor jön elõ, ha ALT-W-vel nyomunk egy padlógázt az emulátoron. Ekkor nem lehet gépelni, mert egy pillanatnyi gombnyomásból lesz vagy 50 karakter...
Viszont a leírás szerint a videómegszakítást használja a KEYBOARD, az viszont nem gyorsul a turboval! Akkor miért is változik a billentyûzet sebessége?

Alt+W-nél az egész emuláció gyorsul (Z80, NICK, és DAVE is), az órakártya kivételével, tehát a nagyon "lelassuló" CMOS órától eltekintve ezt az EP-s programok nem tudják érzékelni, és mivel valós (nem emulált) időben a video megszakítások is gyorsabbak, így érthető, hogy nehezebb gépelni.
Viszont turbós hardver emulációjakor - a Machine configuration ablakban a Z80 és DAVE frekvenciát átírva - nem kellene ilyen problémának lenni, és nekem jónak is tűnik, legalábbis IS-BASIC alatt, mást nem néztem. 100 MHz-s Z80-at és a memória várakozások emulációjának kikapcsolását (hogy ne legyen ~100 ciklus várakozás video RAM hozzáférésnél) beállítva még mindig jól lehet gépelni.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4806
  • OS:
  • Linux 64 bit (Suse) Linux 64 bit (Suse)
  • Browser:
  • Firefox 3.5.4 Firefox 3.5.4
    • View Profile
Re: EXOS 2.3 tovább fejlesztése
« Reply #26 on: 2010.May.24. 14:39:52 »
Na csináltam egy EI vadász scriptet :-)

Ezt valamivel egyszerűbben is lehet írni:

Code: [Select]
function breakPointCallback(t, a, v)
  return (t == 3 or readMemory(getPC()) == 0xFB)
end

Itt egyébként az "or" utáni memória olvasás nem is fut le, ha a "t == 3" igaz (ez így van a C/C++ nyelvnél is).

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13523
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.3 Firefox 3.6.3
    • View Profile
    • http://enterprise.iko.hu/
Re: EXOS 2.3 tovább fejlesztése
« Reply #27 on: 2010.May.25. 09:18:58 »
Alt+W-nél az egész emuláció gyorsul (Z80, NICK, és DAVE is), az órakártya kivételével, tehát a nagyon "lelassuló" CMOS órától eltekintve ezt az EP-s programok nem tudják érzékelni, és mivel valós (nem emulált) idõben a video megszakítások is gyorsabbak, így érthetõ, hogy nehezebb gépelni.
Áhá! Akkor ez kavart meg, azt hittem az 50Hz marad 50Hz ilyenkor is  :oops:

Offline Zozosoft

  • EP addict
  • *
  • Posts: 13523
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.4 Firefox 3.6.4
    • View Profile
    • http://enterprise.iko.hu/
Re: EXOS 2.3 tovább fejlesztése
« Reply #28 on: 2010.June.26. 00:27:01 »
Ez EXOS "hiba", a ~ karakter érvénytelen fájlnévben.
Igazából már régebben is gondoltam arra, hogy ezt ki kéne javítani  :oops:
Így néz ki a kérdéses rész EXOS 2.0-ban:
Code: ZiLOG Z80 Assembler
  1.   CCE6  1A           LD    A, (DE)
  2.   CCE7  FE 2D        CP    2D
  3.   CCE9  38 23        JR    C, CD0E
  4.   CCEB  FE 3A        CP    3A
  5.   CCED  38 15        JR    C, CD04
  6.   CCEF  FE 5F        CP    5F
  7.   CCF1  28 11        JR    Z, CD04
  8.   CCF3  FE 5C        CP    5C
  9.   CCF5  28 0D        JR    Z, CD04
  10.   CCF7  38 02        JR    C, CCFB
  11.   CCF9  D6 20        SUB   20
  12.   CCFB  FE 41        CP    41
  13.   CCFD  38 0F        JR    C, CD0E
  14.   CCFF  FE 5B        CP    5B
  15.   CD01  3F           CCF
  16.   CD02  38 0A        JR    C, CD0E
  17.   CD04  23           INC   HL
  18.   CD05  77           LD    (HL), A

És így 2.1-ben:
Code: ZiLOG Z80 Assembler
  1.   CD05  1A           LD    A, (DE)
  2.   CD06  FE 23        CP    23
  3.   CD08  38 2D        JR    C, CD37
  4.   CD0A  FE 2B        CP    2B
  5.   CD0C  38 1F        JR    C, CD2D
  6.   CD0E  FE 2D        CP    2D
  7.   CD10  38 25        JR    C, CD37
  8.   CD12  FE 3A        CP    3A
  9.   CD14  38 17        JR    C, CD2D
  10.   CD16  FE 3F        CP    3F
  11.   CD18  28 13        JR    Z, CD2D
  12.   CD1A  FE 5B        CP    5B
  13.   CD1C  38 06        JR    C, CD24
  14.   CD1E  FE 61        CP    61
  15.   CD20  38 0B        JR    C, CD2D
  16.   CD22  D6 20        SUB   20
  17.   CD24  FE 41        CP    41
  18.   CD26  38 0F        JR    C, CD37
  19.   CD28  FE 5B        CP    5B
  20.   CD2A  3F           CCF
  21.   CD2B  38 0A        JR    C, CD37
  22.   CD2D  23           INC   HL
  23.   CD2E  77           LD    (HL), A

2.0 esetén invalid a 2Dh-nál (minuszjelnél) kisebb karakterek, onnantól elfogadható a 9-esig (3Ah), az alsóvonal (5Fh), a visszaper (5Ch), és nagybetûsítés után A-Z-ig.
Aztán amikor elkészültek az EXDOS-szal, rájöttek, hogy van itt némi bibi, az EXOS nem fogadja el a lemezes rendszerben gyakran használatos * és ? jokekaraktereket se  :oops:

Így a 2.1-ben kibõvült a rutin, így 23h (fontjel vagy kettõskereszt UK/BRD) lett az alsó határ (ezt speciel meg az EXDOS nem fogadja el :-) ), egészen a csillagig (2Ah), majd folytatódik a minuszjeltõl (2Dh) a 9-esig (3Ah), ahogy a 2.0-ban is. Külön vizsgálattal bekerült a kérdõjel is (3Fh). Nagybetûsítés elõtt még elfogadja a 5B-60h karaktereket is.

De ez még így sem lett tökéletes, mint ahogy azt a ~ mutatja, amely 10 évvel az EP kifejlesztése után lett gyakori fájlnév karakter.
További csúnya probléma a ! nem elfogadása, mivel az EXDOS-ban ez használható a \ helyettesítésére (mivel a német billentyûzeten nincs visszaper), de ez így csak EXDOS parancsok esetén mûködik, EXOS fájlnév megadásnál nem lehet így megadni az útvonalat. Ugyanilyen funkciójú a ' is, ez esetben csak EP64-en van ez a probléma, EXOS 2.1 esetén már belekerült a szórásba :-)
A kis z feletti tartományban pedig nemcsak a PC felõl érkezõ ~ okozhat gondot, ilyet EP-n is elõ lehet állítani, az EXDOS parancsok elfogadják ~ karaktert, meg a szomszédos kapcsos zárójeleket is, valamint továbbá az összes ALT-tal elõhívható karaktert is, így pl HFONT-os rendszerben REN paranccsal elõállíthatóak EP-s ékezetes fájlnevek, MD-vel könyvtárak...
...csak betölteni nem lehet az ilyeneket tartalmazó fájlokat :-)

Ezért én azt mondanám, hogy ne lacafacázzunk, legyen elfogadva a teljes EP-s karakter tartomány (33-160)!
Vélemény?
« Last Edit: 2010.June.26. 00:30:13 by Zozosoft »

Offline Lacika

  • EP addict
  • *
  • Posts: 2930
  • Country: hu
  • OS:
  • Windows XP Windows XP
  • Browser:
  • Firefox 3.6.4 Firefox 3.6.4
    • View Profile
    • http://www.ep128.hu
Re: EXOS 2.3 tovább fejlesztése
« Reply #29 on: 2010.June.26. 08:06:44 »
Ezért én azt mondanám, hogy ne lacafacázzunk, legyen elfogadva a teljes EP-s karakter tartomány (33-160)!
Vélemény?


Nem tartom jó ötletnek, ha szerény véleményemre vagytok kíváncsiak. Abból lenne csak kavarodás. Konzervatív vagyok, csak a hullámjelet adjuk hozzá az elfogadható karakterekhez.