Classic 99 & Win99/a memory question

[Bones-69]

I have an idea for a new program/game and I am doing the intial homework to work out memory in advance.

 

As part of my homework I have run the following simple program;

 

10 DIM A$(27),A(2268)
20 FOR I=1 TO 27 :: A$(I)=RPT$("F",84) :: NEXT I

 

I run this in Classic 99 and SIZE reports;

11466 BYTES OF STACK FREE

6265 BYTES OF PROGRAM SPACE FREE

 

I run this in Win994a and SIZE reports;

9378 BYTES OF STACK FREE

6265 BYTES OF PROGRAM SPACE FREE

 

Any idea what is going on here? I need to nail the memory (limitations) in advance before I go any further.

 

Also... As a general learning curve observation, I always thought PROGRAM SPACE was effectively the space only used by typing in the program and was separate from allocation of variables. This obviously isn't the case?

[Opry99er]

From the XB manual

 

 

SIZE

 

Format

 

SIZE

 

Description

 

The SIZE command displays the number of unused bytes of memory left in the computer. If the Memory Expansion peripheral is attached, the number of bytes available is given as the amount of stack free and the amount of program space free. A byte is the memory space required for such things as one character or digit, or one TI Extended BASIC keyword.

 

If the Memory Expansion is not attached, the space available is the amount of space left after the space taken up by the program, screen, character pattern definitions, sprite tables, color tables, string values, and the like is subtracted.

 

If the Memory Expansion is attached, the space available in the stack is the amount of space left after the space taken up by string values, information about variables, and the like is subtracted. Program space is the amount of space left after the space taken up by the program and the values of numeric variables is subtracted.

 

 

Hope this helps...

Edited February 23, 2011 by Opry99er

[Bones-69]

Thanks Owen. Any thoughts on the different figures reported by Classic and Win994/a?

[Opry99er]

Tursi should really comment on this, but if I'm not mistaken---

 

Classic99 fakes some stuff... It actually allows you to use the memory bytes taken up by certain DSRs and such on the real deal. For example: A TI BASIC game that uses ALL available memory cannot run on a real TI with a disk drive attached. This IS possible in Classic99.

 

However--- the difference is almost 2k.... I don't think we're talking about 2k of difference. Tursi will have to chime in.

[Bones-69]

Cheers mate. If anybody could run this little program on original hardware I would be interested in the results....

[Opry99er]

I can run it on my CF7 machine... don't have the ability to transfer via serial anymore... all my real TI work happens with my CF7 nowadays. =)

[Tursi]

Please don't run too quickly down the road of supposition. It takes so long to read through all the guesswork and make sure I didn't miss anything.

 

Classic99 doesn't have a disk controller installed. The TI, Corcomp, and Myarc disk controllers reserve VDP RAM for file buffers (this occurs before the master title screen appears). This is what CALL FILES() changes - the number of disk buffers reserved. By default they reserve 3 buffers. If you do CALL FILES(1)/NEW/SIZE on Win994A, you'll see the stack size go up. If you do CALL FILES(5)/NEW/SIZE on Win994A, you'll see the stack size go down.

 

Classic99 therefore has the same amount of stack space free as a standard console without a disk controller (for instance, a cassette system). Note that because it doesn't use VRAM buffers that CALL FILES() doesn't do anything - Classic99 can always open 9 files.

 

And yeah, the difference is actually more than 2k - 2088 bytes.

 

If you want to fake it in Classic99, boot to the title page (the color bars!), open the debugger, and enter "8370=37D7" in the box near the bottom, then click Apply. Then operate normally. This sets the top of VRAM to the same position as the disk controller sets it, and SIZE and the like should return the same values.

 

Edited February 23, 2011 by Tursi

[matthew180]

Real Hardware: 99/4A, XB, PEB, 32K, TI Disk Controller

 

1. Power on

2. Type program

3. SIZE

 

11840 BYTES OF STACK FREE

24425 BYTES OF PROGRAM SPACE FREE

 

4. RUN

5. SIZE

 

