retroclouds

oh yes, I’ve been thinking about that. First have to bring back 24x80 mode though. The thing is that the file dialogs are on rows 26-30 so I’m kinda blind while loading/saving files. But bringing back 24x80 mode is well worth the effort if it allows me to run classic99 debugger.

Thanks, these are all great ideas, and certainly worth investigating. I’ve taken some notes for revisiting later. Makes some great experiments.

Probably. The question is if it even matters for slow devices like a floppy drive. Probably not worth the effort. For mass storage devices like TIPI, HRD, nanopeb & IDE it might be another story when handling large files. For a long time I’ve been thinking about a way to distinguish between “slow” and “fast” devices. What I have in mind is that on application startup, a device scan is done (e.g. CRC check on DSR roms or other way to identify device like a HRD). Having that information you could have a standard DSRLNK and an optimized one for mass storage devices. Then again, not sure if worth the effort, considering compatibility issues, etc. Would be interesting to see how far this can be pushed though.

This evening I was watching the blinkenlight show on my peripheral expansion box while I was loading and saving large files with my programming editor. The way I've set the PEB up CRU wise, is that my HRD4000B is at >1700, TIPIPEB at >1400 and TI Disk Controller at >1100. Then it occured to me that for each individual level 3 I/O record access, the DSRLNK scans the cards in the PAB looking for a matching device to delegate the call. Isn't that quite an overhead? Are there DSRLNK's out there that keep track of state? If the DSRLNK has detected on the first call, that DSK6 belongs to >1700, then it could keep that state internally somewhere and in consecutive calls it could skip scanning all cards again until it finds a match. Would it be worth the effort speed wise?

Small update on Stevie; I finally have the save functionality in place. So I guess I can officially call it an editor now. 🙂 Works great on tipi and HRD4000B. But currently not so great on the standard TI Disk Controller. I get an immediate lockup when loading/saving from that controller. Guess I still have an old bug lurking around (thought I fixed that a long time ago, but there you have it, it's there again). Presume it has to do with scratchpad pollution and the TI Standard disk controller being more picky, so will take some time debugging this.

Does that mean the source code is available?

Can you elaborate on that? Does that mean the DSR space on the SAMS 4MB card can be accessed as well?

What is the most advanced assembler on the TI-99/4a and on the Geneve? With advanced I’m thinking of: Features Length of labels Speed Lines of source code it can handle. Linker For starters: how many assemblers are out there? I know: Editor/Assembler Mini Memory line-by-line assembler MG Diskassembler? ... EDIT: do we have source code available for any of the assembler mentioned?

looks like bad vram to me.

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

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

Thanks Vorticon!

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.

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!

Sony Hitbit for MSX1 and Philips for MSX2 😀

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.

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

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.

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

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.

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.

Here's a new demo. It's Stevie loading an assembly source file from github.

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.

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.

ok, got the memory barrier out of the way. I'm using low Memory expansion: >2000 - >2FFF (1) Spectra2 library >3000 - >3FFF (2) Resident Stevie modules Already had (1) running for a while. But now with (2) in place, I've got much more space left in bank 1. The cartridge image setup is as follows: Bank 0: Copy SP2 and resident Stevie modules to low MEMEXP Bank 1: The meat of editor. I've moved some of the Stevie modules from bank 1 to bank 0 where they get copied to low MEMEXP upon startup. Also the code layout is now changed in such way, that it's easy to add additional banks, but with the freed space I can wait for a bit longer.