On 12.08.2018 21:19, Sebastian Biały wrote:

> Która była ładowana z czego?

Pętla opóźniająca była osobnym podprogramem, który był wywoływany po
każdym zmianie stanu diody. Wewnątrz tego podprogramu znajdowały się
właściwie tylko dwie pętle, jedna zagnieżdżona w drugiej. Pierwsza
operowała na rejestrze X, druga na Y. Każdy z nich był inicjowany
wartością 0xFF i po każdym przejściu zmniejszany o jeden.


> Ponadto jednak w tego typu projekcie wykluczyłbym najpierw hardware.
> 6502 można solidnie przetaktować przez zniekształcony sygnał zegarowy,
> wtedy częśc funkcjonalności nie działa a takim małym programie czasem
> nie widać że np. się sam resetuje. Jak wygląda generator zegara?

To była moja pierwsza myśl. Na oscyloskopie wszystko wygląda ok. To
znaczy sygnał zegarowy bezpośrednio na wyjściu generatora SG51P jest
minimalnie "postrzępiony" na górze, jednak po przejściu przez dzienlnik
na 74HCT74 robi się z tego całkiem ładny sygnał, niemalże kwadrat z
lekko zaokrąglonymi krawędziami.


> Niezainicjowania zmienna/rejestr, błąd w sofcie. Mozliwe, choć watpliwe
> że wina asemblera/kompilatora. Czego używasz?
>
> Pokaż źródła jednego i drugiego. Jeszcze coś pamiętam z asm 6502.

Przy większych projektach używam cc65, ale tutaj posłużyłem się prostym
webowym narzędziem asm80.com.

Pierwszy program - ten, z któ(C)ym były problemy:

CTRL EQU $0BC00

.ORG $0C000
CLD
LDX #$FF
TXS

LOOP:
LDA #$04
STA CTRL

JSR DELAY

LDA #$80
STA CTRL

JSR DELAY

JMP LOOP

DELAY:
LDX $FF
DELAY_LOOP1:
LDY $FF
DELAY_LOOP2:
NOP
DEY
BNE DELAY_LOOP2
DEX
BNE DELAY_LOOP1
RTS

.ORG $FFFE
DW $0C000


Drugi program - ten, który teraz zdaje się działać prawidłowo:

TRL EQU $0BC00

.ORG $C000
INIT:
LDX #$FF
TXS
LDA #$80
STA CTRL
LDA #$01
STA DIODE
LDA #$FF
STA TIMER
LDA #$FF
STA TIMER+1
LOOP:
JSR HANDLE_TIMER
JMP LOOP


HANDLE_TIMER:
DEC TIMER
BNE HT_RET
LDA #$FF
STA TIMER
DEC TIMER+1
BNE HT_RET
LDA #$FF
STA TIMER+1
; tutaj wykonujemy nasz kod
LDA DIODE
BEQ SET_DIODE
LDA #$04
STA CTRL
LDA #$00
STA DIODE
JMP HT_RET
SET_DIODE:
LDA #$80
STA CTRL
LDA #$01
STA DIODE
HT_RET:
RTS


IRQ:
RTI

NMI:
RTI

.ORG $0200
TIMER: DS 2
DIODE: DS 1

.ORG $FFFA
DW NMI
DW INIT
DW IRQ

do góry

I jeszcze jedno, czy hipotetycznie powodem (lub jednym z powodów) takiej
niestabilności może być fakt zasilania tego z 5V stabilizowanego
zasilacza impulsowego?

do góry

On 8/12/2018 9:51 PM, Atlantis wrote:
> I jeszcze jedno, czy hipotetycznie powodem (lub jednym z powodów) takiej
> niestabilności może być fakt zasilania tego z 5V stabilizowanego
> zasilacza impulsowego?

Jak chiński to może. Dodaj solidny elektrolit, najlepiej mały i duzy na
zasilaniu.

do góry

On 8/12/2018 9:43 PM, Atlantis wrote:
> To była moja pierwsza myśl. Na oscyloskopie wszystko wygląda ok. To
> znaczy sygnał zegarowy bezpośrednio na wyjściu generatora SG51P jest
> minimalnie "postrzępiony" na górze, jednak po przejściu przez dzienlnik
> na 74HCT74 robi się z tego całkiem ładny sygnał, niemalże kwadrat z
> lekko zaokrąglonymi krawędziami.

A co wychodzi na outpucie F1 i F2? Nie obciążyles przypadkiem za bardzo
jednego z nich? F2 nie może popychac więcej jak 2 bramek TTL jak pamiętam.

> Pierwszy program - ten, z któ(C)ym były problemy:

Nie widze jakiś dramatów. Wyłącz jeszcze przerwania SEI.

Oczywiście po adresem $0100 masz ram na stos :) ? I stronę zerową ?

do góry

Dnia Sun, 12 Aug 2018 21:07:36 +0200, Atlantis napisał(a):
> On 12.08.2018 20:47, Sebastian Biały wrote:
>> Kasowalem kiedyś epromy słońcem, ale trwało to kilka dni i zazwyczaj
>> kończyło sie w 50%. Niektórych w ogóle nie dało się skasować.
>
> Chodzi mi o to, czy wystawienie EPROM-u na działanie słońca (właśnie
> przez kilka dni, poprzez położenie go koło okna) może w teorii
> spowodować niestabilne działania programu?

Moze

