Welcome, Guest. Please login or register.


Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Povi

Pages: 1 2 3 [4] 5 6 7 8 9 10 11 ... 107
46
Programozás / Re: EXOS
« on: 2019.March.10. 11:43:07 »
átírtam a blokk olvasó rutint, most a nullás lapra van belapozva a DE által kapott cím, a P1-en marad a csatorna RAM.
Így eléggé fölgyorsult, most 7447 byte / sec lett az eredmény a korábbi 3960 helyett.

Code: [Select]
READ_BLCK:
; exos 6

        bit  0, (ix-3)
        jp   nz, RET_NOFN

        ; HL = pointer to buffer
        ld   l, (ix-6)
        ld   h, (ix-5)

        ; DE' = DE
        push de
        exx
        pop  de
        exx

        in   a, (0b0h)
        push af
        di
        call SET_USER_SEGMENT0  ; at return DE points to P0

.loop:  ld   a, b
        or   c
        jr   z, .vege           ; if (BC == 0) { A = 0; goto vege; }

        ld   a, (ix-1)
        or   (ix-2)
        jr   z, .eof

        inc   (ix-4)
        call  z, Read256ByteFromEeprom
        ldi
        exx
        inc   de
        exx
        bit   6, d
        call  nz, SET_USER_SEGMENT0

        inc  (ix-2)
        jp   nz, READ_BLCK.loop
        inc  (ix-1)
        jp   READ_BLCK.loop

.eof:   ld   d, ERR_EOF         ; End of file
        db   020h               ; JR NZ, .. skip next byte
.vege:  ld   d, a               ; no error
        pop  af
        out  (0b0h), a
        ei
        ld   a, d
        ld   (ix-6), l
        ld   (ix-5), h
        exx
        push de
        exx
        pop  de
        ret

47
Interface / Re: Enterprise MIDI hardware
« on: 2019.March.09. 22:59:41 »
What does this MIDI module do? Is it only a 31250 bit/s serial port, or anything else is added?

48
Programozás / Re: EXOS
« on: 2019.March.09. 22:57:11 »
Amit viszont nem értek:
a csatorna RAM mindig az 1-es lapon lesz, ha jól értem. (ide mutat az IX regiszter).
Akkor EXOS 6 és 8 esetén, miért az 1-es lapra számoljuk át a DE értékét? Így állandóan lapozgatni kell, ha nekem szükségem van a csatorna RAM-ra (mondjuk ott van a puffer, ott tárolom a fájlméretet, ami alapján nézem, hogy EOF van-e).
Logikusabb lenne nekem a 2-es lapra átszámolni a DE-t, és odalapozni. A 2-es lapon úgyis csak a rendszerszegmens van, szóval szerintem tiltott megszakítás mellett, és CALL / RET / PUSH / POP használata nélkül működne a dolog, mivel ha jól értem, a verem is a rendszerszegmensen van ilyenkor. Aztán a végén persze visszalapoznám a rendszerszegmenst a 2-es lapra. Vélemény? De akár a nullás lapra is tehetném, tiltott megszakítás mellett, és akkor a verem használatáról se kéne lemondanom.

49
Programozás / Re: EXOS
« on: 2019.March.09. 22:52:16 »
egyébként ami nem világos nekem az EXOS leírásból: milyen regisztereket kell megőriznem?
az ugye világos, hogy az A-ban adok vissza hibakódot, vagy nullát. BC és DE regiszterben meg eredményt. De pl. mi van olyan hívásoknál, ahol nincs eredmény, csak az A-ban? Pl. EXOS 1 esetén? Akkor BCDE-t is elronthatom? Mi van a vesszős regiszterekkel? Azokat is megváltoztathatom?
Asszem meg van a megoldás: "A perifériakezelő alprogramok tönkretehetik az összes regiszter - közöttük az indexregiszterek és az alternatív regiszterkészlet regisztereinek - tartalmát, mivel ezek a tárolását az EXOS hajtja végre. "

