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 · Z80 · Thread

Z80 slump

20 posts in thread

Petter Stahre <4501> · Text 896 · w8 · inlagg

1987-07-20 20:20

Ärende: Z80 slump

Hur gör jag lättast en "slumpgenerator" i assembler? Hur gör BASICen? Någon som har någon liten rutin, som inte använder så många register. Förrexten - om jag vill läsa maskinkoden för kommandona RAND../RND, hur går jag tillväga, hur hittar jag rätt adress i tolken att disassemblera? / mvh PSt
- Mikael Carlstedt <7105> · Text 899 · w8 · kommentar
  
  1987-07-21 00:17
  
  Ärende: Z80 slump
  
  Om jag inte har missförstått saken helt så finns det vissa instruktioner som sätter några av flaggorna (Sign-flaggan och Parity/overflow-flaggan för att vara exakt) helt slumpmässigt. Med utgångspunkt från detta kan man ju tänka sig något i stil med nedanstående: * En snutt för att få fram ett 8-bitars slumptal * LD r,02H ; r är registret där du vill ha slumptalet NÄSTA BIT 0,r ; BIT-instruktionen är en av de slumpmässiga JP M,SKIFTA INC r SKIFTA SLA r JP NC,NÄSTA BIT 0,r RET M INC r RET Voila! Lite spagettiartat kanske, men bara ett ynka enkelregister används. Det är instruktionerna med 2-ords OP-kod (BIT, SET, RES och några till) som har den här egenheten med slumpmässig flaggsättning. Jag valde BIT-instruktionen för detta ändamål, eftersom den inte påverkar några register. * Girbat *
  - David Andersson <5201> · Text 902 · w8 · kommentar
    
    1987-07-22 14:09
    
    Ärende: Z80 slump
    
    Har du testat metoden, att den verkligen ger slumptal? Jag har inte gjort det, men jag misstänker att den är dålig. Inga instruktioner sätter nog några flaggor helt slumpmässigt. Det vissa instruktioner gör är att de påverkar flaggor på ett odokumenterat sätt. T ex. säges H-flaggan vara odefinierad efter ADC HL.DE, men den har säkert fått sitt värde efter någon bit i något register.
    - Mikael Carlstedt <7105> · Text 905 · w8 · kommentar
      
      1987-07-23 08:02
      
      Ärende: Z80 slump
      
      Hm, testat den har jag inte...Jag bara såg att "Roddan" hade skrivit slumpmässigt, och han är ju professor och allt. Den där snutten var bara ett stundens infall, och vid närmare eftertanke tror jag nog att du har rätt på den punkten. Det där med H-flaggan i samband med ADC HL,DE var emellertid lite lustigt; i min "Programmera Z80" av Roddan står det klart och tydligt att "H sätts om det finns någon carry från bit 11". * Girbat *
      - Lars Gjörling <6825> · Text 907 · w8 · kommentar
        
        1987-07-24 17:59
        
        Ärende: Z80 slump
        
        I Z80 Technical Manual talas inte om slumpmässighet, bara om att S-flaggan är 'unknown' efter BIT b,r. Beträffande S-flaggan står det på annat ställe att den visar 'sign' genom att kopiera bit 7 från r. Jag misstänker att det är så att S-flaggan inte är opåverkad, men att dess värde inte beror på utfallet av BIT-testet för bit b, utan av värdet av bit 7. I så fall kan din metod inte fungera. Vad slumptal beträffar, så räcker det inte med att det genererade talet slumpmässigt och oförutsebart kan anta olika värden. Sannolikhetsfördelningen måste också vara likformig, dvs vart och ett av talen 0-255 måste ha samma sannolikhet att bli valt. När du kastar tärning, har 1, 2, ... 6 lika stor sannolikhet varje gång du kastar, där är sannolikhetsfördelningen likformig. Men om du kastar 2 tärningar och lägger samman 'ögonen', så kan du visserligen slumpmässigt erhålla vilket som helst av talen 2, 3, 4, ..... 12, men sannolikhetsfördelningen är inte likformig. Summan 2 kan bara erhållas ett enda sätt (båda tärningarna visar 1) men summan 7 kan erhållas på 6 st olika sätt. Det är därför 6 gånger sannolikare att summan blir 7 än att den blir 1. I ditt förslag till slumptalsgenerator finns BIT 0,r med 2 ggr, vilket liknar ovanstående exempel. Det är nog ganska säkert att fördelningen i varje fall inte skulle kunnat bli likformig. Datorn genererar sina 'slumptal' med en algoritm, och de är alltså inga riktiga slumptal. Om man vet värdet av ett 'slumptal' och har kännedom om algoritmen, så man ju i förväg räkna ut vilket nästa 'slumptal' kommer att bli (roulettespelarens önskedröm). Men serien av slumptal skall imitera slumpmässighet och måste därför ha bl a likformig fördelning. Risken för periodicitet är ett bekymmer. Om man med en algoritm i ett assemblerprogram genererar 8-bitars tal, så blir (förutsatt att fördelningen är likformig) sannolikheten 0,50 för att 18 olika tal skall genereras i följd. Sannolikheten för 19, 20, .... är mindre än 0,50. Att använda 8-bitars register är helt olämpligt, om det inte enbart gäller något eller några enstaka slumptal i hela programmet, och då kan man lika gärna läsa av adress 65525 (TIC). Vid 16-bitars tal är risken väldigt mycket mindre och vid 40-bitars tal nästan obefintlig (om algoritmen är den rätta). På datorns slumptalsgenerator kan man lätt göra olika tester beträffande likformighet. Om man skriver ett basicprogram, som genererar tärningkast, så kan man ha 6 räkneregister för de olika utfallen. Om man 'kastar' ett stort antal gånger (t ex 60000), så skall procenttalen ettor, tvåor etc tendera mot samma tal (16,7%). Tyvärr räcker det inte ens med likformighet för att generatorn skall imitera slumpmässighet på rätt sätt. Programmet 10 WHILE -1 : IF X<1 OR X>6 THEN X=1 20 PRINT X; : X=X+1 : WEND genererar talföljden 1,2,3,4,5,6,1,2,3,4,5,6,1,2,3,4,5,6,...... vilken självfallet inte utgör några slumptal, men klarar likformighetstestet med glans. Man kan därför göra det s k pokertestet. I tärningpoker kan man ju slumpmässigt få par, tretal, fyrtal etc. Även om man genererar tär- ningkast med dator kan man få par (samma tal två ggr i följd), tretal etc. Man förstår ju lätt, att när man slår en tärning, så är sannolikheten 1/6 för att man får detsamma som föregående gång. Om man har en räknare, som räknas upp varje gång det slumpas ut samma tärningkast två gånger i följd, så bör i en stor serie detta hända i 16,7% av kasten. Tretal har p.s.s sannolikheten 1/36 = 2,8%. Osv. De algoritmer, som används i datorerna, är noggrannt uträknade och utprovade för att ge god imitation av en likformig sannolikhets- fördelning. Andra statistiska fördelningar (poisson-, exponential- etc) kan erhållas genom matematiska manipulationer av datorns slumptal. Mvh Lars
        
        Staffan Lantz <6650> · Text 908 · w8 · kommentar
        
        1987-07-25 19:15
        
        Ärende: Z80 slump
        
        Här kommer ett program som beräknar slumptal. Det är hämtat Starting Forth av Leo Brodie, och översatt till assembler. Fortprogrammet ser ut som följer: VARIABLE RND HERE RND ! : RANDOM RND É 31421 * 6927 + DUP RND ! ; RANDOM U* SWAP DROP ; : CHOOSE RANDOM U* SWAP DROP ; Och här följer assemblerprogrammet: ; Program: RANDOM Av: Staffan Lantz ; Slumpgenerator som ger slumptal mellan ; noll och värdet i DE-reg - inberäknat ; noll men inte värdet. 0>= n < värde. ; Genom anrop av RANDOMIZE får man ett slumpmässigt startvärde. ; Slumptalet hamnar i HL-registret. ; Formel: slumptal=låga delen av slumpfrö*31421+6927 ;--------------------------------------- START ORG 40000 RND DW 2 ;Reserverat för ett slumptal ;--------------------------------------- RANDOMIZE LD A,(65008) ;Klockbytes LD H,A LD A,(65009) LD L,A LD (RND),HL ;Slumpmässigt startvärde RET ;--------------------------------------- RANDOM PUSH DE LD A,(RND+1) LD C,A LD A,(RND) ;C+A faktor1 LD DE,31421 ;DE faktor2 LD B,16 ;B biträknare LD HL,0 ;Summa MUL16 SRL C ;Högerskift RRA ;Högerskift med carry JR NC,NOADD ;Om inte carry- ingen delssumma- hoppa ADD HL,DE ;Addera summa NOADD EX DE,HL ADD HL,HL ;Vänsterskifta DE EX DE,HL DJNZ MUL16 ;Gör alltihop 16 ggr ;--------------------------------------- ADDERA LD DE,6927 ADD HL,DE LD (RND),HL ;--------------------------------------- PUSH HL POP BC POP DE LD HL,0 LD A,16 MUL32 ADD HL,HL RL E RL D JR NC,NOADDI ADD HL,BC JR NC,NOADDI INC DE NOADDI DEC A JR NZ,MUL32 PUSH DE POP HL ;Slumptalet i HL RET END START Håll till godo / Hälsningar Staffan.
        
        Lars Gjörling <6825> · Text 909 · w8 · kommentar
        
        1987-07-26 19:35
        
        Ärende: Z80 slump
        
        Assemblerprogrammet för slumptalsgenerering är skrivet för ABC80, vilket syns av att som adress till klockbytes anges 65008-65009. Om man har en dator i 800-serien (vilket Petter Stahre, som ursprung- ligen efterfrågade det här, har), så måste man byta ut dessa två adresser mot förslagsvis 65524 och 65525 (eller istället avläsa Ref- resh-registret, som Basic-Randomize gör enligt David Andersson). Annars fungerar programmet bra. En fördel är ju att man kan skicka med ett maximivärde för slumptal i DE-registret. Mvh Lars
        
        Kent Jönsson <5924> · Text 910 · w8 · kommentar
        
        1987-07-27 00:19
        
        Ärende: Z80 slump
        
        Se inlägg 447 i möte EjBASIC
