Or “I finally learned how to use more memory”
Often while folks gather and talk about their computers I hear something like this, “Why don’t you try this” and the almost standard reply is “I didn’t know you could do it that way, thanks” This article is the result of my being in that same boat and finding an answer by myself.
Way back when, really just last May (1987) during the T/S Midwest Computer Fest held in Indy, I found enough time to visit with Tom Bent and Tom Woods. The purpose was to get one of the 64K Non-Volatile RAM (NVM) boards they are selling for my trusty Timex 2068. The current version uses 43256 120ns type 32K static RAM chips allowing you to operate with 32K or 64K of RAM on the board and retain the 43256 chip memory with a battery backup method. Current battery life expectancy reaches beyond the life of the 2068 or you and I if you follow the guide lines in the owner’s manual.
One of my major problems in writing a BBS program in BASIC is/was, the size of the program directly affects the amount of features and messages it can contain in 38K of HOME RAM in an unexpanded 2068.
I wanted to experiment with the 64K unit by placing the BBS program in the Timex Command Cartridge port. I wanted to escape the problems of trying to fit additional features in the BBS program and retain the original size of the message base in the computers memory. I was excited with the prospects of the additional features I could add to the program with an extra 32K or 64K of RAM available, and still retain the original message base size the program uses.
After the dust from handling the Fest settled I placed an order with my local mail-order house for 2 43256 32K static RAM chips and read/reread the manual for the board until the chips arrived.
Well, to put it mildly, I failed to understand everything in the owner’s manual, even after 2 or 3 readings. I followed the directions as I understood them. Every time the program I installed in the NVM memory ran and tried to use the short section of machine code it crashed on me. Sure, there was something I was doing wrong, but what, I didn’t realize.
So I did a silly thing. I set the darn thing aside and proceeded onto other things. Like learning to live with my Oliger Disk interface. Even the wife became interested in the 2068 after the disk setup was finished.
In Sept. 1987, our user group received about 2 megabytes of public domain programs for the 2068. The first thing we did was to place all those programs on disk. In an effort to clean up, weed out duplicates, and to reduce the total disks needed, I had to come up with a way of managing my disks. I ended up with a program that did what I wanted, but every time I had to FORMAT a disk I had to LOAD the file 0 loader program that Oliger’s SAFE program can use, SAVE it to file 0, then reload my Disk File Manager program. I needed a better way.
DING!!! A light went on. I have this NVM board sitting there doing NOTHING. Sure would be nice to put my manager program on it so that I could use it without having to do a lot of disk swapping. In a fit of late night brilliance everything finally clicked. I had made it!
My programming efforts were now using the 64K NVM board in the DOCK port and machine code worked, DATA/READ worked, operating the Oliger disk interface from BASIC in the NVM board worked. Now I can use the DOCK port memory and have the original 38K of HOME bank memory available. At this time I am using the NVM board to contain a program and the original HOME bank of memory holds all the variables used by that program while another BASIC program is loaded. So I have 1 program in the DOCK port, 1 program in the 2068’s HOME memory, and plenty of room for variables.
If any program you wish to place on the NVM board contains machine code, it should be programed to operate and be stored starting at location 26688 (there is another way to run machine code out of the DOCK port, but that secret escapes me so far, I was elated to just make this much work). Then include a subroutine in your main program to POKE the code into memory starting at 26688. Make sure you POKE all your code. I used a DATA/READ method, and it worked with raw numbers and with a $ string variable. That should be relatively easy to do. Also try to make sure all the bugs are dead in the rest of the your program.
Next VERY carefully follow the guide lines in the NVM owner’s manual for relocating the 2068 system variable PROG, then the movement of the program you want placed into the NVM board.
NOW for the POKEs as given in the manual.
- POKE 32768,1 tells the system you have BASIC, or BASIC and machine code to deal with.
- POKE 32769,2 tells the system you are trying to use the AROS feature of the 2068.
- POKE 32770,8 is the first of a 2 byte indicator to inform.
- POKE 32771,128 the 2068 that BASIC in the NVM board now starts at 32776.
- POKE 32772,15 specifies the memory CHUNKS you are using to hold the program to be ran by the computer. That is the NVM’s memory area it occupies for your utilization at this time.
- POKE 32773,1 AUTO runs the basic program contained in the NVM board.
- POKE 32774,xx and
- POKE 32775,xx the values stored here inform the 2068 of the size of area you need for your machine code. This info is needed so that the 2068 can find out where the BASIC and variables sections will end up being found in HOME memory. Yes, as I understand it, this info changes as you move from DOCK to HOME memory and back. Use these conventions to determine the values for these 2 POKEs. 32774 will need the value found by code size (INT(code size/256)*256), 32775 will need this value INT(code size/256).
Remember that a POKE 23750,0 restores the HOME memory for operation of any program there, and POKE 23750,128 turns the DOCK port back on.
Not to worry, if you do all this and find a bug in your program as you use/test it, this is what I do. I remove the NVM board from the DOCK port, carefully slip a piece of paper under the battery contact, then carefully short out the main 220uf capacitor (the round can next to the switches) for a moment so that the static memory chips fully drain and clean its memory, remove the paper and reinsert the NVM in the 2068, power it up, reload the program I am experimenting with, and fix my bugs, then do it all over again.
If you know of a easier way, I await your tips.
Right now, as I finish dashing this off, I am reaching for my BBS program and will begin adding the features I wanted as if I had all kinds of memory, which I have now, thanks to the 64K NVM board.
LATE THOUGHT: this is a real neat way to program and test your programs before you place them on an EPROM board to be ran out of the DOCK port like the Timex Command cartridges. It sure beats finding a bug in a program then having to erase and then reprograming an EPROM so that your program runs better. I also wonder what this means to those folks toying with the IM2 interrupt experiments. I can see it now, the 2068 with a program in HOME memory, an IM2 utility, and the DOCK port with a program;
Multitasking
Can it work? Time and the talents of fellow Timex/Sinclair survivors will only tell.
