Kategori: Tekniska dokument

Basen nere just nu

Bad news, everyone… För att citera Vera Lynn: we’ll meet again…

The ERICADE Network BBS är för tillfället avstängd i väntan på omkonfigurering av hårdvaran. Den beräknas vara tillbaka inom kort.

NikomStat

Exempel på topplista skapad med NikomStat

Det utvecklas fortfarande kommandon för Nikom. I alla fall har jag skrivit ett kommando som används för att generera topplistor över de mest aktiva användarna.

Ladda ner det här!

Här är manualen:

NikomStat
=========

Version 1.1 – Släppt 2019-07-17
Skapat av Erik Zalitis på The ERICADE Network BBS.
Supportas på https://the.ericade.net/?p=938

Versionshistoria
============

Version 1.1 – Släppt 2019-07-17
————————-

(Buggfix) Första parametern lästes aldrig in.

(Ny funktion) – Parametern n som sätter poäng för antalet veckor användaren varit inaktiv. Sätts normalt till ett negativt värde för att ”straffa” inaktiva användare, så att de åker ner från topplistan.

Version 1.0 – Släppt 2019-07-14
————————-

Första versionen.

Kontakt
=======

Jag kan nås på epostadressen erik@zalitis.se.

Finns också på BBSen The ERICADE Network på:

– SSH, the.ericade.net:22. Inloggning:bbs med lösen bbs.
– Telnet, the.ericade.net:23.

Följ min berättelse om en BBS någonstans i Stockholm under 90-talet:
https://the.ericade.net

Förbehåll
=======

Jag tar inget ansvar för eventuella problem som kan uppstå med detta program. Läs denna manual innan du installerar programmet. Dvs, läs den nu!

Vad är NikomStat?
==============

Tidigare har det funnits en del skript som använt NikomUS för att generera topplistor i Nikom. NikomUS fungerar inte med versioner av Nikom nyare än version 1.61. Då ingen verkar ha kunnit hitta orsaken till detta, valde jag att bygga en ersättare i Arexx.

NikomStat ersätter den vildvuxna flora med skript som tillsammans med NikomUS användes för att generera topplistorna. NikomStat genererar direkt färdiga listor som kan användas i basen utan att man måste ha några skript som formatterar datat. Resultatet ser i princip likadant ut som de listor som du är van vid.

Fördelar med NikomStat

– Två filer behövs för att generera alla listor att så de blir helt uniforma.

– Installationen är extremt enkel och tar bara några minuter.

– Det är extremt enkelt för den som kan Arexx att lägga till funktioner
eller ändra hur rapporterna ser ut.

– Skripten använder standardfunktioner i AmigaOS/Arexx/Nikom och borde vara
hyffsat framtidssäkra.

– Varje ny lista du vill ha skrivs in i maketoplist.rexx som en ny rad.
Detta gör det trivialt att skapa alla listor du någonsin skulle kunna drömma
om.

Installation
==========

1. Packa upp arkivet.

2. Se till att filerna nikomstat.rexx och maketoplist.rexx hamnar i nikom:rexx

3. Öppna nikomstat.rexx i en bra editor (inte ed!) och ändra namnet på din BBS i variabeln bbs.

4. Öppna maketoplist.rexx i valfri editor och kolla om du vill ändra någonting. Detta är generellt sett inte nödvändigt. Men du kanske har andra åsikter om hur poängen ska beräknas. Vad vet jag? 🙂

5. Lägg in ”rx nikom:rexx/maketoplist.rexx” i din crontab-fil. Detta förutsatt att du kör cronjob och har en cronprogramvara installerad. Annars får du köra skripten manuellt.

För att generera listorna, kör du ”rx nikom:rexx/maketoplist.rexx”. Då kommer den att köra några minuter och bygga alla listor som definierats.

Exempel
=======

rx nikom:rexx/nikomstat.rexx i1 r0 w10 u20 d-20 fnikom:texter/svenska/g.txt

Denna kommandorad gör att en fil som heter g.txt skapas i nikom:texter/svenska/. Poängen beräknas som 1 poäng för varje inloggning, 0 poäng för varje läst text, 10 poäng för varje skriven text, 20 poäng för varje uppladdad fil och avdrag på 20 poäng för varje nedladdad fil.


Att notera
========

– Avsaknade funktioner

Parametern ”p” är inte implementerad. Denna parameter ska normalt göra att NikomStat visar vad den gör. Kommer troligen i nästa version.

– Förvalda poäng

Om du inte anger några parametrar, kommer poäng ges enligt:

i=inloggningar=1 poäng
r=last=0 poäng
w=skrivet=5 poäng
d=nedladdat=-20 poäng
u=uppladdat=20 poäng
t=inloggadisekunder=0 poäng

– Parametrar

Parametrarna följer NikomUS standard enligt:

i – Poäng för inloggningar. Sätter du parametern i10 ger du 10 poäng för varje inloggning. Detta format gäller alla parametrar som ger poäng. Notera att det INTE är något mellanslag mellan i och poängsiffran.

