BLOAD en BSAVE problematiek

Pagina 2/2
1 |

Van [D-Tail]

Ascended (8259)

afbeelding van [D-Tail]

27-08-2007, 22:37

OK, ik heb een stukje research gedaan... wanneer niet he? Wink

Het blijkt volgens m'n boek dat F676-F677 [TXTTAB] het BASIC startadres bevat. Zover waren we al. Nu voor het eind van BASIC. F6C2-F6C3 [VARTAB] bevat het beginadres van het opslaggebied voor variabelen. Dit adres varieert naarmate het programma in lengte varieert (dus, variabelen komen sequentieel ná het programma, maar dat was ook al bekend). F6C4-F6C5 [ARYTAB] is hetzelfde, maar dan voor arrays. Deze verschuift uiteraard ook als je een nieuwe variabele introduceert. Arrayvariabelen komen na gewone variabelen. F6C6-F6C7 [STREND] bevat vervolgens het eindadres van het BASIC programma, inclusief de ruimte voor alle (array)variabelen. Wil je dus op een gegeven moment een 'snapshot' van je programma maken, dan bewaar je dus vanaf het adres waarnaar verwezen wordt in TXTTAB, tot (NIET tot en met) STREND. Moet je nog wel je strings apart opslaan, aangezien daarvan slechts een verwijzing wordt ogpeslagen in VARTAB, maar dat spreekt voor zich.

Nu over de werking van je programma.
Als ik het goed begrijp wil je een BASIC programma binair laden (waarom is me eigenlijk een raadsel, maar toe maar). Dit is vrij eenvoudig. Maar het programma uitvoeren is totaal andere koek! Goed, de procedure.

1. Schrijf je programma dat je binair wilt bewaren
2. Schrijf de adressen TXTTAB, VARTAB, ARYTAB en STREND op. Voor nu ga ik even uit dat die gevuld zijn met &h8001, &h8023, &h8033 en &h8043.
3. Bewaar het programma van TXTTAB (dus niet TXTTAB-1 ofzo) TOT STREND

4. Schrijf je loader. Die wil je laten beginnen op het adres wat in STREND gespecificeerd staat, en wel als volgt:

1 ' loader.ldr
10 if peek(&hF676) <> &h43 or peek(&hF677) <> &H80 then poke&hF676,&h43: poke&hF677,&h80: run "loader.ldr"
20 bload "binair.bin" ' Zie commentaar 1
25 ' Zie commentaar 2
30 poke&hF6C2,&h23: poke&hF6C3,&h80 'VARTAB
40 poke&hF6C4,&h33: poke&hF6C5,&h80 'ARYTAB
50 poke&hF6C6,&h43: poke&hF6C7,&h80 'STREND
60 poke&hF676,&H01: poke&hF677,&h80 'TXTTAB
70 run ' Zie commentaar 3

Commentaar 1: Nu staat ons binaire BASIC programma dus VOOR de loader in het geheugen. Hier wordt nog niets mee gedaan, het staat er alleen. Dit komt omdat je het startadres van BASIC en de bijbehorende variabeltabelpointers en eindadressen verandert hebt om de loader z'n werk te laten doen.
Commentaar 2: De belangrijke adressen TXTTAB, VARTAB, ARYTAB en STREND goedzetten voor het binaire BASIC programma.
Commentaar 3: Ik heb geen idee of dit werkt.

5. Nu is het zo dat loader.ldr de systeemvariabelen zo zet, dat ze werken voor het binaire programma. Ik kan me voorstellen dat BASIC flink op z'n bek gaat als je STREND verandert in een adres ONDER de pointer naar de huidige instructie. Dat is wezenlijk wat de loader doet in regel 50. Ik zou zeggen, probeer dit uit, en als het niet werkt, verander VARTAB, ARYTAB en STREND als eerste instructie in het binaire programma.

Ik hoop voor je dat dit een werkende oplossing is.

Van [D-Tail]

Ascended (8259)

afbeelding van [D-Tail]

27-08-2007, 22:54

WICKED!

Mijn vorige oplossing werkte [helaas] niet. Ik vergat dat een BASIC programma moet starten met een 1-byte header met de waarde '0' (FE is een binaire header). Als je vóór 'run"loader.ldr"' even een poke STREND-1,0 invoert, dan werkt-ie. Tataaa... Missie geslaagd.

Van [D-Tail]

Ascended (8259)

afbeelding van [D-Tail]

27-08-2007, 22:58

Ten overvloede, ik ben lekker bezig met m'n postcount in deze thread, mijn programma's en manieren enzo:

10 PRINT "Mijn eerste binaire programma!"
20 END

BSAVE "binair.bin",&H8001,&H8030

LOAD"loader.ldr"
# adressen van TXTTAB, VARTAB, ARYTAB en STREND aanpassen

RUN
Mijn eerste binaire programma!
files

Aldus mijn proof-of-concept.

Van AuroraMSX

Paragon (1902)

afbeelding van AuroraMSX

30-08-2007, 20:57

Hannibal Well done, master Tailz... The MSX Force is strong in you

(Fok, ik wil een <:yoda:> slimey!)

Van JohnHassink

Ambassador (5605)

afbeelding van JohnHassink

31-08-2007, 00:06

Hannibal Well done, master Tailz... The MSX Force is strong in you

