General Category > Programming

BASIC programming tips

<< < (2/28) > >>

AMSDOS:
I made up some speedy was of drawing stuff in BASIC (of course it was all based on Loops and drawing shapes like Circles), the idea was to vision the Memory as one large array just waiting to be filled. It would require two programs one which would draw the Image and Poke it to memory and the second to pull it back out of memory and draw it on screen really quickly. In the inital program to make it perform faster I wrote a simply POKE16 to POKE 16bit Numbers quickly into those memory allocations. Just making a Poke to Poke 16bit Numbers is handy in itself cause it just feels like your knocking two birds with one stone sort of thing!  ;D  Unfotunately I can't find my examples!  :(  Probably have to obtain it from my other dying computer before the HD dies!

AMSDOS:
#1 Tip for people using BASIC:
 
* Never ever use "GOTO" unless you fancy a bit of Spaghetti Programming or as a Looping effect!  ;D
* Responcible "GOTOs" are possible if you keep them Local to a routine which is being applied, Bad is when a program is all over the place - moving to other sections which aren't related, or is a subroutine in which case should of been GOSUB instead!

Gryzor:
Damn, 20 years too late...

AMSDOS:
Gryzor wrote:

Damn, 20 years too late...

Heh!  ;D  I think everyone has been guilty of using GOTOs at one stage or another.  8)  I simply reduce them to what I could and was surprised by the result in the readability of my programs. Of course Amstrad Magazines like AA would try to help people understand BASIC better with Tutorials and they might have suggested to restrain using GOTOs as well, not sure if this ever came though. I simply restrain from using it as much as possible in BASIC cause I keep it to "0" GOTOs in my Turbo Pascal programs - and yes Borland were very naughty to incorporate GOTO into Turbo Pascal and some very naughty Turbo Pascal 3 website recommends the use of it!!  >:(  It should have been excluded cause it's not of a True Pascal at all!  One BASIC program I was interpreting did present a problem in TP cause of a certain GOTO in it. In the end I managed to write it with without any GOTOs by making an Array which returned the values the original program had - it was looping in such a way it was like "320 DO this : Do that : Do this as well : GOTO 320".
 
Which brings me to my next point  ;D  Having stacks of Code separated by the Colon ":"  per line is another one of those it's getting hard to read code. I guess the main problem here is for a program to be published in a Magazine, it was always better to stack in the code per line. I guess it's one of those things where if you wanted to learn some BASIC programming, nobody was around to say - just separate the code per line - you simply typed in the program and do whatever the program did. Keeping a line to a specific command is breaking the code into something more readable cause you can begin looking at the process of the program. The other thing I like is separating a BASIC program into it's own Line Numbers to give it more identity. "Renum" is sort of a enermy in a way cause a standard RENUM turns your program into that usual format of "10,20,30,40,50,etc" - Yeah sure you might have "10,20,30,40,50, etc" as your Main Nerve center of your BASIC program - the bit which runs the rest of the program, check out my Collision Detection Game for example and see how it's structured! I've set it up in such a way that it's got a main core, and then the routines are separated with the Line Numbers. This helps to define what belongs to what and kind of defines what an easy to read BASIC program should look like!  ;D  Of course over the years Magazines presented this standard way of presented programs, Authors were subjected to presenting their programs in such a way they could only cram in 255 bytes of Text per line cause it had to be a 10 Liner or because it helped to reduce space a program would take up (as in AAs case they were always on about making a program consume less space by cramming in longer BASIC lines). Though as a suggestion it maybe possible to take some of those programs and make them more readable. RENUM can be used properly when it's understood. The proper way to use RENUM is to issue a new Line number first, followed by the Old Line number and a third parameter relates to the Increment of it, so it looks like this RENUM <new line number>,<old line number>,<increment>. Just avoid the programs which have GOTO everywhere!  ;)

arnoldemu:
Basic and using extra 128k ram:

Using OUT &7F00,&C4 or similar to change bank is not 100% safe with BASIC.
In fact, if HIMEM is between &4000 and &7fff, expect problems.

Normally you can "get away with it", if HIMEM is high (above &8000) and your basic program is small and doesn't use many variables.
You can also safely work with BASIC and banks if you set HIMEM < &3fff. But for large basic programs this is not useful.

But if your basic program is big (goes past &4000), or uses lots of variables (so fills up memory down from himem), or himem is low, you will find problems.

Basic doesn't know about the ram banking, and so if you change bank and then do something with BASIC it could read bad data and this will cause program to stop working, or work unpredictable.

So how can you solve this?

The best way is to use some assembler functions to help you to access the bank in a way that is safe for BASIC. e.g. You have control over banking, and only return back to basic when normal ram banking is set back (e.g. OUT &7F00,&C0).

Your asm code is then responsible for changing the bank to the one you want, doing some work, and then returning the banking back to normal.

Basic stores font/symbol data below himem. Then below this it stores strings and variable data.

Using these recommendations, HIMEM can be anywhere you want (sensible values), and you can still use the extra ram for data.

1. Use Bank manager. This is useful for reading/writing extra ram.

2. You need some asm/rsxs to handle your banking. You need to put this above HIMEM where BASIC can't touch it.
The asm/banking needs to be above &8000 so that it is safe when you bank memory into the range &4000-&7fff.

3. If you are loading data into the extra ram, then consider having an rsx, or asm function to do this safely:


--- Code: ---setbank:
        ld (BuffBank),a
        and &3f
        or &c0
        ld b,&7f
        out (c),a
        ret

BuffBank: defb 0

;; CALL loadbank,<filename>,<address>,<bank>
;; e.g. a$="filename":call @a$, &4000,&c4

loadbank:   
        ;; load address
        ld l,(ix+2)
        ld h,(ix+3)
        push hl
       
        ;; string descriptor (note this is in main ram, so we can't change bank until
        ;; we have read the value. In addition cas in open needs to see it too. So either
;; copy filename to a buffer, or change bank when we read data.
;; Note, the buffer for AMSDOS or tape, needs to be above &8000. Normally for disc it is around &a700, and for tape a bit higher.

         ld l,(ix+4)
         ld h,(ix+5)
                           
         ;; length
         ld b,(hl)
         inc hl
;; address of chars in string
         ld a,(hl)
         inc hl
         ld h,(hl)
         ld l,a
         ;; address of string
        ld a,(ix+0)
        push af
;; this 2k buffer needs to be outside of &4000-&7fff. With binary it can be any value because the buffer is not used.
         ld de,&c000
         call cas_in_open
         pop af
         call setbank
         pop hl
         call cas_in_direct
         call cas_in_close

;; restore back for basic         
         ld a,&c0
         call setbank
;; return to basic
         ret

--- End code ---

4. Any functions that access the extra ram, must set the ram bank, do some work and restore it. Remember if you are accessing any basic variables, then these are in main ram, so you need to read them and remember their data, now change banks, now work with them, and then restore bank back.

If you follow these tips your programs will work safely with basic, you can set himem as you want, and have less bugs.
 

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version
Powered by SMFPacks Reactions Mod
Powered by SMFPacks Alerts Pro Mod
Powered by SMFPacks Mentions Pro Mod