Jump to content
IGNORED

Stevie Development Thread


retroclouds

Recommended Posts

11 minutes ago, RXB said:

If you change a single 4K page you could do the same thing like I do with RXB that loads 540K in my game IN THE DARK.

All of it sits at lower 8K >2000 to >3FFF so I swap out the 2 pages of 4K there to use 540K for the game.

Just to not have a problem with Assembly in my game the Assembly is at >D000 and thus this does not interfere with the XB at >A000 to >C9F8

Of course I do not use CALL LINK but instead use RXB CALL EXECUTE(ADDRESS) instead as it needs no name to be found.

But do you get the idea?

 

 

Yes, I see where you are going when using SAMS. That's the approach I will be following for the lines index (mapping line numbers to editor buffer) as well. The index is at >3000 - >3fff. In this 4K area I store the pointers for the 2048 lines, by swapping this to the next SAMS page I get access to the next 2048 lines and so on. So, if you want to for example jump to line 9600 in the file you are editing, it's just a matter of deriving the correct SAMS pages for index and editor buffer.

 

Do note that I will have a different memory map depending on when using SAMS or not. For example, the editor buffer will be RLE encoded when only 32K  memory expansion is available. Don't see going through the overhead of doing RLE encoding/decoding if I have many SAMS pages at my disposal. 

 

So, coming back what you mentioned. It would be possible when using SAMS I don't use the whole >a000 - >ffff range as usual, but only a subset of that. But again, I'm quite sure that as long as everything is properly saved/restored upon program entry and exit, things should work as planned.

 

While we're at it; are there many other critical memory areas to stay clear of when using extended basic? Has been a while since I looked at Extended Basic memory map. 

 

 

 

  • Like 1
Link to comment
Share on other sites

Just the normal pointers in Scratch Pad you know about and VDP pointers you delete if you make a copy and put back.

This is what I do in RXB to load screens, most of the VDP pointers are just copies but some are very important, like flags.

 

IN THE DARK game in RXB on SAMS I use 768 bytes to write to screen and save 768 bytes of screen to SAMS

when the 768 bytes gets within upper of lower 8K limit I move the >2000 to >2FFF to >3000 to >3FFF and load lower page at >2000 to >2FFF

same happens when I get to upper 8K limit and move >3000 to >3FFF to >2000 to >2FFF and load a new page at >3000 to >3FFF

 

It looks like a box moving in a larger box and that small box is the screen. You could use the same trick for Text,

the cool thing is this leaves you 24K to play with for programming space. Also most of VDP too.

Link to comment
Share on other sites

  • 2 weeks later...
On 1/12/2020 at 9:38 PM, retroclouds said:

So I have been doing some major refactoring again. Well up to the point I've broken TiVi.

But that's ok, just have to go through the painful debugging steps again ;-)

 

I've reworked the index so that a 4K page now can address 2048 lines instead of 1024 lines. 
This is especially important for those that only have 32K memory expansion and no SAMS.

 

Until now an index slot was 2 words:

  word 1: compressed length or SAMS page, uncompressed length

  word 2: pointer to line in editor buffer.

 

Now it's just the pointer to the line (not an absolute address, just an offset). 
I am also able to store the editor buffer SAMS bank in the high-nibble of the MSB as well. 

 

With this I am able to address 11 SAMS banks, 24K each high-memory (a000-ffff) for a total of 11*24K or 264K of editor buffer space.

Think that should be ok for now. Will come up with some enhanced scheme if need arises.

 

The below explains it in more detail:


***************************************************************
* Size of index page is 4K and allows indexing of 2048 lines.
* Each index slot (1 word) contains the pointer to the line in
* the editor buffer.
* 
* The editor buffer always resides at (a000 -> ffff) for a total
* of 24K. Therefor when dereferencing, the base >a000 is to be 
* added and only the offset (0000 -> 5fff) is stored in the index
* itself.
* 
* The pointers' MSB high-nibble determines the SAMS bank to use:
*
*   0 > SAMS bank 0
*   1 > SAMS bank 0
*   2 > SAMS bank 0
*   3 > SAMS bank 0
*   4 > SAMS bank 0
*   5 > SAMS bank 0
*   6 > SAMS bank 1
*   7 > SAMS bank 2
*   8 > SAMS bank 3
*   9 > SAMS bank 4
*   a > SAMS bank 5
*   b > SAMS bank 6
*   c > SAMS bank 7
*   d > SAMS bank 8
*   e > SAMS bank 9
*   f > SAMS bank A
***************************************************************