9378 BYTES OF STACK FREE

6265 BYTES OF PROGRAM SPACE FREE

[Opry99er]

Sorry Tursi. I didn't mean to suppose anything---

 

For clarity-- PROGRAM and STACK indicate "what" precisely... I understand the space limitations--- but what exactly is the difference between PROGRAM and STACK space? How are these calculated with the 32k mem attached?

[unhuman]

If you want to fake it in Classic99, boot to the title page (the color bars!), open the debugger, and enter "8370=37D7" in the box near the bottom, then click Apply. Then operate normally. This sets the top of VRAM to the same position as the disk controller sets it, and SIZE and the like should return the same values.

 

This is a good workaround. Might I suggest to make this the default (or an option to do so) in Classic99. For those of us who develop primarily in Classic99, I suppose I could just be lucky until now that I haven't bumped into this yet... Rarely do I actually use a real console. That's how much I love Classic99.

[Tursi]

If you want to fake it in Classic99, boot to the title page (the color bars!), open the debugger, and enter "8370=37D7" in the box near the bottom, then click Apply. Then operate normally. This sets the top of VRAM to the same position as the disk controller sets it, and SIZE and the like should return the same values.

 

This is a good workaround. Might I suggest to make this the default (or an option to do so) in Classic99. For those of us who develop primarily in Classic99, I suppose I could just be lucky until now that I haven't bumped into this yet... Rarely do I actually use a real console. That's how much I love Classic99.

 

I considered it, but that /is/ faking things. Classic99 operates exactly as a real TI-99/4A with a disk controller that manages its own buffers would. However, to address the people who want to emulate that restriction (and other issues with the disk DSRs), I will eventually add actual disk controller support which runs the real code. At that point you just need to have the controller enabled to get all the same quirks and limits. It's all in the pipeline. It's somewhat rare that people actually bump into that issue, in the last 10 years or so I think it has come up twice -- it's just as likely as someone who develops on a cassette-only system running into it.

[Tursi]

For clarity-- PROGRAM and STACK indicate "what" precisely... I understand the space limitations--- but what exactly is the difference between PROGRAM and STACK space? How are these calculated with the 32k mem attached?

 

PROGRAM space is just free memory in the 32k memory expansion - XB stores the program and numeric variables here. STACK space is free memory in VDP RAM - XB stores program stack information and string variables here, plus the GPL interpreter uses it for its stack and data storage.

 

The text you quoted from the XB manual tries to explain that, but like most TI Home COmputer documentation, it tries to simplify it to the point of making no sense at all.

[Opry99er]

Yea, I read that section over and over but (like most computer manuals) I never really got it. =)

 

Thanks for your explanation. Makes perfect sense now. =)

[Opry99er]

Hmm, looks like I've got plenty of space left in my Beryl program. =) That's good because the bulk of the menu and battle code has not been added yet. =)

 

[RXB]

For clarity-- PROGRAM and STACK indicate "what" precisely... I understand the space limitations--- but what exactly is the difference between PROGRAM and STACK space? How are these calculated with the 32k mem attached?

 

PROGRAM space is just free memory in the 32k memory expansion - XB stores the program and numeric variables here. STACK space is free memory in VDP RAM - XB stores program stack information and string variables here, plus the GPL interpreter uses it for its stack and data storage.

 

The text you quoted from the XB manual tries to explain that, but like most TI Home COmputer documentation, it tries to simplify it to the point of making no sense at all.

 

Even with the 80 column cards the memory stayed the same as people were afraid it would affect programs, but turns out it would not be a problem at all and adding 128K of VDP memory would have really speeded up the TI for many applications as then all programs would not need to garbage collect the VDP so much, that is why you see the real TI99/4A do that pause for a second in the middle of a program, it is trying to do a garbage colllection of VDP to get more memory. Take out that garbage collection and most software would run quicker.

 

I was asked way to late to write a 80 column XB for the TI. I started the project using XHI as a rally point for features but they killed the project when WHorizon and Horizon had some money problems.