Jump to content
IGNORED

How to make a modular program?


starraider

Recommended Posts

I am coding a strategy game in Turbo Basic (that I will compile later using the Turbo Basic Compiler), but it seems that memory is getting already low....

 

So I thought about making the game modular, loading only parts of the code into memory.....

 

My first Idea was to just replace programlines "on the fly" with the "Enter"-Command.

 

But whenever programcode is being loaded with "Enter", the game returns afterwards to Basic, showing the "Ready"-sign.....

 

So, how can I make the game continuing, after an "Enter"-command?

 

Is there any other method to make a program modular in Turbo Basic (without having to reload the main program and its variables over and over again)?

Link to comment
Share on other sites

Hmmm,

 

Thats odd, it may be a quirk with Turbo Basic, I used to do the very same thing with my old BBS software running on my Atari 800.... I bought a Magna 256K Ramdisk board, started using RDOS with OSS Basic XL and I had broken my BBS into modules and set aside I think it was lines 1000-2000 for modules to load in and this allowed me to really expand the software and create a much larger BBS for users, I kept each module in ramdisk so it would load as fast as possible, I also learned that trick with my password file as it used to be murder on my disk drives each time someone logged in until I finally got a Corvus 10mb HD, but other then the system locking up about twice a day which was fairly typical, sometimes it would last for 2 days which was a miracle, I never encountered the system stopping and going to a ready prompt. ENTERing code was always a tricky thing for the Atari's, the system just wasn't stable enough.

 

I believe Forem Pro also did this, but of course, it was done in assembly and ran very fast and clean.

 

 

Curt

Link to comment
Share on other sites

i am not sure if this is possible for a compiled turbo basic program (as it's now mashine language...) but you could try to do this:

 

1000 exec load_part

1010 gr.0

1020 print "enter"d:part2.lst""

1030 print "cont"

1040 position 2,0

1050 poke (i have forgot this adress!!!),13

1060 stop

1070 endproc

 

the idea is to print the commands on screen to load the new parts... then you fake a "return" in the keyboard buffer which is simulated by poking 13 into the buffer or the special adress (842?)

 

of course the print command in 1030 is wrong as you will need to do something like this:

 

print "enter";chr$(???);"d:filename.lst";chr$(???)) where ??? is the value for the ".

 

i am not sure if this works. sorry. i have done this once or twice in nearly 15 years and i have forgotten how... maybe others could help?

 

what code does the "loaded part" contain? if it's level data or grafics then you can use the "BLOAD" command to load binary files directly into memory without any hassle...

Link to comment
Share on other sites

POKE 842,13 puts Basic into automatically entering carriage returns, and POKE 842,12 clears it.

So you could enter POKE 559,0 to disable the display, flip to graphics 0, Use PRINT commands to enter this (for example)...

 

(the Atari screen)

STOPPED AT LINE XXX

READY.

ENTER "D:SECOND.LST"





CONT







 

Then you would position the cursor at the top of the screen as you said, POKE 842 with 13, and use the STOP command.

Although you wouldn't be able to see it because of turning off the display, the cursor will enter through those "ENTER" and "CONT" lines you PRINTed, and load the next part from the disk before continuing at the next line number following where it STOPped. When the program is resumed, use POKE842,12 to clear this "auto-return" mode, restore your display and turn it back on with POKE 559,34. The lines in the running program will have been modified by the contents of the file you ENTERed from disk, and all variables will be intact.

 

This method is kind of slow though...a better way is to manage your memory better...perhaps by using random-access files to hold values that you would have used DATA commands for.

 

For example, rather than holding DATA lines in the program for a redefined character set, use this instead...

 

OPEN #1,4,0,"D:CHSET.DAT"

 

POKE 852,CRLO:POKE 853,CRHI:POKE856, 0:POKE 857,4:POKE 850,7:X=USR(ADR("hhh*"),16)

 

CLOSE #1

 

(red is inverse)

CRHI/CRLO would be the address of the redefined character set. and the 0 and 4 would be the low/high values of the number of bytes to read (0+256*4). The final POKE is used for read mode (7=read, 11=write)

The file CHSET.DAT in this case would be a 1024-byte file holding all the values that you would have otherwise POKE'ed into memory the slow way of READing them from data lines in the running program itself. That's over 1k of memory you just saved.

Link to comment
Share on other sites

thanks...! ;) my "RAM" works stilll with 842.... hahaha.... strange that you forget more your PIN for your credit card or mobile phone but you won't forget atari stuff...esp. registers... ;)

 

nukey thanks for your explanations but your code is pure atari basic...

 

OPEN #1,4,0,"D:CHSET.DAT"

 

POKE 852,CRLO:POKE 853,CRHI:POKE856, 0:POKE 857,4:POKE 850,7:X=USR(ADR("hhh*LVd"),16)

 

CLOSE #1

 

 

this would be much nicer in turbo basic:

 

open#1,4,0,"d:chset.dat"

bget #1,charbase,1024

close#1

poke 756,charbase div 256

 

where charbase is the RAM adress to load the font to...

 

starraider you should hold data abeginning from the top of RAM downwards...

 

so from $bfff downwards as DOS + turbo basic XL + your code need some RAM as well... you can block RAM against overwriting by pokeing ramtop adress into 106...

 

