Retro Preservation Workspace

Monitorn

Browse archived Monitorn möten and the ABC80 mailing list, with full-text and text-number search.

← Back to ABC Tools

Meetings · ABC800 · Thread

Jag behöver HJÄLP med vissa mkodsorder...

19 posts in thread

Martin Persson <7174> · Text 6760 · w8 · inlagg

1987-05-15 23:51

Ärende: Jag behöver HJÄLP med vissa mkodsorder...

Jag behöver hjälp med hur man programmerar datorn för att få den att ersätta romet med en grafikbild, för att på det sättet kunna ändra hejvilt bland orderna... Till saken hör att jag laddar upp de aktuella ändrade rutinerna från fil till, i det här fallet, bild 3 på en 512k RAM:-maskin. Min stilla undran är: Hur kommenderar man datorn att byta ut romet mot en VISS grafikbild (jag vill veta hur man talar om vilken bild det aktuella romet ligger på). Om det är skillnad mellan en 128k maskin och en 512k maskin, vill jag även veta detta, och vad som skiljer... SAD. PS. Snälla, snabbt. Helst DENNA helg!!!!
- Lars Gjörling <6825> · Text 6761 · w8 · kommentar
  
  1987-05-16 00:27
  
  Ärende: Jag behöver HJÄLP med vissa mkodsorder...
  
  Jag föreslår att du läser igenom ABC-bladet 2.1984 sid 27-29. Där står beskrivet hur man blockar in HR-minnet över basictolken och även hur man kan välja bild. Ditt problem skiljer sig väl litet från det på dessa sidor beskrivna, men om man förstår principerna så ..... Mvh Lars
