Jump to content
IGNORED

Stevie Development Thread


retroclouds

Recommended Posts

Classic99: I don't get a cursor, but that would appear to be a sprite issue. I have text mode sprites but not in 80 columns yet. It also doesn't like the way Classic99 simulates the arrow keys - your KSCAN might be running fast (in which case the PS/2 keyboard adapter might also have trouble). Other than that I don't know how to use it so I couldn't test much more. :)

  • Like 1
Link to comment
Share on other sites

  • 2 months later...
5 hours ago, Vorticon said:

How's progress?

I've been working on adding file system I/O to the underlying spectra2 libraries and have been doing quite some refactoring in the progress as well. 

 

So next steps is to incorporate the updates in TiVi. Actually doing file I/O and the refactoring of spectra2 took a lot more time than I anticipated,
but I think it is well worth the effort.

Using spectra2 so far I was completely isolated of the surrounding TI-99/4a  (except for joysticks and keyboard input, which is also an own implementation).
When doing file I/O basically using the peripherals made it necessary to change stuff to be more aligned with the TI-99/4a.

The refactoring I did should allow me to combine spectra2 with C a lot more easily, which is something I want to concentrate on next year.
What I can definitely tell is that the project is not dead.  I'm basically hopping back and forth due to dependencies.

 

My next milestone is to have save/load possibility for large text files in TiVi

 

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

  • 3 weeks later...

ok, so this evening I made some good progress on importing a file into TiVi.

Now that pieces are starting to fit together it was real easy to do. 

 

Did my first tests with an 8 kb file (speechdocs) and with the XBEADOC file, which is 56 kb if I'm not mistaking. 

As I do not have SAMS support working yet, I stop loading the file once the 32kb high memory area  gets full.

 

For my tests I'm loading the files from a real floppy. Tests with ramdisk, cf7/nanopeb/tipi will have to wait for now.

Anyway I'm really pleased with the file browsing / editing speed. Inserting and deleting lines is very fast.

 

I'll try to add a youtube video

 

 

 

 

 

 

  • Like 2
Link to comment
Share on other sites

ok, so I used my phone to record floppy file reading.

 

What you are seeing is TiVi running on the final grom cartridge and using the F18a in 31 rows, 80 columns mode.

I'm loading the XBEADOC file from floppy drive 2.

 

During loading you see the VDP buffer, which is kinda handy as it allows me to track file loading progress for now.

Counters on the bottom left line show lines read and kilobytes read from file.  

I made a quick patch to bail out of the file reading once high memory expansion (>a000->ff..) gets full.

 

After that I start moving around in the file and do some line inserts/deletes. 

Apparently still have some issue when reaching end of file, but that'll have to wait for another day.

 

It's kinda rewarding seeing this run on the TI-99/4a itself.

 

 

 

  • Like 4
Link to comment
Share on other sites

On 9/8/2019 at 1:56 PM, Tursi said:

Classic99: I don't get a cursor, but that would appear to be a sprite issue. I have text mode sprites but not in 80 columns yet. It also doesn't like the way Classic99 simulates the arrow keys - your KSCAN might be running fast (in which case the PS/2 keyboard adapter might also have trouble). Other than that I don't know how to use it so I couldn't test much more. :)

I ran into a repeated key issue myself on RI.  I'm sure once he slows it down it'll be golden.

Link to comment
Share on other sites

  • 2 weeks later...

So by using 32KB memory expansion I'm currently able to load files that occupy up to 24KB RAM or 1024 lines (4K index starting at >3000) whatever is filled up first.

 

Basically for each line the index entry (4 bytes) currently looks like:

 

word: Pointer to line content in editor buffer (or line content itself if length <= 2)

word: MSB=SAMS page (not used yet), LSB=line length

 

With some (further) optimisation (e.g. RLE compression/decompression) I could squeeze more out of the 24KB editor buffer at >a000. 

The question is, if RLE on the fly compression/decompression would be worth it. Any ideas on that. Would like to give it a try though (the XBEADOC 

file I use for testing has plenty of whitespace in it).

 

