>>A to, że nie mogłeś załadować tego pliku z użyciem "WZab 2T12", też by się zgadzało.
tzn załadowało ale potem nie uruchomiło, ale nie istotne. wybór wzab2t12 na tyle świadomy i celowy, bo: onegdaj w czasach słusznie minionych ten loader był na carcie dodawanym do płytki t2000kso, sprzedawane w komplecie. więc był to podstawowy soft do obsługi turbo (czyt. 'włączyć komputer i wgrywania gier'). i tamten cart mam do dzisiaj i odkąd jest sic! mam składankę (dzięki temu wątkowi) z multum różnych loaderów do różnych turbo w jednym.
jak wysokie/niskie jest memlo akurat wzab2t12, to raczej nie był problem użytkowników 'końcowych' w dawnych czasach (czyli tych którzy szli na halę, kupowali kasetę i obchodził ich tylko to, żeby się wczytywało); to była raczej zagwostka 'producentów' takich zestawów, dobrać takie wersje danego programu, żeby nagrane na kasetę działały, żeby nie było zwrotów i marudzeń klientów. to teraz mamy 'klęskę urodzaju' - w sensie każdy tytuł w wielu/kilkunastu wersjach, i co chwila jojczenie 'przerobiłem xexa z nazwą v1 i nie działa, dlaczego, co mam robić, pomuszcie' - wziąć kolejny plik z nazwą v2 i sprawdzić.
a pamiętam że 'little divil' zaś i kiedyś miałem w turbo; najpewniej w innej wersji niż ta z powyższej składanki. ot i wsio ;-P

Być może Baktra, jeżeli będzie miał chęci, czas i możliwości, doda obsługę formatu NEW FORMAT do TURGEN-a. Źródła loadera są udostępnione w repozytorium, więc można z nich korzystać do woli. Wtedy będzie jeszcze łatwiej. Na razie, aby skorzystać z narzędzia, potrzebny jest Python 3 oraz umiejętność korzystania z wiersza poleceń - pod Linuksem albo Windowsem, wedle preferencji.

Kolejny punkt do odrobienia w moim backlogu. Przynajmniej tym razem nie jest to zadanie z własnej winy :-)
Biorąc pod uwagę wszystkie czynniki, konwersja ChainLoading, którą zapewnia moduł KSO Turbo 2000, jest prawie taka sama.

wczytywanie w NewFormat nie jest szybsze niż przez *ajka, zazwyczaj jest szybsze niż zwykły/naturalny format t2000kso - czyli coś pośredniego. chociaż - dla pozycji 01, z tych trzech formatów to NewFormat wczytuje się najdłużej

W opisie (readme.md w repozytorium dla "new format loader"), napisałem taką notkę:

Ten format średnio sprawdza się przy plikach .xex zawierających bardzo dużo krótkich segmentów danych. Dotyczy to np. plików potraktowanych tzw. "Zagęszczaczem" Dariusza Rogozińskiego (IRON SOFT). Przy dużej liczbie segmentów pomiędzy kolejnymi blokami pojawia się dużo impulsów synchronizujących, co bezpośrednio wydłuża czas ładowania.

Testowałeś na "Little Devil" który jest najgorszym możliwym wyborem dla tego testu ;-) Dlaczego, oto odpowiedź:

chkxex 01_little_devil.new_f.xex 

Input file is 01_little_devil.new_f.xex and the file size is 25863 bytes.

