retroclouds

@jedimatt42 Would be interesting to know if Stevie 1.2Q is any better with your USB keyboard. My hope is that now that I've switched to OS rom KSCAN there's an improved compatibility.

I've released Stevie 1.2Q

I've released Stevie 1.2Q You can grab the binaries here: This time there are 2 different cartridge binaries: 1. As usual we have the 30 rows 80 columns mode version. That one works best on the TI-99/4A with F18A and in the JS99er emulator. 2. Also have a 24 rows 80 columns mode version. This version is meant for using with the classic99 emulator. Don't see a reason to use it on the TI-99/4a itself, but if you do see a legit reason then let me know, I'm interested in your use case. One thing to notice is, that some of the keyboard shortcuts have moved again. That is due to technical reasons and for better compatibility. Check the help screen for current definitions. The list of changes that made it to Stevie 1.2Q is quite long. Check the issue tracker for full details: https://github.com/MirrorPusher/Stevie/issues?q=is%3Aissue+is%3Aclosed Features: #46 Multiple help pages in help dialog #43 Use KSCAN instead of custom keyboard scanning solution #42 Improve compatibility with classic99 #41 Introduce session ID display in TI Basic #40 Support multiple TI-Basic sessions #39 Add file append functionality #34 Smart filename selection on file load/insert/save #26 Add print file option #11 Upgrade to latest xas99 version #08 Shortcut: Position cursor on bottome line of screen #07 Insert file at cursor #06 Clipboard file functionality Bugfixes: #39 Reset SAMS to default bank layout upon program exit #32 Flickering in editor dialogs #31 Fix color clash on help dialog #29 Crash on file save/load with no filename given #05 Cursor moves out of editor area into bottom row #03 Crash on long filename As usual bugs can be reported via the Github issue tracker https://github.com/MirrorPusher/Stevie/issues You can also contact me on Atariage via PM or report bugs in the Stevie development thread Note: the classic99 cartridge binary has "(24X80)" in the program title.

I'll be releasing Stevie 1.2Q in the next few days. This is the first release where there will be 2 separate cartridge ROM binaries: Stevie 1.2Q Requires the F18a and runs in 30 rows 80 columns mode. Uses sprites for cursor and ruler. Runs on TI-99/4a with F18a VDP. Runs on js99er emulator Stevie 1.2Q (24x80) Requires the F18a and runs in 24 rows 80 columns mode. No support for sprites. Cursor is character. Runs on TI-99/4a with F18a VDP. Runs on classic99 emulator

Hi Fabrice, I just looked at the v3 demo again. In particular I'm interested in knowing: Will you stick to the v9958 ? Is the SAMS on the motherboard 1MB? Do you have any updates on the project? Reason I'm asking is that I would like to look into what it takes to get a proper 9938/9958 version of Stevie working. (now that I have a Stevie 24x80 build for classic99 working, it seems like one of the logical next steps) https://github.com/MirrorPusher/Stevie/issues/44 Would be kinda cool to do a Stevie version that supports the TinyPC

But R12 was set before as below, so it's not bit 0. If the CRU were to be switched to timer mode, than I would have expected more of a lockup? li r12,>000e

