4,426

(190 odpowiedzi, napisanych Software, Gry - 8bit)

Spoko, bug dotyczy obsługi rozkazu COP #$00, kropnąłem się o jeden bajt stosu  :?  Ponieważ tego przerwania nic nie używa, więc to nie problem.

Serwis pak polega na poprawieniu bajtu pod adresem $CB0A (offset $0B0A od początku ROM-u) z wartości $0B na $0C, oraz sumy kontrolnej pod adresem $C000-1 z $9D03 na $9D04.

Po tym zabiegu handler powinien działać i można się bawić w pisanie tekstu po ekranie opisanym w specyfce sposobem. Ale nie radzę w ten sposób wywoływać DOS-u  8) Jeszcze nie w tej wersji ROM-u.

Oczywiście normalnym trybem (tj. bez użycia COP #$00, a przez tablicę skoków) wszystko powinno działać normalnie.

4,427

(190 odpowiedzi, napisanych Software, Gry - 8bit)

A nie masz jeszcze ROM Changera? Rewelacyjna sprawa, wrzucenie nowego romu trwa tyle, co wczytanie go z dyskietki + wpisanie 2 instrukcji poke spod dosu?

Mnie by się coś takiego bardzo przydało, ale zdaje się, że nie ma takiego odważnego, który zdecydowałby się tknąć tę plątaninę kabli, która pokrywa płytę w moim 65xe.

[ Dodano: 14.11.2004 11:42:41 ]

Wersja atarowskiego ROM-u dla komputerów z 65c816 jest dostępna pod tym adresem:

http://82.210.159.30/xlos.zip

To jest wersja alpha, czyli do przetestowania i zgłoszenia mi błędów.

Archiwum przepakowałem, wywaliłem starszą wersję, za to dodałem bojowe pliki tekstowe, tj. specs.txt, CHANGELOG oraz przede wszystkim known_bugs.txt, bo już takowe (a raczej takowy, liczba pojedyncza) zauważyłem.

Nowa wersja, 1.91, pewnie w przyszły weekend, o ile Simius będzie miał trochę czasu na programowanie EPROM-a  8)

4,428

(16 odpowiedzi, napisanych Emulacja - 8bit)

Nie, nie chciało mi się  :|

4,429

(16 odpowiedzi, napisanych Emulacja - 8bit)

Lizard: EmuXL nie emuluje 65c816, tylko 65c02.

4,430

(190 odpowiedzi, napisanych Software, Gry - 8bit)

A to akurat na pewno nie przejdzie  :D

Pin: na twoim miejscu zostawiłbym sobie gdzieś prztyczek pod którym miałbys oryginalny system. Ja tak mam: wywaliłem QMEG-a 3.2, a na to miejsce dałem mój ROM. Jak dotąd nie zauważyłem, żeby jakiś program nie działał, ale oczywiście trzeba przetestować np. gierki ...

4,431

(190 odpowiedzi, napisanych Software, Gry - 8bit)

Z kompatybilnością czego z czym?  8O

4,432

(190 odpowiedzi, napisanych Software, Gry - 8bit)