Header is: $ffff
block 001: $1200-$12ac ($00ad)
block 002: $022e-$022f ($0002)
block 003: $026f-$026f ($0001)
block 004: $02c4-$02c8 ($0005)
block 005: $0058-$0059 ($0002)
block 006: $0230-$0231 ($0002)
block 007: $a036-$a0ff ($00ca)
block 008: $a14e-$a14e ($0001)
block 009: $a3aa-$a3cb ($0022)
block 010: $a3d2-$a3f4 ($0023)
block 011: $a3fa-$a41c ($0023)
block 012: $a422-$a444 ($0023)
block 013: $a44a-$a46c ($0023)
block 014: $a472-$a494 ($0023)
block 015: $a49a-$a4bc ($0023)
block 016: $a4c2-$a7b5 ($02f4)
block 017: $a7bb-$a7dc ($0022)
block 018: $a7e3-$a804 ($0022)
block 019: $a80b-$a82c ($0022)
block 020: $a833-$a854 ($0022)
block 021: $a85b-$a87c ($0022)
block 022: $a883-$a890 ($000e)
block 023: $a896-$a8a4 ($000f)
block 024: $a8ab-$a8b5 ($000b)
block 025: $a8c1-$a8cc ($000c)
block 026: $a8d3-$a8dd ($000b)
block 027: $a8e9-$a8f4 ($000c)
block 028: $a8fb-$a905 ($000b)
block 029: $a911-$a91b ($000b)
block 030: $a923-$a92d ($000b)
block 031: $a939-$a943 ($000b)
block 032: $a94b-$a955 ($000b)
block 033: $a961-$a96b ($000b)
block 034: $a973-$a97d ($000b)
block 035: $a98a-$a993 ($000a)
block 036: $a99b-$a9a0 ($0006)
block 037: $a9b5-$a9bb ($0007)
block 038: $a9c3-$a9c8 ($0006)
block 039: $a9dd-$a9e3 ($0007)
block 040: $a9ea-$a9f0 ($0007)
block 041: $aa05-$aa0b ($0007)
block 042: $aa12-$aa18 ($0007)
block 043: $aa2d-$aa33 ($0007)
block 044: $aa3a-$aa40 ($0007)
block 045: $aa55-$aa5b ($0007)
block 046: $aa62-$aa68 ($0007)
block 047: $aa7e-$aa83 ($0006)
block 048: $aa8a-$aa8c ($0003)
block 049: $aaa9-$aaab ($0003)
block 050: $aab2-$aab4 ($0003)
block 051: $aad1-$aad3 ($0003)
block 052: $aada-$aadc ($0003)
block 053: $aaf9-$aafb ($0003)
block 054: $ab02-$ab04 ($0003)
block 055: $ab21-$ab23 ($0003)
block 056: $ab2c-$ab2c ($0001)
block 057: $ab4a-$ab4b ($0002)
block 058: $ab52-$ab54 ($0003)
block 059: $ab72-$ab73 ($0002)
block 060: $b2ad-$b2b8 ($000c)
block 061: $b2be-$b2c8 ($000b)
block 062: $b2d5-$b2f1 ($001d)
block 063: $b2fd-$b319 ($001d)
block 064: $b325-$b341 ($001d)
block 065: $b34d-$b369 ($001d)
block 066: $b375-$b391 ($001d)
block 067: $b39d-$b3b9 ($001d)
block 068: $b3c5-$b3cf ($000b)
block 069: $b3d6-$b3e1 ($000c)
block 070: $b3ee-$b3f7 ($000a)
block 071: $b3fe-$b409 ($000c)
block 072: $b416-$b41f ($000a)
block 073: $b426-$b42f ($000a)
block 074: $b43e-$b447 ($000a)
block 075: $b44d-$b457 ($000b)
block 076: $b466-$b47f ($001a)
block 077: $b48e-$b4a7 ($001a)
block 078: $b4b6-$b4cf ($001a)
block 079: $b4de-$b4f7 ($001a)
block 080: $b506-$b520 ($001b)
block 081: $b52e-$b548 ($001b)
block 082: $b556-$b55f ($000a)
block 083: $b565-$b570 ($000c)
block 084: $b57e-$b587 ($000a)
block 085: $b58d-$b598 ($000c)
block 086: $b5a6-$b5af ($000a)
block 087: $b5b5-$b5c0 ($000c)
block 088: $b5ce-$b5d7 ($000a)
block 089: $b5dd-$b5e8 ($000c)
block 090: $b5f6-$b5ff ($000a)
block 091: $b605-$b610 ($000c)
block 092: $b61e-$b627 ($000a)
block 093: $b62d-$b638 ($000c)
block 094: $b646-$b64f ($000a)
block 095: $b655-$b65f ($000b)
block 096: $b66e-$b677 ($000a)
block 097: $b67d-$b687 ($000b)
block 098: $b696-$b6af ($001a)
block 099: $b6be-$b6d7 ($001a)
block 100: $b6e6-$b6ff ($001a)
block 101: $b70e-$b727 ($001a)
block 102: $b736-$b74f ($001a)
block 103: $b75e-$b777 ($001a)
block 104: $b786-$b79f ($001a)
block 105: $b7ae-$b7b5 ($0008)
block 106: $b7c2-$b7c7 ($0006)
block 107: $b7d6-$b7dd ($0008)
block 108: $b7ea-$b7ef ($0006)
block 109: $b7fe-$b805 ($0008)
block 110: $b812-$b817 ($0006)
block 111: $b826-$b82d ($0008)
block 112: $b83a-$b840 ($0007)
block 113: $b84e-$b855 ($0008)
block 114: $b862-$b869 ($0008)
block 115: $b876-$b87d ($0008)
block 116: $b88a-$b891 ($0008)
block 117: $b89e-$b8a0 ($0003)
block 118: $b8b5-$b8b9 ($0005)
block 119: $b8c6-$b8c8 ($0003)
block 120: $b8dd-$b8e1 ($0005)
block 121: $b8ee-$b8f0 ($0003)
block 122: $b905-$b909 ($0005)
block 123: $b916-$b918 ($0003)
block 124: $b92d-$b931 ($0005)
block 125: $b93e-$b940 ($0003)
block 126: $b955-$b959 ($0005)
block 127: $b967-$b968 ($0002)
block 128: $b97e-$b981 ($0004)
block 129: $bf4d-$bf4d ($0001)
block 130: $0480-$0568 ($00e9)
block 131: $022e-$022f ($0002)
block 132: $1000-$1019 ($001a)
block 133: $1025-$1036 ($0012)
block 134: $1047-$1050 ($000a)
block 135: $105c-$1063 ($0008)
block 136: $106d-$107a ($000e)
block 137: $1080-$1105 ($0086)
block 138: $02c4-$02c5 ($0002)
block 139: $02c4-$02c5 ($0002)
block 140: $3780-$37f8 ($0079)
block 141: $3808-$3a47 ($0240)
block 142: $3a50-$3ab1 ($0062)
block 143: $3ab8-$3ac7 ($0010)
block 144: $3ad4-$3b07 ($0034)
block 145: $3b10-$3bfe ($00ef)
block 146: $3c08-$3cd0 ($00c9)
block 147: $3cfb-$3e0c ($0112)
block 148: $3e1c-$3e22 ($0007)
block 149: $3e2f-$3e39 ($000b)
block 150: $3e42-$3e51 ($0010)
block 151: $3e57-$3e65 ($000f)
block 152: $3e6c-$3fa9 ($013e)
block 153: $3faf-$3fb9 ($000b)
block 154: $3fc2-$3fcc ($000b)
block 155: $3fd5-$3fdf ($000b)
block 156: $3fe8-$4269 ($0282)
block 157: $426f-$4339 ($00cb)
block 158: $433f-$436f ($0031)
block 159: $4375-$4635 ($02c1)
block 160: $4675-$46cf ($005b)
block 161: $46fb-$497a ($0280)
block 162: $4980-$4aba ($013b)
block 163: $4ac0-$4b67 ($00a8)
block 164: $4b80-$4bff ($0080)
block 165: $4c07-$4c08 ($0002)
block 166: $4c16-$4c19 ($0004)
block 167: $4c24-$4c2b ($0008)
block 168: $4c32-$4f58 ($0327)
block 169: $4f5f-$4f64 ($0006)
block 170: $4f6d-$4f6f ($0003)
block 171: $4f76-$4ff2 ($007d)
block 172: $5000-$5227 ($0228)
block 173: $5241-$52cb ($008b)
block 174: $52d1-$5417 ($0147)
block 175: $5420-$5436 ($0017)
block 176: $5440-$57dd ($039e)
block 177: $57ee-$57ff ($0012)
block 178: $5808-$5817 ($0010)
block 179: $5820-$585d ($003e)
block 180: $5864-$5877 ($0014)
block 181: $587d-$5897 ($001b)
block 182: $589d-$589f ($0003)
block 183: $58a8-$58bf ($0018)
block 184: $58d0-$58ff ($0030)
block 185: $5906-$5907 ($0002)
block 186: $590d-$591f ($0013)
block 187: $5925-$5927 ($0003)
block 188: $5930-$5a01 ($00d2)
block 189: $5a0d-$5a0d ($0001)
block 190: $5a14-$5a14 ($0001)
block 191: $5a1e-$5a1e ($0001)
block 192: $5a30-$5a9d ($006e)
block 193: $5aa8-$5aff ($0058)
block 194: $5b05-$5b27 ($0023)
block 195: $5b2e-$5b67 ($003a)
block 196: $5b80-$5baf ($0030)
block 197: $5bb8-$5bbf ($0008)
block 198: $5bd0-$5ced ($011e)
block 199: $5cf9-$6061 ($0369)
block 200: $6070-$6619 ($05aa)
block 201: $6622-$672f ($010e)
block 202: $6791-$6bcf ($043f)
block 203: $6c00-$6c88 ($0089)
block 204: $6ca0-$6d5b ($00bc)
block 205: $6d62-$6d62 ($0001)
block 206: $6d6b-$6d8a ($0020)
block 207: $6d90-$6dda ($004b)
block 208: $6de0-$6dfc ($001d)
block 209: $6e02-$6e02 ($0001)
block 210: $6e08-$6e23 ($001c)
block 211: $6e2a-$6e2a ($0001)
block 212: $6e33-$6e52 ($0020)
block 213: $6e58-$6ea2 ($004b)
block 214: $6ea8-$6ec4 ($001d)
block 215: $6eca-$6eca ($0001)
block 216: $6ed0-$6eeb ($001c)
block 217: $6ef2-$6f03 ($0012)
block 218: $6f0b-$6f2e ($0024)
block 219: $6f35-$6f53 ($001f)
block 220: $6f59-$6fff ($00a7)
block 221: $7010-$7017 ($0008)
block 222: $7020-$7117 ($00f8)
block 223: $711d-$711f ($0003)
block 224: $7125-$71ff ($00db)
block 225: $7208-$72af ($00a8)
block 226: $72b8-$72e0 ($0029)
block 227: $72e8-$72e8 ($0001)
block 228: $72ef-$72f0 ($0002)
block 229: $72f6-$73ff ($010a)
block 230: $7410-$7417 ($0008)
block 231: $7420-$745f ($0040)
block 232: $7468-$7481 ($001a)
block 233: $7488-$74e7 ($0060)
block 234: $7510-$7517 ($0008)
block 235: $7540-$7547 ($0008)
block 236: $7550-$7557 ($0008)
block 237: $7568-$75d7 ($0070)
block 238: $7610-$7636 ($0027)
block 239: $7640-$76a1 ($0062)
block 240: $76a8-$76e7 ($0040)
block 241: $772e-$772e ($0001)
block 242: $7778-$777f ($0008)
block 243: $7799-$779e ($0006)
block 244: $7800-$79db ($01dc)
block 245: $79e2-$79e2 ($0001)
block 246: $79eb-$7ca2 ($02b8)
block 247: $7cb2-$7cb6 ($0005)
block 248: $7ce1-$7de2 ($0102)
block 249: $7df1-$8067 ($0277)
block 250: $806d-$808f ($0023)
block 251: $809b-$80b7 ($001d)
block 252: $80c3-$80d3 ($0011)
block 253: $80eb-$811b ($0031)
block 254: $8126-$8135 ($0010)
block 255: $813b-$8142 ($0008)
block 256: $8151-$815c ($000c)
block 257: $8165-$816a ($0006)
block 258: $817b-$8184 ($000a)
block 259: $818d-$819b ($000f)
block 260: $81a3-$81ac ($000a)
block 261: $81b5-$81c3 ($000f)
block 262: $81cb-$81eb ($0021)
block 263: $81f3-$81f9 ($0007)
block 264: $81ff-$820f ($0011)
block 265: $821b-$8237 ($001d)
block 266: $8243-$825a ($0018)
block 267: $8260-$826d ($000e)
block 268: $8274-$8282 ($000f)
block 269: $8289-$82b5 ($002d)
block 270: $82bb-$82c6 ($000c)
block 271: $82cc-$82ee ($0023)
block 272: $82f5-$82fb ($0007)
block 273: $8302-$8316 ($0015)
block 274: $831d-$836f ($0053)
block 275: $8399-$83bd ($0025)
block 276: $8400-$8747 ($0348)
block 277: $8799-$87bd ($0025)
block 278: $8800-$8803 ($0004)
block 279: $880b-$880b ($0001)
block 280: $8811-$8812 ($0002)
block 281: $881a-$881a ($0001)
block 282: $8820-$882b ($000c)
block 283: $8839-$883c ($0004)
block 284: $8846-$8851 ($000c)
block 285: $8858-$8858 ($0001)
block 286: $8861-$8862 ($0002)
block 287: $886e-$8879 ($000c)
block 288: $8885-$888b ($0007)
block 289: $8894-$88a9 ($0016)
block 290: $88b1-$88b7 ($0007)
block 291: $88bd-$88be ($0002)
block 292: $88c5-$88cf ($000b)
block 293: $88d5-$88da ($0006)
block 294: $88e4-$88f8 ($0015)
block 295: $8900-$890d ($000e)
block 296: $8913-$8917 ($0005)
block 297: $8939-$893c ($0004)
block 298: $894c-$8958 ($000d)
block 299: $895e-$8968 ($000b)
block 300: $896e-$896e ($0001)
block 301: $8974-$8981 ($000e)
block 302: $8994-$89a9 ($0016)
block 303: $89b7-$89d8 ($0022)
block 304: $89de-$8b3f ($0162)
block 305: $8b48-$8bbd ($0076)
block 306: $8c00-$8f6f ($0370)
block 307: $8f99-$8fbd ($0025)
block 308: $9408-$9477 ($0070)
block 309: $9480-$94cf ($0050)
block 310: $9501-$9554 ($0054)
block 311: $955c-$957f ($0024)
block 312: $9590-$95a7 ($0018)
block 313: $95b0-$95b7 ($0008)
block 314: $95c0-$95c7 ($0008)
block 315: $9600-$9828 ($0229)
block 316: $982f-$9879 ($004b)
block 317: $987f-$98a7 ($0029)
block 318: $98ad-$98c0 ($0014)
block 319: $98ca-$98db ($0012)
block 320: $98e5-$98f7 ($0013)
block 321: $98ff-$98ff ($0001)
block 322: $990b-$990c ($0002)
block 323: $9913-$993f ($002d)
block 324: $996c-$997d ($0012)
block 325: $02e0-$02e3 ($0004) --->  RUN/INIT $3780/$3786

