InsaneMultitasker

I was specifically thinking about the CF7 compact flash device. Guess it won't work there as it emulates normal disk drives ? Yep, VDP PAB/buffer is required with the CF7 device. It is essentially the TI floppy controller DSR modified for use with the IDE device. The parallel port DSR is, like the IDE portion, a modified TI-RS232 DSR.

With a modified DSRLNK, both PAB and buffers may reside in either CPU or VDP RAM. Of course, this depends on the device; the HFDC and possibly Myarc FDC are capable of CPU transfers, the IDE card will also be compatible when Fred releases the next DSR revision. The SCSI card may allow buffers to reside in CPU but IIRC, the PAB is restricted to VDP. For compatibility with standard TI devices, VDP is the way to go. But if you want to eek out some speed with newer devices, it can be done.

Thanks for posting, Tim. Yes, you are absolutely right, and just such a thing is certainly the FIRST thing I would do. Here's the only thing though... how many of us have hardware and emulators? A hundred? Two hundred? Of those two hundred, how many are interested in playing video games? Of those interested in video games, how many RPG gamers are there out there? A person willing to play a game for 10-20 hours to beat it.... We're essentially limited in most part to THIS FORUM!!! We're the ones who love games, love programming, and love supporting others to do the same. Over on the list, 90% of those people have never played any of the SSGC games, they don't care about new software, and for the most part--- they are mostly great people who enjoy talking about the TI as something they remember fondly. I love them all, they're all great people. But really... show of hands... Who thinks fdos, epergrem, jacques, tom, or any number of others would really enjoy a CRPG? It's really quite simple if you follow me. The ones in THIS Atariage community who love games are simply co-designers, as far as I"m concerned. I look at this thread like a development document, in a way, with hundreds and hundreds of co-authors. You guys are my inspiration, my BETA testers, my co-conspirators, mentors, all wrapped up into one little community. So, here's the rub. YOU are all co-authors of the game.... you are all on the BETA testing team... so who are we doing this all for? Honestly, I'm hoping we can find a way to go the way of the "wrap" as was suggested previously. That way, this game can be a testament to the /4a. An accessible, understandable, labor of love showcasing the TI and what it can do. "Here, RPG world... you have a new CRPG to play, it's Windows executable, it's well done, it's 100% documented, 100% tested and guaranteed to play well. And best part... It's written on the TI-99/4a home computer.... 16k of RAM, 256 bytes of scratchpad RAM... and we did it in spite of all the limitations and challenges! Come to the /4a-side. See what's possible?" That's what excites me about the project... There is such a HARDCORE community of RPG lovers and enthusiasts who have ALL heard of Tunnels of Doom. Tens of thousands of people who are looking for a project like Adamantyr's "Realms of Antiquity" or my own RPG (to a lesser extent). Let them eat cake. =) You're right... before AA there was a lot of disjointed talk about various topics. As much as I'm not a fan of forums, I must say this one has turned out to be quite positive for all involved. What you write and for what platform is entirely up to you. I only meant to point out that it is easy to look for solutions to problems that might not exist, when you are still working on the game itself. The more you think about it, the more difficult making a decision can occur. I've heard it called 'analysis paralysis' and it can derail or delay work. Your vids of FF brought back memories of sitting at home on summer school break spending countless hours with the NES, running through FF, Zelda, and others. Ahh... those were the days. Hmm.. now where is my console...

This all seems like a solution looking for a problem. I have never timed the sequence but I would be most surprised if your steps required more than 2-3 minutes to accomplish. From my perspective, time would be much better spent catering initially to the audience who would use the program - those with emulators or hardware - versus trying to please a larger audience who would see nothing of the original, emulated machine. Not to discourage anyone from creating a "wrapper" but it seems there are many more worthwhile, fun tasks out there. Back to my work-imposed lurking...

1. CRU instructions - remembering when the offset is doubled or not. As well as which order the bits get loaded/stored. 2. Using a WRITE opcode in place of a READ, especially where sectors 0 and 1 are being accessed. 3. combining #2 with a MOV instead of a MOVB, and writing random sectors all over your hard drive containing your source code files. 4. Backing up your source files AFTER you made a thousand modifications and finding out that nothing works properly anymore, without a clue as to when it stopped working and my favorite: 5. assembling the files over and over, making more "fixes", as frustration mounts, nothing is working.... until you realize the object code you are testing is the PREVIOUSLY named iteration and that you should be testing the new object file you told the assembler to create.