This got me thinking. I would like to support multiple memory configurations, but I need to decide what minimal required equipment will be.

Forgetting the F18a availability for a moment (which is required for 80 colums mode) I think minimal requirement is the FG99, 32KB RAM and a CF7+ / nanopeb.

By using the FG99 advanced mode, I could have 512KB RAM splitted in 4k pages in the cartridge space at >7000 which I could then use for the index and  editor buffer.

 

What do you think about that?

  • Like 1
Link to comment
Share on other sites

How is a line represented internally in TiVi? With Adamed, I had a fixed 1024 line limit as well, but that was because each line was fixed in length (40 characters) regardless of the number of characters it actually contained, obviously not the most efficient use of memory by any stretch, but much easier to code :) The reason I ask is that I am curious about the reason(s) behind the 1024 line limit.

  • Like 1
Link to comment
Share on other sites

8 hours ago, Vorticon said:

How is a line represented internally in TiVi? With Adamed, I had a fixed 1024 line limit as well, but that was because each line was fixed in length (40 characters) regardless of the number of characters it actually contained, obviously not the most efficient use of memory by any stretch, but much easier to code :) The reason I ask is that I am curious about the reason(s) behind the 1024 line limit.

 

The current 1024 line limit is caused by the fact that I have a 4K index area at (>3000 - >3fff).
Each line takes an "index slot" which are basically 4 bytes each, so that makes 1024 lines. The index has a pointer to the line in the editor buffer (word1). The 2nd word contains the SAMS page (MSB) and the line length (LSB)

Putting the index on a 4K boundary should allow me to page it out real easily using SAMS.

 

The editor buffer itself is just a collection of strings (no length byte or termination character) starting at >a000. If a line is "crunched" after modification it does a copy on write. Meaning the updated line is not changed inline. Instead the line gets appended after the last line and the pointer in the index changed to point to that new line. That is real quick and will allow me to add some form of "undo" functionality. The line crunching only happens when the line is "dirty" and if I press "enter", move the cursor away from the modified line or do some other modifying action (insert line, delete line, search & replace)

 

I could probably squeeze more out of the editor buffer if I'd do a RLE compression when the line is crunched. 

RLE decompression could then happen when the lines are moved from the editor buffer to the frame buffer.

The frame buffer is basically just a 80*30 RAM memory area which is automatically copied to VDP by a task that currently runs 60x times a second.

 

Now back to the index and 1024 lines limitation. I could increase the index size to 8K by using >2000 - >3fff allowing up to 2048 lines.

However if I do that, I need to relocate the 4K area (>2000 - >2fff) that currently contains all variables used, the frame buffer, file stuff, etc.

Only place I can think of right now would be to use the final GROM 4K cartridge area (>7000 - >7fff).

 

This again requires me to put my spectra2 library and TiVi program code in 4K code blocks at (>6000 - >6fff) instead of the current 8K code block at (>6000 - >7fff). This means I will have to start to use bank switching.  Not a big deal by itself but does cause a lot of work to plan a proper code overlay layout.

 

 

  • Like 1
Link to comment
Share on other sites

Ah interesting scheme. I think it might be worth increasing the index buffer to 8K and having 2048 lines available. With Adamed, it turned out that 1024 lines was not as big as I thought it would be particularly with assembly programs where a line might only contain a few characters...

  • Like 1
Link to comment
Share on other sites

2 hours ago, Vorticon said:

Ah interesting scheme. I think it might be worth increasing the index buffer to 8K and having 2048 lines available. With Adamed, it turned out that 1024 lines was not as big as I thought it would be particularly with assembly programs where a line might only contain a few characters...

 

Yes, that's the road to go. I mean when using SAMS it is not an issue. The index itself will also be spread across many SAMS pages for up to 65536 lines. But if you only have 32K memory expansion I'd like to have more than 1024 lines. Assembly language source code should be a good fit for RLE compression as well.

 

  • Like 4