File 01_little_devil.new_f.xex is OK!

325 segmentów ;-) Gorzej trafić nie mogłeś :D

A to, że nie mogłeś załadować tego pliku z użyciem "WZab 2T12", też by się zgadzało. "Little Devil" próbuje ładować się dość nisko, bo od adresu $1200, a "WZab 2T12" ma MemLO ustawione na $1A63. W efekcie próba wczytania tego pliku po prostu zadeptuje sam system albo bufor, w którym znajduje się aktualnie wczytywany rekord.

Takie pliki dało się ładować systemami turbo, które lokowały się pod OS-ROM, pod warunkiem, że mimo niskiego adresu ładowania program nie korzystał z pamięci znajdującej się pod OS-ROM. Zdarzały się jednak również programy, które z tej pamięci korzystały, więc nie zawsze było to rozwiązanie uniwersalne. Wtedy ratunkiem był np. "Speedy 2700" albo "NEW FORMAT". Loader NEW FORMAT, który udostępniłem, po poprawkach ma MemLO na poziomie $08BA.

Warto przy tym pamiętać, że rozwiązania typu "*AJEK/Speedy2700" czy "NEW FORMAT" miały przede wszystkim skracać czas ładowania, ale przy okazji omijały też konieczność trzymania w pamięci dużego, około 3 KB bufora na rekord danych zapisany w klasycznym formacie Turbo 2000. Dane mogły być ładowane bezpośrednio w docelowe miejsce pamięci, więc MemLO mogło pozostać niskie, a sam loader był znacznie mniejszy niż klasyczne rozwiązanie bazujące na handlerze instalującym urządzenie "D:".