w – Poäng för skrivna texter.

r – Poäng för lästa texter.

t – Poäng för antal inloggade sekunder.

u – Poäng för antal uploads.

d – Poäng för antal downloads. Man sätter normalt minuspoäng för detta. ex.vis d-10.

n – Poäng för antalet inaktiva veckor. Man sätter normalt minuspoäng för
detta. ex.vis n-2.

f – Filnamn. fram:katt.txt lägger den färdiga rapporten i ram: som katt.txt. Som standard blir filnamnet ram:temp.dat om man inte sätter parametern.

h – Generera huvud. Utan huvud blir det bara en lista. Som standard genereras  ett huvud.

l – Namn på listan. Skriver du lInloggnings, kommer rapporthuvudet skriva ”Inloggningslistan”. Suffixet ”listan” kan ändras i nikomstat.rexx.

q – Vänd listan upp och ner. Dvs, den som får lägst poäng hamnar högst upp i rankningen. q0 slår från och q1 slår till värdet. Som standard är det högst poäng som kommer högst upp i listan. Alltså q0.

Om man inte anger en parameter, används ett standardvärde. Det är därför viktigt att allt ange alla parametrar även om de ger 0 poäng för att se till att poängen blir korrekt. Så om du vill garantera att inloggningar t.ex. ger noll poäng, sätter du i0, annars kommer inloggningar tilldelas 1 poäng per inloggning om du inte anger i-parametern.

Exempel:
rx nikom:rexx/nikomstat.rexx i1 w1 u10 d-20 n-2 fram:lista.txt

– Minnesanvändning

NikomStat genererar två filer i ram:. Dessa finns bara medan skriptet körs och tas sedan bort. Däremot läser skriptet in alla användare i minnet medan den kör. Varje användare tar upp runt 80 bytes i minnet.

Så har du 4500 användare i basen, kommer NikomStat behöva drygt 350 kb för att hålla dem i minnet. Så fort skriptet körts klart, lämnas minnet tillbaka.

Men om du har många användare och ont om minne, bör du inte använda NikomStat.

Namnsdagskommandot – en studie i Arexx

De var namnsdagsbarn dagen då detta inlägg skrevs i alla fall.

1997 lade vi till ett namnsdagskommando till basen som kördes vid inloggning och berättade vem som hade namnsdag när någon loggade in. Det skrevs från början 1994 av Mattias Appelqvist. Kommandot läste från en textfil som innehöll alla namnen.

En fråga till er som programmerar: hur skulle ni skapa ett kommando som ska hämta ett namn ur en lista med namn baserad på dess position? Personligen skulle jag trycka in dem i en array och sedan ta reda på vilket namn i ordningen som ska plockas fram. Man får hitta en lösning för skottår, men annars är det bara att plocka fram post 218 ur arrayen dag nummer 217 (arrayer börjar normalt på 0!) förutsatt att namnen är lagrade i ordning efter vilken dag på året de har namnsdag. Inget problem här.

Men 1994 fungerade det lite annorlunda. Först och främst var minnet begränsat. The ERICADE Network hade en Amiga med 6 MB minne. Detta minne skulle räcka för att köra basen och operativsystemet med hundratals användare. Så att läsa in alla namnen i minnet vara lite mer tveksamt. Det andra skälet är att Arexx arrayhantering var ganska primitiv.

Så hur löser man detta? Jo, kommandot måste läsa från disken. Detta är i sig ett problem, för diskar är slöa jämfört med minnet. Om man antar att man lägger alla namnsdagar i ordning efter dag, skulle arexx-programmet behöva stega ner 219 rader för att hitta namnet bundet till dag 219. Detta är inte effektivt och kommer att göra kommandot slött och resurskrävande.

När jag startade upp BBSen 2018, insåg efter några månaders drift att namnsdagskommandot ofta visade fel namn. Det visade sig bero på att det hade en del intressanta buggar och dessutom använde 1993 års namnlängd. Denna slutade gälla på 2000-talet. Så jag hämtade den senaste namnlängden från Wikipedia och gjorde den till en textfil. Men vi har fortfarande inte svarat på frågan hur kommandot hittade dagens namn.

Detta var inte helt uppenbart för mig när jag tittade på koden eller på textfilen den läste. I början av namnfilen såg det ut såhär:

0062 0451 0817 1216 1614 2026 2410 2817 3233 3619 4026 4425
*
SVEA SVERKER

filen fortsatte sedan med alla namnen.

Vad var alla dessa märkliga siffror? En titt i koden visade att den verkade koppla siffrorna till månaden.

dag = right(date(’s’),2)
man = substr(date(’s’),5,2)
sendstring lf lf
if ~exists(fil) then call fel(’Hittar inte ’fil)
if ~open(’t’,fil,’r’) then call fel(’Kunde inte läsa från ’fil)
mpos = readln(’t’)
mpos = word(mpos,man)
call seek(’t’,mpos,’b’)