- Lars Gjörling <6825> · Text 900 · w8 · kommentar
  
  1987-07-21 16:35
  
  Ärende: Z80 slump
  
  I matematiken menas med ett slumptal ett tal mellan 0 och 1. I datasammanhang bildas en slumptalsserie, genom att varje nytt tal fås ur det föregående genom någon algoritm, t ex Newrandom = Frac(SQR(Oldrandom+Pi)) el dyl Man inser, att om ett slumptal är lika med ett av de föregående, så blir talföljden periodisk, så att den upprepar sig själv. Förr eller senare MÅSTE detta inträffa, eftersom 6-siffriga tal inte kan bilda mer än högst 999999 olika kombinationer. Man måste starta med ett första värde, ett s k slumptalsfrö. I vissa datorer måste man själv mata in detta, i andra kan man använda den inbyggda klockan, om sådan finns. Detta aktiveras med RANDOMIZE. I programmerbara räknedosor använder man ofta en enkel algoritm, den s k 47-generatorn, som arbetar genom att multiplicera Oldrandom med 47 och sedan ta bort heltalsdelen: Newrandom = Frac(47*Oldrandom). I assembler får man väl istället generera heltal mellan 1 och 32767. Nedanstående förslag använder den enkla 47-generatorn. Helt säker på att man inte får en alltför kort periodicitet, kan man väl inte vara men talet 47 är valt för att minimera den risken: RND ZPROG ; Program för alstring av slumptal. ; ORG 64512 ; Läggs i dosbuf 7. ; DE förutsätts innehålla ett slumptalsfrö. START LD B,47 ; En s k 47-generator används. LD HL,0 LOOP ADD HL,DE ; Det nya slumptalet läggs i HL, och erhålls DJNZ LOOP ; genom att det gamla multipliceras med 47. RES 7,H ; Inga negativa utparametrar! LD D,H ; Det nya slumptalet blir ev. frö till nästa. LD E,L RET ; Vid return finns slumptalet i HL (1-32767). END START Du kan prova det i nedanstående basicprogram, där slumptalsfröet hämtas från två bytes i klockan (SEC och TIC). Så länge man håller en tangent nedtryckt, får man nya slumptal. 10 INTEGER : EXTEND : ; CHR¤(12); 20 POKE 64512,6,47,33,0,0,25,16,253,203,188,84,93,201 30 Start=64512 ! Maskinspråkrutin i dosbuf 7. 40 ! För att få ett slumptalsfrö användes två bytes i datorns klocka: 50 Frö=PEEK2(65524) : IF Frö=0 THEN 50 ELSE Slumptal=CALL(Start,Frö) 60 ; USING "#.###### " Slumptal/32768.; 70 Slumptal=CALL(Start,Slumptal) : GET W¤ : GOTO 60 Om du vill ha en synnerligen enkel metod att få ett litet slumptal mellan 0 och 96, så kan du helt enkelt läsa värdet av adress 65525, som visar aktuellt värde av klockans hundradelssekund. Mvh Lars
  - Lars Gjörling <6825> · Text 901 · w8 · kommentar
    
    1987-07-21 16:56
    
    Ärende: Z80 slump
    
    Förlåt, i näst-näst-sista raden skall det förstås stå 'mellan 0 och 93' (och inte 96 som jag skrev)! Mvh Lars
  - David Andersson <5201> · Text 904 · w8 · kommentar
    
    1987-07-22 14:33
    
    Ärende: Z80 slump
    
    Förutom 47-generatorn finns också 137-generatorn. Antagligen finns framtaget pseudoslumpgeneratorer med större tal och som passar för 16-bitars register. Fördelen med 137-generatorn är att 137 binärt har färre bitar=1 än 47 så multiplikationen kan göras snabbare med några få skiftoperationer och några få additioner.
    - Lars Gjörling <6825> · Text 906 · w8 · kommentar
      
      1987-07-24 17:49
      
      Ärende: Z80 slump
      
      Tack för svaret. Jag ser att 137-generatorn måste kunna göras väsentligt snabbare än 47-generatorn. I den första dator jag använde för många år sedan, en Nova, använde RAMDOMIZE sig (enligt den uppgift jag fick) av klockan. Om man (fel- aktigt) lade RANDOMIZE i loopen (FOR I=1 TO 10 : RANDOMIZE : PRINT RND : NEXT I) fick man mycket riktigt ett antal helt lika 'slumptal' ef- ter varandra. I M-soft Basic för APPLE II var man tvungen att mata in ett slumptalsfrö som inparameter till RANDOMIZE, för att inte få samma talföljd alltid. Mvh Lars
