26

cena... slyszalem ze okolice 100zl ale tak jak wczesniej pisalem nie wiem przy jakiej ilosci obowiazuje ani co jest w cenie... mysle, ze nalezy ja traktowac jako orientacyjna. jak przyjdzie co do czego to sie dowiemy ;-) poki co trzeba sie rozeznac o jakiej ilosci bedzie mowa.

http://atari.pl/hsc/ad.php?i=1.

27

tak naprawde to xxl planuje wszystkim sprzedac mapram, no chyba ze bedzie promotorem rozszerzenia do 4mb, sdx i 65c816 i bedzie aktywnie wspieral taka platforme piszac na nie oprogramowanie
coz, zobaczymy te piekne produkcje na 816 z 4mb pamieci
az chce sie zyc!

przechodze na tumiwisizm

28

Ja bym się też pisał na takie rozszerzenie do mojego 65XE, jeśli jest ono wersją rozwojową znajdującego się tam prototypu.

Z tym że, ponieważ ten komputer ma 65C816, jeśli jest taka opcja, pozostałbym przy następującej konfiguracji:

1) PORTB: wybieralne do 1 MB (chyba że problemy zgodnościowe z 2 MB już zostały rozwiązane) plus 2 MB liniowej.

2) Axlon: 2 MB plus 2 MB liniowej.

4 mega w bankach mnie niezbyt interesuje, MapRAM też nie. Jeśli natomiast wersja rozwojowa nie oferuje takiej opcji, to nie reflektuję. Czyli: zapisałbym się warunkowo.

KMK
? HEX$(6670358)

29

pierwszy post wyedytowany. wiecej info o rozszerzeniu i lista chetnych.

http://atari.pl/hsc/ad.php?i=1.

30

+1

31 Ostatnio edytowany przez Pin (2013-03-12 13:17:03)

ok, podobnie uczynię jak Draco, czyli

warunek:

IF post#28=%1:biore=%1:kasemam$="kwiecien,maj,czerwiec, bo wczesniej pracy niet":else:niebiore=%1:endif

wynik odprowadzony do:
*biore
*niebiore

;)

Kontakt: pin@usdk.pl

32

+1 z linią od Pina ;)

33 Ostatnio edytowany przez willy (2013-03-13 13:13:44)

Tak sobie myślę ...
Projekt jest (nie widziałem ale z opisu wnioskuję) fajnie zaawansowany, złożony i wogóle wybiega nieco w przyszłość blebleble itd.
Ale opiera się na pewnym przestażałym założeniu: czytaj SIMM ... cieżko dostępna przestarzała  technologia itd.

Może by tak przerobić to na w miarę nowoczesną 1 kość SDRAM (1 układ nie moduł DIMM)? Wydaje mi się że nie było by  z tym specjalnie dużo pracy.

Zalety:
- Odpada generowanie cykli odświerzania na rzecz autorefesh. Znacznie prostszy układ.
- Odpada problem z zakupem pamięci
- Rozmiar

Wady:
- prawdopodobnie trzeba by było pogonić pamięć asynchronicznie od Atari - czytaj trochę szybciej - aczkolwiek tego pewien nie jestem.

Co o tym myślicie ?

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

34

a ja na to: http://www.tme.eu/pl/details/as6c4008-5 … ce-memory/

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

35

Maiłem na myśli coś takiego: http://www.tme.eu/pl/details/as4c8m16s- … e-memory/#

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

36

hint: 3.3v, sdram (wiec nie masz pewnosci ze to o co pytasz - dostaniesz)
ze statykiem na 5V jest znacznie mniej roboty. wrecz mozesz 1/3 atarki wyciac, podpinajac go.
co nawet chyba przetestuje...

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

37

willy, produkcyjnie to ddr3 mozesz uzywac
sdram jest tak samo obsolete jak simm

przechodze na tumiwisizm

38

DDR (kążdy) ma pewną wadę której nie ma SDRAM. Ma minimalną częstotliwość taktowania + sam kontroler nie jest prosty. A SDRAM mimo że OBSOLETE to nadal jest produkowany, nadal jest powszechnie dostępny i prosty w użyciu.

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

39

i rowniez wymaga kontrolera

przechodze na tumiwisizm

40

Jak każdy DRAM.

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

41 Ostatnio edytowany przez jellonek (2013-03-13 15:26:37)

dlatego tez proponuje prostote, static ram, od razu na 5v, bez potrzeby stosowania przejsciowego bufora...
jak i jakiegokolwiek kontrolera, odswiezania itd.

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

42

Plus tego rozwiązania (SRAM) to prostota.
Koszt i rozmiar przy 4M robi się spory :)

"tatusiu zobacz, narysowałam tobie takie same coś jak na twojej koszulce" 
https://github.com/willyvmm/mouSTer
jmp $e477

43 Ostatnio edytowany przez jellonek (2013-03-13 18:30:06)

4M? po co to komu?
przeciez wiadomo ze 640kb powinno wystarczyc kazdemu...

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

44

Ale to było pod DOSem. A flashjazzcat właśnie kończy Windows dla Atari... :D

The problem is not the problem; the problem is your attitude about the problem

45

Jaki łindołs - porządne X11 :P

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

46

Jak wierzchem pójdzie CDE, KDE albo Gnome to i 4 mega się przyda :)

The problem is not the problem; the problem is your attitude about the problem

47

na gnome to i 4G nie styknie...

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

48

wieczor napisał/a:

A flashjazzcat właśnie kończy Windows dla Atari

Kończy? - tu bym obstawiał opcję /może jest w połowie/ ;) ... no i zależnie od sposobu działania, będzie to albo nieużyteczna ciekawostka, albo użyteczne gui.

Kontakt: pin@usdk.pl

49 Ostatnio edytowany przez flashjazzcat (2013-03-14 23:01:49)

It all depends on the presence or absence of productivity applications written expressly for the interface. All A8 GUIs have previously failed in this respect. I can do so much myself, depending on my life expectancy. :) Much depends on how useful interested developers can be when the time comes.

As for 4MB: I can't even imagine how the GUI would use that, but time will tell.

50 Ostatnio edytowany przez wieczor (2013-03-15 10:37:18)

How I could imagine using extended memory by windows based system is running several programs in the same time. Of course with 8-bit Atari we cannot think about real multitasking - within programs started concurently only one would be active and running. But other programs can remain in memory frozen at current state and stored in extended memory. When you're switching between programs they are becoming active and taking place in basic memory while program becoming unactive is stored in extended memory. At such approach any amount of memory can be useable - problem with graphics environments for 8-bit computers is limited amount of memory.

Of course if you have a HDD that can be solved also by swapping memory blocks to hard drive .

The problem is not the problem; the problem is your attitude about the problem