Jump to content

Photo

STACK, DATA, and strings


46 replies to this topic

#26 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 9,726 posts
  • Location:Hustisford, WI

Posted Wed Jan 10, 2018 2:09 AM

Yea, those asshats auto-debited my account for $110 for a stinking web-design service I didn't want.  It got kind of testy.... the credit card company was called, things were said... Needless to say, I temporarily lost the domain.

 

Hard to win these days.  :)



#27 apersson850 OFFLINE  

apersson850

    Moonsweeper

  • 490 posts

Posted Wed Jan 10, 2018 12:04 PM

Since you seem to have separate stack and program space, you must be using Extended BASIC with 32 K RAM expansion. This allows for using assembly language as well.

I once was part in a development of a word processor in Extended BASIC and assembly. The assembly part was written to use 8 K RAM as extra string storage space. The assembly routine allowed storing and reading strings from 8 K RAM, as well as sending them to a file or read them back. Tape as well as diskette, that didn't matter.

 

The BASIC program contained a minimal loader, which read in a larger assembly file from cassette and installed the assembly program that way.

 

Such an approach would give you more memory to work with, if I understand the foundation for your task correctly.



#28 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 9,726 posts
  • Location:Hustisford, WI

Posted Wed Jan 10, 2018 11:07 PM

First, thank you for your reply!

 

The plan is to load a program from cassette which contains a small loader at the top.  This will draw 9K of data from CS1 and plug it into VDP RAM.  The remainder of the program (after the loader does its job) will be a user interface for a game.  I do not have the ability here (at the current moment) to try, but I am hoping I can do all of this without the 32K memory expansion.  A bare console and tape project.

 

So basically, I know I can load a program of up to 12K into memory from CS1.  This is no problem, as the main program will only be ~5K.  Then there will be the 9K of data pulled from cassette on top of that.  This gives a total of 14K (+/-) that will be required for this to work.  Not having a vast understanding of the infrastructure of VDP RAM, I am sort of going semi-blind here, hoping that my method will work.

 

I am currently coding and testing using disk access for the data files, and it is working flawlessly.  The test will be to set up a physical system (or learn to navigate MAME) and try it out on a real (or emulated) cassette interface.  If it works, I will do backflips.  :)



#29 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,152 posts
  • Location:Lansing, NY, USA

Posted Thu Jan 11, 2018 7:39 AM

Don't overlook Win994a which has a casette interface and is easy to figure out.  With this emulator you can turn off the memory expansion and turn off the disk drive, and for that matter, run with no cartridge in the slot.  (I don't think Classic99 can do any of these, but would have to RTFM to know for sure.)

Anyway, with no memory expansion and no disk drive you have 13928 bytes of VDP ram to use which just might be enough for you.  With a disk drive and CALL FILES(1) you have 12876 bytes of VDP ram available.

Sounds like an interesting project, and it's nice to see people working with a more minimal system.



#30 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,692 posts
  • Location:Silver Run, Maryland

Posted Thu Jan 11, 2018 8:32 AM

Don't overlook Win994a which has a casette interface and is easy to figure out.  With this emulator you can turn off the memory expansion and turn off the disk drive, and for that matter, run with no cartridge in the slot.  (I don't think Classic99 can do any of these, but would have to RTFM to know for sure.)

 

I am pretty sure Classic99 can do all of those things.  You can turn off memory expansion in “Options”(I was wrong on this one), set each disk drive to “None” (not quite right—see Tursi’s post below) and “Eject” any cartridge.

 

...lee

 

[Edited]



#31 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 9,726 posts
  • Location:Hustisford, WI

Posted Thu Jan 11, 2018 12:14 PM

Don't overlook Win994a which has a casette interface and is easy to figure out.  With this emulator you can turn off the memory expansion and turn off the disk drive, and for that matter, run with no cartridge in the slot.  (I don't think Classic99 can do any of these, but would have to RTFM to know for sure.)
Anyway, with no memory expansion and no disk drive you have 13928 bytes of VDP ram to use which just might be enough for you.  With a disk drive and CALL FILES(1) you have 12876 bytes of VDP ram available.
Sounds like an interesting project, and it's nice to see people working with a more minimal system.


Interesting. I gave Win994a a shot several years ago but was kind of turned off by it for some reason. I cant remember what it was now.

This will be an XB game, so I will need XB in the slot. The primary issue is the cassette interface. I will need to load my loader utility from disk, then modify it to save to tape, then save all data to tape. Then I will need to modify the main program to open CS1 to load the data in. I will need to load that main program from disk, then save it to tape.

The testing will be basically, load main program from tape, load data into main program from tape, type RUN, and cross fingers. :)

#32 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,152 posts
  • Location:Lansing, NY, USA

Posted Thu Jan 11, 2018 7:41 PM

 

