Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1:
      
     CommentAuthorxeen
   • CommentTime9 Jul 2009 13:07

    
   Witam,
   czy istnieje (ktoś widział, ktoś zrobił) gotowa procedura w basicu, która
   wczyta zestaw fontów wygenerowanych w fontmaker z dyskietki do pamięci (podmieni zestaw cczcionek od razu)?
   Czy też niestety ewentualnie będę musiał sobie sam napisać?
   
   Oczywiście może też być procedura w języku maszynowym, ale do użycia w basicu
   
   dzięki
2. • 2:
      
     CommentAuthorlarek
   • CommentTime9 Jul 2009 13:07 zmieniony

    
   ->link<-
   SupGen2000 2.00 potrafi wygenerować podprogram w Basicu z nowym zestawem i to w dwóch wariantach - 1. linie data, 2. zmienne. Dokładny opis, jak to zrobic, jest na dyskietce z programem w pliku PORADNIK.SG2, który można uruchomić z poziomu DOSa.
   
   Domyślam się, że masz normalny zbiór fontów (1KB danych). Taki plik SupGen odczyta bez problemu i wtedy możesz wygenerować gotową prockę w Basicu i zapisać ją na dyskietce.
3. • 3:
      
     CommentAuthorxeen
   • CommentTime9 Jul 2009 13:07

    
   ok, dzięki
   spróbuję wykorzystać generowanie lini danych, jednak może mi zabraknąć miejsca na wiele zestawów
   
   zależy mi na tym, aby zestaw fontów z pliku podmieniać w czasie rzeczywistm w pamięci za pomocą procedury
   tzn. na dyskietce zestawów będzie dużo, w zależności od sytuacji ja wczytuje innym zestaw co zaowocuje zmianą wyświetlania.
   nie wiem czy nie przeginam i to lamerstwo, ucze się :)
4. • 4:
      
     CommentAuthorKaz
   • CommentTime9 Jul 2009 14:07

    
   Byly jakies procedury w pisemkach Atari, ale teraz nie pamietam w ktorych (Bajtek? Atari Magazyn?), moge sprobowac poszukac wieczorem.
5. • 5:
      
     CommentAuthorlarek
   • CommentTime9 Jul 2009 14:07

    
   A to przepraszam. Nie zrozumiałem pytania ;-)
   Jeśli masz już w pamięci zdefiniowany zestaw znaków, a program go widzi i używa, to w Basicu może wyglądać to tak:
   
   

   100 OPEN #1,4,0,"D:ZESTAW1.FNT"
   110 FOR Q=ZESTAW TO ZESTAW+1023
   120 GET #1,BAJT : POKE Q,BAJT
   130 NEXT Q
   140 CLOSE #1
   

   
   
   gdzie ZESTAW1.FNT to nazwa pliku z fontami
   ZESTAW - zmienna z początkiem pamięci dla fontów
   Q, BAJT - zmienne pomocnicze
   
   Program odczyta zestaw i wrzuci w obszar fontów.
   
   W Turbo-Basic XL może być prościej:
   
   

   100 OPEN #1,4,0,"D:ZESTAW1.FNT"
   120 BGET #1,ZESTAW,1024
   130 CLOSE #1
   

   
   
   lub gdy plik z zestawem ma nagłówek dosowy (SupGen 2000 2.00 potrafi dołaczyć taki nagłówek):
   
   

   100 BLOAD "D:NAZWA1.FNT"
   

   
   
   Jeżeli program nie widzi nowego zetawu, to piszesz POKE 756,strona
   strona - początek obszaru pamięci, którą przeznaczasz na fonty / 256, np. jeśli fonty mają być w pamięci od adresu 38912, to 38912/256 = 152, czyli POKE 756,152
   Pamięć dla fontów musi zaczynać się od pełnej strony, czyli jest to wielokrotność 256. Obszar ten też nie może być całkiem dowolny, ale to już inna historia.
   
   Być może to wiesz, ale napisałem na wszelki wypadek :)
   Może komuś innemu się przyda.