(Fok, ik wil een <:yoda:> slimey!)

En ik wil wel een Slimer smiley! Leuke tongbreker, ook. ;)

[enigszins on topic]Mee de fors bie wis joe![/enigszins on topic]

Van Laurens

Supporter (7)

afbeelding van Laurens

09-09-2007, 22:02

@D-Tail: Bedankt voor je inspanning. Ik ga er gelijk deze week mee aan de slag. (ben net terug van vakantie)


Nu over de werking van je programma.
Als ik het goed begrijp wil je een BASIC programma binair laden (waarom is me eigenlijk een raadsel, maar toe maar). Dit is vrij eenvoudig. Maar het programma uitvoeren is totaal andere koek! Goed, de procedure.

De reden dat ik binair wil opslaan en inladen is kijken of het laden sneller gaat dan laden via Basic. Ik ben nl. met een menu aan het fabriceren dat vrij flexibel moet gaan werken, alleen wordt ie nu een beetje traag naarmate er meerdere opties in komen.

Van AuroraMSX

Paragon (1902)

afbeelding van AuroraMSX

12-09-2007, 20:35

De reden dat ik binair wil opslaan en inladen is kijken of het laden sneller gaat dan laden via Basic.k Betwijfel het. Je verandert alleen 't formaat van de file, niet de eigenlijke info: t Blijft BASIC. Als je echt snelheidswinst wil halen zou je es kunnen kijken NestorBASIC/NestorPreter ...

Van [D-Tail]

Ascended (8259)

afbeelding van [D-Tail]

12-09-2007, 22:41

AuroraMSX: dat is bij de executie van de BASIC code, niet bij het laden ervan. Ik denk zeker dat een BLOAD (marginaal) sneller is dan een LOAD. Dit is puur speculatie van mijn kant, gebaseerd op het feit dat *alles* te BLOAD'en is, terwijl een LOAD ook kijkt naar de header van een bestand en met fouten gooit als er iets niet 100% in de haak is. Maargoed, aan de andere kant denk ik dat het snelheidsverschil te verwaarlozen is. Laurens' motief om 'te kijken wat sneller gaat' is dus terecht, dat scheelt ons weer testen he!

Maar de reden dat een menu trager wordt naarmate die groter wordt, en dat in verband brengen met het laden van een BASIC file ontgaat mij een beetje. Vanuit dat menu laad je pas een programma op het moment dat je keuze daarop gevallen is, toch? In het geval van een filelisting uitlezen kun je dan beter NBASIC gebruiken ja.

Van AuroraMSX

Paragon (1902)

afbeelding van AuroraMSX

16-09-2007, 14:24

het feit dat *alles* te BLOAD'en is,
Ehm... alleen files die beginnen met #FE Smile Ook hier wordt naar de header gekeken. Namelijk om begin, eind en executie adres van de file te bepalen.

terwijl een LOAD ook kijkt naar de header van een bestand en met fouten gooit als er iets niet 100% in de haak is.
Hm, dat hangt vermoed ik (ja, ook speculaasjes Smile) af van t type BASIC file. Als je de platte ASCII versie neemt (BSAVE"blah.bas",A) wordt t laden inderdaad traag: elke regel text wordt afzonderlijk ingelezen en net zo verwerkt alsof je m versch hebt ingetypt (voor de kenners: via (P)INLIN). Een getokenized BASIC progje (BSAVE"blah.bas" ) wordt volgens mij gewoon naar RAM gedumpt, als ware het een BLOAD dinges.

Maar ik ben wel nieuwsgierig naar Laurens' bevindingen...

Van Laurens

Supporter (7)

afbeelding van Laurens

17-09-2007, 10:34

Bij dezen heb ik een aantal tests gedaan, en met het opstarten van de msx met de disk in de drive tot aan het aanwezig zijn van het menu op het scherm van de tweede diskette is de binaire variant niets sneller dan de gewone, het lijkt zelfs dat de binaire variant iets trager is. Beide zijn in 17 seconden opgestart, de binaire soms in 18. Dan komt idd het Nestor Basic verhaal eerder aan bod, maar dan moet ik me daar eerst in verdiepen. Toen ik de msx voor het laatst in de kast gezet had jaren geleden wist ik van het bestaan ervan nog niet af... ben toen met de pc in Quick Basic / Turbo Basic verder gegaan. Het menu programma is dan ook een vervolg op programma's die ik toentertijd voor de pc gemaakt heb in het verleden voor DOS en nu ik dat weer op de MSX wil doorborduren is het net kantje boord met het geheugen en de snelheid van de machine. Wat ik misschien ook nog zou kunnen doen is het programma in twee afzonderlijke programma's opsplitsen waarbij er een menu programma en een menu editor ontstaat. Dan hoeft bij elke diskette de editor in ieder geval niet meer meegeladen te worden...

Met het trager worden bedoel ik de tijd die het programma nodig heeft om in te laden en op het scherm te verschijnen. Het programma laadt bij opstart het menu

Bdw: ik save de basic bestanden alleen in ascii formaat als het echt niet anders kan, zoals het aanmaken van ldr bestanden vanuit een basic bestand of communicatie met de pc om met een geavanceerde text editor een heel programma onder handen te nemen.

Pagina 2/2
1 |