Jump to content

retroclouds

+AtariAge Subscriber
  • Posts

    2,502
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by retroclouds

  1. Quick question on TIPI VDP memory usage: Does the TIPI DSR use VDP memory besides the memory specified in the PAB header or record/file buffer?

    Is there anything in the TIPI DSR that writes to the VDP >0980 memory range?

     

    Reason I'm asking is because I'm refactoring VDP memory usage in Stevie. I'm trying to make free space for FIO level 3 opcode 5 loading EA#5 image.

    Works fine with ROS (which is not using any VDP memory at all I guess). And having some issues with especially the TI Disk Controller and a little with the TIPI controller as well.

     

  2. 2 hours ago, Gary from OPA said:

    some carts have bad coding, but they can be patched, my original program for my Pop-Cart, would scan the G/K images being added and make patches for ones that I figured out, it is normally a simple scan to spot the code, as alot of it do with version of GPL Macro Assembler they were originally assembled with, there a series of various macros that handled multiple banks and also some cartridges have a bad habit of using fixed addresses in the console grom 0 and part of ti basic as well, so sections of grom 0 and grom 1 have to be mirrored into the other grom bases if you doing a total override as well.

     

    my pop-cart cartridge making program would also scan regular e/a5 assembly programs and patch their dsrlnk usage as well so it would handle a cartridge dsr which i called CART. which greatly allowed for better block management of using extra rom/grom area not used by cartridges with empty spaces mapped as sectors into a ROMDISK for programs, allowing for simple as is loading of support files, without any rewriting of original assembly just changing DSK1 to CART and patching the dsrlnk to scan the grom space.

     

    converting the ubergrom to how my pop-cart was looks easy enough once i got one converted and tested, i will release more details and info, just one of many little things i want to do, one step at a time.

    Using the cartridge space as a ROMDISK is a real cool feature to say the least. This is a topic I’d like to take a closer look myself.

    If I’m not mistaking there’s another romdisk project by Fred, but might be wrong here and have no details on that.
    My purpose is, to distribute DV80 files on my Stevie editor cartridge image. Unfortunately all of this is on hold for now, because of real-life sh*t called work. Oh well.

     

    • Sad 1
  3. Here’s an interesting article on the Tomy Pyuuta. There’s a picture of a small board with a v9958 that plugs into the Pyuuta and VGA enables it.
    This brings up a lot of very interesting questions

     

    1. Can the board be reproduced or is for sale?

    2. How is the Pyuuta able to disable the built-in TMS9918 and put output on the V9958 without doing any internal console modifications

    3. How much VRAM is there on the board? Does it use VRAM on board or somehow accesses internal VRAM?

    4. How old is the board?

     

    https://www.kernelcrash.com/blog/the-tomy-pyuuta/2023/10/08/

     

    EDIT: some of the questions are addressed in the article, left here for discussion nonetheless.

  4. On 11/14/2022 at 4:41 PM, arcadeshopper said:

    sams provides 32k - only 1 32k source will work at a time 

    1mb sams is larger than any software we currently have made that I know of, why would you need more?

    4mb sams is available but expensive (ram costs) 

     

     

    I for one would be very interested in bigger SAMS. Could for example imagine having Final command in 1MB and stevie in the higher 1MB.

    And to be honest I have run into the 1MB limit a couple of times while testing Stevie

    • Like 4
  5. I’m not sure what settings to put in the settings file. There’s nothing too special, it’s just a 64K non-inverted ROM image.

    For “mounting” the cartridge I always use the classic99 menu option “user cartridge” (or similar) and pick the file.

    If it resets, its perhaps a sign that either SAMS and/or F18a are not enabled in classic99 ?

     

    I’ll let @Vorticon chime in, because I think he used classic99 more than I.

    Most of the development I did with js99er. Having said that, I can take a look at the weekend if it still don’t work.

    What’s still lacking at the moment is a proper user message if SAMS and/or F18a are missing. 

  6. Should you be running Stevie on a real TI-99/4A install, I wouldn't mind if you attach a photo or short video of the thing in action.

    Did not have a chance yet to try it out on my TI-99/4a with IDE card, as my harddrive is broken.

    So far it got tested with my TIPI PEB card and HRD4000B cards and in emulation land. But the latter obviously doesn't count 😁

    • Like 1
  7. Just a word on the file picker functionality. When you're in the File -> Catalog dialog or in File -> Open, Insert, Append you basically just type the device/file path.

    • If the last character is a dot "." and you press ENTER, Stevie will interpret that as a device path and will try to read the directory.
    • If the directory is successfully read, you can move the file selector by using arrow key up or down.
    • You can also switch pages (if you have more files than fit the screen) with CTRL-E and CTRL-X.
    • You can switch between columns with CTRL-S and CTRL-D
    • You can move to the parent directory by pressing SPACE.
    • In most of the dialogs you can press CTRL-1 to CTRL-9 to read the catalog from device DSK1 to DSK9. If you are on a supported dialog, the filepicker functionality will kick-in and you'r able to navigate on the device.
    • You can find the necesary key combinations by going to the Help screen (or use shortcut key CTRL-H)
    • Once a directory is read, it's cached in memory. So if you're in the editor screen, you can press CTRL-< to read the previous file, or CTRL-> to read the next file.
    • Like 1
  8. I've released Stevie 1.5.32 

     

    As of this version I will be using semantic versioning. Actually I planned to release this around Xmas, but I wasn't pleased with the overal functionality yet. So I had to postpone for a bit.

    Besides some minor things, the biggest update on this release is the catalog with its file picker functionality.

    If you are on a supported device like TIPI or IDE you can move between subdirectories and this really improves the usability IMHO.

     

    Besides that there are a ton of bugfixes again (and most likely a ton new bugs introduced) and some minor new features.

    Going forward I will probably have to do a better job on documentation because there are quite a few hidden functionalities to speed-up navigation.


    Having said that, here's a list of some of the changes (in no particular order)

    Usability:


    Bugfixes:

     

    Grab the newest version here:

     

    As usual a big thanks to @Vorticon for testing, feedback and keeping me motivated 

    • Like 2
  9. I am looking if I can do something along the lines for the TI Basic integration in my Stevie editor.

    There I have the possibility to run up to 5 TI Basic sessions. Basically there is an ISR that is setup before jumping into TI Basic.

    Purpose of the ISR is to show the session number and read the command buffer so I can jump back into the editor. Think it watches for the command “EXIT”, but have to verify. Has been a while.

     

    Long story short, in regards to your question. What perhaps is possible is to have an ISR that watches the command buffer, pokes OLD DSK…… and after completion pokes “RUN”.

    • Like 1
  10. Most interesting, actually myself I have been planning and started doing something similar for my Stevie tool. Here’s some of the ideas:

     

    1. Possibility to have multiple TI-Basic sessions and jump from one session to another and back to the “control” program (editor, …). Working

    2. Possibility to “uncrunch” / “crunch” TI Basic source-code to full-screen editor (have it working for the uncrunch)

    3. Embed assembly source code in TI Basic source code (worth looking on how that works on the BBC Micro, it’s very impressive) 

    4. ISR that runs in parallel with the TI Basic session, shows the session and other “real-time” debug info, Working for session

    5. Enhance Basic with some new commands, tailored for development (e.g. better support for HEX values in Basic). Not there.

    6. Recovery from lockup. Got that working for the Editor source. So you jump from the editor into basic, quit to title screeen or lock-up. If console is reset

    memory is restored when returning to the editor (partly working, memory is saved to SAMS when exiting editor and restored on re-entry)

    7. Support for the F18a 30 rows mode. That way you could have rows 25-30 for debug information while running TI-Basic. Would require some severe patching of TI Basic (or use F18a functionality to overlay a layer, not sure)

     

    Perhaps not what one is looking for, but actually with the FGROM99 you have already a whole lot of possibilities

     

    1. Almost “unlimited” memory albeit in small 4K chunks, can e.g. use that to store VDP memory while jumping from session to session (I am using SAMS for that at the moment, but do not see why it would not work)

    2. Possibility to store pre-defined example source code snippets, think like a ROMDISK

     

    What is missing on the FGROM99 IMHO is the ability to create new files, a limitation of the internally used petitFAT filesystem 

    This could probably be solved by using another ATMEGA (was recently discussed) here in the forum.

     

    Do very much like the idea of a new (interactive) assembler on the TI-99/4a itself. If I would have to write something like that I’d probably go for version a version written in C or FORTH.

     

    Anwyay, sorry for derailing the thread. Looking forward seeing anything you come up with. I know it will be impressive.

    • Like 2
  11. I’m following this thread with the most interest. And have a question to its implementation on the TI-99/4a.

    Normally the p-code card takes control as soon as the computer is turned on -if the card switch is toggled on-, unless a particular memory location has a magic value. Is that assumption correct? 

    The one thing I don’t like about the p-code card is exactly this behaviour. So I was wondering if there are other ways to prevent the DSR from taking over without turning the card switch off. 

    Was thinking about another DSR or cartridge with autostart that pokes the magic value. But perhaps there are better options?

  12. Not to derail this thread. But could not let pass this one. Here is a github Copilot suggestion on my code in Visual Studio code. Not too bad I would say. 

    Obviously all of its knowledge is fed of the comments I have in my source code. Nonetheless, kinda scary how far next-token prediction has progressed.

    In general the TMS9900 code suggestions it does, looks ok from syntax point of view (but obviously not always make sense). It even predicts whole code blocks. 

     

     

    image.thumb.png.d0fd43e1b214a78028b9c43bf3fe9d86.png

     

    image.thumb.png.46152f7bdd0e8cb8a55dc866417af66d.png

     

    • Like 3
×
×
  • Create New...