so f.e. you want to keep $8000-$bfff free for your data...poke 106,$80 (or $7f? again not sure...) now your available free memory for basic will be less ... check it with print free(0).

 

nukey.... will this method work when the turbo basic code is getting compiled???

Link to comment
Share on other sites

It should...IIRC the memory addresses 850-857 are used by the Atari computer's hardware file access (not Dos), so it should work regardless of Basic/ML versions.

 

And the code is pure Atari Basic, because that is what I used ;) I have no clue about more advanced Basics (though I have compiled a few using Advan).

Link to comment
Share on other sites

First of all, thanks for the many replies!

 

This is my first coding experience on the Atari since about 10 years, but it's fun :D

 

Since then, I have only coded in Java, so now the 34k of free ram seem much less to me than they did back then....I really thought that I could code the complete game in about 16k, but now I see that I might have only implemented about 10% of the complete game and over 10k are already gone....I can forsee that I won't be able to implement all the features I had in mind, just bc of the lack of RAM and thats really a pity....

and I am talking solely about functionality, no graphics or sound-fx are coded yet at all! Additionally, I will need some really BIG datafields, as huge amounts of data are being used and collected during the game....

 

 

If anyone is interested, it will be a managergame where you start as a garagecompany, back in the 70s, to manufacture your first computer ;)

 

You will be able to buy all the cpus of that time, starting with the very first Intel 4004 until the Pentiums of today.....

 

So you ever dreamed of building a computer with the Antic and the Sid-Soundchip? Here you go, see how well it will do on the market :)

 

Or if you think all those chips won't satisfy your needs, invest in your own r&d-team to develop the best cpu of all time.....

 

If you're low of cash, go to the bank, get some funds, but beware! you have to pay back every single cent some day!

 

etc, etc.....

 

So I hope it will be fun to play with some accurate data, like the original launching dates of the Cpus, and some economic background (as I have studied business administration, it should be of some use at last ;) )

 

So mainly it will be text-based only at this early stage, I do not plan any fancy graphics or sound-fx, despite maybe a titlescreen and titletune....

 

So now back to the topic.....

 

Yeah, I am afraid too, that it might not work with the compiler, but since speed isn't crucial (not yet at least), it would be ok to not compile it at all....I plan to release the sourcecode to the public anyway (if anyone is interested), so that wouldn't be much of a problem.....of course, it just doesn't look as "professional" as a compiled program, oh well...

 

I just wonder how did the gamecompanies do it? I can't believe that, e.g., complex text-based adventures, like "The Pawn" from Magnetic Scrolls were entirely programmed in assembly language.....those games load constantly from disk....or do they just load contents into variables?

Link to comment
Share on other sites

Huge amonts of data eh? In that case, how about coding it with a Ramdisk in mind? Or coding it as several "mini's" and using specific addresses in lower memory to hold your variable values? (POKE addresses 1536-1701 are good for this...as page 6 is normally left unused).

Link to comment
Share on other sites

I just wonder how did the gamecompanies do it? I can't believe that, e.g., complex text-based adventures, like "The Pawn" from Magnetic Scrolls were entirely programmed in assembly language.....those games load constantly from disk....or do they just load contents into variables?

 

Beside of creating some graphics and sound...

I can't see any problem by coding an adventure in Assembler because you need simple compare , branch and jump routines...

At a lower level of coding you can simply use the ROM-routines for IO...

A Friend of mine and I did once a try on an adventure in basic... To go through 4 screens did take use of about 16K of Basic Data. The most of this data was in the parsing. In machine code it would be 1/10 of program data.

 

For your Basic-program: If you want to pack the game into more parts, you can use an unused page and poke the variables in there. Then you can simply "run" the next program and peek the variables from this page...

Link to comment
Share on other sites

As far as simple adventure-type games go, those don't have much "program" at all...just a limited set of instructions that the game understands and a few variables that hold the "winning" conditions. Even a two-byte word has the capability to be able to indicate 1 of 65536 different rooms/scenarios...and the program uses that number to point to a certian spot on the disk to gather the next room or group of rooms' data and description (which is how come the constant disk access).

Link to comment
Share on other sites

Or coding it as several "mini's" and using specific addresses in lower memory to hold your variable values? (POKE addresses 1536-1701 are good for this...as page 6 is normally left unused).

 

If you want to pack the game into more parts, you can use an unused page and poke the variables in there. Then you can simply "run" the next program and peek the variables from this page...

 

Those are some good ideas, thanks!

 

The Poke 842-method worked fine, by the way...Thanks to Nukey and Heaven!...I am able to load different programmodules into memory now, the loading speed is ok as I try to keep the modules compact....

 

I might use a combination of the several techniques....I will have to see which one suits me best....

 

You might be right about the adventures, I was always faszinated about how accurate the parser of those games have usually been....

Link to comment
Share on other sites

I can't recall exactly, but I believe that if there is a keypress registered in location 764 when the STOP command is issued, it might be transferred to the screen right below the "ready" prompt. So you want to print those other commands a bit lower to take the eventuality of a syntax error popping up on the editor screen (obscuring the instructions it was supposed to execute)...or, clear this location just prior to where it is stopped by a POKE 764,255

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...