Also be careful to account for the 8 bytes used by the CF7+ device. At powerup, the DSR sets 0x8370 to the highest available VDP address by accounting for the buffers (file and VIB), last drive/filename, etc. Since the CF7+ uses the TI controller DSR as its base, coding practices applicable to the latter apply to the former. The VDP considerations are detailed in one of the Texas Instruments specs/standards docs; I forget which one off-hand but can locate and provide the name if interested. -Tim

I think you first have to "import" the character set. There is a demo character set PNG file in the Magellan directory. Ahh.. I see. That seemed to work but it over-wrote my character definitions. Oops! I didn't find a merge option...yet... but I am new to using the program. Time for some sleep...

Ok guys... was playing with this great editor. I didn't realize that the docs file was in the ZIP but after I found it, no longer had to scratch my head how to set the character background color <sheepish grin> What I cannot figure out is how to use ASCII text characters? It seems that all the char patterns are set to "0000000000000000"?

LI R12,MAPDAT *usable register to hold mapdat "status" DRWMAP LI R5,14 * Draw map LI R0,35 *Starting screen position MOVB R12,R1 *Load current mapdat location into R1 LI R2,14 Quick observation: Your MOVB is suspect... did you intend a MOV?

As Tursi mentioned earlier, there are generally two methods used to catalog disk devices: 1. Direct sector access 2. Catalog "file" DIRECT SECTOR ACCESS: Quite a few programs catalog floppy devices using direct sector IO (also referred to as level 1 access). Instead of a file PAB, one uses a subroutine pab, sector IO routine 0x10 and calls DSRLNK via the subroutine entry 10 (instead of 8 ) : BLWP @DSRLNK DATA 10 To catalog the disk, you first read sector 0 (Volume Info Block/VIB) to determine the volume name, the proper sector-to-allocation unit ratio, and the bitmap. Sector/AU is important when a disk exceeds 1600 sectors, since the bitmap then allocates sectors by factors of 2. You now know the disk characteristics and can read sector 1, which contains the File Descriptor Index Record (FDIR), containing 16-bit pointers to the File Descriptor Records (FDR) of each file. The FDR pointers are sorted alphabetically - not only to keep order but to allow a binary search, reducing IO time when locating a file. To catalog the files, you would loop through the list of FDR pointers and read the respective FDR. Each FDR contains the filename and other critical info needed to identify and access the file content. Of importance for most catalog routines are the file status flags, records per sector, and total sectors. File clusters can be reviewed to determine fragmentation, if desired. The Myarc FDC and Myarc HFDC (and the Geneve) allow for three subdirectories on a floppy. Pointers to the three additional FDIRs are stored in sector 0. (most programs ignore this functionality) 2. CATALOG FILE Most people are familiar with the BASIC/XB file catalog routine. It is printed in the disk controller manuals and is the common way for someone programming in BASIC/XB to check out a disk. But what happens behind the scenes? The DSR EPROM is programmed to catalog the disk device using sector IO. It then presents the catalog data as if it were a file. In this manner the DSR can pass, on a per-record basis, file information to your program. Reading a file catalog via assembly requires the programmer to set up a standard PAB. The catalog file is opened as INPUT, INTERNAL, FIXED and usually SEQUENTIAL. IO operations are no different than reading a regular file. A catalog file will return the program name, file size, file type (signed to note protected/unprotected), and record length/program bytes. The record is 38 bytes though some DSRs extend the record length to include extra info such as date/time stamps. Programmers should be aware that unless they force a 38 byte rec size, their input buffer may overflow. <len><filename><len><float1><len><float2><len><float3> 1 10 1 8 1 8 1 8 Each record is composed of a space-padded filename and three 8 byte floating point values in RADIX100 format. The values must be converted and interpreted. FILE TYPES: File types 1-5 [DV,DF,IV,IF,PRG] are common to all devices. Hard drive devices may extend the file types during a catalog operation: 6 - subdirectory 7 - emulation file Additionally, files copied from Myarc devices (and possibly other hard disk devices) may have the archive bit set. This can be masked with a bit-wise function in XB or assembly. ADDITIONAL HARD DISK CONSIDERATIONS A program written to accommodate both floppy and hard devices should at minimum: 1. Reserve space for 127 files and 114 subdirectories during the catalog phase 2. Account for the extended file types 3. Account for space used/free values greater than 65,535. A hard disk may be catalogged using the direct sector IO method; however, one must account for a 31-sector bitmap and up to 114 subdirectories. The process is similar to that of a floppy with a few considerations: 1. SCSI and Myarc HFDC use the same sector IO subroutine, 0x20. Unfortunately, level 2 IO is based on device number not device name. Therefore.. 2. To distinguish between the two devices, the programmer must ensure his/her DSRLNK and calls select the proper card. This can be done at program initialization by searching the DSR for card-specific information, and storing the CRU address for each device type. 3. The IDE card uses sector IO subroutine 0x80, requiring further intervention. WHICH ONE SHOULD I USE? Both options are valid and workable. It is my opinion that the catalog file is the better option, simply due to its standard support across most devices and integrated support within each cards' respective DSR. I'll try to get a few code examples this week... that's all for now. -Tim