I am pretty sure Classic99 can do all of those things.  You can turn off memory expansion in “Options”, set each disk drive to “None” and “Eject” any cartridge.

 

...lee

SAMS can be turned off, but I can't see any provision to turn off the 32K expansion. 

I forgot this line from the manual: "Unlike the true disk system, you can use CALL FILES(0) to disable all VDP buffer space – in this situation you

will have the same amount of free VDP RAM as on a cassette system." (Yes, I have been known to read manuals!)

I see that "Eject" is indeed an option.  This was not in v373 that I have been using for years.

 

Unless there is a way to turn off the 32K, if you test in Classic99 you will have to add the memory used in both CPU and VDP ram to see if you exceed 13928 bytes.  That shouldn't be too hard and of course there are usually ways to slim down a program.

 

As I recall, Win994a is slow when it records to cassette.  I don't know if it is as slow as a real cassette drive, but at least you don't have to rewind and check the recording.  Reading from cassette happens in seconds, much faster than a real cassette. 

 

Fred Kaal's TI99Dir gives an easy way to send files between Classic99 and Win994a.



#33 unhuman OFFLINE  

unhuman

    Stargunner

  • 1,203 posts
  • Location:Vienna, VA

Posted Thu Jan 11, 2018 8:57 PM

Depending how hard core you want to get, you could write a relatively simple compression algorithm..  It'd slow things down significantly, but if you wanted just single case letters, spaces and numbers, you could fit 2-3 chars per byte.  Additionally, if you had some / many re-used works, perhaps you could token them... 



#34 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,692 posts
  • Location:Silver Run, Maryland

Posted Fri Jan 12, 2018 1:18 PM

... but I can't see any provision to turn off the 32K expansion. 

 

Oops!  My bad.  :dunce:

 

...lee



#35 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,253 posts
  • Location:Germany

Posted Fri Jan 12, 2018 1:34 PM

MAME can give you a blank console with cassette only, no expansions.



#36 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,072 posts
  • HarmlessLion
  • Location:BUR

Posted Sun Jan 14, 2018 3:27 PM

If you want to disable the 32k RAM in Classic99, just make a fake cartridge in Classic99.ini that loads anything overtop of the RAM space. Classic99 will flag it as ROM and you won't be able to write to it. There's an example here:  http://atariage.com/...test/?p=3918345

 

This has been coming up a lot lately, so I guess I'll add it as an option.

 

As discovered above, to free all disk memory, use CALL FILES(0). Classic99's DSR does not make use of VDP memory so the disk is still available, but for compatibility reasons it was important to reserve the VDP space anyway. It doesn't matter if you set the disks themselves to be empty or not.


  • Lee Stewart likes this

#37 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 9,726 posts
  • Location:Hustisford, WI

Posted Sun Jan 14, 2018 11:46 PM

Thanks for the info, Tursi.  :)

 

I certainly would enjoy a 32k on/off switch in Classic99.  Much of the development I'm working on right now is for sans-32k programs.  Much appreciated.



#38 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 9,726 posts
  • Location:Hustisford, WI

Posted Mon Jan 15, 2018 1:03 AM

MAME can give you a blank console with cassette only, no expansions.

Thanks Michael!  I may have to give it one more try.  :)  Last time I tried MESS/MAME was 3 or 4 years ago and I did not have ROMs and the like.  I assume the user still has to provide ROMs for the emulation to work?



#39 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,253 posts
  • Location:Germany

Posted Mon Jan 15, 2018 1:26 AM

All ROMs are on Whtech.

 

I added some examples for batch files on https://www.ninerped...MAME_on_Windows

 

If you intend to install MAME, please follow this guide.


Edited by mizapf, Mon Jan 15, 2018 5:41 AM.


#40 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 9,726 posts
  • Location:Hustisford, WI

Posted Wed Jan 17, 2018 12:07 AM

So, here is where I am currently... minimum optimization, no compression of DATA:

 

1912 BYTES OF STACK FREE

17059 OF PROGRAM SPACE FREE

 

 

So I'm significantly over my limit for a tape-only cassette release, but the program is basically done... All elements are in place, and it functions as it should.  At this point, I'll just be optimizing, cleaning up code, working on eliminating unnecessary elements of displays, etc.  

 

The DATA compression is something I'm not super familiar with, but I'm willing to look into it.  Basically, I have to determine whether an un-packing routine in the main program would be small enough to give me some significant gains in space.  Being as most of my DATA is text which I must display onscreen, I doubt that much compression can be done to eliminate the 3,429 bytes I need to lose in order to fit this onto tape.

 

But, let me just clarify something here--to be 100% sure before I start slashing features...

 

The 13,928 BYTES that seniorfalcon mentioned earlier.... That is literally ALL that I can use... PROGRAM lines, string variables, everything... all told, that's all I get... am I reading that correctly?  If so, I will be unable to continue with this project as it is currently configured, because there is truly no way to eliminate 3,429 bytes of program/stack space from this thing.

 

 