Nie znam  :(

4,433

(20 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

Obejrzyj "inny obrazek na który możemy popatrzeć", to zrozumiesz kompleks czułków :>

4,434

(20 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

Idąc dalej tym tropem można zauważyć, że Japonki z całą pewnością nie mają czułek na głowie; a Japończycy są z Marsa i lubią czułki 8O

4,435

(18 odpowiedzi, napisanych Sprzęt - 8bit)

w TOP DRIVE - czyli TOMS TURBO wszystkie rozkazy do stacji (jakies 2-3% danych) sa przesylane z predkoscia standardowa - jakos nikt nie przyznal sie jaki to ma wplyw na ogolna predkosc i podawana zawsze byla tylko predkosc przesylu danych.

O ile pamiętam, w Indusie jest jeszcze (trochę) gorzej. W Topie i TOMS-ie Multi rozkaz do stacji jest wysyłany na 19200, cała reszta natomiast, to jest potwierdzenie zwrotne, dane itd. idzie już w turbo. W Indusie natomiast nie dość, że rozkaz jest wysyłany na 19200, to potwierdzenie zwrotne przychodzi też w normalnej transmisji, i dopiero cała reszta idzie w turbo.

To jest główna przyczyna dla której stacje TOMS nie chcą chodzić w TOMS Turbo pod Spartą X. Nie zgadza się szybkość przesłania potwierdzenia rozkazu.

To natomiast, że nie chcą chodzić w Ultra, to już wina Sparty, która nie pyta stacji o częstotliwość pracy, tylko ustawia na pałę 52 kbd.

O ile pamiętam, cała korespondencja pomiędzy komputerem a stacją to 6 czy 7 bajtów na sektor. Przy podwójnej gęstości jest to w istocie nieco ponad 2% transmitowanych danych.

4,436

(43 odpowiedzi, napisanych Sprzęt - 8bit)

A ja napisałem w C rewolucyjny (Lizard wie o co chodzi, reszta nie musi :lol: ) program do liczenia sum kontrolnych ROM-u, i sprawdziłem, że plik jest OK.

Czyli, panie Pin, coś waścin emulator nie teges.

4,437

(2 odpowiedzi, napisanych Bałagan)

Oj, strasznie fałszują :( I to słychać mimo zastosowania się do meritum :(

4,438

(43 odpowiedzi, napisanych Sprzęt - 8bit)

Suma kontrolna pierwszego bloku jest pod adresem $C000 i wynosi $9D03. Suma kontrolna drugiego bloku jest pod adresem $FFDE i wynosi $647D.

ckrom1 ldx #$00
    stx cksum
    stx cksum+1
?loop jsr getcks
    cpx #$0c
    bne ?loop
    rts
;
ckrom2 ldx #$00
    stx cksum
    stx cksum+1
    ldx #$0c
    jsr getcks
    jmp getcks
;
getcks ldy #$00
?loop lda ckstab,x
    sta tmpreg,y
    inx
    iny
    cpy #$04
    bne ?loop
    ldy #$00
?n  clc
    lda (tmpreg),y
    adc cksum
    sta cksum
    bcc ?nxt1
    inc cksum+1
?nxt1 inc tmpreg
    bne ?nxt2
    inc tmpreg+1
?nxt2 lda tmpreg
    cmp tmpreg+2
    bne ?n
    lda tmpreg+1
    cmp tmpreg+3
    bne ?n
    rts
;
ckstab .wo buf+2, buf+$1000
    .wo buf+$1000,buf+$1800
    .wo buf+$1800,buf+$2000
    .wo buf+$2000,buf+$3fde
    .wo buf+$3fe0,buf+$4000

'buf' to jest adres, pod który jest wczytana zawartość pliku xlos2.bin. jsr ckrom1 wpisuje sumę kontrolą pierwszego bloku ROM pod adres 'cksum', jsr ckrom2 wpisuje sumę kontrolą drugiego bloku ROM pod adres tenże. cksum musi być zmienną dwubajtową, a tmpreg czterobajtową, obie na stronie zerowej.

[ Dodano: 13.11.2004 10:21:30 ]

3)  there's a test for extended linear memory, peek(591) should return a number of *additional* (i.e. beyond the first 64k) 64k memory segments;

Poprawka: peek(590), nie peek(591).

4,439

(43 odpowiedzi, napisanych Sprzęt - 8bit)

Ja tego nie mogę teraz zrobić. Plik kopiował mi kolega, przez kabel szeregowy. Fakt, kretyni jesteśmy, żeśmy tego przedtem nie skompresowali, od razu byłoby wiadomo, czy przekopiowało się dobrze.

W każdym razie, u mnie plik wypalony w EPROM-ie działa. Jeśli to, co zapodałem pod wyżej wymienionym adresem nie działa, to znaczy, że transmisja się spieprzyła :(

4,440

(190 odpowiedzi, napisanych Software, Gry - 8bit)

Wersja atarowskiego ROM-u dla komputerów z 65c816 jest dostępna pod tym adresem:

http://82.210.159.30/xlos.zip

To jest wersja alpha, czyli do przetestowania i zgłoszenia mi błędów. Release notes są dostępne gdzieś tu:

http://atariarea.histeria.pl/forum/viewtopic.php?t=2368

Wspomnę tylko, że archiwum zawiera dwa pliki. Oba nadają się do zaprogramowania EPROM-u i użycia zamiast oryginalnego systemu, ale xlos2.bin nadaje się bardziej (jest nowszy).

4,441

(43 odpowiedzi, napisanych Sprzęt - 8bit)

Niestety, nie pomyślałem o tym, ofiara jestem. A teraz takiej możliwości nie mam :(

[ Dodano: 13.11.2004 03:38:52 ]

.. odpaliłem na początek emu - UltraXE (oczywiście z emulacją 65c816)... i krzak (tak?>:D)

No zawsze jest możliwość, że transfer z Atari na peceta się nie udał i plik binarny ma błedy transmisji :/ Proponuję przeliczyć sumy kontrolne, mogę udostępnić tu listing programu, który to robi.

PS. Self test może wywalać wszystko na czerwono, on po prostu nie działa, nie napisałem jeszcze nowego self testu, po prostu :>

4,442

(20 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

Obrazek wygląda na double Sweet 16  :mrgreen:

Czyli to samo, ale dużo wolniej  ;)

Jak to, "stanie"? A przy PIO co robi?

4,445

(14 odpowiedzi, napisanych Software, Gry - 8bit)

Ja zawsze mam problem jak na ekranie 1000x700 pomiescic wszystkie wymagane informacje (program, ze 2 podglady pamieci, rejestrow, timerow,...). Na Atari to musi byc masakra.

Panowie, bez jaj. Po co to wszystko mieć na ekranie? To - wartości rejestrów, stany znaczników, operacje wykonywane przez rozkazy - widzi się po prostu na generowanym przez debugger listingu kodu. Debugger, który nie może pomieścić istotnych informacji na ekranie 1024x768 może potrzebny jest przy łamaniu cudzych programów, ale do śledzenia własnych wystarczy 40x24 (= debugger MAE).

Poza tym, ale to moja prywatna opinia, jeśli ktoś się uczy asemblera, to uzależnianie się od debuggera na tym etapie jest największą krzywdą, jaką sobie można zrobić na przyszłość. Albowiem do wykrywania błędów we własnych programach wcale nie jest potrzebny debugger, tylko umiejętność analizy kodu, a w wyrobieniu tej umiejętności debugger akurat przeszkadza, bo odmóżdża już na samym wstępie.

4,446

(43 odpowiedzi, napisanych Sprzęt - 8bit)

Wrzucę tu linka.

Well, here:

http://82.210.159.30/xlos.zip

There are two binaries, xlos.bin is earlier and it's interrupt routines are at the same place as in the original XL OS rev. B.

In the xlos2.bin the IRQ and NMI routines are moved to new locations. This version will be developed further and I would prefer this version to be tested.

Ok, what it should already do:

1) start up successfully ;-)
2) the CPU native mode should be now available without switching interrupts off;
3)  there's a test for extended linear memory, peek(591) should return a number of *additional* (i.e. beyond the first 64k) 64k memory segments;
4) the FP functions should be a bit faster than in the original;
5) the boot drive number is no longer initialized inside the BOOT routine, it is done while initializing other disk related variables. The new device can now effectively change the boot drive number simply updating the DUNIT.

