Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by retroclouds

  1. This is Stevie, a new 80 columns programming editor for the TI-99/4a. Key facts: 64 kilobytes cartridge rom Written in TMS9900 assembly language Requires the F18A VDP Requires 1MB SAMS memory card Requires FinalGROM cartridge (or compatible device) Only uses level 3 file I/O for better compatibility with various storage devices (tested with HRD4000B ram disk, TIPI, IDE DSR card and TI disk controller) Main features: It's fast Support 80 columns 30 rows Support 80 columns 24 rows Editor buffer with space for 10.200 lines of text (80 characters) 10 color schemes TI Basic integration 5 parallel TI-Basic sessions possible. "Fastmode" option on File I/O. Possibility to bypass VDP memory when loading files from a device with a supported DSR (ROS, IDE, ...) Clipboard support (copy between files) 2 cartridge ROM binaries exist: 30 rows 80 columns with "hardware" cursor (aka sprite cursor) Supported on the TI-99/4a with F18A and 1 MB SAMS. Fast storage device recommended (ramdisk, TIPI, ...) Runs in js99er emulator 24 rows 80 columns with "character" cursor Supported on the TI-99/4a with F18A and 1 MB SAMS. Fast storage device recommended (ramdisk, TIPI, ...) Runs in classic99 and js99er emulators. Help built-in (at least for keyboard shortcuts) Indicator for alpha lock up/down Source code: https://github.com/MirrorPusher/Stevie Issue tracker: https://github.com/MirrorPusher/Stevie/issues Development discussion thread on Atariage: 2022-01-22 Stevie v1.2S 30 rows 80 columns version stevie_v1_2s_8.bin 24 rows 80 columns version (for classic99) stevie_v1_2s_24x80_8.bin 2022-01-18 Stevie v1.2Q 30 rows 80 columns version stevie_v1_2q_8.bin 24 rows 80 columns version (for classic99) stevie_v1_2q_24x80_8.bin 2021-10-03 Stevie v1.1X stevie_v1.1x.bin 2021-02-06 Stevie v1.0 no longer available
  2. I think I saw one on Ebay recently. Thought how cool is that, a dongle for the TI-99/4a. Do you know how it works?
  3. Released Stevie v1.0 BETA 2. Some stability improvements, polishing and bugfixes. Polished about dialog (show all key mappings) Polished color schemes Bugfix: Properly initialize all SAMS index banks (fixes potential crash issue for files >2048 lines) Bugfix: Show code block filename instead of editor buffer filename when IO error during block save Bugfix: Show updated counters when saving file Bugfix: Added memory full error during file load Bugfix: Don't crash editor when reaching bottom of file after delete operation Bugfix: Properly refresh frame buffer when at end of editor buffer Bugfix: Refresh screen early when starting file load operation Get the cartridge binary in post #1
  4. Currently working on preparing Stevie v1.0 BETA 2. This means ironing out some bugs still present in BETA 1. As part of the testing I'm working with some larger files. So far I worked with medium sized files of ~ 3000 lines. For the remaining tests I'm using DV80 files with a minimum of 8000 lines. I have locked the editor to loading files with a size of max. 10200 lines. That's not an issue for a 1 Megabyte SAMS card, it boils down to 860KB of editor buffer space required if all lines really contains 80 characters. For most of the "real" assembly language source code files I loaded so far, it's a lot less though. More in the area of 350-500 KB. The limiting factor at this time is the space required for the index. I have 5 SAMS pages reserved for the index, allowing space for up to 10240 lines. Reason for having a maximum of 5 SAMS pages is that, when doing index reorganisation, I map these 5 pages into the 32KB continuous memory area >b000->ffff. Index reorganisation is what happens when lines get inserted or deleted. If there's interest I can consider rewriting the index handling so that it can manage a variable amount of index pages. But for now I think that 10200 lines is plenty. Thinking about it more, probably could bump to 6 SAMS index pages at >a000->ffff for a maximum of 12288 lines without doing too much rework. Would have to find some space for the stuff I currently have in >a000->afff. For the future I'm considering having a "stable" version of Stevie v1.0 where I probably do more bugfixing if necessary and a "development" version for the folks that want to experience the newest features.
  5. This seems like an interesting device: https://hackaday.com/2021/01/22/mouster-brings-usb-to-retro-computers/ A very small USB adapter that takes any USB mouse (not only PS2) and turns signals into DB9 for the joystick port. Works with some USB game controllers too. Wonder if it would be any good on the TI-99/4a. Unfortunately firmware source code doesn’t seem to be available and the price is perhaps a bit steep (25 euros), but still acceptable.
  6. I like it very much and yes the twinkling stars certainly help create a magical atmosphere. Looking forward seeing how this further develops. 👍
  7. Thought I’d give an update on what to expect in the first public beta I released yesterday. Stevie v1.0 BETA 1 System requirements First some details on the system requirements. This is the setup you will need to run Stevie on the real deal: Required: TI-99/4A Home Computer F18a MK1 VDP (80 columns mode/30 rows with sprite support) SAMS 1MB card (will work with smaller version, but not tested and there’s no RAM boundary testing in place) Highly recommended: TIPI (as PEB card or standalone with 1MB SAMS expansion) HRD4000B ramdisk. Alternative: js99er emulator I’m aware that’s a setup that’s limiting the scope for many of you, mainly due to the lacking availability of the F18a VDP. However, I’m convinced that will change in the future. And at that time it’s good to be ready with the editor. Had very good results with file loading/saving on both the TIPI and the HRD4000B. Same goes for the standard TI floppy disk controller. Also tried the IDE and works there as well (but had mixed results due to my Seagate drive being partly broken). In terms of compatibility it’s important to know I’m only doing level 3 file I/O. Reasoning is that I think it offers the best compatibility among the storage devices out there. And it’s reasonably fast (at least on the HRD4000B, IDE and TIPI). Also note that Stevie support device paths (e.g. for TIPI) and has an option to skip the VDP when loading files for those DSR’s that support that (e.g. ROS on the HRD4000B, IDE DSR, etc.) Testing and bugfixing Development testing was done with the js99’er emulator. That’s currently the only emulator that emulates the F18a in 80 rows, 30 columns mode combined with sprite support.The cursor in Stevie is a sprite. I’m planning on supporting classic99 in a future release when I’ll do the enhancements for supporting the V9938 and V9958. It implies that for these VDP’s the cursor handling will no longer can be done with a sprite, and won’t be able to have position based color attributes (need to verify that). Really tried my best to fix as many bugs as possible. I know there are still edge cases that crash the editor. Chances you’ll see the editor stall in a loop with garbled VDP are small though. I have tons of asserts in the code that trigger the “crash screen”. Reasoning is that if something goes wrong, it’s better to immediately halt the editor instead of moving on and possible corrupting file during saving later on. With that being said, make sure you have backups of the files you edit with Stevie. Things can and will go wrong. When doing bug-reports please add a screenshot of the crash screen, it will tremendiously help in identifyng the cause of the issue. Vorticon did a lot of testing in the previous internal alpha versions. His feedback was very valuable. In fact he encouraged me to have block commands (copy, move, delete) in there as well as search and replace. Both of these I did not have on my task list for the first release. Managed to cram the block commands in there. Unfortunately search and replace will have to wait for a future release. So a big thanks to Vorticon for doing the testing. It’s very much appreciated. Next steps I’m not planning on introducing any new features in the initial release. The editor should be rock solid and any new features that get introduced increase the risk of something not working as expected. That’s especially the case when programming in assembly language. There will be a Stevie v1 beta 2. If there will be more betas depend on the user feedback. Roadmap for future releases I have a ton of stuff I want to include in the editor. Besides doing more changes in SAMS memory handling (speedup for large files) first things to come will be catalog and file picker, multi-file editing and code templates. Then next up is integration with perhaps a c99 compiler and an assembler. Also want to do tight integration with Basic and make the editor configurable. I also want to abstract some of the code in such way that it can run on other TMS9900x equiped computers. And last but not least add support for the V9958 as I want Stevie to run on Fabrice’s Tiny-99 system.
  8. Press Ctrl - O (Open file) and a dialog will appear where you can enter the filename. In the first post I’ve listed the current key mapping. In this version everything is pretty much controlled by key combinations.
  9. ok, first beta of Stevie v1.0 released. Check post#1 for the cartridge image.
  10. have to ask this, without starting a copyright/patents war. Would it be legit to do a replica (board) of the 99/8 and are all components used still available today?
  11. You should check out the youtube videos of Opcode’s homebrew Donkey Kong arcade port for the colecovision. Still not released to the public, but is by far the best port on the 9918VDP and very close to the arcade version.
  12. Not really, there are plenty of functionalities you have that are not available in Stevie. 🙂 But I am finally approaching the first public beta. Currently doing some polishing and more bug-fixing. Looking forward to the release, because after that I'll probably take a break for a while.
  13. I so much enjoyed the interview. Thank you for that!😀 To be honest myself I’m more into arcade style games, but from a programmer’s view I very mich appreciate the huge amount of work and skills you put into writing the game. Heck, for a moment I remembered the pain I went through trying to fit Pitfall into only using scratchpad memory and the slow progress when writing more complex stuff in assembly language (also thinking about my abandoned games Time Pilot and Tutankham where I just lost interest after a long time and having put hundreds of hours of work into it). Seeing your interview helps me keeping concentrated on finishing a project before starting the next one. You’ve truely raised the bar and as one of the “new” software packages making active using of SAMS, I’m hoping we’ll be seeing more games and programs written exclusively for it. Perhaps for the next project you could consider the HRD4000B. From a development perspective it has a lot of nice features (besides being a ramdisk).
  14. Another update: I've got the block commands working (copy, move, delete, save block). I'm rather pleased with the results. Speed is very good for the most part. Deleting a few hundreds lines of code sure is fast enough. If you have a 100 KB file and start doing copies in the first lines, then it can get rather slow. I've got a strategy for dealing with that, but it does mean a rather large code change handling SAMS and I don't plan on doing any more changes/enhancements for this version. Only bugfixes for now as I want to get the first beta out of the door. On a sidenote, I've moved from a 16KB ROM to a 32KB ROM. *-------------------------------------------------------------- * Bank order (non-inverted) *-------------------------------------------------------------- bank0 equ >6000 ; Jill bank1 equ >6002 ; James bank2 equ >6004 ; Jacky bank3 equ >6006 ; John This is what the 4 banks do: Jill: Startup code (Memory setup, copies spectra2 code to RAM, copies some low-level Stevie routines to RAM (used in multiple banks) James: Does the heavy lifting, main part of the editor Jacky: File load/save functionality John: Dialog stuff EDIT: All in all I've reached a status where the editor at least doesn't crash that often any more. That means that SAMS memory handling is working properly for the most part.
  15. Have been a little quiet about my current Stevie development activities. Due to personal reasons I was not able to work much on Stevie in the last few weeks of 2020. So I didn't manage to get a first beta out. Anyway, I'll first release the beta if I think I managed all milestones I defined for myself. This will take some more time. In the meantime here's a short video where I demonstrate block marking, copy, delete and saving code block to file. js99er-20210110183635.webm
  16. That is just incredible! Motivates me to add V9958 support to my Stevie editor. 👍
  17. I wasn’t aware there are any SAMS boards out there that have DSR memory. Did I miss something? Buy yeah, I also wondered how SAMS is able to do an initial mapping of SAMS pages itself upon startup.
  18. Could you give some details on the steps involved? e.g. what does the conversion tool do?
  19. That is most intertesting! Is there any information available on the Tomy Tutor BIOS calls?
  20. Nice find! I don't think anyone in the community was aware this was released as a full package.
  21. I don't think the VHDL for the F18A FPGA MK1 is available. There's VHDL code available on github for the F18a as used in the Colecovision Phoenix FPGA, but not sure if it's identical to the MK1. https://github.com/CollectorVision/Phoenix-Colecovision
  22. That's a fast-paced game! Reminds me of Robotron 2084. Got to level 5. My top score: 430 Well done. This game rocks big time! 👍 It also impressively shows what seniors' XB compiler is capable of. 😎
  23. Thanks for providing this. Like it a lot. Just noticed that when pressing the right FCTN key while alpha lock is up, it shows alpha lock going down. Is that actually the case? On a sidenote, In my Stevie editor I'm using a variant of the keyscan routine published by Simon Koppelmann taken from the book "TMS9900 assembler auf dem TI-99-4A". Not using the TI99-4A ROM keyscan routine. Before I'll release Stevie, I have to revisit and have to learn more on how to properly debounce keys. Because that is what is required for getting a fluent typing experience. Is there a good way to do a reliable keyboard debounce, without using a very precise CPU loop? I tought about the 9901 timer function here for a moment. Seems like a waste spending CPU cycles while reading the keyboard. Also makes it difficult if you are on a machine that has a higher clock rate.
  24. Don't know if this has been already reported and fixed in the past, so please ignore if necessary: The config program ("CALL TIPI") locks-up if the URL in URI1 is too long. Just verified it again. Had to ssh into the PI and edit the tipi.config manually to make it work again. After I removed the URL and restarted the TI-99/4a, the config started responding normally again. Tested with TIPCFG v10, PI-Version 1.65 The URL I used was: URI1=https://github.com/kl9900/TMS9900Family/blob/master/Consoles/TI-99/99-8/Rom/TXT
  • Create New...