Took some time to look into this weird issue again. Was able to narrow down to this piece of extra code I used to detect the status of the alpha-lock key. That code was basically part of my wrapper around kscan, as seen in the following commit: https://github.com/MirrorPusher/spectra2/blob/facf40d83a4b11650aeb9ffcb50287a99dd01d98/src/modules/keyb_rkscan.asm Here's the offending snippet: ;------------------------------------------------------ ; (1) Check for alpha lock ;------------------------------------------------------ li r12,>002a ; Address of alpha lock sbz 0 ; Set wire low li r12,>000e ; Select keyboard row 5 tb 0 ; Test input wire (ALPHA-Lock key down?) sbo 0 ; Set wire high jeq rkscan.prepare ; No, alpha lock is off blabla ; Yes, alpha lock is on, so As far as I can tell, the problem was caused by the "sbo 0" instruction. I looked at Thierry's site and I'm still unsure here. But it looks that by setting the bit I'm basically enabling interrupt on INT7* That was not an issue in my Stevie editor itself, because I have "limi 0" there all of the time. But in TI Basic interrupts are enabled. I presume that what happened was, that by pressing the FCTN key I trigger an interrupt that can't be recognized/handled in the interrupt service routine. Is that what happened? As said, that's a behaviour that only happens on the real deal, not in classic99 nor in js99er. Haven't tested in MAME because Stevie doesn't work there. In the console ROM (looked at TI intern) I found the following code for checking alpha lock: ;------------------------------------------------------ ; (1) Check for alpha lock (same as in console rom. works) ;------------------------------------------------------ clr r12 sbz >0015 tb 7 jeq rkscan.prepare ; No, alpha lock is off blabla ; Yes, alpha lock is on If I understand the code correctly: 1. "sbz >15" sets the output value of bit 21 to low, that is pin P5 attached to alpha lock column 2. "tb 7" is then used to check the status of the INT7*/P15 pin (that's the keyboard row with the keys FCTN, 2, 3, 4, 5, 1, (joy1-up, joy2-up, Alpha lock) Is that correct? It seems that as far as CRU is concerned, there are many ways to skin the cat when reading the keyboard. Working with the CRU is kinda mind-boggling to me, probably because I haven't done any low-level HW/SW stuff before. But hey, I guess you are never too old to learn.

Thanks Rich. That rings a bell somehow. Might well be that my TI-Basic initialisation is not properly done. Have to do some more testing in the next days. Will let you know on the results.

I have this weird issue on my TI-99/4a which must be related to KSCAN. The good news is that I switched to KSCAN in Stevie and in the editor everything is working as expected. Happy about that. Now in Stevie I have the possibility to open a TI-Basic session, basically what happens is that I pick a session in Stevie, some setup is done for TI-Basic and you are in TI-Basic. If you want to know more about it, related source code is here: https://github.com/MirrorPusher/Stevie/blob/master/src/modules/tibasic.session.asm Now here to the strange part: If I press the FCTN key in TI-Basic, the cursor is blocked and the LEDs of all peripheral expansion cards (HDR, TIPI PEB, disk controller), light up. As soon as I release the FCTN key everything is back to normal, cursor blinks and LEDS are off again and the interpreter keeps on working. Note that this behaviour happens on the real TI-99/4A only. In classic99 and js99er everything works as one might expect. First I thought it was related to my ISR that I'm using for switching back to Stevie. But it's not that. Got the same when the ISR isn't setup. Then I checked scratchpad locations for invalid setup, that still is a possibile cause. But haven't found anything yet. The stupid thing is, that because of this "bug" I can't use the function arrow keys for editing in TI-Basic. FCTN-Quit does work as expected and brings the TI Title screen again. Any clues what this might be? Could this be a left-over of the keyboard not being properly setup during last CRU scan? It must have something to do with CRU I suppose. Kinda lost here. EDIT: Note that TI Basic behaves normally if I jump right into it from the TI selection screen.

You only have to copy the 16K VDP RAM and scratchpad memory to SAMS, the 24K RAM is already there in SAMS. It's just a matter of switching the proper SAMS pages. Copying 16KB VDP RAM is fast. In the latest Stevie revision I have up to 5 TI Basic sessions and can switch between them in no time. There's nothing wrong with brute force if it's fast.?