50
Programozás / Re: EXOS
« on: 2019.March.09. 21:16:55 »
sebességteszt:

közvetlen portírással / olvasással, 256 byte-os puffer-t használva (egyszerre ennyi adatot töltök be az EEPROM-ból) 11700 byte / sec. A 256 bájtnyi adat valójában 2313 bitnyi jel az I2C buszon, ha jól számolom.

Puffer használata nélkül közvetlen port olvasással: 5715 byte / sec, ebben az esetben a 256 bájt valójában 4608 bitnyi infó a buszon, szóval reális a kb. kétszeres sebesség a puffer használata esetén.

Ugyanez a 256 byte-os buffer-es módszer EXOS 6-tal már csak 3960 byte/sec. Szóval van még mit faragni, főleg, hogy pl. minden bájtolvasásnál újra számolom a DE-t az egyes lapra...

Puffer nélkül EXOS 6-tal 3360 byte / sec, szóval minimális a gyorsulás, ebből is látszik, hogy a fő overhead maga az EXOS 6 rutinom, amit még faragni kéne :-D

51
Enterprise DevCompo #1 / Re: Enterprise program: Bricky Prise
« on: 2019.March.07. 20:39:22 »
szerintem is legyen interlace nélkül! igazi CRT monitoron úgyis vibrálna, az szerintem zavaró egy kicsit

52
Programozás / Re: EXOS
« on: 2019.March.07. 20:38:22 »
egyébként ami nem világos nekem az EXOS leírásból: milyen regisztereket kell megőriznem?
az ugye világos, hogy az A-ban adok vissza hibakódot, vagy nullát. BC és DE regiszterben meg eredményt. De pl. mi van olyan hívásoknál, ahol nincs eredmény, csak az A-ban? Pl. EXOS 1 esetén? Akkor BCDE-t is elronthatom? Mi van a vesszős regiszterekkel? Azokat is megváltoztathatom?

53
Programozás / Re: EXOS
« on: 2019.March.07. 18:34:12 »
naaaa, rájöttem a hibára!

megcsináltam az exos 7 és 8 funkciókat is, és ott is hasonló hiba jött elő: a karakteres írás működött, de blokkírás nem igazán

aztán rájöttem, hogy azért, mert a csatorna RAM, amire az IX mutat, az a P1-en van, és én kilapozom azt blokkműveletnél!!!!

szerk: MOST MÁR MŰKÖDIK!!! COPY, LOAD, SAVE stb... minden fasza! :razz:

54
Programozás / Re: EXOS
« on: 2019.March.07. 16:31:30 »
Az ide betett kódodban nincs EOF vizsgálat :oops:
tudom, azóta változott:
hátha látod a hibát:
az IX-1 és IX-2 a fájlméret negáltját tárolja (IX-2 low byte, IX-1 high byte)
Code: [Select]
; ======================================================================

READ_CHR:
; exos 5

        ld   a, (ix-1)
        or   (ix-2)
        ld   a, 0E4h         ; End of file
        ret  z
        call rdChr
        ld   b, a
        xor  a
        ret

rdChr:  ld   a, CMD_RD_BYTE_EEPROM
        out  (port_PIC), a
        jr   $ + 2          ; wait 12T cycle
        in   a, (port_PIC)
       
        inc  (ix-2)
        ret  nz
        inc  (ix-1)
        ret

; ======================================================================

READ_BLCK:
; exos 6

        ld   a, b
        or   c
        ret  z
        ld   a, (ix-1)
        or   (ix-2)
        ld   a, 0E4h        ; End of file
        ret  z
        push de
        in   a, (0b1h)
        ex   af, af'        ; save A
        call SET_USER_SEGMENT
        call rdChr
        ld   (de), a
        ex   af, af'        ; restore A
        out  (0b1h), a
        pop  de
        inc  de
        dec  bc
        jp   READ_BLCK

; ======================================================================