- Lars Gjörling <6825> · Text 6763 · w8 · kommentar
  
  1987-05-16 17:10
  
  Ärende: Jag behöver HJÄLP med vissa mkodsorder...
  
  Jag kom just på någonting. I programbanken finns ett program, som he- ter RAMBAS.806. Det laddar in ett maskinspråksprogram, som kan kopiera hela basictolken (32 kb) till HR-minnet och blocka in det, så att man sedan kör datorn som en RAM-maskin. Det är sedan möjligt att POKA i basictolken och ändra 'hej vilt' som du skrev. RAMBAS lägger tolken i bild 3, om man har 128k HR-minne och i bild 15 om man har 512k minne. 1) Ta hem programmet RAMBAS.806. 2) Kör det med RUN RAMBAS. Nu är maskinspråksprogrammet inladdat, men inte kört. 3) Kör maskinspråksprogrammet genom att skriva Z=CALL(49152). 4) Släck skärmen med ctrl-L. Nu är din dator en RAM-maskin. Adresserna till rutinerna i tolken är desamma, men du kan POKA och ändra hur du vill. Om du vet vilka änd- ringar du vill ha, kan du göra dem själv. Om du har en ändrad version (på 32 kb) liggande i en datafil, så kan du ladda in den istället för den nuvarande (tror jag) med programmet: 10 DIM A¤=0 : POKE VAROOT(A¤),0,128,0,0,0,128 20 OPEN 'BASTOLK.DAT' AS FILE 1 ! ....... eller vad den heter? 30 GET #1,A¤ COUNT 32768 40 CLOSE 1 50 END Jag har provat genom att kopiera tolken till en fil på diskett, ändra i denna fil (så att jag kunde känna igen den) och sedan kopiera till- baka den med ovanstående program. Det gick bra i mitt fall. Mvh Lars
  - Kristoffer Eriksson <5357> · Text 6775 · w8 · kommentar
    
    1987-05-18 03:34
    
    Ärende: Jag behöver HJÄLP med vissa mkodsorder...
    
    Det där sättet att läsa in ny Basic-tolk förutsätter förstås att GET-rutinen och DOS:et inte ändras av själva inläsningen medan GET exekveras.
    - Lars Gjörling <6825> · Text 6779 · w8 · kommentar
      
      1987-05-19 00:02
      
      Ärende: Jag behöver HJÄLP med vissa mkodsorder...
      
      Nej just precis, det var därför jag tillade 'tror jag' som en reserva- tion. Det riktiga är naturligtvis att först föra över filen med ruti- nerna i HRINOUT till en HR-bild och först därefter blocka in denna bild över basic-tolken enligt rutinerna i RAMBLK. Nu är det väl kanske inte så sannolikt att den som vill göra en ändrad version av tolken, ger sig på att ändra på de fundamentala rutinerna, och OM den föreslagna metoden fungerar, så blir det hela ganska enkelt. Om det inte går, så får man ta till andra metoder. Mvh Lars
  - Martin Persson <7174> · Text 6782 · w8 · kommentar
    
    1987-05-19 01:15
    
    Ärende: Läsproblem i rommet...
    
    Jag förstår andemeningen med ditt program, men det kör sig på en punkt, nämligen samma som runram.bas (?) kör sig på. Skärmen ligger över de två kilona i grafikrommet, och det är DET jag vill strula med... I övrigt har jag fått de uppgifter jag ville i den artikel du hänvisade till i ett tidigare inlägg. Nu en NY fråga! HUR läser man de två ovannämda kilona i grafikrommet??? SAD.
    - Lars Gjörling <6825> · Text 6793 · w8 · kommentar
      
      1987-05-20 08:37
      
      Ärende: Läsproblem i rommet...
      
      Jag har tittat närmare på programmet RAMBAS.806 (som visst nu heter RUNRAM.806). Jag har upptäckt att det bara blockar in 28k av rommet till HR-minnet, inte 32k. Grafikrommet ligger kvar som romminne. Det borde gå att ändra på om man vill. Angående läsning av grafikrommet, titta på inläggen 6720,6724,6741 och 6744! Angående att blocka tillbaka (ditt inlägg 6792), se ABCbladet 2.1984 igen. Utblockningsrutinen ser i assembler likadan ut som inblocknings- rutinen, med en enda skillnad. Det fysiska blocknumret skall ju läggas i register A, men tar där bara upp bitarna 0-6. Bit 7 blir då ledig att användas som flagga. Om man sätter bit 7, får man inblockning, och om man istället gör reset på bit 7, får man utblockning. Mvh Lars
      - Lars Gjörling <6825> · Text 6794 · w8 · kommentar
        
        1987-05-20 19:41
        
        Ärende: Läsproblem i rommet...
        
        Jag får nog ta tillbaka det där med att man skulle kunna ändra på RUNRAM så att 32k rom blockas in. Då blockas även skärmen in, och datorn blir oanvändbar. Mvh Lars
        
        Gunnar Faith-Ell SYSOP <2733> · Text 6812 · w8 · kommentar
        
        1987-05-23 19:24
        
        Ärende: Läsproblem i rommet...
        
        Under CP/M så blockar man in alltsammans och sedan anropas en liten rutin i slutet av minnet varje gång något ska ut på skärmen. Rutinen blockar tillbaka bildminnet, skriver ut ett tecken och återställer sedan. På vissa versioner av CP/M till ABC800 med mycket extra minne läggs vissa styrrutiner paralellt med arbetsminnet och plockas in vid behov vilket gör att man får ytterligare något k arbetsminne.
        
        Lars Gjörling <6825> · Text 6815 · w8 · kommentar
        
        1987-05-23 23:27
        
        Ärende: Läsproblem i rommet...
        
        Aha! Du menar att en liknande metod skulle kunna användas i Basic II som har överförts till ramminnet genom blockning? Så intressant! Har någon gjort det? Mvh Lars
        
        Nils Hansson <519> · Text 6829 · w8 · kommentar
        
        1987-05-24 19:45
        
        Ärende: BASIC II i RAMet
        
        Är det inte detta programmet RUNRAM gör eller missförstod jag frågan
        
        Lars Gjörling <6825> · Text 6832 · w8 · kommentar
        
        1987-05-24 22:49
        
        Ärende: BASIC II i RAMet
        
        I viss mån ja! Om du läser källkoden till RUNRAM (eller RAMBAS) som finns i ABCbladet 2.1984 sid 27, så finner du att den bara kopierar 28k till ram-minnet och blockar in det, alltså adresserna 0 - 7000H, och INTE de sista 4k på adresserna 7000H-8000H. Därmed blir det omöjligt att 'pula' med Printer/Terminal-prommet och med grafik-prommet, vilket uppenbarligen lockar många. Jag förvånade mig först över detta, men fann att det berodde på att kopiering och inblockning av även dessa adresser medförde att skärmen, som ligger parallellt med grafikprommet, blev död, och därmed blev datorn oanvändbar. Det inlägg jag svarade på påpekade möjligheten att efter en inblockning av även adresserna 7000H-8000H, ändra basic-prommets rutin för skärmut- skrift så, att anrop till en ny speciell subrutin blockade ut dessa ad- resser tillfälligt till det gamla, så att utskrift kunde ske, varefter åter inblockning skedde. Det intressanta är väl, att det såvitt jag för- står rätt, kan tänkas öppna möjligheter att 'pula' även i Printer/Terminal- prommet och grafikprommet. Mvh Lars
        
        Martin Persson <7174> · Text 6836 · w8 · kommentar
        
        1987-05-25 00:00
        
        Ärende: BASIC II i RAMet
        
        Det är tom så illa, att om man blockar in ram över options- och grafikromme så skriver skärmen i det nya rommet. Försök med att blocka in det och sedan använda grafikkommandona... (De är vid det laget 'bortskrivna') SAD.
    - Kristoffer Eriksson <5357> · Text 6798 · w8 · kommentar
      
      1987-05-20 20:59
      
      Ärende: Läsproblem i rommet...
      
      Både grafikminnet och optionsprommet (den del som ligger parallellt med bildminnet) kommer du åt via HRLDIR (eller 4k-blockning).
