Jump to content

retroclouds

+AtariAge Subscriber
  • Content Count

    2,284
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by retroclouds

  1. @Retrospect you keep'em coming! 👍 Think it's about time I make a Retrospect game collection cartridge. 😊
  2. ROMDSK is an amazing project and am very interested in it. Are there any details on progress/current state? Can you share details on the sidecar PCB? Will it have pass-through? My use case is a bit different. I’m currently working on my 80 columns editor Stevie (64K cartridge image for finalGROM) and want to have the option to load files from the cartridge image itself (e.g. instruction manual, basic, extended basic programs) Stevie requires SAMS as it is designed for handling big files (e.g. tested with 100Kb-500Kb file), hence my question on pass-through.
  3. Yes,that is correct. Program editing is still 32 columns, but there are instructions to turn on 80 columns mode while your program is running. For many of the extended basic commands (hchar, vchar, etc.) there are comparable call link instructions. There are also calls for defining a window, scrolling, input, etc.
  4. Think I stumbled upon a small bug. When doing "CALL HELP" after having run a T80 program the first few screens are garbled (as it displays in 80 columns mode). Other than that, let me take the opportunity to say what an amazing package this is! I am very impressed! 🙂 js99er-20210706194345.webm
  5. This thread is sure in need for an update. I have some holiday days coming up. I’ll see that I’ll update the thread with the collected documents/packages. Updating the thread is not a joy, due to the big amount of links it contains it has a certain complexity and it’s not a task I look forward doing. I’d rather spent my free time on doing TI stuff. Having said that, if there’s any volunteer wanting to take over that task in the future, I’m more than happy to let go. Could imagine having some web tool where the package authors can make their own updates and generate the content out of that automatically. Then only have to put the generated code in the thread and are ready to go.
  6. I also bought several F18a’s I still need to install. Looking forward doing that (3 weeks vacation coming up early July).
  7. As usual, a joy to read. Thank you so much. You should really consider doing a special edition, “Todays news” with news of the last years. Lots of software and hardware to be written about 😃
  8. Voted! Flashpeb sounds good to me! 😀
  9. I'm currently working on a Stevie revision for classic99. This means I have to let go of the F18a 30x80 mode with sprites. Instead it's 24x80 with a character based cursor and ruler. But you get a lot of stuff in return; (1) the CLIP. device, (2) speed, (3) the integrated classic99 debugger. The Classic99 debugger immediately pointed to a bug in my F18a detection code, so I'm happy about that.
  10. Yes, but the thing is you have to write quite some code to reliably detect features. And it could work on real hardware as well if any of (future) devices have a corresponding DSR.
  11. oh, and perhaps with the possibility to write to the platform file you could interact with the platform, e.g. do stuff like define shortcuts in the emulator. Thinking about js99er here where depending on the browser and host platform you are running on, it's difficult to have access to many of the keys without them being hijacked by host OS or browser and never reaching the application. If you could define such shortcuts you could then just click on the corresponding shortcut in the 'keyboard' section.
  12. ok, this is something I have been thinking about: a universal way for a program (Basic, assembly, ...) to detect on what emulator/platform it is running on. My proposal is to add a fake device (DSR) e.g. "PLATFORM." that gives read-only access to a DIS/VAR 80 file that has a specific syntax. Line 1: Platform type. Possible values "EMULATOR", "HARDWARE" Line 2: Platform identification number: 0=TI-99/4a, 1=TinyPC, 100=mame, 101=classic99, 103=JS99'er Line 3: Platform name Line 4: Platform version Line 5: Platform capabilities (*) Example 1: JS99'er EMULATOR 102 JS99'er 8.6.2 ... Example 2: Classic99 EMULATOR 101 Classic 99 v399.047 ... Example 3: TinyPC HARDWARE 1 Tiny-99/4a v3 ... Now I am aware that on the real deal (or on mame without embedding the fake platform device) there is no "PLATFORM." device, but in that case you can act accordingly. Thinking about it further, what if having multiple devices? Perhaps something like 'PLATFORM.TIPI' or 'PLATFORM.RAMDISK' ? When having a GPL based DSRLNK you could also detect FG99 if it had such DSR? Where it gets really interesting is the optional platform capabilities string. Suppose you would be able to detect platform specific settings like (SAMS enabled, F18a enabled, etc.). What do you think?
  13. This is to confirm that it does work fine in js99er. Sorry for the confusion. I must have done something wrong while building the cartridge image. Repeated the build step once more and then it worked flawlessly. Will do some more testing. Now if I could only dump my changes to the cartridge image again. Perhaps I can hack something on a local js99er version. Quick question; with the online version, suppose the dump functionality is in place, couldn’t it just dump to a browser cookie that gets restored and used instead of the cartridge image? Probably not as easy as that, but the basic idea. For sure you wouldn’t that as persistent storage, but for development purposes I guess it might work.
  14. hmm, that is strange. I made a 64K cartridge image of Stevie that runs in FG99 ‘R’ mode (4K rom/4K ram) and it works on the real deal but locks up in Js99er. I’ll do some more testing this weekend and let you know.
  15. The FG99 still has some hidden gems barely utilized: https://endlos99.github.io/finalgrom99/ I mean you have 512K of RAM to your disposal in assembly language. Yes, it is in 4K chunks/banks hidden in the cartridge space but very interesting nonetheless. Also the possibility to save bank contents to the cartridge image on the SD card.
  16. Just some thoughts: * Perhaps it would make sense to have compatibility with the "advanced modes" of the FinalGROM99. https://endlos99.github.io/finalgrom99 * A way to query the StrangeCart (via assembly language, a DSR?, fake device) so that apps can identify what cartridge they are running on and act accordingly.
  17. Too bad the FG99 cart has no option to query the device so that you can detect if it’s a FG99. Don’t know if this is something that could be added by a firmware update. But let’s be honest how many folks out there would do a firmware update or would be aware there’s even a firmware update. This got me thinking that for future devices it would be cool if there’s a uniform way to identify the device. Thinking about a GPL DSR call / device that returns a device, version, capabilities string. Strangecart?
  18. I'm currently doing some experiments with FG99 usage in Stevie. Basically what I want to do is store my program settings and add the possibility to backup editor text to the FG99. That way I can take the final grom cartridge, plug it into my other TI-99/4a (which also has SAMS ofcourse) and continue working there. That should be possible by creating an appropriately sized cartridge image and by using the advanced mode as described here: https://endlos99.github.io/finalgrom99/ (Yes, I am aware I can accomplish the same by saving my files to TIPI, but that's not the purpose of this excercise) 😃 Anyway, the thing is, that as it stands now the final grom isn't supported in any of the popular emulators (js99er, classic99, mame, ...) So I need a way to detect if I have a final GROM cartridge and enable programs options accordingly. Is there a way to detect if there is a FG99 cartridge present? Obviously it would be cool if any of the emulators would support FG99, but as long as that isn't the case I need to find an alternative.
  19. Took a break on working on Stevie. My development machine was kinda in a non-working state, but it's there again now. Anyway. Here's a short video of some of the stuff I'm working on for v1.1 EDIT: Not shown in the video is the tab functionality. There's room for up to 20 tab position and fctn-7 moves the cursor to the next tab position. It's currently not yet possible to define your own tab positions. I'll probably implement that when the config stuff is in place. Forgot to mention, the ruler is toggled on/off by pressing ^U js99er-20210515212421.webm
  20. Don’t think so, at least not when emulating the F18a.
  21. Yes, I would certainly use that feature. It would allow me to automate the build pipeline for Stevie. Currenly I am using FGROM99 and swap SD-cards a lot.
  22. I downloaded the zip, but it only seems to contain the "FONT0230" file.
  23. I can write the software, but not build it. I'm an absolute hardware noob.
×
×
  • Create New...