EDIT; In case you are wondering;  line length (and compressed length) is now stored as a string prefix in the editor buffer.

 

On a side note; progress on RLE stuff has been very good and I'm quite pleased with it, but first have to fix the bugs caused by refactoring indexing code.?

 

 

Taking a break on the RLE stuff and started work on SAMS itself. List of open topics and WIPs is getting longer, but that is fine.

 

Today I did another major redesign of the index again. Turns out that the way I described above is becoming too much of a hassle to implement, as it severely limits the number of SAMS pages I could address. So I will be following another more easy approach, which will also give me more flexibility regarding number of SAMS banks. 

 

The previous index redesign increased the possibility to index 2048 lines instead of 1024 lines. Fine so far, certainly keeping the number of lines.

When using SAMS I will have a "shadow" index on another SAMS page, but same size and same addressing.

Instead of the pointer to the line, it contains the SAMS page where the line of code is stored.

So it's basically just another 4K page kept in sync with the index itself.

 

Other changes: 

I have the possibility to load files out of a predefined list, with a single keypress combination (CTRL+0 up to CTRL+9).  That's kinda cool especially when using the HRD ramdisk in my PEB. It's superfast. Plan is to enhance the concept to keep up to 10 editor buffers open at once (When using SAMS that should be easy to accomplish).  Keeping my fingers crossed.

 

8K cartridge space is now mostly filled, so will have to start thinking about bank-switching. Probably will have something like:

1st bank: TiVi editor code

2nd bank: TiVi file handling code (loading/saving, file selection, etc.)

  • Like 4
Link to comment
Share on other sites

  • 4 weeks later...
  • 1 month later...


Here's a quick update on the development of TiVi. 

 

First of all, development has not stalled. On the contrary I've been making very good progress in the last few months.
But I also decided to do some major refactoring along the way. Most important, there are some critical changes coming in the way memory is handled.

 

First of all I have removed all code that is dealing with the plain 32K version of the editor. I need to focus as making major program changes when developing in assembly language can be a real pain.
I stated at the beginning that F18A and SAMS are the primary target. What I've done is that by aligning all editor structures (editor buffer, index, command buffer, frame buffer, etc) to 4K boundaries I can just flip the corresponding SAM page.

That was not possible with the mixed SAMS/32K layout I had been working on in the beginning. By doing this switch to 4K boundaries a lot of stuff gets easier.

 

I also started working on the command buffer, which is basically like a command shell in the editor. The idea is that I can run editor commands, but also some other external stuff from inside the editor.

 

js99er-20200406205602.thumb.png.ed71922614135ad73597a3ecce81a967.png

 

 

As some of you know, the TiVi editor is build using spectra2 (which you can consider like a small kernel for doing background things, reading keyboard, etc.). I've been making a lot of changes there as well too.
In the most critical places I now have some "assert functionality" implemented which lets me crash TiVi in a controlled way. It's a lot better than having to deal with runaway loops while copying memory for example.

 

In the critical places I have something like this:

        ....
        ci    tmp0,>7fff            ; Insane address ?
        jgt   fh.file.read.crash    ; Yes, crash!
         
        jmp   fh.file.read.sams.load1
                                    ; All checks passed, continue.
                                    ;-------------------------- 
                                    ; Check failed, crash CPU!
                                    ;--------------------------
fh.file.read.crash:                                    
        mov   r11,@>ffce            ; \ Save caller address        
        bl    @cpu.crash            ; / Crash and halt system        
        ;------------------------------------------------------
        ; Show "loading indicator 1"
        ;------------------------------------------------------
fh.file.read.sams.load1:        
        mov   @fh.callback1,tmp0
        bl    *tmp0                 ; Run callback function                                    
        ;------------------------------------------------------
        ; Copy PAB header to VDP
        ;------------------------------------------------------
fh.file.read.sams.pabheader:        
        bl    @cpym2v
              data fh.vpab,fh.file.pab.header,9
                                    ; Copy PAB header to VDP

 

Here's the crash screen. By saving the PC, caller address, register content and referencing the source list file really helps a lot when troubleshooting. 

 

js99er-20200406211202.thumb.png.26dbe39a0d80c75206d562d3e7c48cd3.png

 

 

 

 

 


 

  • Like 3
Link to comment
Share on other sites

  • 4 weeks later...
  • 3 weeks later...

I've decided to rename the editor from "TiVi" to "Stevie".

 