Link to comment
Share on other sites

On 12/31/2019 at 4:35 PM, retroclouds said:

 

Yes, that's the road to go. I mean when using SAMS it is not an issue. The index itself will also be spread across many SAMS pages for up to 65536 lines. But if you only have 32K memory expansion I'd like to have more than 1024 lines. Assembly language source code should be a good fit for RLE compression as well.

 

 

ok for those without SAMS I could use up to 7K of VDP memory as additional editor buffer space without too many code changes.
This means I can then free up 4K of memory expansion RAM (20K editor buffer instead of 24K editor buffer) and use that as additional index space.

 

With that I have a total of 8K for index (meaning 2048 lines of text possible) and total editor buffer space of 27K.
Would have to be seen how big the performance impact is when using VDP though.

  • Like 4
Link to comment
Share on other sites

Before starting to look into using VDP as an editor buffer store, I've been busy implementing RLE encoding during file load.

First results look promising. I am now able to for example load an 31K file (XBEADOC) into the high-memory expansion (24K), bumping the number of lines I could from that file from 777 to 909.

 

Still have to add the RLE decompression before the text is moved from the editor buffer to the frame buffer. Let's see how big the performance penalty will be. Don't think it will be noticeable a lot.
At least the RLE on-the-fly compression is not noticeable. I'm using js99er and a real TI-99/4a with HRD ramdisk for testing.

The RLE compression thing will be optional. Thinking about having some kind of configuration file with editor options.

 

  • Like 4
Link to comment
Share on other sites

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

 

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

Looking good! 264K of buffer space with the SAMS is massive and unlikely to be an issue on the TI. Even 2048 lines with just the 32K will suit the needs of many.

Question: will the TIVI created source files have any kind of proprietary formatting or will they be standard text files? I'm hoping to use TIVI to resume work on Ultimate Planet. The unfinished source code is quite large but should not be an issue since I have a SAMS card.

  • Thanks 1
Link to comment
Share on other sites

17 hours ago, Vorticon said:

Looking good! 264K of buffer space with the SAMS is massive and unlikely to be an issue on the TI. Even 2048 lines with just the 32K will suit the needs of many.

Question: will the TIVI created source files have any kind of proprietary formatting or will they be standard text files? I'm hoping to use TIVI to resume work on Ultimate Planet. The unfinished source code is quite large but should not be an issue since I have a SAMS card.

They will be standard text files (DIS/VAR 80).

Obviously DIS/VAR 80 is not the fastest, so that is why I want to try out some other file types as well. But DIS/VAR 80 will always be there as that offers most compatibility.

Link to comment
Share on other sites

1 minute ago, wierd_w said:

Since you are using a FG99, and are using 4k pages, is there any way to use/abuse the 4k RAM window capability of the FG99?  You could get ~480kb that way, assuming your editor can live in a 4k banked rom.

 

I have been thinking about that and it is certainly a possibility.

But it's too early at this time to consider as I'm still rearranging code in the >6000->7fff area a lot and don't feel limiting myself to 4K code blocks and jumping accross banks the whole time and laying out code.

SAMS is still my primary target. Perhaps we'll see a SAMS sidecar in the near future? (I mean besides Ralphs' SDD99). Anyway I'm not saying I won't do it, just not at this stage.

Link to comment
Share on other sites

1 minute ago, retroclouds said:

 

I have been thinking about that and it is certainly a possibility.

But it's too early at this time to consider as I'm still rearranging code in the >6000->7fff area a lot and don't feel limiting myself to 4K code blocks and jumping accross banks the whole time and laying out code.

SAMS is still my primary target. Perhaps we'll see a SAMS sidecar in the near future? (I mean besides Ralphs' SDD99). Anyway I'm not saying I won't do it, just not at this stage.

 

I was thinking something like this:

 

1) Test for 32k. Note it present

2) Test for SAMS if 32k present.

3) If SAMS present: Temporarily copy bank 1 ROM into Bank 0 RAM, via 32k area as temporary holder. Page back to Bank 0. Pretend you are an 8k cart, use SAMS memory.

