Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


retroclouds last won the day on November 16 2015

retroclouds had the most liked content!

Community Reputation

1,177 Excellent

About retroclouds

  • Rank
    River Patroller
  • Birthday 01/05/1973

Contact / Social Media

Profile Information

  • Gender
  • Location

Recent Profile Visitors

20,845 profile views
  1. This is probably a stupid proposal, as I can imagine lacking space on the F18a MK1, but perhaps an option for the Mk2? What about having 2 “VDP cores” and a frontend that switches between the two depending on the graphics mode/VDP register settings. That way when you are in pure “TMS9918A” mode, the 9918A core is in charge. If you are in F18a mode the F18a core takes over and you get all the bells and whistles. Guess that would require a major rewrite, for something that are edge cases. (BTW still hoping to see 48/60 rows mode someday ;-)
  2. True, that’s why I have three of them 😀 Having said that, I always thought that the HRD4000B ramdisk is a very underestimated device. It’s more than a ramdisk.
  3. How about the other way around? Use the HRD4000B as a ramdisk and SAMS replacement. Have to go through the development manual again, but if I recall correctly there’s enough RAM on the HRD4000B that you can get away with it. Obviously you have to do your own paging, so your software have to support it.
  4. Regarding the metal case. Just a few days ago I saw an online add of a company with an online site where you can send your design files to, they validate and build it for you. Think prices where very reasonable.
  5. Rasmus did quite a few F18a demos. If you look at http://js99er.net under software - F18A specific, you can run the demos in the emulator and compare. They should also be available as cartridge images. Perhaps Rasmus can chime in on that.
  6. I’d be interested in one too, should you have one left. Thanks a bunch! 😃
  7. Thank you so much for creating and releasing the source code of Rock Runner! The quality of the game is amazing and having developed all that with just the line-by-line assembler is incredible.
  8. Today's a special day. I finally got around releasing Stevie 1.0 Grab the ROM in the official release thread. Source code is available on Github. Still have to add a markup page, but there you go. Basically there are 2 repositories involved that need to match in order to make a successful build: Spectra2 is the basic library for low-level stuff like keyboard scanning, VDP output, memory copy, task handling, etc. https://github.com/MirrorPusher/spectra2/tree/release/Stevie_v1.0/src Stevie is the editor source code itself https://github.com/MirrorPusher/Stevie/tree/release/v1.0/src The way my build process works, is that I push my commits to a local Bitbucket installation. In there I have a plugin that then pushes all changes to GitHub. Both github repositories where private before and I've opened them to the public this evening, now that I know things are kinda stable. (well you can still look at the many previous releases for a good laugh or two). That being said, you won't be able to build Stevie from source code out of the box. I have some custom build utilities currently not on github. They do things like moving all files from subdirectories to a build directory, do string replacements, etc. The scripts are just some hacks and not pretty at all, that's why I don't release them to the public at this time. Most of it can now be done with xas99 I suppose, but still have to look into that. Anyway, the source code is there for history purposes and if you really want to build it, it's not that hard and you'll manage. I'll be taking a break for a while, it has been quite a ride. Especially the debugging phase was really tough, a lot of hard work. It's time to move on and try out new things. Some of it TI-99-4a related and other things less so. Looking forward to both! Anyway. Have fun! EDIT: I very much believe in open source software and I encourage everyone to release source code whenever possible. 😃
  9. This is the first GA release of Stevie, a new 80 columns programming editor for the TI-99/4a. Some of you may have been following the Stevie development thread. For those that haven't, here are some key facts: 32 kilobytes cartridge rom Written in TMS9900 assembly language Requires F18A VDP Requires 1MB SAMS memory card Only uses level 3 file I/O for better compatibility with the various storage devices out there (tested with HRD4000B ram disk, TIPI, IDE DSR card and TI disk controller) Some of the main features: It's fast 80 columns, 30 rows mode Edit up to 10.200 lines of text with maximum length of 80 characters each. That should be a first on the TI-99-4a. 10 color schemes "Hardware" cursor (uses sprite as cursor (that is something currently only possible on the F18A VDP) "Fastmode" option. Possibility to bypass VDP memory when loading files from a device with a supported DSR (ROS, IDE, ...) Help built-in (at least for the keyboard shortcuts) Indicator for alpha lock up/down There have been 2 public betas and Vorticon has been helping me with testing the alpha releases. So I think that for a first GA release it is quite stable. Nonetheless, please make sure you always have backups of the files you edit with Stevie. Sorry, there's no search and replace option in this release. If you want to try out Stevie, but do not have an F18A equipped TI-99/4A or a SAMS 1MB expansion card, you can give it a spin in the js99er emulator (Classic99 and MAME are currently unsupported) Big thanks to vorticon for helping me with testing the alpha releases. His feedback was very valuable and it is very much appreciated. Still have a lot of ideas with things I want to accomplish, but this will have to do for now. I've been working for almost 3 years programming Stevie, and it is now time to take a break and move on to new things. That being said, I will look into bug fixes. Please report bugs to the Stevie development thread with a description of what happened and a screenshot if possible. Have fun! retroclouds 2021-02-06 Stevie v1.0 stevie.bin
  10. 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?
  11. 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
  12. 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.
  13. 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.
  14. I like it very much and yes the twinkling stars certainly help create a magical atmosphere. Looking forward seeing how this further develops. 👍
  15. 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.
  • Create New...