55
Programozás / Re: EXOS
« on: 2019.March.07. 16:24:24 »
arra rájöttem már, hogy az EXOS 5 jól működik, de a EXOS 6 valamiért nem lép ki EOF hibaüzenettel, amikor eléri a fájlvéget... Úgy tűnik, akkor a WP EXOS 5-tel olvassa be a cuccot...

56
Programozás / Re: EXOS
« on: 2019.March.07. 15:23:59 »
no, közben hozzáadtam EOF vizsgálatot (a file méretet is eltárolom az EEPROM első két byte-ján): WP-ben már beolvassa hibátlanul, ASMON-ban még nem az igazi...

57
Programozás / Re: EXOS
« on: 2019.March.07. 14:30:37 »
az exos 9-re mindig 0-át adok vissza a C-ben és az A-ban is
az exos 5 meg van:
Code: [Select]
; ======================================================================

READ_CHR:
; exos 5

        call rdChr
        ld   b, a
        xor  a
        ret

rdChr:  ld   a, CMD_RD_BYTE_EEPROM
        out  (port_PIC), a
        jr   $ + 2          ; wait 12T cycle
        in   a, (port_PIC)
        ret

; ======================================================================

58
Programozás / Re: EXOS
« on: 2019.March.07. 13:47:14 »
De ha csak simán betöltöd egy szegmensre, és nyomsz egy hideg resetet (C+Reset), a gyors tesztem megtalálja ROM szimulációként.
Na, ez tűnik egyelőre a legegyszerűbbnek, és működik!

Kérdés:
most már működik a karakter és blokk olvasás
exos 6-tal szépen be tudok olvasni az EEPROM-ból

viszont pl. ASMON-ban a "R" paranccsal már hülyeségeket csinál, de a WP-ben is az F1-re
mi hiányzik még?
Code: [Select]
READ_BLCK:
; exos 6

        ld   a, b
        or   c
        ret  z
        push de
        in   a, (0b1h)
        ex   af, af'        ; save A
        call SET_USER_SEGMENT
        call rdChr
        ld   (de), a
        ex   af, af'        ; restore A
        out  (0b1h), a
        pop  de
        inc  de
        dec  bc
        jp   READ_BLCK

59
Programozás / Re: EXOS
« on: 2019.March.07. 10:59:30 »
ROM fájlt be lehet valahogy tölteni?

Jelenleg készítem az EEPROM driver-t, ami EXOS_ROM formátumú, de teszteléshez macera lenne mindig újra égetni a flash-t az SD-kártyán.

Tudom, hogy az EPDOS-ban ott az LROM parancs, ami pont erre jó, de az EPDOS is csak ROM formában van meg (persze beégethetem azt is a 4-5 szegmensre).

A ZozoTools meg van EXT formátumban, de ott csak ROM likvidátor van, amivel csak kiírtani lehet ROM-ot, betölteni nem (vagy mégis?)

60
Programozás / Re: EXOS
« on: 2019.March.04. 15:04:41 »
ha a blokkírás / olvasás implementálva van, akkor onnantól kezdve működik automaikusan a :load, :copy stb. parancs is az adott eszközre? (vagy a BASIC LOAD, SAVE?)

ill. másik kérdésem az EOF -val kapcsolatos. Maga az EEPROM 4kB-os, de ha csak pl. 1kB-nyi adat van rámentve, akkor honnét tudja majd az EXOS, hogy elérte a fájlvéget? Nyilván nekem (a saját periféria vezérlőmnek) kéne küldenie EOF hibaüzenetet, ha többet próbálunk olvasni az eszközről, mint 1kB (a példánál maradva). De ebben az esetben akkor úgy látom, nekem a fájlhosszt is le kéne menteni az EEPROM-ba, mondjuk pl. úgy, hogy azt az első két byte tartalmazná?

Fájlnevekkel, és több fájl rámentésére az EEPROM-ra nem akarok foglalkozni.

Pages: 1 2 3 [4] 5 6 7 8 9 10 11 ... 107