Klasyczny format nadal świetnie sprawdzał się przy programach normalnie współpracujących z DOS-em. Tam wysokie MemLO nie było problemem, bo DOS i tak zajmował sporo pamięci oraz ustawiał MemLO gdzieś w okolicach $2000. Takie programy musiały więc z założenia uwzględniać ograniczenia pamięciowe wynikające z obecności DOS-u w pamięci, czyli właśnie podwyższone MemLO.

Zupełnie inaczej wyglądała sytuacja w przypadku programów i gier, które DOS-u do działania nie wymagały. Użytkownicy stacji dysków korzystali wtedy z tzw. inicjalizerów, MicroDOS-ów albo innych małych programów ładujących, których zadanie było bardzo proste: poprawnie załadować plik binarny i zostawić po sobie jak najniższe MemLO.

Jeżeli taki program miał tylko odczytać plik ze stacji i przekazać mu sterowanie, jego kod mógł być znacznie prostszy niż pełny DOS. Nie musiał udostępniać całego systemu plików, obsługi katalogów, zapisu, kasowania plików czy innych funkcji potrzebnych w normalnej pracy z dyskietką. Dzięki temu zajmował mniej pamięci i pozwalał uruchamiać programy ładowane niżej niż byłoby to możliwe spod pełnego DOS-u.

Podobna idea stała za małymi loaderami kasetowymi: nie chodziło o stworzenie pełnego systemu operacji na plikach, tylko o możliwie proste wczytanie konkretnego programu w konkretne miejsca pamięci. Im mniej kodu rezydowało po stronie loadera, tym niższe MemLO i tym większa szansa, że program przygotowany pierwotnie z myślą o inicjalizerze albo MicroDOS-ie da się uruchomić również z taśmy.

Doprecyzuję jedną rzecz, bo faktycznie w tej całej sadze mogło to łatwo umknąć: gry "Klątwa" nie było nigdzie - ani na cartridge'u, ani tym bardziej na kasecie. Nazwa "Klątwa" wzięła się z naklejki na cartridge'u oraz z tego, że cały zestaw, czyli ten konkretny cartridge używany razem z tą konkretną kasetą, zachowywał się jak przeklęty komplet.

Problem polegał na tym, że kaseta i cartridge nie były ze sobą zgodne w praktycznym użyciu. Przy takim zestawieniu wielu pozycji z kasety nie dało się poprawnie wczytać.

W uproszczeniu wyglądało to tak:

1. Część gier była zapisana w Turbo 2000F+ NEW FORMAT i poprzedzona loaderem, który oczekiwał konkretnej wersji oprogramowania systemowego Turbo. Chodziło o wersję lokującą się pod OS-ROM, np. taką jak system MUEL, do którego linkowałem wcześniej. Loader nie był całkowicie samodzielny - korzystał z procedur obecnych w pamięci systemu Turbo i skakał pod konkretne adresy. W efekcie jakakolwiek niezgodność wersji powodowała zawieszenie loadera. Tak właśnie działo się przy próbie wczytania tych pozycji z użyciem "Klątwa Cartridge".

2. Ten loader ładował się bardzo nisko w pamięć. To dodatkowo komplikowało sprawę, bo cartridge z naklejką "Klątwa" zawierał inną wersję systemu Turbo, również lokującą się nisko w pamięci. W takim układzie loader i system z cartridge'a wchodziły sobie w drogę, a próba uruchomienia programu kończyła się zawieszeniem.

3. Niektóre pozycje były zapisane z użyciem innego loadera, który roboczo nazwałem LoMemLdr. W praktyce był to mały system Turbo ładujący się nisko w pamięć, podobnie jak oprogramowanie z cartridge'a. Te nagrania miały charakterystyczne "pyknięcia" w tonie pilotującym - ich sens opisałem szerzej w części 2.5. Przy próbie kopiowania takiego nagrania albo wczytania go z pominięciem właściwego loadera wszystko kończyło się błędem 140.

Mój główny wniosek był taki: ktoś, kto próbował używać "Klątwa Cartridge" razem z tą konkretną kasetą, najpewniej widział po prostu zestaw, z którego praktycznie nic sensownego nie dało się wczytać - zwłaszcza pozycji zapisanych w NEW FORMAT. Podejrzewam, że po wielu nieudanych próbach uznał całość za "przeklętą" i stąd właśnie wzięła się naklejka "Klątwa" na cartridge'u.

Oryginalną kasetę, która tworzyła ten komplet, zostawiłem w stanie nienaruszonym. Dorobiłem do niej tylko J-card, czyli wkładkę do pudełka. Dodatkowo przygotowałem drugą kasetę - tę widoczną wyżej - z nowym, poprawionym loaderem. Tę odklętą wersję można już bez problemu wczytywać także z użyciem "Klątwa Cartridge".

Podsumowując: gdyby do oryginalnej kasety dobrać inny cartridge, np. taki z systemem MUEL, żadnej "klątwy" najpewniej by nie było, bo większość pozycji dałoby się wczytać normalnie. Działałyby również programy z loaderem LoMemLdr i z tymi charakterystycznymi "pyknięciami" w tonie pilotującym, bo w przypadku kombinacji LoMemLdr oraz systemu MUEL takie "pyknięcia" były wręcz wymagane.

Jeżeli jednak użyło się innej wersji oprogramowania systemowego niż MUEL, te same "pyknięcia" przestawały być obejściem problemu, a zaczynały same ten problem powodować - skutecznie uniemożliwiając poprawne wczytanie.

Natomiast przy użyciu innej wersji oprogramowania systemowego - takiej jak ta z "Klątwa Cartridge" - pozycje poprzedzone loaderem LoMemLdr, czyli Silent Service, Fantastic Soccer i World Soccer, również nie miały realnych szans na poprawne wczytanie.

