46 replies to this topic

[Opry99er]

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. 

[apersson850]

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.

[Opry99er]

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. 

[senior_falcon]

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.

[Lee Stewart]

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]

[Opry99er]

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.

[senior_falcon]

 

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.

[unhuman]

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... 

[Lee Stewart]

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

 

Oops!  My bad. 

 

...lee

[mizapf]

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

[Tursi]

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.

[Opry99er]

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.

[Opry99er]

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?

[mizapf]

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.

[Opry99er]

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.

[senior_falcon]

 

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.

[Opry99er]

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. 

[mizapf]

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.

[RXB]

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.

[senior_falcon]

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.  

[Opry99er]

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.

[Opry99er]

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.