When using Win994a, with no 32k attached and no disk system installed, I get a SIZE return of 13928.

 

 

Is this just PROGRAM space available, or are there any crevasses I can cram additional DATA into?  :)


Edited by Opry99er, Wed Jan 17, 2018 12:53 AM.


#41 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,152 posts
  • Location:Lansing, NY, USA

Posted Wed Jan 17, 2018 8:09 AM

 

The 13,928 BYTES that seniorfalcon mentioned earlier.... That is literally ALL that I can use... PROGRAM lines, string variables, everything... all told, that's all I get... am I reading that correctly?  If so, I will be unable to continue with this project as it is currently configured, because there is truly no way to eliminate 3,429 bytes of program/stack space from this thing.

 

That is all you can use.  BUT you can stash numbers in character definitions using CALL CHAR and then retrieve them with CALL PEEK which works on an unexpanded TI.  the pattern for ASCII 128 is 8 bytes starting at 1792. So your initial program can do CALL CHAR(128,"0102030405060708") then CALL PEEK(1792,X) makes X=1.  There are 8 bytes per character.  You could even use the lower case characters if you needed more space.

 

edit - Oops, that was a senior moment.  Disregard above - you need to do a PEEKV which is not available in Extended BASIC.  I guess you could use CHARPAT but by the time you extract the number from the string there might not be much memory savings, if any.

 

 


Edited by senior_falcon, Wed Jan 17, 2018 11:20 AM.


#42 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 9,726 posts
  • Location:Hustisford, WI

Posted Thu Jan 18, 2018 12:20 AM

Thanks for the details there, falcon.  I'm going to have to cut down on my expectations if I want to fit this into cassette.  It's going to be a fairly big re-write, eliminating multiple sections of text and re-sequencing all my logic, but I think it'll be worth it.  I've always wanted to do a console-only tape release... I think (IIRC) even the Holiday demos required 32k memory expansion, due to the way they were chained together.  

 

This can work... I've got some math to do.  :)



#43 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,253 posts
  • Location:Germany

Posted Thu Jan 18, 2018 2:49 AM

When dealing with memory constraints, this could be helpful

 

CALL USERWRITE(name, value[, reason])

Prompt the current user to associate the given name with the given value. This subprogram is useful in tight memory situations, when no further memory allocation is possible. Since the user's willingness to comply is crucial for the continuation of the program, a reason can be provided.

 

See also CALL USERREAD

 

I thought about waiting until April 1st, but I'll have forgotten it by then.



#44 RXB OFFLINE  

RXB

    River Patroller

  • 3,075 posts
  • Location:Vancouver, Washington, USA

Posted Thu Jan 18, 2018 4:46 AM

RXB 2018 will have a useful feature:

 

CALL FILES(0) 

 

Yep as long as you do not want any files opened you can use max memory possible with RXB 2018

 

Of course this has no effects on RXB 2018 CALL BLOAD("DSK#.ASSEMBLY") or RUN "DSK#.XBPROGRAM")

 

So using SAMS and CALL BLOAD or CALL BSAVE with max VDP memory provides all kinds of things you could do.



#45 senior_falcon OFFLINE  

senior_falcon

    Stargunner

  • 1,152 posts
  • Location:Lansing, NY, USA

Posted Thu Jan 18, 2018 7:17 AM

Thanks for the details there, falcon.  I'm going to have to cut down on my expectations if I want to fit this into cassette.  It's going to be a fairly big re-write, eliminating multiple sections of text and re-sequencing all my logic, but I think it'll be worth it.  I've always wanted to do a console-only tape release... I think (IIRC) even the Holiday demos required 32k memory expansion, due to the way they were chained together.  

 

I just checked and verified that with TI Extended BASIC and a cassette drive, RUN "CS1" is legal, same as RUN DSK1.PART2 would be.  So maybe there is a way to split the program into smaller pieces.  



#46 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 9,726 posts
  • Location:Hustisford, WI

Posted Thu Jan 18, 2018 9:49 AM

Thanks... the program is actually fairly small... the beef is in the DATA pulled from tape. :)

I may post a beta version here to give everyone a glance. Id hoped to keep it under wraps, but its basically done now.

#47 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 9,726 posts
  • Location:Hustisford, WI

Posted Fri Jan 19, 2018 4:40 PM

The project has shifted to a full-on disk-based game. I would have had to give up too much to get this particular game onto tape.

The programming is complete and the game is functional. Now I am just dressing it up and doing some graphics work.

It has been a really cool journey making this game. I learned a ton. Thanks everyone for your help and suggestions.

Expect the game to be released sometime in the next few days hopefully. :D
  • Ksarul , RXB and digdugnate like this




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users