Czyli "Klątwa" nie była nazwą gry. Była raczej nazwą bardzo konkretnego, pechowego zestawu: cartridge'a i kasety, które osobno mogły mieć sens, ale razem tworzyły piękny generator frustracji.

A przynajmniej taka jest moja spekulacja po rozebraniu tego przypadku na części pierwsze. Prawda może być oczywiście znacznie bardziej banalna: ktoś znalazł naklejkę "Klątwa" i po prostu przykleił ją na cartridge. Być może nikt wcześniej nie próbował wczytywać tej konkretnej kasety z użyciem tego konkretnego cartridge'a. Całkiem możliwe, że "Klątwa" dotknęła dopiero mnie, gdy podążyłem tą przeklętą ścieżką, próbując znaleźć sens i logikę tam, gdzie być może nigdy ich nie było ;-)

Nie oszukuję się: te moje posty były dość ciężkie w odbiorze. Zawierały sporo niskopoziomowych szczegółów technicznych, które większości "normalnych" ludzi pewnie nie interesują. Mimo to dzięki tej przygodzie udało się zdeasemblować loader do NEW FORMAT, zrozumieć jego działanie, trochę go poprawić i napisać prosty konwerter generujący pliki w tym formacie.

Być może ktoś kiedyś z tego skorzysta, bawiąc się taśmami i starymi systemami Turbo. Dla mnie samego była to ciekawa przygoda, choć wciągnęła mnie znacznie bardziej, niż powinna. Trochę jak chodzenie po bagnach: człowiek wie, że nie powinien iść dalej, ale z jakiegoś powodu robi jeszcze jeden krok, potem następny, a potem okazuje się, że stoi po kolana w mule i rysuje mapę dla kolejnych śmiałków.

Czy ja dobrze rozumiem, że mimo naklejki "KLĄTWA" na kartridżu, gry "Klątwa" nie ma ani na carcie, ani na kasecie? Nie wiemy co naklejający miał na myśli? ... Czy coś przegapiłem?

Oczywiście nie wiemy czy kaseta nie była dołączona do magnetofonu przypadkowo gdy kupiłem zestaw lata temu.

Nowy format, nowy loader, ta sama klątwa

W poprzednich częściach opisałem, co udało się znaleźć na oryginalnej kasecie, z czym był problem i dlaczego część programów okazała się bardziej podstępna, niż początkowo zakładałem. Tym razem pora na praktyczne domknięcie tematu: wszystkie odzyskane pozycje przygotowałem ponownie w formacie Turbo 2000F+ NEW FORMAT, z nowym loaderem, który nie powinien już zależeć od konkretnej wersji systemu Turbo 2000F.

Innymi słowy: to nadal ta sama "Klątwa Tape", ale przepisana do postaci, którą łatwiej uruchomić, zachować, nagrać ponownie i wykorzystać jako punkt wyjścia do własnych eksperymentów.

Pliki do pobrania

Poniżej znajdują się pliki przygotowane w nowej wersji. Zawartość odpowiada temu, co udało się odzyskać z oryginalnej kasety, ale została skonwertowana do formatu Turbo 2000F+ NEW FORMAT i opatrzona nowym, poprawionym loaderem: The UnCursed Tape

W archiwum znajdują się trzy katalogi: cas/, hex/ oraz xex/.

• Katalogi cas/ i hex/ zawierają obrazy plików, które można wczytać za pomocą emulatora albo skonwertować do postaci WAV, np. za pomocą TURGEN, a następnie nagrać na taśmę i wczytać na prawdziwym sprzęcie.

• Katalog xex/ zawiera pliki XEX odtworzone z oryginalnych nagrań, nieco uporządkowane, wygładzone i naprawione tam, gdzie było to konieczne.

Skąd się wzięły te pliki?

Część 2.5 była jeszcze "dopiskiem śledczym" - wyjaśnieniem, dlaczego niektóre programy z dołączonym loaderem "LoMemLdr" zachowywały się inaczej, niż się spodziewałem. Część III jest już bardziej użytkowa: zawiera gotowe pliki oraz wskazówki, jak samodzielnie produkować podobne zestawy.

Żeby nie robić tego ręcznie za każdym razem i nie powtarzać tej samej gimnastyki przy kolejnych zestawach, uzupełniłem moje stare repozytorium T2K_TOOLS z narzędziami do obsługi formatu Turbo 2000 o dodatkowe narzędzie: t2k_new_format.py. Do kompletu dodałem poprawiony loader dla tego formatu. Repozytorium można znaleźć tutaj: T2K Tools

Opisy, czyli pliki README.md, są w języku polskim. Wydaje mi się, że są na tyle szczegółowe, że każdy zainteresowany będzie mógł samodzielnie przygotować własne zestawy kaset w formacie NEW FORMAT.

Być może Baktra, jeżeli będzie miał chęci, czas i możliwości, doda obsługę formatu NEW FORMAT do TURGEN-a. Źródła loadera są udostępnione w repozytorium, więc można z nich korzystać do woli. Wtedy będzie jeszcze łatwiej. Na razie, aby skorzystać z narzędzia, potrzebny jest Python 3 oraz umiejętność korzystania z wiersza poleceń - pod Linuksem albo Windowsem, wedle preferencji.

Jeżeli coś w dokumentacji byłoby niejasne lub niezrozumiałe, dawajcie znać. Spędziłem już nad tym tyle czasu, że nie bardzo widzę ewentualne wady, bo wszystko wydaje mi się oczywiste, ale wcale nie musi być równie oczywiste dla innych.

Kilka słów o loaderze

Osobnym elementem tej układanki był loader do formatu Turbo 2000F+ NEW FORMAT. Zamiast traktować go jak czarną skrzynkę, przeanalizowałem go przy użyciu DIS6502, po czym opisałem i uporządkowałem jego działanie. Chodziło głównie o zrozumienie, w jaki sposób loader odnajduje kolejne bloki, jak przekazuje sterowanie do wczytanego programu i dlaczego jego oryginalna wersja była tak mocno związana z konkretnym środowiskiem systemu Turbo.

Najwięcej pracy zajęło nie samo przepisanie kodu, lecz dojście do tego, co autor pierwotnego loadera miał na myśli, oraz opisanie tego w taki sposób, aby po kilku miesiącach dało się do tych źródeł wrócić bez ponownego rozwiązywania tej samej zagadki. Udało się także zoptymalizować loader i dodać obsługę innych interfejsów turbo. Wyrzuciłem również zbędne oraz błędne fragmenty kodu.

