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

705 Excellent

About retroclouds

  • Rank
  • Birthday 01/05/1973

Contact / Social Media

Profile Information

  • Gender
  • Location

Recent Profile Visitors

20,119 profile views
  1. The game was originally released for the john guidry boards where the banks need to be in reversed order. That is the reason why the original cartridge version doesn't work out-of-the box for the final grom. The bank order needs to be switched for that. But as you have a working binary now, someone apparently already took care of this (can't remember if I did that or if it was someone else). EDIT: the "flickering" as you mentioned it has to do with how the vine is rendered. Can imagine that the amount of flickering even depends if you are on a TMS9918, TMS9928 or F18A GPU. For further details refer to the source code. Just noticed that on feb 20th, it will be 10 years since I released the game on cartridge. Crazy feels like yesterday 🙄
  2. Finally got around trying this today. That is such a cool game, I am very impressed! 😃 Imagine what could have been if we had such high-quality games back in the 80's on our TI-99/4a.
  3. That is crazy, I love it! Thank you for your hard work on this. Bump n jump was always one if my favorite games in the arcade. Can‘t wait to try it out this evening.
  4. Taking a break on the RLE stuff and started work on SAMS itself. List of open topics and WIPs is getting longer, but that is fine. Today I did another major redesign of the index again. Turns out that the way I described above is becoming too much of a hassle to implement, as it severely limits the number of SAMS pages I could address. So I will be following another more easy approach, which will also give me more flexibility regarding number of SAMS banks. The previous index redesign increased the possibility to index 2048 lines instead of 1024 lines. Fine so far, certainly keeping the number of lines. When using SAMS I will have a "shadow" index on another SAMS page, but same size and same addressing. Instead of the pointer to the line, it contains the SAMS page where the line of code is stored. So it's basically just another 4K page kept in sync with the index itself. Other changes: I have the possibility to load files out of a predefined list, with a single keypress combination (CTRL+0 up to CTRL+9). That's kinda cool especially when using the HRD ramdisk in my PEB. It's superfast. Plan is to enhance the concept to keep up to 10 editor buffers open at once (When using SAMS that should be easy to accomplish). Keeping my fingers crossed. 8K cartridge space is now mostly filled, so will have to start thinking about bank-switching. Probably will have something like: 1st bank: TiVi editor code 2nd bank: TiVi file handling code (loading/saving, file selection, etc.)
  5. Tim, let me know if you need help with getting stuff to GitHub. Do you do your source code editing on the TI-99/4a or Geneve or are you using a PC? (When using a PC with Microsoft Visual Studio Code you can for example push all your code changes to GitHub with no effort. I'm doing that with my TiVi assembler source code. I have a private repo on GitHub, when I'm done changing source code in Visual Studio Code it's pushed to GitHub for offsite backup purpose).
  6. The TI BASIC stuff sounds fascinating. Wonder if original documented source code is still available somewhere. Also if there are any original documents on Monitor and Extended Basic. Keeping my fingers crossed! Thanks for sharing, it is very much appreciated! 😎
  7. Ralph, not sure if this has been asked before or if this is already possible; Would it be possible to set address boundaries? If during assembly the PC crosses the boundary a warning/error is generated. Simple case, assembling for an 8K cartridge (>6000 - >7fff) and program is too big, so PC goes beyond >7fff which ofcourse yields unpredictable results. To make this not too specific for this case, it would be cool if "protected" or "allowed" memory areas could be defined via pragma, hint or parameter.
  8. Would it make sense to make this a configuration option?
  9. I have been thinking of using xdt99 as backend assembler in my TiVi editor. Could do some cool stuff, like assemble, halt on error and jump to the corresponding source code line.
  10. Fabrice, didn't one of your previous prototype boards have a V9938 VDP instead of the TMS9918 VDP ? Just asking (because of the possible 80 columns mode). Guess that for best compatibility you reverted back to the TMS9918 ? What video output options will there be with the Tiny 99/4a? Thinking about the F18a here. But again keeping the spirit of the Tiny, it would be cool if there is some kind of 80-column, 80's era VDP solution. 😎 Either way, I'm very much looking forward to the Tiny 99/4a as it stands.
  11. Yes, I see where you are going when using SAMS. That's the approach I will be following for the lines index (mapping line numbers to editor buffer) as well. The index is at >3000 - >3fff. In this 4K area I store the pointers for the 2048 lines, by swapping this to the next SAMS page I get access to the next 2048 lines and so on. So, if you want to for example jump to line 9600 in the file you are editing, it's just a matter of deriving the correct SAMS pages for index and editor buffer. Do note that I will have a different memory map depending on when using SAMS or not. For example, the editor buffer will be RLE encoded when only 32K memory expansion is available. Don't see going through the overhead of doing RLE encoding/decoding if I have many SAMS pages at my disposal. So, coming back what you mentioned. It would be possible when using SAMS I don't use the whole >a000 - >ffff range as usual, but only a subset of that. But again, I'm quite sure that as long as everything is properly saved/restored upon program entry and exit, things should work as planned. While we're at it; are there many other critical memory areas to stay clear of when using extended basic? Has been a while since I looked at Extended Basic memory map.
  12. The TiVi editor code and the underlying library does not have relocatable code at this time. Memory addresses in ROM are fixed at compile (assembly) time. Turning this into relocatable code would mean quite a challenge, not saying it's impossible just too much work at this time. I'd rather focus on functionality and stability at this stage.
  13. Rich, not sure if I understand correctly. I mean it is not like you are running both the extended basic program AND the editor at the exact same time. As long as memory is saved/copied upon editor entry and restored upon editor exit, I do not see a reason why using >A000 - >FFFF is a problem. Actually the reason I use >A000 up to >FFFF for the editor buffer is because it's the biggest continuous RAM memory reason available on the TI-99/4a. I do feel that the TI-99/4a memory map is like a Swiss Cheese 🧀 with all these holes 🙄. Anyway, as a matter of fact I really am looking forward integrating TiVi with Extended Basic. But before I do that I want to have TiVi in a proper working state for DIS/VAR 80 files.
  14. Would it be possible to make these calls run from cartridge space and add multiple banks?
  • Create New...