hjälp med primtalsprogram!

[huruvida]

Hejsan!

Jag gör just nu mitt gymnasiearbete med att programmera i basic på en C64 emulator. jag använder mig av simon's basic plug-in.
Jag gör ett program som skall räkna och skriva alla primtal mellan 1 och 1 miljard. Det mesta är färdigt, men det enda jag behöver
är något sätt att skriva i och läsa av en virtuell floppy disk. Har läst flera böcker med olika commands men inte hittat något sådant...
Snälla hjälp mig!

[Zeela]

Du vill alltså läsa och skriva data till/från en fil med C64:ans basic?

Här har du en bok i ämnet:
http://www.scribd.com/doc/55326181/Comm ... c-Tutorial

Se bara till att du har en d64-fil mountad i emulatorn så "det sitter en diskett i".

[huruvida]

tack!

skall läsa igenom direkt.

[hedning]

Jag gör just nu mitt gymnasiearbete med att programmera i basic på en C64 emulator.

Hur coolt är inte det? Hur kommer dagens ungdom på något sådant?

[sledge]

Hur coolt som helst!

[e5frog]

Anledningen är lärare, pappa eller annan vuxen med C64 kanske.

Om han använder WinVICE så får man väl rekommendera Alt + W vid körning.

Det finns över 78000 primtal under en miljon, de blir snabbt tresiffriga... så de får inte plats på en 171kB disksida...
Om någon vill klistra in i WinVICE:

Kod: Markera allt

0 printchr$(147):l=1000000:b=2:c=3
1 forn=ctol:ford=bto(n-1):ifn/d=int(n/d)then3
2 nextd:printn;
3 nextn
run



Istället för printn får man lägga in kod för att skriva till en fil, handlar väl mest om att öppna en fil och sedan skriva till den med print# kommandot. Sen får man väl kolla om disken är full och be användaren byta disk.
Hade man kört på riktig hårdvara kanske man skulle skickat datan till skrivaren.

Lägger man ett annat fönster ovanpå WinVICE x64 fönster så får man upp hastigheten 3ggr eller något sådant, lite mer än 4800% kom min upp på, tyvärr kör den bara på en processor.

[e5frog]

Hur länge har du tänkt låta programmet köra, vilken hastighet kommer du upp i?

Jag har kört mitt program sen jag postade, har kommit till 36187 och det tar ju längre och längre tid att testa (med den metoden)...

Om man hade låtit varje bit på en diskett representera ett tal, då skulle den räcka för att markera vilket som var primtal och vilket som inte är det, man börjar med att märka varannan bit av de en miljon bitar som man har valt, sedan var tredje etc etc... Undra om det skulle gå snabbare.

[e5frog]

Nu har mitt program hunnit ända till 119183.

[e5frog]

184651

[huruvida]

Så roligt att ni tycker om det! Varför jag ville göra detta som gymnasiearbete är för att jag hittade en commodore SX-64 i mina farförälders garage
när jag hjälpa dem städa det. Hade inget att göra den sommaren så började programmera. Sen dess har jag haft en god grundkunskap i BASIC och
tänkte att jag kunde använde det i mitt gymnasiearbete!

e5frog:

Kul att få se att det går att göra ett sådant program!
Jag använder mig av CCS 64 (svensk som gjort det!) och där kan man också snabba upp processen.
jag tänkte och använda mig av en virtuell diskett. Har inte den obegränsad filstorlek då?

Hur funkar "if n/d = int (n/d) then3" i din kod?

ett förslag på den koden är att ha "N=C to L step 2" så kommer det gå fortare!

[Iggelito]

"hittade en commodore SX-64"
<i Homers röst> why you little... </i Homers röst>

[carlsson]

INT-satsen returnerar heltalsdelen av ett tal. Med andra ord vill e5frog testa om resten blir noll, att N är jämnt delbart med D.

Angående disketter har jag aldrig använt CCS64, men jag vet att i VICE kan man arbeta direkt mot PC:ns hårddisk istället för att använda D64-filer. Däremot vet jag inte hur filhantering på fältnivå fungerar om man gör så, eller hur stora filerna kan växa till att bli.

Man kan väl ansluta en virtuell 1581, då får man lite högre kapacitet. Jag minns inte om VICE har stöd för SFD1001 så man skulle kunna få 1 MB stora disketter.

[e5frog]

Ja, det går nog lite snabbare att bara köra hälften av talen, jag stoppade ihop något snabbt och enkelt bara utan någon större tankemöda.

Blev ju lite sugen på att testa min "bitar på diskett metod", hade varit kul. Men från BASIC är det kanske inte så smidigt att peta med enskilda bitar. Man kunde laddat upp programmet till diskdriven och låtit det köra på för sig själv.

Det finns en del tricks för att göra sina basic-program lite snabbare, såg någon lista någonstans, Boray och Carlsson har väl gott minne gällande detta annars? Skippa alla mellanrum i koden du ska köra (för utskrift eller presentation kan man ha en mer ögonvänlig version) börja på 0, stega ett steg i taget. Använd långa rader... vad mer? Inga onödiga REM i koden, inga gosub, inte goto heller antar jag om det är möjligt att undvika. Variabler i alla beräkningar, går snabbare än att skriva siffror. Inte aktuellt här kanske men multiplikation är snabbare än ^ t.ex.

Har du någon uppfattning om hur lång tid det kommer att ta att köra igenom processen upp till en miljon?

Man kan också kompilera sin BASIC till maskinkod för att få upp hastigheten. Har aldrig lyckats testa detta själv.
Om man har lite olika förslag

CCS64 är trevlig, använde gärna den i helskärmsläge under DOS på Windows 98 men WinVICE har väl dominerat på senare tid, den är smidig.

[carlsson]

Mja, om långa radnummer är långsammare än korta är jag inte helt säker på. Det är väl i så fall vid GOTO och liknande som tolken behöver översätta fler siffror till radnummer. När det gäller GOTO och GOSUB går det bra så länge man lägger alla subrutiner i början av listningen, typ så här:

10 GOTO1000
15 REM SUBRUTIN 1
20 RETURN
25 REM SUBRUTIN 2
30 RETURN
....
1000 REM HUVUDPROGRAM
1010 GOSUB 15
1020 GOTO 1010

Det beror på att vid GOTO och GOSUB så kommer Basic att scanna alla radnummer från början av programmet tills den hittar önskad rad.

Undrar om inte ensam punkt . är snabbare än 0, dvs att IF A=. kommer att göra att punkten tolkas som värdet 0, men använder du variabler för återkommande konstanter är det säkert likvärdigt. Det finns fler sådana knep, nu minns jag inte alla.

I fallet med primtal tror jag det viktigaste är att hitta någon smart algoritm om sådan finns, istället för ett primitivt såll. Tyvärr är jag inte insatt i matematiken så jag har ingen algoritm tillgänglig.

[e5frog]

Om man har korta radnummer blir väl programmet mer kompakt, det går fortare för tolken att bearbeta, eller är jag fel ute. I ett sådant här program är väl varje liten sparad mikrosekund intressant.