Opry99er Posted January 10, 2018 Author Share Posted January 10, 2018 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. Quote Link to comment Share on other sites More sharing options...
apersson850 Posted January 10, 2018 Share Posted January 10, 2018 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. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 11, 2018 Author Share Posted January 11, 2018 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. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 11, 2018 Share Posted January 11, 2018 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. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 11, 2018 Share Posted January 11, 2018 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] Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 11, 2018 Author Share Posted January 11, 2018 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. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 12, 2018 Share Posted January 12, 2018 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. Quote Link to comment Share on other sites More sharing options...
unhuman Posted January 12, 2018 Share Posted January 12, 2018 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... Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 12, 2018 Share Posted January 12, 2018 ... but I can't see any provision to turn off the 32K expansion. Oops! My bad. ...lee Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 12, 2018 Share Posted January 12, 2018 MAME can give you a blank console with cassette only, no expansions. Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 14, 2018 Share Posted January 14, 2018 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/forums/topic/273371-shortnsweet-machine-code-game-contest/?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. 1 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 15, 2018 Author Share Posted January 15, 2018 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. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 15, 2018 Author Share Posted January 15, 2018 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? Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 15, 2018 Share Posted January 15, 2018 (edited) All ROMs are on Whtech. I added some examples for batch files on https://www.ninerpedia.org/wiki/Installing_MAME_on_Windows If you intend to install MAME, please follow this guide. Edited January 15, 2018 by mizapf Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 17, 2018 Author Share Posted January 17, 2018 (edited) 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 January 17, 2018 by Opry99er Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 17, 2018 Share Posted January 17, 2018 (edited) 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 January 17, 2018 by senior_falcon Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 18, 2018 Author Share Posted January 18, 2018 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. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 18, 2018 Share Posted January 18, 2018 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. Quote Link to comment Share on other sites More sharing options...
RXB Posted January 18, 2018 Share Posted January 18, 2018 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. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 18, 2018 Share Posted January 18, 2018 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. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 18, 2018 Author Share Posted January 18, 2018 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. Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 19, 2018 Author Share Posted January 19, 2018 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. 3 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.