The vectors I've described previously (in the "specifications") should be correctly initialized at reset time and work properly. This wasn't yet tested.

The OS revision number is BB 01.90. The release date is the Independence Day.

There are changes all around the first 4k of ROM, in the FP ROM and at the end of the second ROM block too. The interrupt vectors located in RAM will point to different locations. The ROM-based vector tables may contain different values. Some of the jump table entries may be changed as well.

Ok, what does not work:

1) The Self Test will definitely not work correctly;
2) the rev. number, OS release date etc. is not available in the second ROM part ($d800-$ffff, close to the top of memory, I don't remember the address);
3) the second ROM block checksum is available at $FFDE, not $FFF8;
4) Encounter (the game) probably will not work due to different ROM checksums; this is fixable.

I already have this version of ROM (the xlos2.bin) in my computer and it starts up properly and appears to work correctly. Please test and report problems. Thanks.

Polish version:

Panowie, chyba rozumiecie po angielsku :-)

[ Dodano: 13.11.2004 02:33:20 ]

The problem for me is, I can't read polish

So what about learning some polish finally? The language is quite easy ... and polish :D

[ Dodano: 13.11.2004 02:48:20 ]

When I read about this new OS, I read sometimes that there isn't enough room in the original OS. But it must be possible to have a bigger ROM somewhere between $10000 - $FFFFF and run 16-bit code from there...

Well, there is some place even in the original OS.

:rolleyes: UDMA jest bez sensu, ale zwykłe DMA może zwiększyć transfer - teoretycznie oczywiście - do 1,77 MB/s.

4,448

(43 odpowiedzi, napisanych Sprzęt - 8bit)

Wrzucę tu linka.

4,449

(23 odpowiedzi, napisanych Bałagan)

ostatnio dużo flaszek poszło ...

To się chłopie nazywa kac, a nie dół  :twisted:

4,450

(14 odpowiedzi, napisanych Software, Gry - 8bit)

No, jest MAE, które ma edytor, kompilator i debugger w jednym. Debugger ma, jak każdy debugger, opcje śledzenia programu, aczkolwiek nie powiem, żebym kiedykolwiek z niej korzystał.