ABC-80 frågor!

[qx5]

Något i stil med detta?

Kod: Markera allt

10 FOR A%=0 TO 65535 STEP 8192
20 POKE A%, 0
30 IF PEEK(A%) <> 0 THEN GOTO 70
40 POKE A%, 255
50 IF PEEK(A%) <> 255 THEN GOTO 70
60 PRINT "Memory at address ", A%
70 NEXT A%

Eventuellt:
60 PRINT "Memory at address ", A% / 1024, " kB"

[Platis]

Fick inte detta att funka tyvärr!

Tja, på enklast vis, om man förutsätter att det är standard minnes-storlekar:
POKE 32768,170<RETURN>
PRINT PEEK(32768)<RETURN>
Om svaret är 170 så har du med stor sannolikhet 32KB, annars 16KB.
Någon som har ett enklare sätt?

Funka perfekt! Om det finns minne på adressen får du samma nummer du poke:at in tillbaks annars blir det 255=inget minne(såvida du inte poke:at in 255), har jag fattat rätt?

Mellan exakt vilka adresser ligger extraminnet?

[jesse]

Något i stil med detta?

Kod: Markera allt

10 FOR A%=0 TO 65535 STEP 8192
20 POKE A%, 0
30 IF PEEK(A%) <> 0 THEN GOTO 70
40 POKE A%, 255
50 IF PEEK(A%) <> 255 THEN GOTO 70
60 PRINT "Memory at address ", A%
70 NEXT A%

Eventuellt:
60 PRINT "Memory at address ", A% / 1024, " kB"

Ingen bra idé att skriva på de högsta ~128 byten. Där ligger systemvariabler. Sedan kommer stacken.
Eftersom ABC80 i original minst har 16K ram kan man nog förutsätta att adresserna 49152 och uppåt fungerar.

ABC80 har även 1K minne till bildskärmen , tror det ligger på adress 31744 - 32767. Lätt att kolla, läser man det ska det innehålla det som står på skärmen.

[cjw]

Platis, meningen var att du skulle skriva detta utan ha något radnummer. Alltså direkt som vid en kommando-prompt. Om du gjorde det, vad fick du för resultat?

Jag kommer inte ihåg om ABC80 sabbar innehållet i minnet bara det att man skriver in något utan radnummer, men att skriva ett program som testar minnet är lite knepigt då ett "enkelt" sådant program som testar just _enkelt_ med största sannolikhet kommer att skriva över sig självt.

Den normala RAM-arean sträcker sig från 32768 (0x8000) vid 32KB minne, och från 49152 (0xC000) vid 16KB. Det finns andra delar av minnet som går att bestycka, men inte som stöds av BASIC-tolken. Så, om man enkelt vill kolla hur mycket RAM som finns till förfogande är det enklast att göra som beskrivet ovan.

Om nu exemplet jag gav inte fungerade och det är så att minnet används även när man skriver in något utan radnummer så är min teori att vid 32KB minne så kommer just adress 32768 att användas vid testet beskrivet tidigare, varför man då istället använder exempelvis adressen 33792 (tillräckligt långt från att användas för ett litet test som tidigare) vilket då skulle ge exemplet så som:
POKE 33792,170
PRINT PEEK(33792)
Om svaret är 170 så är det 32KB, om inte så är det med största sannolikhet 16KB.
Glöm inte att trycka <RETURN> efter varje rad.

[cjw]

För det var väl bara fråga om att ta reda på hur mycket Basic-RAM som finns tillgängligt i datorn?
Ett minnestest eller en komplett minneskarta kräver lite mera.

[Platis]

Jag menade det qx5 skrev som jag inte fick att funka! Det du cjw sa funkade kanon, på en maskinen med extra minne så får man tillbaks det nummer man poke:at in, på maskinen utan extra minne så får man 255 tillbaks som svar oavsett vad man poka:r in på den adressen!


Så ev extra ram ligger alltså mellan 32768 - 49151!? Verkar stämma bra med verkligheten efter att ha poke:at runt lite på båda maskinerna!

Varför skiljer sej checksum mellan olika maskiner?

[bit96]

Heltal måste ligga mellan -32768 och +32767 vill jag minnas, annars kan bli vissa problem med PEEK och POKE.

Jag TROR att du kan skriva:
POKE 32768%,170
PRINT PEEK(32768%)
Eftersom % ser till att det blir heltal som sen troligtvis internt görs om till teckensatt 16-bitars tal.
Skriver man utan % är det alltid flyttal och det kan bli fel i den interna översättningen.

Alternativ kan man skriva
POKE -32768%,170
PRINT PEEK(-32768%)

D.v.s. du tar 2-komplementet av talet.
Verkligt 32768 skrivs i ABC-BASIC som -32768%
Verkligt 32769 skrivs i ABC-BASIC som -32767%
Verkligt 32770 skrivs i ABC-BASIC som -32766%
...
Verkligt 65535 skrivs i ABC-BASIC som -1%

Med reservation för att jag minns fel.

[jesse]

Checksum avser ROM-minnet (dvs BASIC-tolken) på adress 0-16383.
Jag tror helt enkelt att du adderar alla bytes i den arean till ett 16-bitars heltal (som alltså får owerflow ett antal gånger, men det är som det ska).

Det blir olika checksum beroende på vilken verion av ROM du har.

Har inget att göra med hur mycket RAM du har.

[Platis]