Now THAT is totally awesome! I always forget that we can modify any memory address on our little machine (too much time coding on stupid "modern" computers I guess.) I have no problems with code like this, it is fast, compact, and totally understandable. For those who might not understand what is going on, I'll go over it in detail in another post. I'm going to have to change to this method of subroutine calling I think. :-) Two caveats I might mention: 1. The return will 'fail' if the code runs from a Read-only memory device - you can't modify ROM in-line. 2. If you use this trick in every subroutine, you can call any sub from another sub. However, if a sub doesn't call another sub, you will incur a small, small performance hit for each iteration. For a while I lazily did the former - or was it for consistency? Just returned home with some coffee and a slice of Cheesecake Factory cheesecake. If I can survive my food coma, I may just get into the TI stuff this afternoon.

That reminds me of something I periodically tell my peers at work... that I age in "company years" but am still working on figuring out the ratio Kinda like dog years to human years. I put a little time into it last night and will look at it when I get home tonight. I was looking for a level 3 DSR access tutorial I had written long ago but so far haven't found it....

Beware self-modifying code... I often do things like this versus using a stack... SUB1 MOV R11,@SUB1RT+2 ... SUB1RT B @0 Matthew - this is an awesome thread you've got running This is giving me some great ideas for a few programs I'd have trouble writing without getting out of my dsr/utility/input-driven serial-event processing mindset

Me too.... Tim are you lurking ?? Me? Lurk? Short answer: yes to all four questions File types are extended and floating point numbers returned via the DSR have to be considered, since up to 248MB is possible per hard device. This means 16-bit floats in RADIX 100 format need to be extended to 20 bits. Give me a little time to gather some thoughts and maybe a code snippet or two for you..

Looks good The only question that popped into my mind the first time I looked at the code (and then quickly popped out before I wrote it down) was, "how you are preparing the 8k images?" Your copy/header code is placed in each 8k bank which means you have to split chained 8k program image files outside their 'normal' boundaries..? Course, if you knew which bank this would start in, you could dedicate 8k to your own "loader". But I am pretty sure that's been hashed over many times in SWPB and other arenas. <grin>

