Where does BASIC put its varables and code? & Memory Map

Discuss software for the Apple 1/replica 1

Where does BASIC put its varables and code? & Memory Map

Postby Juz10mac » Sep Fri 14, 2007 11:02 am

Hello,

I'm trying to understand the memory map of the Replica I a little better. I've managed to figure out where most everything is but I can't figure out where BASIC puts its variables and code. Also, I've done a little research and I should be able to change HIMEM and LOMEM, right? (I haven't been able to get it to work) Would this give me control over where basic is going to put its data? Basically, I'm trying to draw out my own detailed memory map and I'd like to know what memory regions BASIC occupies when it's being used.

The memory map on brielcomputers.com shows $0100-$7FFF as user RAM, but wasn't much more descriptive than that. I know that $0100-$01FF is stack, and Krusader writes its code starting at $0300.

[I have the Replica I SE with Woz, BASIC and Krusader.]

Thanks in advance,
Justin

Here's what I've got so far:

Edit: I added BASIC's data area as supplied by daustin777 below.
Edit: I added Krusader's memory usage.

RAM
$0000-$00FF: Zero Page
$0100-$01FF: Stack
$0200-$7FFF: User RAM
---Woz Monitor
---$0200-$027F: Input buffer
---Krusader
---$0300-$1FFF: Target code (changeable with .M directive)
---$2000-$73FF: Program code*
---$7400-$7BFF: Global symbols*
---$7C00-$7CFF: Local symbols*
---$7D00-$7FFF: Forward references*
---BASIC
---$0800-$1000: Memory used by BASIC (changeable with HIMEM and LOMEM commands)

I/O
$8000-$8FFF: CFFA1 Scratch memory
$9000-$AFFF: CFFA1 Firmware
$B000-$BFFF: [Unused]
$C000-$CFFF: Cassette interface
$D000-$DFFF: PIA IO

EEPROM
$E000-$EFFF: Basic
$F000-$FEFF: Krusader
$FF00-$FFFF: Woz Monitor

*The the memory addresses for Krusader can be changed. See post below.

Edit: I also had a question about CFFA1, but I looked into it. It is for the Compact Flash expansion board if I'm not mistaken.

[/quote][/u]
Last edited by Juz10mac on Sep Fri 14, 2007 11:58 pm, edited 4 times in total.
User avatar
Juz10mac
 
Posts: 14
Joined: Jan Wed 10, 2007 7:05 pm
Location: Texas

Postby daustin777 » Sep Fri 14, 2007 1:19 pm

The default Basic user area is $0800 - $1000, until it's changed with HIMEM, LOMEM
--David Austin-- replica 1 se, CFFA1, MicroKIM, [kits]
daustin777
 
Posts: 54
Joined: Nov Sun 12, 2006 4:03 pm
Location: Southern California

Postby Juz10mac » Sep Fri 14, 2007 1:25 pm

daustin777 wrote:The default Basic user area is $0800 - $1000, until it's changed with HIMEM, LOMEM


Thanks!

Also, do the HIMEM and LOMEM commands work with Apple I BASIC? I only get a syntax error when I try them.
User avatar
Juz10mac
 
Posts: 14
Joined: Jan Wed 10, 2007 7:05 pm
Location: Texas

Postby daustin777 » Sep Fri 14, 2007 2:29 pm

HIMEM and LOMEM are commands, not keywords. So you need to set them not in your BASIC program but from the BASIC command line (at the > prompt). Also, they require decimal arguments.
For example:
LOMEM=2048
HIMEM=4096

BTW, these are the default values that are used if not specified. Also, using these commands will destroy any current user programs, so set them before coding your BASIC program.
--David Austin-- replica 1 se, CFFA1, MicroKIM, [kits]
daustin777
 
Posts: 54
Joined: Nov Sun 12, 2006 4:03 pm
Location: Southern California

Postby Juz10mac » Sep Fri 14, 2007 3:19 pm

That works!
The syntax was the problem. I wasn't using =, I just placed the number after the command. It was just one of those careless errors that tends to happen. :D
User avatar
Juz10mac
 
Posts: 14
Joined: Jan Wed 10, 2007 7:05 pm
Location: Texas

Postby vbriel » Sep Fri 14, 2007 5:18 pm

One thing that I don't think gets explained very clear is, where are the values stored for himem and lomem in memory so you know where your program begins and ends.

From the monitor examine 4A-4F and you will get your answer.

If I set lomem=768 in basic and himem=16384 here's what it looks like in memory:

004A: 00 03 00 40
-------lomem-himem------

Lomem is 0300
himem is 4000

now you know where your program is but if you are backing up your data you need to store 4A.FF as well as 0300-4000. Variable information is stored at 4E-FF somehow and it is needed. Since Woz wrote basic by hand it was never written in assembly! He says he has hand written pages on it somewhere and I'd like to see a copy someday.

Anyhow maybe somebody who has messed more with basic knows how the variables are stored.

Vince
User avatar
vbriel
Site Admin
 
Posts: 1184
Joined: Jul Tue 19, 2005 1:10 pm
Location: Ohio

Postby daustin777 » Sep Fri 14, 2007 7:33 pm

I've not had the time to figure out how variables are stored but I do know that the end of variables pointer is at cc.cd
Variables are stored from LOMEM to the address at cc.cd
--David Austin-- replica 1 se, CFFA1, MicroKIM, [kits]
daustin777
 
Posts: 54
Joined: Nov Sun 12, 2006 4:03 pm
Location: Southern California

Postby Kallikak » Sep Fri 14, 2007 8:20 pm

You can make Krusader write its code anywhere you like (though writing to zero page or the stack could create difficulties. :-) ) A module is assembled to the address following the .M directive, so if you start with
Code: Select all
MYPROG .M  $2000
...
the generated code will start at hex $2000. What is harder to control are the other memory locations used by Basic, and Krusader, such as specific zero page values. Krusader needs $E0-$FF to remain intact if you want to use the mini-monitor, or $F8-$FF for just the general Krusader environment. It also uses high RAM for tables during assembly. The Krusader manual describes the memory usage in detail.