That is indeed an issue, the places I can think of: 1. Keep one SAMS page always mapped and store the mappings there, obviously that reduces the overall availability. 2. Store the pages mapped in scratchpad memory (that's an issue when doing XB, not so if you are running a standalone assembly language program, e.g. cartridge) 3. Use VDP memory (as you said) 4. Run FG99 cartridge in advanced mode and store the mappings there, aka. same as when storing in a supercart 5. In the DSR space if there's memory there, e.g. when using RAMDISK, ROS

Tursi would you consider adding 30 rows mode in F18a emulation? That would be so cool. I know that feature requests can be frustrating, so please ignore if that’s the case. I remember you mentioning you wanted a more complete F18a emulation in classic99v4. (For the newest revision of Stevie I’ve added a build-option that replaces the sprite cursor with a character cursor. You win some you lose some. Speed is a bit slower now (mostly technical reasons because I don’t want to rewrite too much of the cursor code) and am running in 24x80 instead of 30x80. But I also gain the CLIP. device and the excellent debugger, well worth it to me).

https://www.unige.ch/medecine/nouspikel/ti99/superams.htm#High-level Haven’t seen this program but if it’s out there, perhaps it fits your purpose or at least the ideas behind could be utilized if you decide to build something similar.

Don’t know how I missed that. I can see a raspberry pico (prototype) project I like to attempt: the “freedom” cartridge.

I'm currently refactoring Stevie for improving compatibility with keyboard debounce, USB keyboards and emulators (for example CPU overdrive mode in classic99). Until now I rolled my own keyboard scanning routine that was based on the work of Simon Koppelmann. The idea is to just call the KSCAN routine as included in the console ROM. Before digging in, I looked at the documented source code TI-99/4A intern, ROM 0 disassembly of addresses 02B2-0496. This is where the questions come in. For KSCAN to work I need to have scratchpad memory setup prepared. One of the first things KSCAN does is a call BL @>0864 to save the GROM-address on the substack. At least that is what TI-Intern says. Does the GROM-address need to be saved because it gets overwritten by setting the GROM address for things like CNTRL, FCTN, SHIFT, letters table? What the best place to find some working KSCAN examples? Is there anything special I need to worry about when calling KSCAN (besides the scratchpad memory locations as derived from console rom disassembly) ?

Do we know for how much this lot got sold?

Thanks for the update. Browsed through the API. That’s some impressive stuff you have going on there.

Next to a Star Wars arcade? How cool is that. ? That is a sharp looking setup you got there.

Multiple TI Basic sessions in Stevie 1.2M js99er-20211229211545.webm

1/3 for me. Still looking forward working on 3D printing stuff and my own cartridge project in 2022 (which in a first stage might turn into a software-only project with the FG99)

Don't know, but the TI-99 should do a version as good as the colecovision.

How are the 32/40/80 column editors going? Really looking forward to the 80 column editor.

Today I was able to solve a long standing stevie bug. The problem was that Stevie locked up while starting. This only happened if I loaded the Stevie cartridge in FG99 after I ran the FC cartridge before. The problem was, that Stevie expected SAMS banks to be in the order of transparent mode SAMS Regs: >2:>02 >3:>03 >A:>0A >B:>0B >C:>0C >D:>0D >E:>0E >F:>0F Now, if I run FC and then type "exit", the TI-99/4a returns to the title screen, but SAMS banks stay in the order: SAMS Regs: >2:>00 >3:>01 >A:>04 >B:>02 >C:>03 >D:>00 >E:>00 >F:>00 (Tested with FC 1.32) I now changed Stevie in such way, that upon startup and exit it sets the SAMS registers in the order SAMS Regs: >2:>02 >3:>03 >A:>0A >B:>0B >C:>0C >D:>0D >E:>0E >F:>0F I also set SAMS in transparent mode upon exit. I can imagine, that you want to keep the SAMS banks in a particular order when you call an "external" program from FC, but perhaps on FC exit, banks can be reset to the standard order? Could imagine it might solve some hard to find bugs in older software.

Myself I’m not so convinced about linux on the desktop. Don’t get me wrong I like linux a lot. In my day-to-day job I’m doing linux server administration and it’s great. It’s just that on the desktop and when using a GUI it’s not on the same level as the windows or mac GUI. And then there’s these little glitches on the desktop where sometimes thing just don’t work out as planned and proper linux drivers are missing (thinking about some of the intel nuc drivers here). Long story short, for my desktop I’ll be switching back to windows and use WSL2. That way I can do anything on the command line in WSL2. For the stuff I do on the desktop WSL2 is the best of both worlds really, as it offers great integration. Just my 2 cents.

I don’t know, ebay prices are going crazy. I’ve seen a used PEB box with only flex card, 32K and serial for more than 450 EUR here in europe. oh, and it got sold at that price…