retroclouds
-
Content Count
2,118 -
Joined
-
Last visited
-
Days Won
1
Posts posted by retroclouds
-
-
Thanks, these are all great ideas, and certainly worth investigating. I’ve taken some notes for revisiting later.
Makes some great experiments.
-
12 minutes ago, Stuart said:But would that method fail if referring to a disk by name (DSK.MYDISK.FILE) as a disk can be changed at any time?
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?
-
2
-
-
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.
-
2
-
1
-
-
23 hours ago, mizapf said:There is also TASM that I am using, but it does have some issues (does not recognize COC mnemonic and sometimes gets into trouble on the second pass, which I am currently investigating).
But it is a two-pass assembler, which I consider conceptually better than single-pass assemblers (like GenAsm). (Yes, it is slower, but I don't care about time. 🙂 )
Does that mean the source code is available?
-
6 hours ago, FALCOR4 said:I like the added feature for the 4K pages in all the 32K space, that was a great change that offers more flexibility! The card can do it, might as well be able to use it!
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?
-
Features
-
looks like bad vram to me.
-
2
-
-
9 hours ago, Tursi said:I've done the "swap in scratchpad for DSRs" before too.. but, the scratchpad is only 256 bytes. Why do you need to move 1.5k /per record/? Even if you did all of scratchpad, that's 512 bytes, plus 80 bytes max for the D/V80 record?
That said, certainly nothing wrong with your plan to move stuff over to regular RAM. Scratchpad really only offers a large benefit for frequently accessed data - if you only hit it now and then you'd be hard pressed to see the difference. It's only 4 cycles slower to read and 8 cycles slower to write - still faster than a single 9900 instruction.
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....
-
1
-
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
-
-
5 hours ago, Vorticon said:Here are all the pcode disks and documentation in one zip file. Also includes the Turtle Graphics disk by apersson.
Thanks Vorticon!
-
3
-
-
2 hours ago, Tursi said:pCode needs disks, yes, which are scattered all over this forum and I am pretty sure WHTech several times over. Classic99 supports it and also includes the disk images in a subfolder. Pretty sure MAME supports it. I didn't see if JS99er did?
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.
-
2
-
-
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!
-
4
-
-
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.
-
11
-
1
-
-
5 hours ago, Vorticon said:I was indeed thinking of the tipi doing all the work, but unfortunately I don't have a good understanding of the underlying work involved in such a task. It would have been so awesome though because then the documents created with STEVI could be backed to the Github with no fear of local hardware crashes and loss of data...
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 hours ago, mizapf said:...
The download into Stevie looks good; you can download files from Github via HTTP, of course. But I think you need a proper Git client to upload stuff.
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.
-
1
-
-
2 hours ago, Vorticon said:Very cool. Would it be possible to save a file back to the Github?
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.
-
1
-
-
8 hours ago, BeeryMiller said:Nice, I presume you used the URI route with the TIPI?
Now, figure out the easy way to go the other direction and save it. Going to throw a note on the TIPI development area for the subject matter.
Beery
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.
-
1
-
-
Here's a new demo. It's Stevie loading an assembly source file from github.
-
5
-
1
-
-
9 hours ago, RXB said:So pressing two keys is to much work to get to Edit Mode (Command Mode)? WOW!
2 RXB
Space Bar now you are in Edit Mode (Command Mode) TO MUCH WORK PRESSING THAT SPACE BAR? AGAIN WOW!
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.
-
2
-
-
21 hours ago, RXB said:Hmm that is EXACTLY what RXB does, PRESS SPACE BAR and drops directly into Edit mode (Command Mode) and never starts "DSK1.LOAD"
And when RXB starts up you either press 1 for "DSK1.LOAD" or press 8 for "DSK8.LOAD" or 0 for "WDS1.LOAD"
I have created exactly what everyone wanted in 2001 that is how long this feature had been in RXB!
All of these key option are all available in RXB, geeze how many times do I have explain it does exactly what you said you wanted?
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.
-
On 7/25/2020 at 4:16 PM, retroclouds said:This week I hit a barrier. The second bank of my 16K cartridge is full. That’s the bank where the actual editor code (8k) resides.
The first bank contains my heavily modified spectra2 library, that gets copied to low-memory expansion (4K so far). It’s used for doing all things I/O (VDP, sprite, keyboard scanning, etc.).
I hate doing bank switching, so I have to see what’s the best way to proceed. I considered copying all file-handling related assembly code to low memory expansion. Basically loading and saving files is for the most part stand-alone code that gets executed only during certain moments while the editor is running. Guess that makes it a good candidate. Also if I consider supporting multiple file load/save options I guess that makes sense. In addition I might copy all constants to low memory. That way, things like color schemes could be overwritten by the user.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.
-
3
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Stevie ("TiVi") Development Thread
in TI-99/4A Development
Posted
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.