Koden ovan tar fram månadens nummer i ordningen. Juni är t.ex. månad nummer 6 och januari är 1. Sen läser den in den första raden och plockar ur den siffergruppen som motsvarar månaden. För juni tar den alltså den sjätte siffergruppen. Men varför då? Jo, denna siffergrupp talar om hur många bytes in i textfilen som månadens namn börjar. Det är ett intressant sätt att göra det på!

Men det ger ju inte hela lösningen. Efter att den hittat första namnet för den aktuella månaden, stegar den fram till korrekt dag. Om det är den 10 juni, stegar den tio rader ner och hämtar namnet.

Detta kommando har krånglat rätt mycket redan innan jag skrev om det för den nya namnlängden. Vissa dagar kraschade skriptet för den inte riktigt hittade rätt. Och att räkna ut hur många bytes in i filen man gå för att hitta månadsstarten visade sig vara en utmaning. Dessutom var man tvungen att tänka på hur Amigan kodar radbrytningar när man gjorde jobbet. Jag skrev nämligen filen på en PC.

Så jag hittade en lösning till sist och fick allting att fungera.

Tillbaka till år 2000

Jag gjorde ju en image från BBS-datorns gamla hårddisk för några veckor sedan, men kunde inte få den att fungera i WinUAE. Idag kom jag på varför. Jag hade trott att felet berodde på hur hårddisk-kontrollern fungerade. Den presenterade PCMCIA-slotten med en fakedisk som startade och lämnade över till den riktiga disken. Men faktum är att RDB-imagen fungerar ändå i WinUAE. Man måste bara välja Auto-IDE som controller. Sen startar den snällt. Här är några vyer från den i stort sätt orörda BBS:en.

2000-1

Man kan se att jag har loggat in två gånger 2001. Det var när jag första gången efter nedstängningen  gjorde en kopia på BBS:en och modularean. Det som är intressant är att datumen är rätt manglade. Detta beror på att tio senaste-listan helt enkelt inte hanterar datum efter år 2000. Detta fel har jag rättat i den BBS:en som nu är uppe och snurrar.

Här är de sista användarna att logga in år 2000 innan BBSen stängde. De två sista posterna är 2001-12-14 när jag som sagt kopierade filer från basen första gången jag räddade data från den. Då hade jag ett nollmodem mellan Jezebel (basdatorn) och en PC med Windows. Om jag minns rätt gick allting i hastigheten 57600 bps, så det tog nog en hel del timmar att få över allting!

Och så ännu en skärmdump med inloggningar.  Som synes är det min hårt prövade Cosysop och några enstaka användare som utgör hela aktiviteten.

Hårddisken kommer tillbaka…

1996 satte jag in en extra 341 MB hårddisk i BBS-datorn. Den höll diverse backuper och data. Exakt vad har jag inte riktigt koll på längre. Men jag har bestämt mig för att ta reda på det. Disken, som trasig, är nu inskickad till Ibas som ska kolla vad det kostar att extrahera data ur den. På denna finns troligen mer data som jag kan använda för att fixa fram statistik och mer intressanta historier från BBSernas historia. Vi får se vad som händer. Jag återkommer….

Vad körde folk på?

Alla modem är inte skapta lika. De första modemen gick på 300 bps, vilket motsvarar 300 tecken per sekund. När vi startade basen, körde de flesta på 14400 bps. Hösten 1994 kom 28800-standarden. Vi skaffade ett 28800 modem i början av 1995. Här är vad folk faktiskt kopplade upp med:

Statistiken gäller mellan 1995-01-25 och 1995-05-25

1200 63 2%
2400 614 18%
4800 2 0%
9600 276 8%
14400 1398 40%
16800 –
19200 178 5%
21600 10 0%
24000 –
26400 64 2%
28800 801 23%

Totalt antal uppkopplingar: 3466

Det är värt att notera att alla hastigheter utom 1200, 2400, 9600, 14400, 16800 och 28800 är anslutningar där störningar på telefonlinjen gjort att man inte nått full hastighet.

Slöare A1200 med WB 3.1.4?

Detta är en mer teknisk text, så om du inte är intresserad av Amiga-teknik, är det bara att titta vidare på sajten. Vi har många intressanta historier från BBS-världen.

2017 testade jag min nyinköpta och accelererade (Blizzard 1230 IV, 50 MHz 68030) Amiga:

Sen uppgraderade jag till WB 3.1.4. och då såg det istället ut såhär:

 Sen installerade jag FastExec, som flyttar Exec.library från chip till fastmem, då såg det ut såhär:

En förbättring. Men fortfarande sämre än värdena jag fick med gamla WB. Frågan är om det beror på att flytten av Kickstart-rommarna till fastmem inte fungerar längre. Kan tänka mig att en hel del av biblioteken ligger kvar i chipmem. Vet inte riktigt…