retroclouds

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.

Yeah, would be cool if you'd could just drop into Extended Basic without any disk activity/delay. While in command mode you could have a keypress like CTRL-1 that does "DSK1.LOAD". That way no harm done. Just load "DSK1.LOAD" with a single keypress.

Mind sharing some details on the OS you’re working on, the toolchain you’re using and perhaps some pictures of the SBC in action?

oh that poor TI-99/4a. Really feel sorry for it... No joke.

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

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.

Thanks for the replies. So it seems the delimiter character that prefixes a file suffix could be anything (except a “.” dot) For me, the most naturals ones seems to be: ; _ / Actually I like the semicolon as a delimiter (at least for C files and assembly files). Also like to keep file extension short. Why waste multiple chars if a single char does nicely, leaves more room for the filename 😀

I’d like to find out what the allowed characters are in filenames on the TI-99/4a, and also which ones are the most commonly use. In particular I’m thinking mostly of DV80 files like source code in assembly language, C code, etc. I’ve seen following: FILE<0..9, A..Z> FILE<0..9, A..Z>;<extension> Examples: FILE1 FILE2 FILE3 FILE4 .... FILE1;S FILE2;S FILE3;S FILE4;S ... FILE1;OBJ, FILE2:C Reason I’m asking is because of my Stevie editor I’m working on. I have a routine that allows you to increase/decrease file names with a single keypress, e.g. FILE1;C to FILE2;C That way you can quickly browse through files. What are the most common extensions? Are they supported on all storage devices (TIPI, HDR, nanopeb, ...) ?

Thank you so much for providing this! The sheer amount of detailed information contained in this single document is unbelievable. Lately I’ve been looking at XBII on the 99/8 closely (an extension of Extended Basic on the TI-99/4a). This document helps explain a lot (terms like NUD and LED). I’m going to print the document and will be looking at it a lot.

My 2 cents on feature requests... There’s only so much that a developer can tackle in an acceptable amount of time. Also Force Command has already seen many nice features in a very short time. jedimatt has done an incredible job on that. Surely it being written in C doesn’t harm and implementation time is shorter as when coding in assembly language. Speaking for myself doing dev work for the TI-99/4a is all about having fun, trying new things, learning, etc. However, when it’s starts to feel like work, I am out. For that I have a day job (where others get to decide what needs coding). As far as feature requests go, perhaps it’s time to further concentrate and finalize the API? That way others could kick-in and help add features to Force Command. But sometimes it’s good to let time pass so that things get stabilized first and move from there. I am already very happy with where we’re now with Force Command.

I haven't checked in detail, but I suppose that the same mechanism that is used in QEMU could also be used on the real TIPI? What would it take to connect JS99er.net to my real TIPI? Do I have to add a websocket server on the TIPI?

For reference I have added the TI-99/8 mapper specification and how Texas Instruments envisioned usage back in the days. The "Mapper and us" document has some example code. It's an interesting read, as after all the TMS9995 in the 99/8 is a 16 bit CPU dealing with a physical address space beyond 64K. TI-99_8 Mapper Specifications 03-23-1983.pdf TI-99_8 The Mapper And Us 05-26-1982.pdf

I stumbled accross this and thought it might be interesting to share: https://retrobrewcomputers.org/n8vem-pbwiki-archive/0/35845334/48860720/33053543/SRAM Replacement for TMS99x8 VRAM.pdf

“The (99/8 memory) mapper and us” document is an interesting read on how Texas Instruments envisioned memory management on the 99/8. They for example had multiple protect bits (WRITE, EXECUTE, READ) for each of the 4K pages that yield an interrupt when a violation occured.

Most interesting discussion. Perhaps the thread title can be modified to better describe the topic? Also should this be moved to the development subforum?

From their documentation:

So if I understand correctly, I can page 8K HRD4000B pages (part of the ramdisk not partitioned/formatted) into the cartridge space >6000 ?

Never mind, found it in the user manual, page 21-32:

The HRD4000B instructions say that it has RAMBO support built-in. I browsed the manual but could not find any examples how to use it. I’d like to play with it and test a few things using assembly language. Can you point me in the direction where to look?

The folks in the Colecovision community created an open source hardware RGB mod for TMS9928A and TMS9929A VDP. https://tms-rgb.com

He also got a Gramulator up for sale: https://www.ebay.com/itm/Ti-99-4A-Gramulator-CaDD-Electronics-Ver-1-0-Vintage-Ti-Computer-Add-On/254643372049?_trkparms=aid%3D1110002%26algo%3DSPLICE.SOI%26ao%3D1%26asc%3D225074%26meid%3Da7e1bec806f447c69504fbf01ded077e%26pid%3D100047%26rk%3D9%26rkt%3D12%26sd%3D254646415059%26itm%3D254643372049%26pmt%3D0%26noa%3D1%26pg%3D2047675%26algv%3DSellersOtherItemsV2&_trksid=p2047675.c100047.m2108 Never seen that one before. Was it released before or after MG GramKracker ?

That is really impressive, i like it a lot!

@fabrice montupet It might be worthwile to dump the ROMS with the Armadillo Basic (if not already out there). There are definitely quite some differences between that one and XB II. Would make it interesting to run Armadillo Basic in MAME.

I also looked at the various XOP's used in the ABASIC source. The XOP's that get called in the source code are of following categories: FIVE SIX SEVEN EIGHT NINE TEN Comparing with what Ninerpedia says: https://www.ninerpedia.org/wiki/MDOS_XOP_Definitions 5 Keyboard 6 Video display 7 Memory Management 8 Device Operation 9 Utility functions 10 Mathematical function So it seems that MDOS OS calls are used to its full potential, throughout the ABASIC source code. Conclusion I can say -that unless you also backport most of MDOS to the TI-99/4a as some kind of compatibility layer-, this makes it impossible to run ABASIC on the TI-99/4a. Backporting all used MDOS calls, including argument compatibility is certainly not for the faint of heart. That's a task that would require multiple years. So I guess this rules out ABASIC as starting point for XBII port on the TI-99/4a. That doesn't mean all is lost though. I'm quite sure that certain part of that code is used on the TI-99/4a as well. Guess it's back to square 1: Look at Myarc XBII that runs with 128K OS. Do some comparisons with Armadillo Basic internal design document Do some disassembly, diagnose what memory is used by using MAME debugger, etc.

Today I compared the value stack as described in the Armadillo Basic Internal design document with the value stack definition in the ABASIC assembly source. That part seems to have been completely reworked by Myarc and does not match the Armadillo Basic spec.