Jump to content

retroclouds

+AtariAge Subscriber
  • Content Count

    2,241
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by retroclouds

  1. Key routine and lookup tables are roundabout 346 bytes (spectra2 keyb_real.asm). https://github.com/MirrorPusher/spectra2/blob/master/src/modules/keyb_real.asm Then you obviously have Stevie specific code and lookup tables for auto-repeat and triggering corresponding actions (e.g. ctrl-o -> trigger file open dialog). Didn’t count that as that is something I would have to implement even when using OS ROM keyscan. Surprisingly key auto-repeat was rather easy to implement (haven’t fully tested if it behaves well in all conditions though). https://github.com/MirrorPusher/Stevie/blob/master/src/modules/hook.keyscan.asm
  2. Thanks. I'm about to release Stevie 1.1 Even though it's only a minor version bump, it has a ton of additions (e.g. keyboard auto-repeat and a menu system), as well as many changes and bug fixes. The version 1.1 has an editor/assembler compatible keyboard mapping. So if you know how to use the Editor/Assembler editor, you should be able to navigate in Stevie without too many hassles. Back to the keyboard issues; Not sure if the keyscan routine in Stevie makes a good benchmark. I'm not using the OS ROM keyscan routine, instead I'm using the one of my spectra2 library. That routine in there is based on the work of Simon Koppelmann taken from his book "TMS9900 assembler auf dem TI-99/4a". I know there are issues with the keyboard debounce still not being accurate enough. I have been postponing reviewing/reworking it as I was unsure about the proper approach. Currently it's using some fixed/timed loops and I don't really like that, as timing could vary depending on where the code is running (thinking about it perhaps I should move it to scratchpad so it's always on the 16bit bus, or better yet make use of the TMS 9901 interval timer). Anyway, all Stevie and spectra2 code is automatically synced to GitHub when I push to my local bitbucket repo. I believe these are the relevant keyboard related files: Stevie repo (master branch) https://github.com/MirrorPusher/Stevie/blob/master/src/modules/equates.asm https://github.com/MirrorPusher/Stevie/blob/master/src/modules/edkey.key.process.asm https://github.com/MirrorPusher/Stevie/blob/master/src/modules/hook.keyscan.asm https://github.com/MirrorPusher/Stevie/blob/master/src/modules/data.keymap.actions.asm https://github.com/MirrorPusher/Stevie/blob/master/src/modules/data.keymap.keys.asm spectra2 repo (master branch) https://github.com/MirrorPusher/spectra2/blob/master/src/modules/timers_kthread.asm https://github.com/MirrorPusher/spectra2/blob/master/src/modules/keyb_real.asm For matching the Stevie 1.0 release it's best to check the corresponding 1.0 branches
  3. Sure, no problem. Here it is. p359_design_spec.pdf
  4. Last time I checked it wasn’t supported in classic99. That is why I’m using the js99er emulator for development in 80 columns, 30 rows mode. js99er has full F18a support. You don’t have the great classic99 debugger, but for a lot of things the js99er debugger is sufficient. Would it nowadays with the availability of the extended basic source code be easier to implement such feature? Can you share some details on how your development cycle for GEM looks like? What tools do you use? Do you start from the source code or do you patch the existing module? Sorry for asking such stupid questions but it’s very interesting to know. On a sidenote , actually the last week I spent quite some time going through the product 359 basic interpreter manual. That is so much fun to read and want to learn and get a better understanding of how the Extended Basic interpreter works. I understand. The reason I’m interested in this, is because it was a feature originally planned for the TI-99/8 and because I have written a programming editor Stevie that works with DV80 files, so I figured it would be the easiest for sharing extended basic programs between the two. Actually what I really would like to do is integrate Extended Basic with the editor. Build a custom cartridge image for the final grom that has the (modified) extended basic and also has the programming editor and jump from the editor straight into extended basic and run the program or return from extended basic into the editor. As the editor is using SAMS and has it’s own SAMS pages I think it would be doable, obviously VDP ram would need to be taken care of.
  5. Are there any plans for a future XB 2.9 G.E.M ? Things I could think of: Support for the f18a 80x30 rows mode Program editing in 80 columns mode Saving/Loading XB programs in DV80 format (as was planned for the TI-99/8)
  6. I have a copy of the document "Product 359 BASIC INTERPRETER Design Specification - 30JUN80". In there following documents are referenced that I'd like to look into: TI Extended BASIC Language Specification (June 30, 1980) Product 359 BASIC Subprogram Specification (June 30, 1980) Product 359 BASIC Sprite Specification (June 30, 1980) Product 359 BASIC Interpreter Expansion RAM Peripheral Support Software Specification (June 30, 1980) Product 359 BASIC Language Implementation and Verification Specification (June 30, 1980) Home Computer BASIC Language Specification (April 14, 1979) Specification of a Texas Instruments Standard for the BASIC Language (June 9, 1978) Does anyone know if these documents are available somewhere?
  7. Hi, I got some questions on Ubergrom after watching @Tursi's excellent tutorial video. Is it possible to use a bank-switched RAM as the rom part of a cartridge. Does such component even exist as chip? Could imagine copying the ROM part of a cartridge from GRAM, not sure how I would be able to bank-switch though. Must the cartridge header be present in each rom bank when using UBERGROM, or is it sufficient to only have it in bank 0, as is the case with the finalGROM.
  8. @Retrospect you keep'em coming! 👍 Think it's about time I make a Retrospect game collection cartridge. 😊
  9. 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.
  10. 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.
  11. 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
  12. 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.
  13. I also bought several F18a’s I still need to install. Looking forward doing that (3 weeks vacation coming up early July).
  14. 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 😃
  15. Voted! Flashpeb sounds good to me! 😀
  16. 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.
  17. 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.
  18. 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.
  19. 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?
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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?
×
×
  • Create New...