There are multiple reasons for doing so:

  • In it's current form it has turned into something completely different and shares no resemblance to the well-known unix "vi" editor.
  • It's not related to the "tipi" device in any form. So having the editor called tivi doesn't do the tipi justice in my opinion.
     

So what's the deal with this "Stevie" name then? I still like the sound when pronouncing the name (like "TeeVee") and I very much like the music of Stevie Nicks. So there you have it. 

 

Note that I'm going to release the source code on Github in the next few weeks. Until now it was synced on Github as a private repo.
But I think that the source code is now stable enough, so that I can make it available to the public.

  • Like 4
  • Haha 1
Link to comment
Share on other sites

T.I. VI or tee-vee -- never sounded like any relation to 'tip-ee' to me... 

 

Someday, though I will write a program called Fred. It will not be an acronym... Just pure use of a proper noun. That will be the name of the most useful program I ever write.  So...

 

Awesome!

  • Like 3
Link to comment
Share on other sites

4 hours ago, jedimatt42 said:

T.I. VI or tee-vee -- never sounded like any relation to 'tip-ee' to me... 

 

Someday, though I will write a program called Fred. It will not be an acronym... Just pure use of a proper noun. That will be the name of the most useful program I ever write.  So...

Actually, it did to me, I thought it was in some way TIPI related. ;)

 

The first telephony product I worked on was called Bob 2 (no relation to Microsoft Bob). It was not an acronym either, it didn't mean anything, and it didn't share a name with anyone who worked on it. They put together the first version of the tool in a weekend, couldn't decide on a name, and went with the advice "Why don't you just call it Bob?"

 

  • Like 1
Link to comment
Share on other sites

19 hours ago, BeeryMiller said:
  Reveal hidden contents

 

 

I almost skipped this whole thread as Stevie didn't interest me.  Might not hurt to put into the thread topic "was TIVI" so those that were following would continue to follow.

 

Thanks, I've updated the thread title accordingly.

 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

  • 4 weeks later...

I`ve recorded a small video in js99er with some of the features in Stevie.

 

At this time I am very pleased with the processing speed on large files (browsing the file once it is loaded into memory).

So index (re)organisation is working very well know.

 

Even though there are still plenty of bugs. The asserts I added seem to catch most unexpected behaviour and you get the CPU crash screen.

 

Edited by retroclouds
  • Like 8
Link to comment
Share on other sites

Today it’s time for giving an update and clarify where I see this project is heading too, as well as some things I’ve learned along the way. When I started thinking about what I want to accomplish with the editor, I knew this was a project that could easily span several years.

 

The fact that it’s completely written in assembly opens up a lot of possibilities, but also means that development is rather slow, when compared to writing in a high-level language. So what is the plan and what is next.

 

Accomplished so far:

  • Loading a large DV80 file into SAMS works really well. The file I/O routines I have implemented go along with the stock disk controller, TIPI and HDR ramdisk nicely. Although loading large files is pretty slow, I am going to keep the file routines I have there and call this “compatibility” mode. I’ll also work on a new set of file I/O that’ll be a lot faster, but probably not as “compatible” with all type of disk devices out there.
     
  • So far I’m really pleased with how fast working with large files on the TI-99/4a works.
    There’s still room for speed optimisation, but you know the saying: premature optimisation is the root of all evil.
    Along the way I did quite a few changes on how a DV80 file is stored in memory. Obviously storing the file as you would in VDP memory is not going to cut it, once your file contains a few thousand lines of text.
     
  • Insert and delete speed is good, even for files with for example 5000+ of lines. As said memory organisation is very important for good performance. Implementing undo shouldn’t be too hard to do with the code I have in place now. Basically I have copy-on-write, so the old lines of text are still there in memory (at least to a certain extent)
     
  • I threw out the 32K code. Mixing 32K and SAMS memory layout was a stupid thing to do. I’d rather create a 32k standalone version instead of mixing the two. 
     
  • Had a hard time fighting feature creep. I mean, this is about having fun and not only doing work. Nonetheless, the goal is to come up with an initial version in the near future. 
     
  • From a code perspective I have a good library in place (made a lot of changes to spectra2 in the last few years). Doing stuff in assembly language does not take as long to implement as it did before. Nonetheless, for a later version I want to have some kind of interface in place so that new functions can be implemented in a high-level language (C99?) or use a custom FORTH 

 

 

Next tasks are:

  • Finally getting “save file to disk in place”
  • Crush the remaining bugs
  • Complete work on the command buffer (command history)
  • Put a file picker in place.

 

After the initial version is out:

  • Work on a configuration file (obviously a DV80 file) and a corresponding parser
    • Custom file settings, color schedule, etc.
  • Implement integration with assembler and C99 compiler
  • Seriously think about the high-level functions (search and replace, mark code, etc.)
  • syntax highlighting (that should be fun to implement, make use of the F18a cpu in gpu?)
  • Plugin infrastructure.
  • Integration with TI-Basic and Force Command
  • Custom fonts
  • Multiple files in memory

 

What I have implemented (but not shown and really tested yet) is a clock plugin that is shown in the status line.

It runs as a background task, reads the clock file, parses & displays it. Actually it’s only a few lines of code.
Quite interesting how much you can accomplish in assembly language once you have the necessary “infrastructure” in place.

 

Really hope to have an initial version of Stevie out the door, before the F18A MK2 makes it to market.

Edited by retroclouds
Added 2nd part of post, after I had to take a break because of some friends visiting our place.
  • Like 2
Link to comment
Share on other sites

16 hours ago, retroclouds said:

I`ve recorded a small video in js99er with some of the features in Stevie.

 