- David Andersson <5201> · Text 903 · w8 · kommentar
  
  1987-07-22 14:25
  
  Ärende: Z80 slump
  
  Tolken använder ett 40 bitars heltal (5 bytes) i slumptalsgeneratorn. RANDOMIZE läser av R-registret (Refresh-registret) och sätter alla 5 bytearna till avläst värde. RANDOMIZE startar alltså en av 128 (eller 127) möjliga slumptalsserier. Hur RND fungerar har jag glömt, men i stort sett är det som följer. Nytt.frö = (Gammalt.frö * stort.tal) + annat.tal Blir det nya talet större än 40 bitar slänger man bara bort överflödiga bitar (vilket händer ofta, stort.tal är *stort*). Sedan används de högsta bitarna i Nytt.frö för att bilda ett flyttal mellan 0 och 1. Det liknar 47-generatorn beskriven i text 900 med den skillnaden att ett annat.tal läggs till så att gammalt.frö kan få vara noll utan att slumptalsgeneratorn står och stampar på noll. När man ska bestämma vilket tal man ska ha som stort.tal så försöker man ta ett tal som ger långa slumptals-serier utan upprepningar. Jag har för mig att man då använder teorier om primtal.
  - Björn Linderson <5829> · Text 913 · w8 · kommentar
    
    1987-07-31 20:58
    
    Ärende: Z80 slump
    
    Detta då?? LD A,R LD L,A LD A,R LD H,R LD A,R LD B,A LOP1 RL H DJNZ LOP1 LD A,R LD B,A LOP2 RR L DJNZ LOP2 RET Läser av ett 16bitarstal från R, skiftar det ett par tre varv, (H och L var för sig). Efter detta returnerar det talet i HL, som är det register man får från ett anrop till assembler från basic via CALL xxxxx,ppppp Kan de va nå?
    - Lars Gjörling <6825> · Text 914 · w8 · kommentar
      
      1987-08-01 11:07
      
      Ärende: Z80 slump
      
      Sorry, men det duger nog inte alls som slumptalsgenerator. Det ger visserligen ett 16-bitarstal som utvärde, men första fordran på en slumptalsgenerator är ju att alla 65536 möjliga värdena skall ha samma sannolikhet att bli valt. Slumpmässigheten i ditt förslag infaller vid första raden LD A,R då den tidpunkt då R-registret avläses avgör vilket av 128 möjliga tal (se David Anderssons inlägg nr 903) som läses in, och lagras i L. Eftersom varje maskinspråksinstruktion tar ett bestämt antal klock- pulser, kan man sedan räkna ut vilka tal som laddas i H, respektive senare i B, och ännu senare i B en gång till. Varje gång den första inläsningen har exempelvis värdet 43, så fås samma 16-bitars tal som utvärde. Av de 65536 'möjliga' värdena är det i praktiken bara 128 st, som kan returneras, medan 65408 st inte har någon chans att bli valda. Att de 128 på en tallinje med talen 0-65535 skulle ligga jämnt fördelade är inte troligt. Att göra en slumptalsgenerator, som inte utnyttjar högre statistiska teorier, är svårt. Även om du skulle göra om programmet så att alla 65536 möjliga talen kan bli valda, så återstår att bevisa, att den statistiska fördelningen blir likformig (så att efter några biljoner försök alla talen skulle ha samma relativa frekvens) och även så att ordningsföljden blir fullt slumpmässig (exempelvis inte har långa se- rier av växande värden). Mvh Lars
      - Hans Holmberg <2838> · Text 915 · w8 · kommentar
        
        1987-08-02 00:51
        
        Ärende: Z80 slump
        
        En enkel och behändig metod är att man börjar med ett frö, adderar ett 16-bitars tal hämtat från R-registret, gör en del matematiska konster med det, tar sedan detta tal och läser av ett 16-bitars tal från den minnesposition som det första talet pekade ut, och returnera sedan det hämtade talet som frö/slumptal! /Hasse
        
        Anders Franzén <5258> · Text 916 · w8 · kommentar
        
        1987-08-02 09:21
        
        Ärende: Z80 slump
        
        Jag beräknade slumptal på följande sätt när jag bara hade en TI57:a (en liten programmerbar miniräknare): Ta ett frö så att 0<frö<1 Beräkna SIN(frö) Låt slumptalet bestå av några av siffrorna i talet Låt talet bli frö till nästa omgång Kanske var det INV SIN jag använde minns ej. Vet ej hurvida siffrorna är slumpartade. Använde nog radianer. Dessa slumptal var användbara till tipset men inte så bra eftersom jag aldrig vann.
        
        Lars Gjörling <6825> · Text 917 · w8 · kommentar
        
        1987-08-03 01:40
        
        Ärende: Z80 slump
        
        Att få fram slumpartade tal är inte så svårt och kan göras på hur många olika sätt som helst. Skall man bara ta fram några enstaka, och använda dem själv för skojs skull, så är det väl inte så noga. Men skall man låta ett datorprogram simulera slumphändelser, hämtade från verkligheten, ställs det krav på att de framslumpade talen har rätt sannolikhetsfördelning. För verkliga händelser har den matema- tiska statistiken ställt upp en hel rad olika slags fördelningar, likformig fördelning, binomialfördelning, normalfördelning, poisson- fördelning, exponentialfördelning etc. Fördelningskurvan ser ut på olika sätt för dessa fördelningar. Funktionen RND *SKALL* slumpa fram tal med likformig fördelning, dvs fördelningskurvan skall bli en rät obrutenlinje, parallell med x-ax- eln. Sinusfunktionen lämpar sig verkligen inte, den kurvan är knap- past en rät linje. Sin(30)=0,5 varav man inser att av slumpmässigt valda vinklar 0-90 måste det bli dubbelt så många sinusvärden mellan 0,5 - 1 som mellan 0 - 0,5. Vanliga hobbyprogrammerare använder väl ofta RND i spelprogram, för att kasta krona och klave, göra tärningskast eller dra kort ur kort- lek etc. Detta är att simulera slumphändelser i verkliga livet. Och dessa är typiska händelser med likformig sannolikhetsfördelning. Tärningkast simuleras exempelvis genom att man delar in hela mängden av möjliga RND-värden i 6 lika stora intervall och ser efter inom vilket man hamnade. Det får då inte bli så, att exempelvis sexa bara inträffar var hundrade gång eller att ettor är dubbelt så vanliga som tvåor eller treor. 47-generatorn, 137-generatorn och 31421-generatorn är inte påhittade genom att man har tagit tal ur luften. Det ligger mycket matematiskt arbete bakom dem. Det är inte helt omöjligt att det dåliga tipsresultatet berodde på att räknaren tippade för många tvåor. Mvh Lars
        
        Lars Gjörling <6825> · Text 918 · w8 · kommentar
        
        1987-08-03 12:19
        
        Ärende: Z80 slump
        
        Metoden inger inte mig förtroende. Man kan inte ta ett '16-bitars tal från R-registret' utan att hämta två 8-bitars tal efter varandra. Att göra matematiska konster med det är meningslöst, det blir ändå bara 128 st möjliga 16-bitars tal som kan bli resultatet (se mitt inlägg 914). Att använda internminnets innehåll för att generera slumptal tror jag inte är någon bra ide. De 65535 st möjliga PEEK2-värdena är inte lik- formigt fördelade, framför allt så är värdet 0 enormt överrepresente- rat. Skriv programmet: 10 ; Slump; : Slump=PEEK2(Slump) : GOTO 10 så får du den inte särskilt lyckade talföljden: 0 29720 -21632 0 29720 -21632 0 29720 -21632 .................. Startar du med ett godtyckligt frö, så får snart PEEK2 värdet 0 och då börjar en sådan serie. Om man varje gång lägger till ett '16-bitars tal från R-registret', så blir naturligtvis variationsmöjligheterna mycket större. Men även då kan knappast fördelningen bli likformig. Det är nog bäst att hålla sig till noggrannt beräknade och utprovade matematiska metoder (t ex enligt inlägg 900). I inlägg 447 i mötet EJBASIC angavs anropsadressen till slumptals- rutinen i basictolken för ABC80, vilket gör att man kan göra ett enkelt CALL för att få ett slumptal. Det måste ju finnas en sådan adress även i BASIC II-tolken, både för RND och RANDOMIZE. Det gäller bara att veta den. Den plats i minnet, där dessa rutiner lagrar det genererade slumptalet är 65351-65355 (ett 40-bitars tal i 5 bytes). Mvh Lars
        
        David Andersson <5201> · Text 949 · w8 · kommentar
        
        1987-08-29 17:24
        
        Ärende: Z80 slump
        
        Som Lars Görling säger, man ska vara försiktig med slumptalsalgoritmer. I ABC80 får vi acceptera att det finns inget enkelt sätt att få ett slumptal som kan ha fler än 128 olika värden (register R). Försöker man mixtra med det värde man får från R så kan man inte få flera värden eller bättre fördelning av värdena, det kan mest bara bli tvärt om. Det säkraste är att ha en pseudoslumptalsgenerator typ 47, 137 eller så. Eller varför inte använda basic-tolkens slumptalsgenerator. I spel (ej kortspel) där slumpfördelning inte är så noga kan man använda register R rakt av. T ex HOPPERT gör så.