Jump to content

Photo

STACK, DATA, and strings


40 replies to this topic

#26 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 8,384 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

  • 445 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
  • 8,384 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,005 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,498 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
  • 8,384 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,005 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,166 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,498 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 ONLINE  

mizapf

    River Patroller

  • 2,764 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

    River Patroller

  • 4,902 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.



#37 Opry99er OFFLINE  

Opry99er

    Quadrunner

  • Topic Starter
  • 8,384 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
  • 8,384 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 ONLINE  

mizapf

    River Patroller

  • 2,764 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
  • 8,384 posts
  • Location:Hustisford, WI

Posted Today, 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, Today, 12:53 AM.


#41 senior_falcon OFFLINE  

senior_falcon

    Stargunner

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

Posted Today, 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, Today, 11:20 AM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users