> A konkretnie działanie
> niestabilne w ten konkretny sposób, gdy czasem po włączeniu do zasilania
> program zaczyna zachowywać się dziwnie?

Ale nie tak, ze raz po wlaczeniu petla dziala dobrze, a innym razem
nie.

> Bop nic innego nie przychodzi mi do głowy. Skoro generator sygnału
> taktującego był ok, a program robił to co powinien (tyko czasem
> szybciej) to mam wrażenie, że raz na ileś tam włączeń musiało się dziać
> coś, co sprawiało, że błędnie interpretowana była wartość, którą
> reinicjowany był rejestr po zakończeniu przebiegu pętli.


... hm, a eproma zakleiles ?
Moze to oswietlenie mu przeszkadzalo i sie zmienialo ?

J.

do góry

On 12.08.2018 22:12, Sebastian Biały wrote:

> A co wychodzi na outpucie F1 i F2? Nie obciążyles przypadkiem za bardzo
> jednego z nich? F2 nie może popychac więcej jak 2 bramek TTL jak pamiętam.

Z tego co pamiętam, sygnały w porządku. F1 jest w ogóle nieużywany w
moim projekcie. F2 w chwili obecnej jest podłączony do wejścia jednej z
bramek 74HCT00, będącej elementem układu generującego sygnały RD i WR.
F2 jest też wyprowadzony na złącze - zgodnie z założeniami ma taktować
generator baudrate'u dla UART-a.



>> Pierwszy program - ten, z któ(C)ym były problemy:
>
> Nie widze jakiś dramatów. Wyłącz jeszcze przerwania SEI.

A właśnie... Możliwe, żeby winę za takie zachowanie ponosił brak tej
instrukcji, jak również brak wektorów wskazujących na (chociażby puste)
podprogramy obsługujące przerwanie? Coś w momencie podłączenia zasilania
powodowałoby odczytanie fałszywej informacji o przerwaniu i namieszanie
w programie?



> Oczywiście po adresem $0100 masz ram na stos :) ? I stronę zerową ?

Tak. RAM zaczyna się od 0x0000.

do góry

On 12.08.2018 22:04, Sebastian Biały wrote:

> Jak chiński to może. Dodaj solidny elektrolit, najlepiej mały i duzy na
> zasilaniu.

Był 1000uF low-ESR. Podczas eksperymentów wstawiłem mniejszy, 220uF.
Opisany problem występował w obydwu przypadkach.

A co do samego CPU - parę tygodni temu przetestowałem go na
prowizorycznej konstrukcji złożonej na płytce uniwersalnej, z dużą
ilością kynaru. Wtedy był w stanie odpalić Enhanced BASIC-a i działał
normalnie. Problemem była jednak wrażliwość tej prowizorki na wstrząsy
(Zimny lut ukryty pod grubą warstwą kynaru? Uszkodzone gniazdko?) więc
przeniosłem projekt na normalne PCB, a właściwie zestaw kilka modułów.

Na razie mam tylko moduł z CPU, pamięciami i podstawową logiką, więc
BASIC-a jeszcze nie odpalę. Mogłem jedynie użyć LED-ów do debugowania.

do góry

Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:5b70974a$0$621$6...@n...neostrada.
pl...
On 12.08.2018 22:12, Sebastian Biały wrote:
>>> Pierwszy program - ten, z któ(C)ym były problemy:
>> Nie widze jakiś dramatów. Wyłącz jeszcze przerwania SEI.

>A właśnie... Możliwe, żeby winę za takie zachowanie ponosił brak tej
>instrukcji, jak również brak wektorów wskazujących na (chociażby
>puste)
>podprogramy obsługujące przerwanie? Coś w momencie podłączenia
>zasilania
>powodowałoby odczytanie fałszywej informacji o przerwaniu i
>namieszanie
>w programie?

A co z liniami IRQ/ i NMI/ ? O ile pamietam to na stale do + dolaczone
i nieaktywne.

Na pewno bezpieczniej bedzie ustawic w obsludze przerwania chocby samo
RETI.

Bo teraz, jesli przerwanie sie zglosi, lub odczytasz rozkaz FF z
pamieci, to program idzie w maliny i robi nie wiadomo co i jak dlugo
...

J.

do góry

Swoją drogą, nie chcę zaczynać nowego wątku, więc napiszę tutaj.
Chciałbym upewnić się co do jednej rzeczy - jak wygląda kwestia
kompatybilności CMOS-owych wersji 6502 np taki (R65C02P4) z układami
różnych rodzin logicznych? Zachowują one wsteczną kompatybilność z
układami TTL? Stosując je mogę stosować takie rodziny jak 74LS czy
74HCT, czy jednak powinienem użyć układów z serii 74HC albo 40xx?

do góry

Hmm... Już chyba widzę w czym rzecz.
Problem dotyczył poniższej pętli opóźniającej:

DELAY:
LDX $FF
DELAY_LOOP1:
LDY $FF
DELAY_LOOP2:
NOP
DEY
BNE DELAY_LOOP2
DEX
BNE DELAY_LOOP1
RTS

Na pierwszy rzut oka wszystko w porządku, a jednak popełniłem szkolny
błąd. W pierwszych dwóch instrukcjach zabrakło znaku "#'. Z tego powodu
argumentem instrukcji LDX i LDY nie była wartość 0xFF, ale wartość
odczytywana spod adresu 0x00FF.

do góry