Efektem końcowym jest wersja loadera, której użyłem przy przygotowaniu "The UnCursed Turbo 2000F Tape". Nie jest to nowy system Turbo ani próba napisania wszystkiego od zera, tylko uporządkowana i lekko poprawiona wersja istniejącego rozwiązania, przygotowana tak, aby zachowała zgodność z większością poprawnych plików XEX oraz większością wersji oprogramowania systemowego dla Turbo 2000F/2001/KSO.

Zamknięcie sagi

Tym wpisem zamykam sagę "Klątwa Tape". Przynajmniej mam taką nadzieję ;-)

Jak zwykle w takich przypadkach, mocno niedoszacowałem czasu potrzebnego na doprowadzenie tematu do końca. Na początku wyglądało to jak prosta historia: jest jedna stara kaseta, trzeba ją zgrać, sprawdzić, co na niej siedzi, i ewentualnie uratować to, co jeszcze da się uratować.

W praktyce wyszedł z tego mały projekt badawczo-archeologiczny: odzysk nagrań, analiza formatu, poprawki uszkodzonych plików, deasemblacja loadera, pisanie i porządkowanie jego źródeł, przygotowanie konwertera, generowanie nowych plików, tworzenie repozytorium, dokumentacji oraz finalnej, "odklętej" wersji kasety.

Nie piszę tego, żeby narzekać, lecz raczej jako uczciwy opis skali zjawiska. W świecie retro bardzo często okazuje się, że "tylko jedna kaseta" albo "tylko jeden mały loader" potrafią rozrosnąć się do kilku tygodni pracy z przerwami: śledztwa, kodowania, testów, dokumentowania i ciągłego sprawdzania, czy przypadkiem pod spodem nie kryje się jeszcze jedna warstwa problemu. Taki już urok grzebania w rzeczach sprzed kilku dekad.

Najważniejsze jednak, że tym razem historia kończy się dobrze: zawartość kasety została odzyskana, uporządkowana, opisana i przygotowana w formie, z której można dalej korzystać. Klątwa została, mam nadzieję, skutecznie "odklęta", a zawartość nagrana na nowym nośniku, tak aby stara kaseta pozostała nienaruszona, w takim stanie, w jakim ją zastałem.

nie miałem kontaktu z tym 'new format'

Przypadkiem (ze środowiska Amigowców :-) ) trafiła mi się instrukcja Turbo 2000F w której jest wzmianka o kasecie systemowej z kopierami, m.in. NEWCOPY. Nie wiem czy ma to związek z 'new format".
Na instrukcji jest data "wykonania usługi", czyli zapewne montażu turbo, z 23.09.92.

@seban, pełną instrukcję i dwie inne, masz udostępnione na moim Drive. Zajrzyj, czy coś nieznanego.

Zatem wychodzi na to że ktoś to przygotował tę kasetę i nagrywał jej zawartość musiał mieć własnie tę wersję systemu i rozwiązał problem przed dodanie "śmieci" w pilocie. W sumie to nie rozumiem czemu tych gier nie zapisano po prostu w "new format", ten loader załadowałby te gry bez problemu.

No to jednak będzie mała aktualizacja i korekta tego, co pisałem wcześniej. Nie dawały mi spokoju te "pyknięcia" w tonach pilotujących. Przyjrzałem się im bliżej i okazało się, że są zbyt regularne, zbyt powtarzalne. Początkowo zakładałem, że taka była uroda magnetofonu, na którym dokonano zapisu, jednak dokładniejsza analiza tych miejsc wykazała, że owe "pyknięcia" nie powstały przez przypadek. To, co wcześniej przedstawiłem jako przykład, czyli fragment tonu synchronizującego przerwanego jakimś "trzaskiem", okazało się celowym zabiegiem. Dla przypomnienia wrzucę to jeszcze raz:

pwmc 00151 46 584 12 1 23 1 46 3463 ; count=4

To, co opisałem jako "potknięcia" a8cas-util, okazało się finalnie moim "potknięciem" i nadinterpretacją faktów. Z mojego wcześniejszego opisu wynikało, że widoczny tam fragment powinien być jednostajnym tonem synchronizującym, przerwanym jakimś "śmieciem". Okazało się jednak, że była to błędna interpretacja całej sytuacji. Po sprawdzeniu kilku plików zobaczyłem, że wszędzie wygląda to tak samo, czyli w rzeczywistości ta sekwencja składała się z:

• początkowej serii impulsów pilota

• impulsu reprezentującego "0"

• impulsu reprezentującego "1"

• końcowej serii impulsów pilota

Początkowo wszystkie testy robiłem w emulatorze i w wersji systemu Turbo 2000F, który wykładał się na tych "śmieciach" w środku pilota. Uznałem więc, jak wspominałem wyżej, że jest to niedoskonałość urządzenia zapisującego. Poprawiłem wszystkie te "uszkodzone" miejsca i uznałem sprawę za rozwiązaną, ponieważ wszystko zaczęło wczytywać się poprawnie. Przetestowałem zarówno pliki w formacie "new", jak i te nagrane w starym formacie, również te z dodanym loaderem, który tak naprawdę był wersją systemu turbo lokującą się w dolnej przestrzeni pamięci - nazwijmy go LoMem_Ldr.

Wszystko wydawało się działać idealnie, aż do momentu, gdy zacząłem ponownie sprawdzać całość podczas pisania drugiej części tej "przeklętej" sagi. Robiąc porządki w tekście i chcąc dodać linki do wszystkich istotnych materiałów, dorzuciłem także odnośnik do oryginalnej wersji Turbo 2000F sygnowanej przez MUEL, czyli tej lokującej się pod OS-ROM.

Post opublikowałem na forum, po czym coś mnie tknęło i zacząłem testować wszystko ponownie, tym razem wykorzystując już pliki ściągnięte bezpośrednio z mojego posta.

Jakież było moje zdziwienie, gdy zobaczyłem, że Silent Service, Fantastic Soccer i World Soccer nie wczytują się poprawnie. Loader najwyraźniej nie "załapywał" nazwy programu nagranego za nim, przez co reszta bloków nie była ładowana wcale. "Loader" nadal oczekiwał na blok zawierający nazwę wczytywanego programu.

Na szybko spróbowałem wczytać pliki .hex niezawierające moich "normalizacji" i "korekt". Te ładowały się bez problemu, mimo że zawierały owe "pyknięcia"! Po odkryciu tego faktu zorientowałem się, że te "pyknięcia" w tonie synchronizującym są konieczne, aby "LowMem_Ldr" był w stanie poprawnie zinterpretować nazwę nagranego za nim programu.

