retroclouds

Hi Michael! Welcome to the Atariage TI-99/4a forum. The best place to hang out if you ask me!

Jim it’s too bad we’ve never met in person, as I live only 80 kilometres away from Kaiserlautern (moved to Neustadt an der Weinstrasse in 1996, but now living near Ludwigshafen since 2006). So were the K’Town 99ers a local Kaiserslautern TI club?

Hi Rasmus, that is correct. The index is a very simple memory structure and I’m wasting memory, compared to more fancy solutions. But with a 1MB SAMS we’ve got plenty of memory to burn and benefit is that index access is very fast. The disadvantage is that index delete/insert operations could get slow due to the amount of memory that needs shuffling. That being said, even with Tursi’s nr80 file (the largest file I’ve tested so far, some +5000 lines of text) it is still more than acceptable. So looking forwards seeing what can be pulled off with the optimized version.

Hi Stuart. Yes, the register set is in scratchpad RAM.

So I have a few lines of code I want to optimize for speed. Have some ideas what I can do, but I'm also very interested seeing what the community comes up with... The code is used for reorganizing my TiVi editor index when I delete a line in the editor. Note that when I reorganize the index, I make sure that the index pages form a continuous memory region, so I don't have to worry about mapping pages or anything. That's already been taken care of. The index can grow up to 5 SAMS pages mapped to (>b000 to >ffff) for 10240 lines of text. ok, Here's what I would do: Copy code to scratchpad and work from there for reducing wait states Reduce loop counter overhead by putting multiple mov instructions in a single loop, say 8 Look at the fastest mov instructions (only use registers?) What else could be done for faster access? Note that in the code fragment tmp0=R4, tmp1=R5, tmp2=R6 and so on. *************************************************************** * _idx.entry.delete.reorg * Reorganize index slot entries *************************************************************** * bl @_idx.entry.delete.reorg *-------------------------------------------------------------- * Remarks * Private, only to be called from idx_entry_delete *-------------------------------------------------------------- _idx.entry.delete.reorg: ;------------------------------------------------------ ; Reorganize index entries ;------------------------------------------------------ ! mov @idx.top+2(tmp0),@idx.top+0(tmp0) inct tmp0 ; Next index entry dec tmp2 ; tmp2-- jne -! ; Loop unless completed b *r11 ; Return to caller *////////////////////////////////////////////////////////////// * TiVi Editor - Index Management *////////////////////////////////////////////////////////////// *************************************************************** * Size of index page is 4K and allows indexing of 2048 lines * per page. * * Each index slot (word) has the format: * +-----+-----+ * | MSB | LSB | * +-----|-----+ LSB = Pointer offset 00-ff. * * MSB = SAMS Page 00-ff * Allows addressing of up to 256 4K SAMS pages (1024 KB) * * LSB = Pointer offset in range 00-ff * * To calculate pointer to line in Editor buffer: * Pointer address = edb.top + (LSB * 16) * * Note that the editor buffer itself resides in own 4K memory range * starting at edb.top * * All support routines must assure that length-prefixed string in * Editor buffer always start on a 16 byte boundary for being * accessible via index. ***************************************************************

Also using SAMS and ramdisk together, no issues at all. Using TIPI PEB and ramdisk together is an issue though. So far I wasn’t able to copy files from the TIPI to the ramdisk using any of the utilities. Could not get it work with ForceCommand, DM2K or anything else. So far I only was able to copy files by writing a small program in extended basic that opens 2 files; source on TIPI and destination on ramdisk. Then I read a record from the TIPI and write it to the RAMDISK. Obviously that solution is kinda slow.

I’ll see if I can come with a good example in the next few days. But for now: Callback “get next free SAMS page” Basically the idea is that as a user you supply a pointer to a callback function that gets called again and again by the DSR while it’s loading the file. Obviously the callback function should follow some conventions so that it’s safe to switch from the DSR to the callback and return to the DSR without crashing it. One such example could be that instead of supplying the page list in advance, callback function would just supply the next “free” page each time the DSR requires one while loading the file. Callback “SAMS page loaded” Same idea, but at a later “trigger” point. As soon as a single SAMS page is loaded by the DSR this callback could be executed when set. The callback could be used for doing something with the SAMS page (in my case that would be change internal memory structures because in memory the layout of my editor is not the same as written on disk). Arguably these are things that can also be done after the file has fully loaded, but I think would offer more flexibility. Another example could be doing a CRC check on the loaded SAMS page, so you can abort file loading if it doesn’t match. Calllback “SAMS page saved” Same idea as for “SAMS page loaded”. Perhaps this could be combined with the above one. Would need to think about that one a bit more 😀

That’s an iteresting idea, I like it a lot. I’ll look into it and let you know. One thing that comes to mind is, that it would be cool if during the file I/O the DSR would allow user defined functions to be called. That way you could for example pass 2 pointers to the DSR: Address of a function that provides the next target SAMS page Address of a function that acts like a processing trigger each time after a SAMS page is loaded. Reason for (2) would be that I store the file internally in memory not in the same format as it is on disk or could do steps to halt processing on some user condition. Either way, would perhaps be sufficient to start with what you’ve proposed, passing a SAMS pagelist pointer.