4) If 32k present but no SAMS: Allocate 8k 32k ram, copy bank 0 ROM and bank 1 ROM there, patch address values, jump execution. Use cartridge RAM, and what is left of 32k RAM for your buffers.

5) If 32k absent: Allocate 8k of base RAM, copy bank 0 ROM and bank 1 ROM there, patch address values, jump execution. Use only cartridge RAM.

 

In all cases, you can still have the apparent utility of 8k ROM, but gain the utility of the fg99 when SAMS is not present.

Link to comment
Share on other sites

Using >A000 for storage totally destroys use do XB for access to SAMS.

After all with 32K >A000 to >FF9F are for XB programs.

 

How come you are not using >D000 to >DFFF as 90% of XB programs never even touch that area.

Maybe the idea is to remove XB from use?

 

Anyway RXB 2020 will allow any 4K boundry from >2000 to >FFFF swapped out and replaced with another page.

This will allow unlimited sized XB programs with imbedded Assembly programs too. (or DATA)

 

(How do I get away with this? Well GPL and VDP are unaffected by SAMS so any page can be changed with no ill effects.)

Edited by RXB
  • Like 1
Link to comment
Share on other sites

21 hours ago, RXB said:

Using >A000 for storage totally destroys use do XB for access to SAMS.

After all with 32K >A000 to >FF9F are for XB programs.

 

How come you are not using >D000 to >DFFF as 90% of XB programs never even touch that area.

Maybe the idea is to remove XB from use?

 

Rich, not sure if I understand correctly. I mean it is not like you are running both the extended basic program AND the editor at the exact same time.

As long as memory is saved/copied upon editor entry and restored upon editor exit, I do not see a reason why using >A000 - >FFFF is a problem.

 

Actually the reason I use >A000 up to >FFFF for the editor buffer is because it's the biggest continuous RAM memory reason available on 

the TI-99/4a. I do feel that the TI-99/4a memory map is like a Swiss Cheese ? with all these holes ?.

 

Anyway, as a matter of fact I really am looking forward integrating TiVi with Extended Basic.

But before I do that I want to have TiVi in a proper working state for DIS/VAR 80 files.

 

 

  • Thanks 2
Link to comment
Share on other sites

23 hours ago, wierd_w said:

 

I was thinking something like this:

 

23 hours ago, wierd_w said:

...

4) If 32k present but no SAMS: Allocate 8k 32k ram, copy bank 0 ROM and bank 1 ROM there, patch address values, jump execution. Use cartridge RAM, and what is left of 32k RAM for your buffers.

5) If 32k absent: Allocate 8k of base RAM, copy bank 0 ROM and bank 1 ROM there, patch address values, jump execution. Use only cartridge RAM.

 

In all cases, you can still have the apparent utility of 8k ROM, but gain the utility of the fg99 when SAMS is not present.

 

The TiVi editor code and the underlying library does not have relocatable code at this time. Memory addresses in ROM

are fixed at compile (assembly) time. Turning this into relocatable code would mean quite a challenge, not saying it's impossible just too much work at this time. I'd rather focus on functionality and stability at this stage.

 

  • Like 1
Link to comment
Share on other sites

9 minutes ago, retroclouds said:

 

Rich, not sure if I understand correctly. I mean it is not like you are running both the extended basic program AND the editor at the exact same time.

As long as memory is saved/copied upon editor entry and restored upon editor exit, I do not see a reason why using >A000 - >FFFF is a problem.

 

Actually the reason I use >A000 up to >FFFF for the editor buffer is because it's the biggest continuous RAM memory reason available on 

the TI-99/4a. I do feel that the TI-99/4a memory map is like a Swiss Cheese ? with all these holes ?.

 

Anyway, as a matter of fact I really am looking forward integrating TiVi with Extended Basic.

But before I do that I want to have TiVi in a proper working state for DIS/VAR 80 files.

 

 

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?

 

Edited by RXB
Added Text.
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...