Po odkryciu tego faktu postanowiłem wyjaśnić sprawę do końca. Początkowo szybko zaktualizowałem problematyczne pliki hex/cas w archiwum, dodając im sekwencję dwóch bitów "0" i "1" występujących w trakcie trwania pilota, a potem zacząłem grzebać, aby dociec, o co właściwie chodzi. Jeżeli to czytacie, to znaczy, że udało mi się dojść do tego, co tak naprawdę tam się działo ;-)

Zacząć musimy od analizy samego loadera. Będę się starał opisać to w miarę prosto, jednak będzie niestety trochę asemblera, trochę opisu struktury plików i trochę działania loadera plików binarnych Atari DOS (.XEX).

Zatem popatrzmy, jak wygląda struktura bloków samego loadera (LoMem_Ldr):

chkxex t2kf_lomem_ldr.xex 

Input file is t2kf_lomem_ldr.xex and the file size is 1797 bytes.

Header is: $ffff
block 001: $1700-$1df6 ($06f7)
block 002: $02e0-$02e3 ($0004) --->  RUN/INIT $1d9d/$1d9d

File t2kf_lomem_ldr.xex is OK!

^^^ Na pierwszy rzut oka nie widać tutaj niczego niepokojącego. Owszem, plik ładuje się dość nisko, ale w przypadku nadrzędnego systemu, z którego jest ładowany, nie ma to znaczenia, bo mamy MemLo na poziomie $0800. Ładowanie od adresu $1700 w niczym nie przeszkadza. Nietypowa wydaje się jednak sekwencja RUN/INIT, czyli jednoczesne ustawienie wektorów RUN i INIT na ten sam adres startu.

Niby czemu miałoby to przeszkadzać? Po prostu program zostanie uruchomiony przez INIT, a nie przez RUN, więc teoretycznie nie powinno to mieć żadnego znaczenia. Okazuje się jednak, że w tym wypadku ma to znaczenie - ale o tym będę mógł opowiedzieć za chwilę, gdy wyjaśnię, jak działa loader plików .XEX/.COM/.EXE w takim systemie jak Turbo 2000F/KSO.

System turbo instaluje w systemie sterownik urządzenia. W tym wypadku jest to urządzenie "D:", aby zachować "zgodność" z programami, które odwołują się do "D:" tak, jak do stacji dysków. W systemie znajduje się więc sterownik, do którego można się odwołać przez CIO. Działają więc wszystkie operacje typu OPEN, CLOSE, GET, PUT. Loader plików binarnych zawarty w oprogramowaniu turbo bazuje właśnie na odwołaniach do urządzenia "D:" przez CIO, a więc używa funkcji OPEN, GET, CLOSE itd.

Przebieg ładowania pliku .XEX przez taki loader wygląda mniej więcej tak:

open_file(filename);

while_not_eof
{
   get_block_header();
   load_block();
   init_segment();
}

close_file();
jmp_to_run_vector();

Czyli loader otwiera urządzenie "D:" do odczytu funkcją OPEN i próbuje odnaleźć blok danych z nazwą pliku. Gdy mu się to uda, rozpoczyna ładowanie bloków danych. W kolejnych krokach loader odczytuje bajty nagłówka pliku, oblicza długość bloku i zaczyna ładować poszczególne bloki w odpowiednie miejsca pamięci. Po załadowaniu każdego bloku sprawdzane jest, czy blok nie był segmentem typu INIT. Jeżeli wektor INITAD ($2e2-$2e3) zawiera wartość niezerową, wykonywany jest skok pod adres, na który INITAD wskazuje. Wszystko dzieje się w pętli aż do napotkania końca pliku, czyli ładowane są kolejne bloki danych. Gdy osiągnięty zostanie koniec pliku, wykonywany jest skok pod adres określony przez RUNAD ($2e0-$2e1). Jeżeli wektor RUNAD nie został ustawiony w pliku, następuje skok pod adres pierwszego z ładowanych segmentów.

Pewnie znowu zastanawiacie się, z jakiego powodu zanudzam was takimi szczegółami technicznymi. Niestety jest to konieczne do zrozumienia mechanizmu, który za chwilę zacznę opisywać. Będzie to opis tego, co właściwie zaczyna się dziać po załadowaniu segmentu danych ($2e0-$2e3), czyli segmentu, który jednocześnie ustawia wektory INIT i RUN.

Przyjrzyjmy się zatem temu, co dzieje się, gdy loader plików zawarty w systemie 2000F (MUEL) skoczy pod adres $1d9d wskazywany przez wektor INITAD ($2e2-$2e3):

; kasujemy poprzedni wpis dla urządzenia "D:" w HATABS
; (na ślepo, zakładamy że on tam jest, )
; (i że jest dokładnie w tym miejscu, tzn. pod adresem HATABS+$0F)

    1D9D: A2 02             LDX #$02
    1D9F: A9 00             LDA #$00
    1DA1: 9D 29 03          STA HATABS+$0F,X
    1DA4: CA                DEX
    1DA5: 10 FA             BPL $1DA1
    
; przygotowujemy się do przepisania załadowanego kodu
; z lokacji $1700 do lokacji  $0700
    1DA7: A9 17             LDA #$17
    1DA9: 85 31             STA $31
    1DAB: A9 07             LDA #$07
    1DAD: 85 33             STA $33
    1DAF: A9 00             LDA #$00
    1DB1: 85 30             STA $30
    1DB3: 85 32             STA $32

; pętla kopiujące dane
    1DB5: A2 0E             LDX #$0E
    1DB7: B1 30             LDA ($30),Y
    1DB9: 91 32             STA ($32),Y
    1DBB: C8                INY
    1DBC: D0 F9             BNE $1DB7
    1DBE: E6 31             INC $31
    1DC0: E6 33             INC $33
    1DC2: E4 33             CPX $33
    1DC4: D0 F1             BNE $1DB7

; ustawiamy wektory     
    1DC6: A9 C2             LDA #$C2
    1DC8: 85 02             STA CASINI
    1DCA: 85 0C             STA DOSINI
    1DCC: A9 08             LDA #$08
    1DCE: 85 03             STA CASINI+1
    1DD0: 85 0D             STA DOSINI+1
    
; skok do procedury instalującej handler "D:"
    
    1DD2: 20 C2 08          JSR $08C2

; inicjalizacja wskaźnika stosu, etc.
    1DD5: A2 FF             LDX #$FF
    1DD7: 9A                TXS
    1DD8: A9 01             LDA #$01
    1DDA: 85 09             STA $09

; bezpośredni skok do procedury "screen open" w OS-ROM
    1DDC: A9 00             LDA #$00
    1DDE: 85 2B             STA ICAX2Z
    1DE0: A9 0C             LDA #$0C
    1DE2: 85 2A             STA ICAX1Z
    1DE4: 20 8E EF          JSR $EF8E