6. • 6:
      
     CommentAuthorxeen
   • CommentTime9 Jul 2009 14:07

    
   dzięki,
   ja jeszcze generalnie to mało wiem
   ale powoli, powoli :)))
   
   generalnie to na razie jestem na etapie Miguta,
   i mam czasem problem pod emulatorem - niby wszytsko jest w ramie, ale fonty to albo krazKi albo nic (przepisałem program z książki toczka w toczkę)
   
   reset + run i działa, po tem znowu itp. niw eim od czego to zależy
   
   dzisiaj sobie poeksperymentuję...
7. • 7:
      
     CommentAuthorxeen
   • CommentTime3 Sep 2009 20:09

    
   mam kolejne pytanie z cyklu newbe
   może mi ktoś pomoże
   mam taki oto prosty programik zgodny z zaleceniem powyżej
   
   0 GRAPHICS 0
   10 POKE 106,PEEK(106)-10
   20 APZ=(PEEK(106)+6)*256
   30 OPEN #1,4,0,"D:FFF.FNT"
   40 BGET #1,APZ,1024
   50 CLOSE #1
   
   niby rezerwuję pamięć, wykorzystuję jej tylko w części, a przy każdym uruchomieniu pojawia się kaszana na ekranie, chyba że zaraz po znowu wywołam instrukcję graphics (jest tylko taki "mignięcie".
   z czego to wynika?
8. • 8:
      
     CommentAuthormiker
   • CommentTime3 Sep 2009 22:09

    
   Ja bym to zrobił tak:
   0 IF PEEK(760)=1 THEN 60
   10 POKE 106,PEEK(106)-10:POKE 760,1
   20 APZ=(PEEK(106)+6)*256
   30 OPEN #1,4,0,"D:FFF.FNT"
   40 BGET #1,APZ,1024
   50 CLOSE #1
   60 GRAPHICS 0:POKE 756,APZ
   
   W ten sposób obniżysz RAMTOP jak zechcesz i nie będziesz go znów kisić kolejnym obniżaniem (stąd zapewne ta kaszanka). Aha, komórka 760 nie jest używana przez system i można spokojnie jej użyć jako wskaźnika, że "coś się stało". No i zapomniałes ustawić "połka" na fonty.
   Nie wiem, czy dobrze wytłumaczyłem, ale przykład powinien działać (w razie czego zmień 760 np. na 1791). Pozdro!
9. • 9:
      
     CommentAuthorxeen
   • CommentTime3 Sep 2009 22:09 zmieniony

    
   dzięki za podpowiedzi
   fonty generalnie działają bez problemu - wkleiłem tylko cześć programu
   ale nie rozumiałem dokładnie dlaczego jest taka kaszana na początku - z czego ona wynika
   domyślam się z Twojej odpowiedzi że raczej wynika to z tego że wielokrotnym wywoływaniem obniżałem ramtop raz po razie coraz bardziej i w końcu na coś tam trafiałem ?
10. • 10:
       
      CommentAuthormiker
    • CommentTime3 Sep 2009 23:09

     
    No na to wygląda. Poza tym dobrze jest jednak wpisać w komórkę 106 wartość już konkretną, najlepiej w systemie szesnastkowym, widać wtedy przed którą stroną pamięci będzie się kończyć ekran i odkąd można umieszczać dane. Np. jak w powyższym przykładzie: POKE 106,$B6:....:BGET #1,$B600,$A00 (wczytanie $A00 bajtów w adresy $B600-$BFFF). Ale - jak kto woli (dla mnie np. system szesnastkowy, czy jak kto woli, heksadecymalny, jest nie do przecenienia).
11. • 11:
       
      CommentAuthorlarek
    • CommentTime3 Sep 2009 23:09 zmieniony

     

    xeen:

    niby rezerwuję pamięć, wykorzystuję jej tylko w części, a przy każdym uruchomieniu pojawia się kaszana na ekranie, chyba że zaraz po znowu wywołam instrukcję graphics (jest tylko taki "mignięcie".
    z czego to wynika?

    
    System po zainicjowaniu umieszcza w RAM pamięć obrazu. Obszar ten nie jest ustalony na stałe, jak np. w ZX Spectrum, ale przydzielany w zależności od np. wybranego trybu graficznego (i nie tylko). Uruchamiając TBXL czy inny Basic system wylicza sobie odpowiednie miejsce w pamięci, które zawsze wypada tuż przed jej końcem i odpowiednio ustawia obszar pamięci obrazu. Obniżając RAMTOP zmniejszasz jednocześnie ilość wolnej pamięci, a tym samym obszar pamięci obrazu również powinnien zmienić miejsce (obniżyć się), więc po dokonaniu POKE 106,xxx należy wykonać GRAPHICS q. System wtedy wyliczy sobie i ustawi nowy, poprawny obszar pamięci obrazu. Jeżeli przeszkadza Ci to mrugnięcie, to wyłącz ekran przed zmianami i włącz dopiero po wszystkich opeacjach z ekranem - POKE 559,0 wyłącza, POKE 559,34 włącza (wartość 34 jest odpowiednia do standardowej szerokości ekranu i bez włączonych duszków). Należy również pamiętac o tym, że pamięć obrazu nie może leżeć po obu stronach granicy bloku 4 KB RAM, więc powinniśmy obniżać RAMTOP o odpowiednią liczbę stron. W zależności od użytego trybu powinna to być (tak w skrócie) wielokrotność 1KB, 4KB lub 8KB, czyli 4, 16, 32 strony (lub odpowiednio więcej). Jeśli po "POKE 106,x: GRAPHICS y" jest sieczka na ekranie, to zmień "x" zgodnie z powyższym. Tryb GR.0 jest mało wymagający, ale jak "niezbyt równo" przytniesz RAMTOP, to i on potrafi wyświetlać śmieci.
12. • 12:
       
      CommentAuthorxeen
    • CommentTime4 Sep 2009 09:09

     
    dzięki Panowie, teraz rozumiem
    w Migucie mętenie to opisano (dla mnie)
13. • 13: CommentAuthorMaciek
    • CommentTime9 Sep 2009 14:09 zmieniony

     
    Chciałbym pociągnąć wątek obszaru zarezerwowanego na obraz jeśli można (nawiasem mówiąc też jestem na etapie Miguta - ta pozycja pozwoliła mi odświeżyć to co zapomniałem przez lata i dobrnąć do etapu na którym zakończyłem kiedyś zabawę z Atari, zabrałem tę książkę ze sobą idąc do szpitala, teraz mam 2 tygodnie L4 i sprawdzam wszystko w praktyce).
    
    Otóż, Migut w którymś miejscu zmieniał pojedyncze bajty w obszarze pamięci obrazu co pozwalało na wyświetlanie liter na ekranie. Z tego co pamiętam robił to na obszarze któregoś trybu tekstowego(zdaje się że GR.2) i wszystko było cacy tylko, że wzór na to który bajt wybrać i jaką wartość wstawić był bardzo prosty ponieważ był to tryb tekstowy. Robiłem parę eksperymentów i nigdy nie dostałem pożądanego rezultatu na trybach graficznych. Zakładam, że najprościej byłoby zmieniać obraz przez zmiany na bajtach w GR.8, gdzie jak mniemam przyjmują one wartości 1 lub 0. Jaki byłby wzór na wskazanie bajtu odpowiedzialnego za pixel o współrzędnych 40,50 jeśli za pierwszy bajt obszaru obrazu przyjęlibyśmy EKR?
14. • 14: CommentAuthormono
    • CommentTime9 Sep 2009 15:09 zmieniony

     
    ADDR=PEEK(88)+256*PEEK(89)+x/8+y*WIDTH
    

    
    czy jak wolisz:
    

    ADDR=EKR+x/8+y*WIDTH
    

    
    WIDTH dla ekranu normalnego to 40 (320/8), dla wąskiego 32 (256/8), dla szerokiego 48 (384/8).
15. • 15:
       
      CommentAuthorlarek
    • CommentTime9 Sep 2009 19:09

     
    Do powyszego wzoru, aby lepiej to zrozumieć (tak mi się wydaje) dodałbym INT(), czyli ADDR=EKR+INT(x/8)+y*WIDTH, bo reszta z dzielenia i tak w tym przykładzie jest pomijana.
    
    Napisz POKE EKR,255 - powinien pojawić się biały pasek o szerokości 8 pikseli w lewym górnym rogu (przy założeniu, że EKR wskazuje na pierwszy bajt pamięci ekranu)
    Zobacz co się będzie działo, jak wpiszesz tam inne warości 0-255.
    
    Aby doprecyzować:
    Bajty przyjmują wartości 0-255, natomiast poszczególne bity w tych bajtach 0 lub 1. Więc jeśli znajdziesz już odpowiedni bajt, to jeszcze trzeba znaleźć odpowiedni bit w tym bajcie aby móc precyzyjnie zapalić dowolny piksel na ekranie - tu się już przyda ta reszta z dzielenia przez 8.
    
    Dla Twojego piksela o wsp. 40,50 będzie to: POKE EKR+2005,128 przy normalnej szerokości ekranu, czyli POKE EKR+INT(40/8)+50*40,128
    
    Mam nadzieję, że nic nie pokręciłem ;-)
16. • 16:
       
      CommentAuthorxeen
    • CommentTime9 Sep 2009 20:09

     
    czy ekran w pamięci (zwłaszcza dla gr.8) stanowi zawsze spójny obszar "bez przerw"? tzn. kolejny bajt to np 8 pixeli? czy też może to być jakoś rozrzucone?
    chodzi mi o tryby "jednolite" - bez okienek tekstowych czy okienek w innych trybach (DL)
17. • 17:
       
      CommentAuthorPoklik
    • CommentTime9 Sep 2009 21:09

     
    Xeen:
    dla standardowych trybów Basica: tak.
    Co do "rozrzucania" to jedno jest pewne: jedna pozioma linia zawsze jest złożona z kolejnych bajtów (duszki mogą przykryć co nieco w tej linii jednak to chyba jest jasne? ;).
    Natomiast ręcznie modyfikując DL możesz dowolnie zmieniać adresy źródła rysowania każdej z linii danego trybu przez co cały obszar rysowania faktycznie może być niespójny (jednak i tak poszczególne linie danych trybów - jak już pisałem wyżej - będą spójne).
18. • 18:
       
      CommentAuthorlarek
    • CommentTime9 Sep 2009 22:09

     

    xeen:

    tzn. kolejny bajt to np 8 pixeli?

    
    
    eee... no tak... bajt to zawsze będzie 8 bitów, choć na ekranie może być widoczne mniej, bo np. w GR15 za jeden świecący punkt na ekranie odpowiadają dwa bity (dlatego rozdzielczość pozioma spada z 320pkt do 160pkt) i wtedy bajt to nie 8 pikseli, ale tylko 4, choć to nadal 8 bitów :)
    
    Display List umożliwia zmianę adresu pamięci ekranu po zakończeniu wyświetlania kazdej linii, czyli każda wyświetlana linia może mieć swoją pamięć w innym miejscu RAM-u. Innymi słowy w GR8 i ekranie standardowej szerokości, każda linia to ciągły obszar 40 bajtów, ale kolejna linia (i kolejne 40 bajtów) mogą być już zupełnie gdzie indziej.
    Jak napisał Pokilk, standardowe tryby są tak ułożone, że zajmują jeden ciągły obszar pamięci RAM. Jeśli uruchomisz program (TBXL):
    10 GR.8+16: EKR=DPEEK(88)
    20 FOR BAJT=0 TO 7679
    30 POKE EKR+BAJT,255:PAUSE 3
    40 NEXT BAJT
    50 GET KEY
    
    to zobaczysz, jak te bajty zaczną się po kolei zapełniać.
