Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


retroclouds last won the day on November 16 2015

retroclouds had the most liked content!

Community Reputation

931 Excellent

About retroclouds

  • Rank
  • Birthday 01/05/1973

Contact / Social Media

Profile Information

  • Gender
  • Location

Recent Profile Visitors

20,534 profile views
  1. The code I had basically did the following (assuming DSR scratchpad is already loaded): READ DV80 RECORD Backup "DSR" scratchpad: 256 bytes Restore "SP2" scratchpad: 256 bytes Do stuff with record.... Backup "SP2" scratchpad: 256 bytes Restore "DSR" scratchpad: 256 bytes GOTO 1 (*) (*) That gives me 1K. For sake of simplicity I'm not counting VDP read/write for record and some other stuff I had in there. Anyway, turned out it paid of not to use any fixed memory locations in my source code. Just had to change the required equates and it worked ok. I'm now only using scratchpad for the workspace and 8 bytes of "machinecode" that runs there for copying stuff to VDP and memory. A while back I checked what scratchpad memory addresses dsrlnk is using. Think I'm safe, but have to check with multiple devices to see if everything is fine. Tested it with the HRD4000B and TIPI and it runs fine. Speed increase is roughly 40%. Loading the invaders source code (96KB, 3063 lines of code) from HRD4000B now takes roughly 36 seconds compared to the 60 seconds it took before. What can I say, I'm a happy camper for now 🙂 This makes me wonder how far it can be pushed. At least using ROS' direct read to CPU memory could still give a boost. That's something I'd like to try. I'm also still using normal file I/O, which I heard has quite some overhead in it for record handling. Doing sector I/O and reconstructing the record myself could give another boost. Not sure if I would go down that road though. I'd rather have good compatibility instead of shaving of another few seconds. Then again....
  2. I’ve started working on saving DV80 and well, what can I say.... I didn’t like it. Too much hassle swapping memory. Due to the fact that I’m using my spectra2 library for doing the heavy lifting, I’m making extensive use of scratchpad memory. The library is used for memory copy, keyboard reading, all things VDP, task handling, etc. Original purpose of the library was to run cartridge based games on an unexpanded Ti-99/4a console. Using scratchpad by itself is not an issue, as long as you keep away from DSR or anything else related to the TI-99/4a itself. The solution I currently have in place when reading files, is that I just page out scratchpad memory, page-in scratchpad memory as required for dsrlnk and DSR file-access. No need to say, you’re pushing plenty of memory. Doing a rough calculation, I’m about between 1K and 1,5K for each record read. It shows the power of the 9900 CPU and storage devices like HRD4000B and TIPI that I’m still getting good performance out of it. But honestly pushing between 3 and 4,5 MB when reading a DV80 file with 3000 records is something I’m not fond of. Obviously you can state that most files are A LOT smaller and you don’t even notice it. But it matters to me. With that in mind it’s back to the drawing board. The SP2 library is using equates allover the place. So it should be not too big of an issue to move the SP2 work memory from scratchpad to low memory expansion. This introduces additional wait states, but I don’t think I’ll ever notice that working with the editor. If it does I will have to do the required CPU cycle counting. With SP2 reworked, I can then throw out the scratchpad memory swapping when reading and writing DV80 files. Expecting a decent performance boost out of that. Other than that, I’m also enhancing my keyboard polling routine, so that it also detects individual “non-standard” keys like alpha lock down, left shift, left fctn, left ctrl, etc. So in a nutshell, it will take some more time before I release the first Stevie beta, but it will be worth it (at least to me). On a sidenote, there will be a future version of spectra2 that will be “compatible” with Client Pulleys C. I will also making necessary interfaces so that the spectra2 functions can be called from C. What I want to do at a later time is integrate the C compiler into the editor. Do am aware that most are using gcc for cross-compiling now. Then again, having an integrated C environment on the TI-99/4a itself, is something I really like to have. But first things first... 😀
  3. Plannning on updating the Development Resources thread, adding all required pCode disks. Updating the DevRes thread is not as easy as it sounds, due to its size and risks breaking layout and having to correct all tags again until you get a descent layout again. That is what has been holding me back doing more updates in the last year or two.
  4. Thank you for your hard work on this. This document is so full with details, it’s a joy to read. I know you went through so much effort for testing and making sure all necessary details are there. It is very much appreciated!
  5. Sony Hitbit for MSX1 and Philips for MSX2 😀
  6. This morning I stumbled on the MSX DEV 20 game competition. Quality of entries is (very) high most of the time. Although not TI-99/4a related, I’m listing one MSX1 entry because of its TMS9918 graphics madness. Bullet hell and smooth scrolling on the 9918 with huge bosses.
  7. If you are thinking more about backup and local data loss of files created and edited on the TI-99/4a, then there surely are other solutions to the problem that do not require git or github. I've put it on my "mental" to-do list for Stevie. Could imagine having a Stevie plugin that controls a (still to implement) service on the tipi
  8. Thanks, it’s nothing more than a trick really. And it shows what TIPI is capable off. For the TI-99/4a it’s nothing more than a file it’s loading. Still, was quite pleased that my level 3 I/O routines handle it nicely 😀 Yes, everything beyond that would require a GIT client.
  9. Short answer; no. Due to the complexity involved I don’t see it happening. Unless using the tipi for doing all heavy lifting. Long answer included below. https://atariage.com/forums/topic/308551-dx10-home-computer-software-development-system/?do=findComment&comment=4596872
  10. Uploading to GitHub or other GIT repository servers is indeed a completely different cup of tea. implementing a GIT client on the TI-99/4a is out of the question. Guess you would need to use the TIPI as a proxy for doing the heavy lifting (which it already does now, doing the HTTP transfers, etc). If I was to implement something like that (which I’m not, too much other stuff) I’d probably save my files to a directory on the TIPI and have a proxy service that monitors the directory for file changes and mirrors that to GitHub. With that in place, it would not be difficult to control the service from the TI-99/4a with a simple API for doing commits, etc. When doing it the hard way and trying to implement something like a client on the TI-99/4a for communicating with Github (that’s something different as a plain GIT server), you could try to implement the required github REST calls and parse accordingly. But then you still have login, https, tokens and a zillion other things you probably need to consider.
  11. Not to derail this thread, but I've loaded the 99/8 ROM assmsup.txt source code directly from github into my Stevie editor on the TI-99/4a.
  12. Here's a new demo. It's Stevie loading an assembly source file from github.
  13. You are completely missing the point. And no need to yell at me writing in captial letters. Again, it’s not about too much work holding a key or whatever. It’s the fact that each time I go into Extended Basic, it’s trying to load something for me, I don’t need. So, in my case, and I repeat, in my case, I find it better the opposite is done. From the 99 times I jump in Extended Basic, I perhaps 3 times need DSK1.LOAD Why should I keep pressing a button for the thing not to do something? Sorry, makes no sense to me. Doesn’t matter though. You just encouraged me enough to start looking into the Extended Basic command interpreter more. So I’ll be baking my own version where the darned thing does exactly what I want. Thank you for that.
  14. Yeah, well what I envision is more like, you press 2 for TI Extended Basic or RXB and nothing is loaded at all. Without having to keep pressing space bar, 2 or whatever key. Notice the difference, it’s inversed. When I dedice at a later time I want to load “DSK1.LOAD” while on the Extended Basic command prompt, I just press CTRL-F1 or another combination. It’s in the eye of the beholder. What I see is more something like you have in MSX Basic, a more powerful command prompt, that’s all. BTW I always thought Extended Basic could use a more powerful command prompt. With the possibilities out there now, source code available, etc. perhaps it’s time for a new command prompt.
  • Create New...