; zamykamy kanał IOCB#1 (używając CIO)
; (poprzednio otwarty przez stary handler "D:")
;
; !!! UWAGA! (w tej chwili wpisy w HATABS wskazują już na nowy handler!)
; !!! UWAGA! (to jest piękny przepis na katastrofę!                    )
;
    1DE7: A2 10             LDX #$10
    1DE9: A9 0C             LDA #$0C
    1DEB: 9D 42 03          STA ICCMD,X
    1DEE: 20 56 E4          JSR CIOV

; ustaw flagę oznaczającą "LOAD & RUN"
    1DF1: 38                SEC
    1DF2: 66 48             ROR $48
    
; skocz do procedury ładującej plik binarny (.XEX)
; (mówimy o świeżo załadowanej wersji systemu)
    1DF4: 4C FE 08          JMP $08FE

Teraz, mając już całość jak na talerzu, mogę spróbować wyjaśnić, dlaczego programy nagrane za tym loaderem miały w trakcie tonu pilotującego wrzucone dwa dodatkowe bity danych (0,1), które traktowałem jako przypadkowe śmieci. Istotne okazały się dwie rzeczy. Po pierwsze, ten "loader" jest uruchamiany tak naprawdę przez wektor INITAD ($2e2-$2e3). Po drugie, w procedurze startu tego loadera znajduje się sekwencja zamknięcia kanału IOCB#1, czyli kanału otwartego wcześniej przez poprzedni loader jako kanał do odczytu danych. Tak się ciekawie składa, że w chwili, gdy ten kod zostaje uruchomiony przez wektor INITAD, kanał jest cały czas otwarty.

Teoretycznie, gdyby uruchomić ten kod przez wektor RUNAD ($2e0-$2e1), nadrzędny loader zamknąłby kanał IOCB#1 przed uruchomieniem wczytanego programu, a ponowne otwarcie kanału IOCB#1 przez nowy loader odbyłoby się bez problemów.

W tym wypadku dzieje się jednak inaczej. Bez wchodzenia jeszcze głębiej w szczegóły: wywołanie polecenia CLOSE dla IOCB#1 powoduje błędną reakcję procedury obsługującej CLOSE. Dlaczego? Ponieważ kanał IOCB#1 był otwarty przez poprzednią wersję handlera, czyli tę rezydującą pod OS-ROM, a tutaj program podmienia wpisy w HATABS w locie i instaluje swój nowy handler. W efekcie CLOSE #1 powoduje wywołanie procedury CLOSE już z nowego handlera! Wszystkie komórki dotyczące statusu kanału są ustawione przez inny handler, a nagle odpalany jest CLOSE tak naprawdę z innej wersji systemu. Normalnie powinno dojść do sytuacji, w której kanał zostaje zamknięty. Tutaj natomiast wywołanie CLOSE powoduje, że handler próbuje wczytać następny blok danych zamiast zakończyć odczyt.

I to właśnie jest problemem, bo przy standardowym formacie danych następny blok jest blokiem zawierającym nazwę pliku. Wywołanie CLOSE odczytuje więc ten blok, a następny "czysty" OPEN, wykonywany już przez właściwy loader, nie znajduje bloku nazwy. Wczytywanie programu tak naprawdę nigdy się nie zaczyna.

Ktoś wpadł na pomysł, aby dodać te dwa bity w trakcie pilota - bity, na których procedura odczytu bloku wywołana przez CLOSE się wysypie. Status błędu CLOSE nie jest sprawdzany, więc niczym to nie grozi. Dzięki temu następny OPEN poprawnie odczyta nazwę i loader zadziała prawidłowo.

Co ciekawe, rozwiązaniem tego problemu było tak naprawdę uruchamianie tego loadera przez wektor RUNAD. Wtedy, jak wspominałem, loader zawarty w MUEL przed wywołaniem kodu loadera po prostu zamykałby kanał IOCB#1, a ponowne wywołanie CLOSE przez nowy loader na zamkniętym kanale nie generowałoby już skutków ubocznych.

Warto jednak zaznaczyć, że efekt opisany wyżej występuje tylko w przypadku oprogramowania MUEL, które dołączałem do poprzedniego odcinka sagi o klątwie.

Zaczynam zastanawiać się, czy było to działanie celowe. Czy była to jakaś dziwna forma zabezpieczenia "z epoki", powodująca, że wszystko poprawnie działało tylko z cartridge'em od MUEL? A może był to efekt uboczny kombinowania przez kogoś już w czasach nowożytnych, zaś "pyknięcia" wstawione w pilota były obejściem problemu, które zadziałało trochę "przez przypadek"?

Mogę jedynie gdybać i snuć domysły. Nie mam jednak żadnej pewności, że te przypuszczenia są trafione. Coraz bardziej skłaniam się jednak do teorii, że kaseta i zapis na niej nie są tak stare, jak początkowo przypuszczałem.

Aby nie tworzyć kolejnych problemów, postanowiłem poprawić strukturę pliku loadera i usunąć "pyknięcia" z pilotów. Dodaję więc nową wersję plików w archiwum (v1.2).

Poprawka loadera (LoMem_Ldr) polega, tak jak wspominałem, na zamianie ostatniego segmentu danych z $2e0-$2e3 na zwykły segment RUNAD ($2e0-$2e1). Tak zmodyfikowany loader działa poprawnie z kilkoma wersjami softu Turbo 2000F, które miałem pod ręką.

Heh, no i zamiast odcinka III sagi wyszedł odcinek 2.5. Zatem przyjdzie wam jeszcze chwilę poczekać na obiecaną część III - trzecią i ostatnią :P Zaktualizowane archiwum znajduje się w poście z opisem części II.

@Seban - nie próbowałeś ratować karty E-mu stawiając siódemkę na maszynie wirtualnej?

Ja nadal mam ten stary komputer w którym siedzi E-MU 1212M, mam na nim multi-boot, więc mogę uruchomić "Windows 7", mam tam trochę archaicznego softu do wiekowych CPLD/FPGA, czy innych archaicznych sprzętów, więc trzymam ten system, tyle że niezbyt często uruchamiam już tego Windows 7, ale karta nadal działa. Co prawda Linux już ma sterownik pod dla chipa EMU-10K1, ale w przypadku EMU-1212M działa tylko podstawowa funkcjonalność (play/rec) nie ma rozbudowanego mixera czy też pluginów dla DSP.

Dobry tekst. Ładnie opowiedziana historia pewnego badania :)

tOri

@Seban - nie próbowałeś ratować karty E-mu stawiając siódemkę na maszynie wirtualnej?