19. • 19: CommentAuthorMaciek
    • CommentTime10 Sep 2009 01:09

     
    Właśnie dzisiaj robiłem testy i patrzyłem jak się zapełniają w gr.7. Katastrofa... Za bardzo przywykłem do PLOT więc majstrowanie na bajtach obszaru obrazu jest dla mnie makabrycznie niewygodne :( Przynajmniej opanowałem teorię. Swoją drogą, ponieważ zerkam też troszkę w asemblera, zakładam że proste wstawki dot. animacji w asm polegają właśnie na skomasowanym ataku na bajty w obszarze pamięci gdzie jest obraz... no bo jakże by inaczej, ale być może są inne magiczne sposoby :D Jeśli nie to muszę się już zacząć z tym oswajać :(
20. • 20: CommentAuthorSynthpopalooza
    • CommentTime12 Sep 2009 22:09

     
    I have written a program in BASIC that will take any disk file (font file, binary, or anything else), convert it into DATA statements or string assignments, and also generate the code to move that data into any memory location you want. Here is a link:
    
    ->link<-
    
    When using string assignments, it takes the string S$ and changes the variable name table so that ADR(S$) is set to the location in memory you want the data to be in ... for example (PEEK(106)-8)*256 for character sets.
21. • 21:
       
      CommentAuthorKaz
    • CommentTime13 Sep 2009 12:09 zmieniony

     
    Useful! Thanks Synthpopalooza.
    
    Edit: I put your program on Turbo Basic XL disc. It should work faster than in Atari Basic. TBXL starts automatically, so it's enough to type LOAD "D:CONVERT.BAS" to get the program.
    
    ->link<-
22. • 22:
       
      CommentAuthorxeen
    • CommentTime20 Nov 2009 09:11 zmieniony

     
    mam kolejne newbe pytanie:
    mamy dwie komendy (opisy z sieci)
    
    BLOAD np. BLOAD "D:nazwa.ext" (BL.)
    Odczytuje z podanego urządzenia plik binarny i umieszcza go w pamięci pod adresem podany w nagłówku pliku, lecz go nie uruchamia.
    Odpowiada to funkcji LOAD /N DOS-u.
    
    BRUN np. BRUN "D:nazwa.ext" (BR.)
    Odczytuje z podanego urządzenia plik binarny, umieszcza go w pamięci pod adresem podanym w nagłówku i uruchamia go.
    Odpowiada to funkcji LOAD DOS-u.
    
    dlaczego nieraz bload uruchamia tak wczytany program np. bload "D:TURBOBAS.COM" mimo opisu, że tego nie robi?
    
    Mój problem:
    Mam program w basicu, chcę po jego zakończeniu wywołać inny (chodzi o projekt UnityGames). Jak to ma się do pamięci, czy musze jakoś zwalniac pamięć zajętą przez mój program?
    Nie za bardzo rozumiem jak to działa.....
    Wystarczy BRUN i niczym się nie przejmuję?
    
    Mogę też wywołać reset, jak to się robi programowo (pewnie jakaś wartość w jakieś komórce i gotowe)
    
    z góry dziękuję za pomoc
23. • 23:
       
      CommentAuthorlarek
    • CommentTime20 Nov 2009 10:11 zmieniony

     
    BLOAD nie uruchamia wczytanego programu, czyli nie przekazuje sterowania przez wektor RUNAD. Jeżeli jednak plik wczytuje coś do INITAD, to program może nam ruszyć (zainicjować się). Rządzą tu te same prawa, co w plikach dosowych.
    
    "zimny" reset w TBXL (w AB też, ale nie w systemie szesnastkowym): X=USR($E477)
    "gorący" reset: X=USR($E474)
    
    Nie wiem, jakie zasady przyjęliście w tym projekcie, ale jeżeli program menu jest programem kompliowanego TBXL, to w Twoim programie (również kompilowanym) powinna wystarczyć instrukcja RUN "D:nazwa_menu.CTB" (nie żadne BRUN). Dobrze byłoby, gdyby program na koniec przywrócił wszystkie kluczowe ustawienia do wartości sprzed uruchomienia, czyli np. MEMTOP (jeśli zmieniał), zestaw znaków itp. Z drugiej strony, ładnie napisany program menu, powinnien sobie wszystkie ustawienia przed swoim uruchomieniem również wyzerować.
24. • 24:
       
      CommentAuthorxeen
    • CommentTime20 Nov 2009 11:11

     
    dziękuję, za pomoc :)
    popróbuję
25. • 25: CommentAuthorPaladina
    • CommentTime3 Dec 2009 19:12

     
    Little problem, when I use this program
    
    0 IF PEEK(760)=1 THEN 60
    10 POKE 106,PEEK(106)-10:POKE 760,1
    20 APZ=(PEEK(106)+6)*256
    30 OPEN #1,4,0,"D:FFF.FNT"
    40 BGET #1,APZ,1024
    50 CLOSE #1
    60 GRAPHICS 15:POKE 756,APZ
    
    I become Error of Value 3
    I need to load FNT to memory and use in Turbobasic 1.5 to write, anybody to correct this mistake? thx.
26. • 26:
       
      CommentAuthorlarek
    • CommentTime3 Dec 2009 19:12 zmieniony

     
    10 POKE 106,PEEK(106)-16 ...
    
    60 ... POKE 756,APZ/256
27. • 27: CommentAuthorPaladina
    • CommentTime3 Dec 2009 20:12

     
    1000 IF PEEK(760)=1 THEN 60
    1010 POKE 106,PEEK(106)-16:POKE 760,1
    1020 APZ=(PEEK(106)+6)*256
    1030 OPEN #1,4,0,"D1:PIS.DAT"
    1040 BGET #1,APZ,1024
    1050 CLOSE #1
    1060 GRAPHICS 15:POKE 756,APZ/256
    1070 COLOR 1:TEXT 10,10,"HELLO"
    1080 ? "WOLRD"
    
    ok..I see the HELLO ..but in little window down no WORLD...whuu..? whats now?
28. • 28:
       
      CommentAuthorlarek
    • CommentTime3 Dec 2009 20:12

     
    1020 APZ=(PEEK(106)+12)*256 :)
29. • 29: CommentAuthorPaladina
    • CommentTime18 Jul 2010 23:07

     
    Help with FONTS Space
    
    Ok I use very slim text fonts (only 3 pixel for Y), standart is 8 pixels and I need to become smaller space between the symbols, how can I do it please?
    I use Turbo Basic 1.5, Graphics 15, Command TEXT x,y,my text
    
    How to do smaller space between the symbols (poke for Y?) - not standart 8 pixels, but only 4 ?
    
    Thx.

    • cz8f.fnt
30. • 30:
       
      CommentAuthorlarek
    • CommentTime19 Jul 2010 10:07 zmieniony

     

    DIM TX$(80)
    GRAPHICS 15 : COLOR 1 : POKE 756,xxx
    X=10 : Y=10 : TX$="MY TEXT" : EXEC PRINT4
    
    
    --
    PROC PRINT4
     FOR Q=0 TO LEN(TX$)-1
      TEXT X+(Q*4),Y,TX$(Q+1,Q+1)
     NEXT Q
    ENDPROC
    
31. • 31: CommentAuthorPaladina
    • CommentTime19 Jul 2010 11:07

     
    Yes, this I use before, but there is problem with graphics, its make on my background picture black space ! (as its standard writing lenght of text). Then any else sample, please??