At this time I am very pleased with the processing speed on large files (browsing the file once it is loaded into memory).

So index (re)organisation is working very well know.

 

Even though there are still plenty of bugs. The asserts I added seem to catch most unexpected behaviour and you get the CPU crash screen.

 

 

This is looking awesome! Nice work so far.

  • Like 2
Link to comment
Share on other sites

  • 1 month later...

It’s probably time for another video, but will have to wait for another day.

 

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.

 

Also have been thinking about memory layout again, and perhaps make another change for supporting files with more then 12288 lines of text. The bottleneck is the index really. Each SAMS page (4K) can index up to 2048 lines of text. When I reorganize the index (inserting or removing a line), I page-in the affected SAMS pages so that they form a continious memory region of 6 x 4K (>a000 - >ffff) and that explains the editor limit of 12888 lines. Once the index reorganizing is done, only the single 4K SAMS index page of the line where the cursor is at, is paged-in.

 

At this time I’m not using any of the TI-99/4a console routines. Guess that would make it a good candidate to port to other TMS9900 based systems. Obviously all I/O, SAMS and F18a VDP handling would then have to be rewritten. Also not for the faint of heart.

 

On a sidenote, I now have a basic dialog functionality in place. This is for example used when you load a file. First a dialog is opened with an input box, for filename input. Each dialog can have it’s individual set of hints and supported keymaps for FCTN and CTRL keys.

 

  • Like 1
Link to comment
Share on other sites

oh, forgot to mention; it’s not much of an editor as long as you can’t save files.

Guess I’ll better get of my butt and finally implement a save file routine.

 

It’s not that difficult, don’t know why I haven’t started working on that one yet.

Somehow, there were always other features to implement, things to try out, bugs to fix.

But if I really want to get a first beta out of the door, I’d better start......

  • Like 1
Link to comment
Share on other sites

1 hour ago, retroclouds said:

oh, forgot to mention; it’s not much of an editor as long as you can’t save files.

Guess I’ll better get of my butt and finally implement a save file routine.

 

It’s not that difficult, don’t know why I haven’t started working on that one yet.

Somehow, there were always other features to implement, things to try out, bugs to fix.

But if I really want to get a first beta out of the door, I’d better start......

I left that one for last in Adamed as well. It's just not a very exciting or interesting task ?

  • Like 1
Link to comment
Share on other sites

1 hour ago, retroclouds said:

 

It’s not that difficult, don’t know why I haven’t started working on that one yet.

Somehow, there were always other features to implement, things to try out, bugs to fix.

But if I really want to get a first beta out of the door, I’d better start......

You know... as soon as you implement the SAVE option, you can further develop the editor using Stevie! ;)

 

 

  • Like 2
Link to comment
Share on other sites

54 minutes ago, InsaneMultitasker said:

You know... as soon as you implement the SAVE option, you can further develop the editor using Stevie! ;)

 

 

 

That could actually work when using TIPI.

Would still have to assemble on a unix box though. I have my own preprocessor and I'm using Ralph's xas99 assembler. Then again that could also run on the TIPI. 
Only thing missing would be a way to trigger the preprocessor and assembler on the TIPI. 
 

 

 

  • Like 1
Link to comment
Share on other sites

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.

 

  • Like 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...