Running out of memory in TurboBASIC

[Synthpopalooza]

I can't seem to get it to crash in either emulator.

 

I just noticed I am using v1.6 of altirra. May try using 1.9 to see if that fixes it

 

UPDATE: Altirra 1.9 still gives me an error 136 anytime I try to open my test file TEST.ICE and do a get #1,a on it. Even doing it in immediate mode does nothing for me. And this works properly in Atari800Win.

Edited August 7, 2011 by Synthpopalooza

[phaeron]

Took me a while to figure out that you're reading over the H: device. Disable burst I/O to bypass the problem -- there's a bug in the emulator where the burst I/O code doesn't properly handle the special case of a zero byte read, which is used by BASIC interpreters.

[Synthpopalooza]

Took me a while to figure out that you're reading over the H: device. Disable burst I/O to bypass the problem -- there's a bug in the emulator where the burst I/O code doesn't properly handle the special case of a zero byte read, which is used by BASIC interpreters.

 

 

Thanks! That has been bugging me ... and I much prefer using Altirra for this project, as it does a more accurate emulation of the CIN modes used in this editor .. more specifically, Graphics 12 with GTIA settings ... Atari800Win does not handle these properly so they look wrong.

 

 

[Alphasys]

That "user input" one was a joke.

 

But yes, doing such input from disk would be a memory saver.

 

Another one if the RAM isn't being used could be to have a RAMDisk handler that uses RAM under the OS. Give it NOTE/POINT ability and you can do nice random access.

 

Since it's Turbo Basic, the RAM under the OS is used. That's where the bulk of TB resides.

 

Anyways, some tips to make this smaller, probably repeating some:

 

1. Data statements -> external file, using bget or maybe even bload (if the locations are always the same).

2. Commonly used constants -> variable

3. asc("x") statements -> constants

4. Use binary and/or/eor (&, |, exor) where applicable.

E.g.:

17086 ZZ2=SCR+(PY+4)*40+PX:Z2=PEEK(ZZ2):ZZZ=Z+128*(Z<128)-128*(Z>127)

Will become

17086 ZZ2=SCR+(PY+4)*40+PX:Z2=PEEK(ZZ2):ZZZ=Z EXOR 128

and

170 IF K=ASC("*") THEN ECHAR=ECHAR+1:ECHAR=ECHAR-128*(ECHAR>127):EXEC UPDATECDISPLAY:A2=1:EXEC CDIS:GOTO 174

will become

170 IF K=42 THEN ECHAR=ECHAR+1:ECHAR=ECHAR & 127:EXEC UPDATECDISPLAY:A2=1:EXEC CDIS:GOTO 174

5. Make compound statements to save on superfluous line numbers.

6. Pre-calculate constant expressions.

E.g.:

176 IF ECHAR=27 THEN POKE SCR+17*40+31,219

will become

176 IF ECHAR=27 THEN POKE SCR+711,219

7. Reverse stick handling: When you exor the stick inputs with 15, the bits will become 1 instead of 0, and bitwise ands can be used to see the direction easily.

E.g.:

210 S=STICK(0)

220 IF S<15

221 POKE 53279,1

222 EXEC GRIDCURSOR

223 A2=0:EXEC CDIS

230 GX=GX+(S>4 AND S<*2:IF GX>11 THEN GX=5

240 GX=GX-(S>8 AND S<12)*2:IF GX<5 THEN GX=11

250 GY=GY+(S=9 OR S=13 OR S=5):IF GY>8 THEN GY=1

260 GY=GY-(S=10 OR S=6 OR S=14):IF GY<1 THEN GY=8

270 EXEC GRIDCURSOR

271 PAUSE 5

275 ENDIF

will become

210 S=STICK(0) EXOR 15

220 IF S

221 POKE 53279,1

222 EXEC GRIDCURSOR

223 A2=0:EXEC CDIS

230 GX=GX+((S & >0)*2:IF GX>11 THEN GX=5

240 GX=GX-((S & 4)>0)*2:IF GX<5 THEN GX=11

250 GY=GY+((S & 2)>0):IF GY>8 THEN GY=1

260 GY=GY-((S & 1)>0):IF GY<1 THEN GY=8

270 EXEC GRIDCURSOR

271 PAUSE 5

275 ENDIF

 

Maybe this will help you get those coveted bytes back.

 

Last tip: COMPILE the program. This doesn't always help, but usually a compiled turbo basic program takes up less space.

[Synthpopalooza]

Thanks for the tip ... Compiling isn't an option yet, when I tried to compile it last time the program behaved strangely, tho I may try it again. Never really learned how to do bitwise ops, but I will try that as well. Funny how you can still learn new tricks about 30 years later!

[+therealbountybob]

Yes nice info alphasys

 

Stupid question but have you worked out how many extra bytes you need to free up - it may need a more drastic change

[flashjazzcat]

There are certain things the compiler just doesn't like, although sadly I never bothered to write them down fifteen years ago when I was working on a large compiled project. The problems can usually be worked around by a process of trial and error and recoding things in a different way.

[Synthpopalooza]

It appears, for now, I have worked up enough free bytes for my program (in fact, all three of them) to work properly without freezing or crashing, although in the future if I need to add additional code, I may need more bytes.

[flashjazzcat]

It appears, for now, I have worked up enough free bytes for my program (in fact, all three of them) to work properly without freezing or crashing, although in the future if I need to add additional code, I may need more bytes.

Fun, isn't it!

[Alphasys]

It appears, for now, I have worked up enough free bytes for my program (in fact, all three of them) to work properly without freezing or crashing, although in the future if I need to add additional code, I may need more bytes.

 

If you really need to keep all the code in the program (Since you could also initialise some stuff, then run the actual editor as a separate file) your best bet is then actually to get as much code into Machine Language. This will also speed up certain things considerably. Parts of your code are pretty easy to turn into Machine Language. It won't make it better readable, nor easy to maintain, but that's just what you have to get over with if you really need the code as short as possible.

[Synthpopalooza]

It appears, for now, I have worked up enough free bytes for my program (in fact, all three of them) to work properly without freezing or crashing, although in the future if I need to add additional code, I may need more bytes.

Fun, isn't it!

 

Loads of fun. I have been working on this project for over 2 years, and that includes experimenting in the new display modes this editor supports, and writing extensive documentation for them. Lots of hard work.