- Kristoffer Eriksson <5357> · Text 6776 · w8 · kommentar
  
  1987-05-18 03:37
  
  Ärende: Jag behöver HJÄLP med vissa mkodsorder...
  
  Angående just frågan hur du väljer grafikbild (om man ska arbeta med 32K-blockning), så är det OUT 6,x som gäller. De lägsta 4 bittarna i x väljer den sida CPU:n kommer åt, och de 4 andra väljer vilken sida som visas på skärmen. Det här är samma sak som FGPICTURE. Undras hur det går med grafik-kommandona i basic och optionsrutinerna när man kör som RAM-maskin?
  - Lars Gjörling <6825> · Text 6780 · w8 · kommentar
    
    1987-05-19 00:07
    
    Ärende: Jag behöver HJÄLP med vissa mkodsorder...
    
    Är det verkligen så, att man kan uppnå en PERMANENT inblockning av en HR-bild genom att göra OUT 6,x? Jag trodde att man därmed bara angav parametrar till de rutiner (t ex FGPOINT, FGLINE etc), som tillfälligtvis gör 32k-blockning av HR-minnet. Enligt Mats Knuts rutiner i ABC-bladet 2.1984, måste man göra OUT till minnesporttabellen (utport 52). Därvid blockas visserligen bara 4 kb i taget, men genom 8 st sådana blockningar erhåller man 32k-blockning, och kan välja mellan inblockning och utblockning. Det fysiska HR-minnet är indelat i block om 4 kb. I ett 128-kb-minne finns det 32 st sådana block (0 - 31) och i ett 512-kb-minne 128 st (0 - 127). Vid varje inblockning skall blockets nr placeras i regis- ter A, och det är på så sätt man väljer bild. Numreringen av blocken går i motsatt riktning gentemot bildernas numrering, så att exempelvis bild nr 0 har de högsta blocknumren och blocken 0 - 7 motsvarar bild nr 3 i 128-kb-minnet och bild nr 15 i 512-kb-minnet. Så har jag fattat det, och om jag har fattat det fel, så är jag mycket intresserad av att få veta hur man gör en RAM-maskin av datorn med hjälp av OUT 6,x. Det skulle ju förenkla det hela. Mvh Lars
    - Lars Gjörling <6825> · Text 6781 · w8 · kommentar
      
      1987-05-19 00:32
      
      Ärende: Jag behöver HJÄLP med vissa mkodsorder...
      
      P.S. Jag har prövat hur det går med grafikkommandona, när man kör som RAM-maskin. Det tycks gå bra! Det gick att rita linjer o dyl, och ef- teråt var det fortfarande RAM-maskin, där det gick att POKA i tolken. (Man bör dock inte rita i den bild, där tolken är lagrad, antar jag!). Mvh Lars
      - Martin Persson <7174> · Text 6784 · w8 · kommentar
        
        1987-05-19 01:25
        
        Ärende: RAM-maskin...
        
        Jag har testat att rensa skärmen romet låg på... Mycket intressant... :-/ SAD.
    - Kristoffer Eriksson <5357> · Text 6797 · w8 · kommentar
      
      1987-05-20 20:58
      
      Ärende: Jag behöver HJÄLP med vissa mkodsorder...
      
      Permanent och permanent... Försöker man rita grafik på en annan bild samtidigt som man har tolken i RAM med 32k-blockning, så växlas ju tolken bort, men du frågade ju hur man styrde vilken bild man hamnade i. Grafikinstruktionerna gör inte 32k-blockning, utan det är adress- avkodningen som gör att den maskinkod de utgörs av som ligger i PROM parallelt med bildminnet, automatiskt accessar aktuell grafikbild på adresser lägre än ca 30000, och accessae sig själva på adresser däremellan och 32768. Däremot finns det en 32k-blockning som blockar in en hel grafik- sida över Basictolken och DOS på en gång. Den använder också aktuell grafiksida. Till sist finns 4k-blockningen som sköts helt oberoende av valda grafiksidor, och därför är mycket bättre för körning som RAM- maskin.