retroclouds

I have been thinking of using xdt99 as backend assembler in my TiVi editor. Could do some cool stuff, like assemble, halt on error and jump to the corresponding source code line.

Fabrice, didn't one of your previous prototype boards have a V9938 VDP instead of the TMS9918 VDP ? Just asking (because of the possible 80 columns mode). Guess that for best compatibility you reverted back to the TMS9918 ? What video output options will there be with the Tiny 99/4a? Thinking about the F18a here. But again keeping the spirit of the Tiny, it would be cool if there is some kind of 80-column, 80's era VDP solution. 😎 Either way, I'm very much looking forward to the Tiny 99/4a as it stands.

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.

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.

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.

Would it be possible to make these calls run from cartridge space and add multiple banks?

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.

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.

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

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.

Fabrice, for a price of roundabout $650 I am in for a pre-built system. This will be so cool and am very much looking forward to it.

That's a cool idea! I like that a lot.

I would also consider following important: Possibility for easy extensibility. By that I mean it probably makes sense to decide what belong to "core" functionality and what can be added via extensions (think libraries, ...) What language Ultimate Extended Basic should be implemented in? From my point of view that would be C, mixed with assembly language. Don't know how mature the current TMS9900 gcc target and libraries are at this time though. Nonetheless, having written too much assembly language lately I would not be inclined tackling such a project with only assembly language. For the most performance critical parts or for interfacing with existing libraries one could still mix-in assembly language ofcourse. I don't see GPL in the picture due to the speed penalty and the fact you are more or less at the same coding level as assembly language. But that's just my opinion ofcourse. Don't forget, the idea of this thread is to discuss all possibilities without thinking constraints.

I'm with you it's going to take a group effort for this to ever materialize. However, the idea of this thread is to think about how an ultimate extended basic could look like and what features are most important. This without any thinking constraints of what we had in the past (except for hardware limitations and compatibility with existing extended basic perhaps). That's why I'm very interested learning what people like or consider important and perhaps do some design document based on that. Can you share some details on why Myarc XB has almost no backward compatibility?

These are some nice pictures! I love it. @jedimatt42 where did you get the nice Geneve + TI-99/4A stickers?

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.

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.

Thank you for the replies so far. So it seems that 80 columns, execution speed (and compilation), as well as SAMS support would be crucial. Do concur that looking at extended basic source code in 80 columns can be tiring. Perhaps something along the lines of TidBit could be a solution there. What about graphic commands and utility functions? I think it would make sense to look at the work senior_falcon and RXB have done so far? As far as execution speed is concerned, could imagine having a mode where you can opt for running with integer variables instead of FP? How would you control these modes? Perhaps the first line in the program could be a "HINT" line to tell the interpreter/compiler how to deal with the program.

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.

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?

1. Tried MSX Basic on the real thing. I recently bought a Sony Hit-Bit MSX1 computer. Really pleased with it. 2. I think for Ultimate Extended Basic ever to be useful it should be compatible with Extended Basic so that you can run existing programs. 3. Very much like the idea on the compiler I'm not saying I'm starting development on a new Extended Basic. This is a thread to collect as many ideas as possible and perhaps work out a design specification document. With the ideas collected and a specification document in place, thins could be implemented in such a way that it's a lot more easy to include features such as built-in compilation. Also see this as a team effort, tackling such a project means years and years of work for a single person. I'm sure @RXB or @senior_falcon can chime in on how much work it is to tackle such project. But with multiple people working together I think things can get accomplished (e.g. my TiVi full-screen editor could be a little piece in the puzzle. I'm designing it in such a way that it will be possible to edit TI Basic / Extended Basic source code with it).

Good question regarding RXB and am totally open to what's already available there. Dropping XB's GPL legacy is something that should be seriously considered IMHO. Would give execution speed a higher weight compared to GPL code density, at least with todays options such as final GROM. I've been giving MSX basic a try lately and was very impressed with it's execution speed.

This thread could/should possible be moved the the TI-99/4a development subforum, but I'd like to get as many ideas as possible and as there's no current development I'd prefer if it can stay here.

So I've been thinking about extended basic lately and that it is the go-to language on the TI-99/4A. We've seen multiple extensions to Extended Basic, like for example Gram Kracker Utility 1 which probably generated one of the first enhanced Extended Basic versions. We also have Rich Extended Basic and now Extended Basic G.E.M. Also don't forget the work on SDD99 that is enhancing Basic in multiple ways. Just for fun, and who knows what happens next in the future, I'd like to collect ideas on how an Ultimate Extended Basic should look like. What the benefits are, etc. I'll kick it off with following proposals: Compatible with existing Extended Basic Fully runs from cartridge space so that we get as much program space use out of 32KB memory expansion as possible Built-in support for SAMS Full-screen editor or advanced line editor as seen in MSX Basic Built-in assembler integrated in Extended Basic, so that you can mix assembly source code right with your extended basic program code. Something along the lines of: http://www.peter-cockerell.net/aalp/html/ch-4.html Full 80 columns support, both for basic program code and line editor.

True, not for any existing applications. If you were to do a small multitasking environment it could be useful though.