Ken
Last edited by Kallikak on Sep Sat 15, 2007 1:32 am, edited 1 time in total.
Kallikak
 
Posts: 172
Joined: Jan Sun 29, 2006 7:42 pm
Location: Sydney

Changing memory addresses used by Krusader.

Postby Juz10mac » Sep Sat 15, 2007 12:06 am

After reading in the Krusader manual, I found that you can change the default memory addresses it uses. To quote the Kursader manual:

Figure1: Memory map for both the high RAM and the ROM versions of KRUSADER. Note that
the global symbol table starts at the local/global table boundary and grows downwards, whereas
the program source starts at the low address and grows upwards. As mentioned in section 6.1,
the important values are the high byte of the target memory, the high byte of the local/global
symbol table boundary, and the start of the source code storage. For the RAM version, the values
are $03, $6D, $00 and $1D, and for the ROM version they are $03, $7C, $00 and $20. After
initialisation, these values are stored in zero page locations $F8, $F9, $FE and $FF.

6.1.1 Changing Default Memory Locations
The default values for the RAM based version of KRUSADER can be altered by changing the
values at memory locations $7101, $7105 and $7109 in the assembler code. For the ROM based
version, the default values can only be altered after the program has been run, and the alternative
values must be entered directly into the zero page locations mentioned above, before resuming
KRUSADER at location $F01A7.
User avatar
Juz10mac
 
Posts: 14
Joined: Jan Wed 10, 2007 7:05 pm
Location: Texas

Postby daustin777 » Sep Sat 15, 2007 12:22 am

Woz BASIC variable storage table format:

http://www.gloonk.com/programming/images/wozbasicvars.txt

Let me know if you find any errors or additional info.
--David Austin-- replica 1 se, CFFA1, MicroKIM, [kits]
daustin777
 
Posts: 54
Joined: Nov Sun 12, 2006 4:03 pm
Location: Southern California

Re: Changing memory addresses used by Krusader.

Postby Kallikak » Sep Sat 15, 2007 1:31 am

Juz10mac wrote:After reading in the Krusader manual, I found that you can change the default memory addresses it uses. To quote the Kursader manual:
6.1.1 Changing Default Memory Locations
The default values for the RAM based version of KRUSADER can be altered by changing the
values at memory locations $7101, $7105 and $7109 in the assembler code. For the ROM based
version, the default values can only be altered after the program has been run, and the alternative
values must be entered directly into the zero page locations mentioned above, before resuming
KRUSADER at location $F01A7.

This is correct, except the address should be $F01A - the '7' is a superscript for the footnote that mentions the impact this runtime change has on the "P" command for recovering source. Also, that is the manual for Krusader version 1.1. I cannot recommend upgrading to version 1.2.1 too strongly. There are two bug fixes I can think of (though both very minor), but the addition of the debugging mini-monitor is a huge advantage to beginning and experienced assembly programmers alike.
Kallikak
 
Posts: 172
Joined: Jan Sun 29, 2006 7:42 pm
Location: Sydney


Return to Software

Who is online

Users browsing this forum: No registered users and 4 guests

cron