I'm sure there are other ways to skin this cat I assumed each bank must contain the stub because you don't know the initial bank at startup, hence the header and GOGO routine are up front. I modified COPYME to use data statements to conserve space. And hopefully no errors crept into what I typed. * HEADER * GOGO routine ****COPYME **** MOV R11,R8 * Save our Return Spot (not needed unless we branch outside this routine) **** MOV R0,@R7 * Do the bank switch (how did @R7 work?) COPYME MOV *R11+,R7 bank address MOV *R11+,R4 count MOV *R11+,R9 source MOV *R11+,R10 dest MOV R7,*R7 set the bank LOOPIT MOV *R9+,*R10+ *could eliminate a MOV if we double the R4 count MOV *R9+,*R10+ DEC R4 JNE LOOPIT RT * use R11 ** B *R8 * We're done. *-------------------------------------------------------------- * Let's determine proper bank (22 bytes) * CF2K LI R7,>6000 4 bytes JMP MOVEIT 2 bytes DM2K LI R7,>6008 4 JMP MOVEIT 2 DU2K LI R7,>6010 4 JMP MOVEIT 2 BNK4 LI R7,>6018 4 * start code for this module copy * each 32K bank should contain the copy data for the 4 8k banks * * use DATA statements to eliminate 2 bytes per LI statement * (2*16=32 bytes - 10 added to COPY = 22 bytes saved. Offsets our header branch above) MOVEIT MOV R0,*R7 change to bank BL @COPYME * following code should change depending on bank DATA >6000,>076A,>6258,>A000 bank,count/4, from address, to address BL @COPYME DATA >6002,>076A,>6258,>A000 BL @COPYME DATA >6004,>076A,>6258,>A000 BL @COPYME DATA >6006,>076A,>6258,>A000 B @>A000 FINISH EQU $ SLAST END

What if you re-order the routines so that the common routines are at the start of your code and each 32K bank has only the respective four COPY routines for its bank? Your header could start by branching to GOGO to set up the environment, which could then bank to the proper bank, then continue execution to the COPY statements for the proper block. You'd have to store R0 somehow at the start of GOGO, if I read the code correctly. (though I'm not sure how R0 is properly set before the COPYME routine - I must be missing something there). you can save 2 bytes in COPYME by eliminating the extra MOV and adjusting your copy counter. If I count correctly, you'll save approx >A0 bytes if the changes above are effective. tim

I'm not sure of the size of the book but have you considered mimicking how Micropendium and some of the TI columnists listed their code, in 28-column format, like a newspaper with multiple columns? Just a thought. It might conserve space and it has the added benefit of lining up a program as it would look on a TI. Granted, the programs are on disk so no one should have to re-enter the code... but it might give you flexibility for the book. No matter what you select, it's a cool idea and looks great )

That's very, very cool ))

OK...I couldn't resist... TI-Simon! Written by T. Tesch 2010 SSGC Competition STORY: When the Inaccurate Invaders' spacecraft landed on Memory Lane, the occupants were perplexed as to which humans would best serve them and their repetitious ways. They had learned about the Texas Instruments TI-99 Computer and its color and music capabilities from early television transmissions. They needed a way to test their future "repeaters"... could this popular TI Technology come to their rescue? The invaders designed TI-Simon!, a memory game designed to "test" concentration through the use of randomly generated sequences of sound and sight. Four "tiles" illuminated in random order and progressively faster challenge your memory. Mimic the sequence and TI-Simon! adds another tile. The better your memory, the higher your score. Because these aliens are sadomasochists, there is no end... the game continues until you hit the wrong key and fail your endeavor. Or by failing do you truly win? Try again...and again... and again... MENU OPTIONS: 1-4: select your skill level 5-8: Hidden options mirror 1-4 but display the sequence key. Good trainer option. 9: In game instructions PLAYER CONTROLS: Use the arrow keys (E,S,D,X) to select the appropriate color tile. Spacebar to repeat the sequence - active at any time Q to quit Notes: A "timed" option and joystick control were planned but didn't make it into 30 lines of code * Written in memory of Gene Hitz, a prolific game programmer and friend.

It had better be sugar-free pudding or the ants and other *bugs* will certainly wreak havoc

Very cool! Now if we could only place speech, 32K, and the CF7+ inside the console easily <grin>

I was thinking that maybe as part of your compendium - and if the authors felt this was valuable - each author could describe how their program works and some of the tricks they used to make things "hum". Sort of a mini tutorial via their own programs that folks could look at and learn from. Cause you know, SSGC#2 could be right around the corner.

SysTex encapsulates the assembly code within the XB program, allowing a quick load. The alternative would be to load the assembly code as a DF80 object file via CALL INIT::CALL LOAD("DSKx.filename). The former is simply quicker and more efficient. As for this particular program, the SysTex'd assembly code is a simple file loader hard-coded to CRU 0x1100, written as lean, quick, and dirty as possible. No real GPL simulation or interpretation - though the loader and screen do look pretty nice. IIRC, I disassembled and posted the code on one of the Yahoo group sites. Marc and John pretty well sum up the rest. Tim