Aha okej! Finns det listat nånstans vad som skiljer mellan dom olika rom-versionerna?

Heltal måste ligga mellan -32768 och +32767 vill jag minnas, annars kan bli vissa problem med PEEK och POKE.

Jag TROR att du kan skriva:
POKE 32768%,170
PRINT PEEK(32768%)
Eftersom % ser till att det blir heltal som sen troligtvis internt görs om till teckensatt 16-bitars tal.
Skriver man utan % är det alltid flyttal och det kan bli fel i den interna översättningen.

Alternativ kan man skriva
POKE -32768%,170
PRINT PEEK(-32768%)

D.v.s. du tar 2-komplementet av talet.
Verkligt 32768 skrivs i ABC-BASIC som -32768%
Verkligt 32769 skrivs i ABC-BASIC som -32767%
Verkligt 32770 skrivs i ABC-BASIC som -32766%
...
Verkligt 65535 skrivs i ABC-BASIC som -1%

Med reservation för att jag minns fel.

Är det inte skillnad på adresser och data här, hade inga problem att skriva adresser över 32767

[cjw]

Jag har aldrig stött på att flyttalsöversättningen blivit fel i minnes-sammanhang, men det kan ju vara en parameter som skiljer sig mellan bugg-rättningar mellan de olika BASIC-ROMen. Mitt ROM har checksumma: 10042. Vore kul att se en sådan versionslista med en diff och buggrättning eller dylikt.

Jag har för mig att den inte skriker på att skriva in 32768% heller, och att det blir rätt, men vid utskrift så blir det -32767, men det minns jag inte längre.

Vad gäller minneskartan så...
Lite förenklat ser minneskartan ut såhär (om jag minns rätt)
49152-65535 Arbetsminne, inklusive systemvariabler, buffertar för filhantering, stack etc
32768-49151 Ev extra arbetsminne
31744-32767 Bildminne (som är lite intressant gjort relaterat till hårdvarans uppbyggnad)
30720-31743 Används i förekommande fall till drivrutiner och enheter för expansionskort, framför allt till skrivare. Har sett andra funktioner också.
28672-30719 Används i förekommande fall till drivrutiner och enheter för expansionskort.
24576-28671 DOS (finns i de fall man har anslutit en diskettstation och innehåller drivrutiner och enheter för diskettstation. Lite överdrivet kalla det OS, men så blir det iallafall begripligt vad det används till)
16384-24575 Reserverat för utökad BASIOC-tolk
0-16383 BASIC-tolk

Som sagt, med reservation för minnet det finns säkert någon som har mer detaljerad/korrekt info..

[Platis]

Hehe hyfsat bra minne! Jag hinner typ glömma bort vad jag ska handla på väg till affären!

Jag sett iallfall tre olika checksummor; 9913, 10042, 11273 ...om jag minns rätt

[bit96]

Är det inte skillnad på adresser och data här, hade inga problem att skriva adresser över 32767

Som sagt, jag kanske minns fel.
Men, heltal på ABC80 är teckensatta 16-bitarstal så de måste ligga mellan -32768 och +32767.
Detta slog jag nu också upp i en ABC-BASIC-bok, där det står: -32768% till +32767%.
Men jag tittar nu också i en programlistning (ufdlib.bas) för ABC80 och där hittar jag:

Kod: Markera allt

290 A%=PEEK(65065%)+PEEK(65066%)*256% 

Det vore intressant om du kunde prova både med och utan %-tecken, t.ex:
POKE 40000,167 resp. POKE 40000%,167
Och sen i båda fallen läsa tillbaka med PRINT PEEK(40000) resp PRINT PEEK(40000%).
Kul att se om de fyra permutationerna av ovanstående funkar som förväntat.

[cjw]

Det är korrekt att det är "16 bits signed integers" som används i ABC80s heltals-konstanter och variabler. Dvs de kan representera värdena -32767 till 32768.

Om man tilldelar variabeln A%=32768 eller A%=32768% eller A%=-32767% kommer utskriften av den samma alltid att bli -32767. Bitvärdet kommer dock vara 32768. Men eftersom den representerar en "signed int" så kommer utskrift att bli -32767.

Notera att jag tidigare exempel skrev POKE 32768,170. Så det torde vara bevisat! BASIC-tolken är kabel att översätta heltalsrepresentationen oavsett hur den anges, så länge den är inom ramen för ett 16-bitars heltal. Jag minns inte om den slår runt eller genererar ett felmeddelande om den är utanför spannet, dvs 65536 och uppåt, eller mindre än -32767. Det får någon nyfiken luska ut med empiriska försök. Min röst ligger på att det blir ett felmeddelande.

[gkar]

Hehe hyfsat bra minne! Jag hinner typ glömma bort vad jag ska handla på väg till affären!

Jag sett iallfall tre olika checksummor; 9913, 10042, 11273 ...om jag minns rätt

Jag har för mig att 11273(Har en Metric 80 som är sådan) är äldst, sedan 10042 och 9913 sitter i de nyare med lackade kåpor.

Prova att skriva!
10 for i = 1 to 10
20 setdot i+1
30 next i

list
ta sedan bort rad 30
list
Vad händer?

[Platis]

Hann tyvärr packa ner datorn, ska kolla detta nästa gång jag har den uppe!
Det verkar som om det även finns olika text/ascii-rom, nollan ser olika ut på olika datorer!