Hi Matthew, not trying to derail your thread, but I thought you might be interested in this:

Thank you for providing this, makes a very interesting read and interesting machine I must say. More as anything else the 99/2 needs an F18a upgrade I’d say, just kidding 😀 Was the 99/2a TI-Basic specification or any other 99/2 specifications ever released?

For those who it might concern. I had some stability issues with the TIPI when loading large files. It worked fine for normal operations, but as soon as I started loading large files the TI-99/4a locked up after 30 seconds to two minutes and appeared to hang. What happened was that the Raspberry rebooted. Checking journalctl on the Raspberry showed that it very frequently went into an “undervoltage” situation and then quickly normalized. I threw away my USB power plug (one of my old mobile phones) and replaced it with a more powerful one, and problems disappeared.

It is loading text files. There still a couple of tricks I can use to speed it up a bit. Probably can make better use of scratchpad RAM and for HDR I can copy directly to memory instead of hopping via VDP memory. Do have the impression that the HDR ramdisk is a bit faster as TIPI. Thinking about it I’m going to keep the DIS/VAR 80 as an “import/export” functionality (for compatibility reasons with other software on the TI-99/4a). But also allow native saving/loading as program.

That’s a very nice demo. So there only seem to be system ROM chips and no GROM chips. Is there any GPL in the TI-99/2 ? I mean is the TI-Basic interpreter rewritten in assembly language? If yes, this raises a couple of questions: How does TI-Basic execution speed on the TI-99/2 compare with TI-Basic on the TI-99/4a ? Did any source code for the TI-99/2 system ROMs ever appear? Is the TI-Basic on the TI-99/2 a stripped down version of the 99/4a TI-Basic? I presume some commands do not exist (call color,..)

Here's a demo of me loading and then browsing some large files in SAMS.

As promised here's a rather long video of me demoing loading large files into SAMS.

Thanks guys, really appreciate it a lot. The largest file I loaded so far was Stuart Conner’s TI Invaders source code. That’s some >3000 lines of assembly source code. With the files you all provide I’ll. have some bigger files to experiment with. What I’ve learned so far is that I’ll need to speed up file loading, because using normal file I/O takes a long time even from ramdisk or TIPI. Also need to fine tune index handling. But I’ll take that discussion to my TiVi thread. I’ll see if I can do a couple of videos on the TI-99/4a (no emulation).

I'd like to do a little experiment using the TiVi edtor I'm currently working on. What is the largest DIS/VAR 80 file you were able to load and browse on the TI-99/4a? I'm trying to get my hands on some big DIS/VAR 80 files and with "big" I mean that it should be at least > 100 kilobytes. If you have such file and don't mind posting it (as a disk image). I'll try to load it on the TI-99/4a. For further details on the editor see here:

Thanks for the reply. I understand. 🙂

Thanks for the update, it is much appreciated! 😊 I have a feature request Tursi: would you be willing to add the F18a 30 rows mode to classic99 (in combination with allowing sprites in text mode, the same as the F18a allows)?

Looking at Power Strike, wouldn’t it be cool to have a genuine arcade machine driven by a custom mainboard with a TMS9900 CPU or derivate and F18a. A board perhaps kinda similar to Stuart Conners board. Not talking about 99/4a compatibility so games would need to be reworked, but for all homebrews of the last 10 years or so we do have source code. Put some real arcade control buttons in there and of you go.

I’d be interested in a fully populated board if this makes it to production. Heck, already have a couple of sideboard tipi’s and PEB tipi’s but it would be incredibly cool to put one in a speech synth. Would be nice to have a 1MB SAMS on there instead of the 32K though. Guess 1MB SAMS will become the gold standard for tipi in the future.

Also still requires a VDP PAB, but HDR ROS has the same buffer capability, and it is not too late to start using it with the new HRD4000b being released in the near future. It is something I sure want to give a try. Thierry’s page says: If you add >40 to the opcode, VDP memory will not be used as a data buffer. Instead, the address specified in PAB bytes 2-3 is considered as a cpu RAM address. This allows for much faster data transfer. Of course, your program has to be written so as to take advantage of this feature, which is therefore only available to assembly programmers. http://www.unige.ch/medecine/nouspikel/ti99/horizon.htm There are so many hidden gems in that beautiful device and its DSR.

This is a most interesting discussion. Can you share some details on how you exactly do this? For my TiVi editor I'm currently using normal file I/O to load DV80 files. But ofcourse it takes time when loading >100KB even from ramdisk/HDR or TIPI. So I'm considering alternatives to speed things up (at least for HRD).

guess that would be: systemctl restart tipi.service To check the status: systemctl status tipi.service Note: instead of cron you could also setup a systemd timer, but that is just a matter of taste I‘d say.

That's some impressive work, like it a lot. 😎 I especially like the possibility to load the DSR from file. I've included the github URL so that folks can check it out: http://github.com/jambuur/APEDSK99