Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

retroclouds

+AtariAge Subscriber
 View Profile  See their activity

  • Content Count

    2,118

  • Joined

  • Last visited

  • Days Won

    1

Posts posted by retroclouds

  1. Posted · Edited by retroclouds
    Added 2nd part of post, after I had to take a break because of some friends visiting our place.

    Today it’s time for giving an update and clarify where I see this project is heading too, as well as some things I’ve learned along the way. When I started thinking about what I want to accomplish with the editor, I knew this was a project that could easily span several years.

     

    The fact that it’s completely written in assembly opens up a lot of possibilities, but also means that development is rather slow, when compared to writing in a high-level language. So what is the plan and what is next.

     

    Accomplished so far:

    • Loading a large DV80 file into SAMS works really well. The file I/O routines I have implemented go along with the stock disk controller, TIPI and HDR ramdisk nicely. Although loading large files is pretty slow, I am going to keep the file routines I have there and call this “compatibility” mode. I’ll also work on a new set of file I/O that’ll be a lot faster, but probably not as “compatible” with all type of disk devices out there.
       
    • So far I’m really pleased with how fast working with large files on the TI-99/4a works.
      There’s still room for speed optimisation, but you know the saying: premature optimisation is the root of all evil.
      Along the way I did quite a few changes on how a DV80 file is stored in memory. Obviously storing the file as you would in VDP memory is not going to cut it, once your file contains a few thousand lines of text.
       
    • Insert and delete speed is good, even for files with for example 5000+ of lines. As said memory organisation is very important for good performance. Implementing undo shouldn’t be too hard to do with the code I have in place now. Basically I have copy-on-write, so the old lines of text are still there in memory (at least to a certain extent)
       
    • I threw out the 32K code. Mixing 32K and SAMS memory layout was a stupid thing to do. I’d rather create a 32k standalone version instead of mixing the two. 
       
    • Had a hard time fighting feature creep. I mean, this is about having fun and not only doing work. Nonetheless, the goal is to come up with an initial version in the near future. 
       
    • From a code perspective I have a good library in place (made a lot of changes to spectra2 in the last few years). Doing stuff in assembly language does not take as long to implement as it did before. Nonetheless, for a later version I want to have some kind of interface in place so that new functions can be implemented in a high-level language (C99?) or use a custom FORTH 

     

     

    Next tasks are:

    • Finally getting “save file to disk in place”
    • Crush the remaining bugs
    • Complete work on the command buffer (command history)
    • Put a file picker in place.

     

    After the initial version is out:

    • Work on a configuration file (obviously a DV80 file) and a corresponding parser
      • Custom file settings, color schedule, etc.
    • Implement integration with assembler and C99 compiler
    • Seriously think about the high-level functions (search and replace, mark code, etc.)
    • syntax highlighting (that should be fun to implement, make use of the F18a cpu in gpu?)
    • Plugin infrastructure.
    • Integration with TI-Basic and Force Command
    • Custom fonts
    • Multiple files in memory

     

    What I have implemented (but not shown and really tested yet) is a clock plugin that is shown in the status line.

    It runs as a background task, reads the clock file, parses & displays it. Actually it’s only a few lines of code.
    Quite interesting how much you can accomplish in assembly language once you have the necessary “infrastructure” in place.

     

    Really hope to have an initial version of Stevie out the door, before the F18A MK2 makes it to market.

    • Like 2

  2. Posted · Edited by retroclouds

    I`ve recorded a small video in js99er with some of the features in Stevie.

     

    At this time I am very pleased with the processing speed on large files (browsing the file once it is loaded into memory).

    So index (re)organisation is working very well know.

     

    Even though there are still plenty of bugs. The asserts I added seem to catch most unexpected behaviour and you get the CPU crash screen.

     

    • Like 8

  3. Posted

    For me there is a very important difference between TIPI and the IDE card.

     

    I love my TIPI’s, in fact I have multiple, be it as PEB card, sidecar and now also in the speech synth.

    What I like so much about TIPI is that they basically are software devices. What I mean by that is that allmost all of its functionality comes from software running on the raspberry.

     

    Me being a software guy, and the fact that tipi is very open (you find everything on github) allows me to try and extend things as I please. Having said that, at the same time I somehow get that “triton xt” feeling. What I mean by that is that on the other side of the line you have a device that is a LOT more powerful than the TI-99/4a itself and it somehow feels a bit like cheating.

     

    So that is the reason why I also preordered 2 IDE cards. I want to built 2 systems. One with TIPI and new devices and a more classic one with devices that were already around a long time ago.

     

    You just might call me crazy, because from a usability standpoint I’m sure TIPI is on par or beyond the IDE card. 

    However, to me it’s not only about usability, but also letting my system be a “classic” (whatever that means, but you get the idea).

    • Like 7

  5. Posted

    On 6/4/2020 at 3:38 PM, opcode said:

    This was done in record two weeks for the ColecoVision with SGM, using I new tool I created for porting arcade games for the OMNI. It works pretty well with the ColecoVision as well as you can see here. Only thing missing is sound, and I will take care of that soon.

     

    This is very interesting stuff.

     

    I know this is your competetive advantage, but would you mind sharing some technical details on how the tool works and on what level. How does the work pipeline look like. I presume first step is to disassemble and work from there with the tool you implemented.

     

    Does the tool scan for certain code patterns and does code replacements or only makes hints for you then to work on.

    What programming language is the tool written in (python?) and what text processing libraries did you use?

     

    Again I understand if you don’t want to share these details. But heck, to me the tool and its underlying technology is as much interesting as the games that are ported with it.

  6. Posted · Edited by retroclouds
    changed RS232 to 64k printer buffer

    There’s currently a Triple-Tech Card up for sale on Ebay and there’s a nice picture with lots of details.

    https://www.ebay.de/itm/Ti-99-4a-Corcomp-Triple-Tech-card-for-PEB-box/254613797358

     

    Looking more closely I notice they sneaked a Zilog Z80 CPU on there. What is it used for?

     

    I mean the only thing the card does is:

    • Host a speech synthesizer board
    • Clock
    • RS232 64k printer buffer

     

    Did I miss something? Is having a Z80 on there total overkill?

    Well there will be no danged Z80 in my PEB (unless perhaps me running some emulated Z80 on the raspberry in my TIPI PEB board) 😉

    • Like 2

  7. Posted

    15 hours ago, FALCOR4 said:

    Here you go.  Looks like the 1M card with a couple extra ICs.  The two memory ICs contain the batteries for backup if you choose to use those instead of conventional SRAMs.  You can get 512K versions of those for the existing 1M card as well (fact check me Ksarul).  This version card is configurable as 1M or 4M.  

     

    SAMS 4M PEB card.jpg

     

    Yes, that’s a beauty for sure. The possibilities are endless. If only it could map the DSR space >4000 as well.

    With the ROS source code out there you could possibly even turn it into a HRD ramdisk. 

     

    So where did you get the DALLAS SRAM’s ? Are they still available?

     

     

     

     

    • Like 1

  9. Posted

    On 5/27/2020 at 11:01 PM, FALCOR4 said:

    I have a proto 4M SAMS from Ksarul that I'm working on which is the extension of the 1M board.  Once we find and fix a peculiar issue with it I'm sure he'll begin making them available if interested.  The one I have in my possession, in particular, has battery backed RAM just for fun. 🙂

     

    It would be nice to have a routine to test it, if that's doable. or else I have to slog my way through it in other ways.

    I almost missed this and am very excited about it. Having battery backed RAM opens up a lot of new possibilities.
    Truely hope that when the 4M SAMS released this stays an option. Would you mind sharing a picture how the card looks like?

    • Like 2

  11. Posted

    34 minutes ago, GDMike said:

    Yes, but I can't stand using the PC or laptop. 

    So I suffer

     

    Trying to find and solve a bug in assembly language is a mission impossible without a proper debugger I would say.

    If you insist on debugging on the TI-99/4a itself, then the best debugger to use is Miller Graphics Explorer. 

    It’s basically an TI-99/4a emulator running on the TI-99/4a itself. It allows you to single-step trough your assembly code and watch registers and memory, including VDP registers & memory as it happens. Very cool!

     

    Look for it in the development forum here, there is even an updated version of last year.

    • Like 3

  15. Posted

    What is the proper way to reset the F18a extended registers so that they have the same values as after a clean power-up cycle?

     

    Reason I'm asking is that if you change extended VDP registers the settings stay active even after down a "BLWP @0".

     

    In this particular case I have a crash handler in my assembly program that resets the TI to a defined state.

    But obviously I do not know what was set in the F18a extended registers by the calling program before.

    Could keep track of any value written to the F18a registers, but with the many extended registers that may get cumbersome.

     

    In my last example I turn on position-based attributes, but obviously if I reset the TI, the screen is unreadable. 

    I know how to resolve this particular case, but would prefer a generic solution.

     

     

    • Like 2

  16. Posted

    19 hours ago, BeeryMiller said:
      Reveal hidden contents

     

     

    I almost skipped this whole thread as Stevie didn't interest me.  Might not hurt to put into the thread topic "was TIVI" so those that were following would continue to follow.

     

    Thanks, I've updated the thread title accordingly.

     

    • Like 2
    • Thanks 1

  17. Posted

    6 minutes ago, jedimatt42 said:

     

    Yep, TIPI is more of a project than a product. I try to keep the docs up to date, but they too lag behind the source, depending on my mood.

     

    There have been 2, almost 3 ROM updates and 1 CPLD update, all optional for 95% of the user base. But around 100 PI side software releases since the hardware assembly was put up for sale. 

     

    It is a system designed for change. 

     

    Quick question. Does a compatible battery-backed SRAM chip exist that could replace the DSR EPROM chip? That way it could be more easy to replace the DSR contents.

  19. Posted

    I've decided to rename the editor from "TiVi" to "Stevie".

     

    There are multiple reasons for doing so:

    • In it's current form it has turned into something completely different and shares no resemblance to the well-known unix "vi" editor.
    • It's not related to the "tipi" device in any form. So having the editor called tivi doesn't do the tipi justice in my opinion.
       

    So what's the deal with this "Stevie" name then? I still like the sound when pronouncing the name (like "TeeVee") and I very much like the music of Stevie Nicks. So there you have it. 

     

    Note that I'm going to release the source code on Github in the next few weeks. Until now it was synced on Github as a private repo.
    But I think that the source code is now stable enough, so that I can make it available to the public.

    • Like 4
    • Haha 1

  23. Posted

    10 hours ago, matthew180 said:

    Yes, that can be done.  The sprite limit is completely programmable.  The only thing the MK1 user-jumpers do it set the power-on / reset default, but that can be over-ridden by software.  Also, the F18A registers are not affected by CPU soft resets (FCTN= on the 99/4A), but they will be reset if the actual reset-pin to the VDP is pulled low.  So, changing a cartridge will probably reset the VDP settings, and of course a power-off/on cycle.

     

    You can also change the palette registers on the F18A, and those registers *do* survive a powered reset, i.e. they are only restored for power-off/on cycle.  But, to do a software selection of sprites-per-line, you would have to be able to run your settings program, then start the game or other software in question without hardware-resetting the computer.  Basically I think you need assembly language access from ROM-BASIC, which has been shown to be possible (I think the forum thread is called "breaking out of the BASIC sandbox", or something similar).

    Here’s the link to that thread: 

     

  25. Posted · Edited by retroclouds
    Added link

    8 hours ago, Tursi said:

    - Use registers as Rasmus suggests

    - unroll - do 4 copies in a single loop - deal with the leftover externally. Even two loops (one unrolled and one normal) will be much faster

     

    The biggest win with registers is simply the number of bytes read. With very few exceptions, nearly all contrived, the smallest code on the TI is the fastest code.

     

    That said, the big non-contrived exception is unrolling loops. And this is just a matter of work/overhead. If you have a common loop like this: 

    lp
  mov *r0+,*r1+
  dec r2
  jne lp

    Even if it's all in scratchpad, you are spending 30 cycles doing work (the mov), and 20 cycles counting (so 40% of the time, it's not working). Put another way, every word costs you 50 cycles to move.

     

    If you unroll 4 times: 

    lp
  mov *r0+,*r1+
  mov *r0+,*r1+
  mov *r0+,*r1+
  mov *r0+,*r1+
  dec r2
  jne lp

    Now we have 120 cycles of work and 20 cycles counting (so the non-work portion is only 14%). On average, this loop costs 35 cycles per word.

     

    If your loops have any substantial size, the time gained can be significant and well worth the extra setup time (so assuming a shift, for instance, to set the count, you'd want to have more than about 12 words to move to see a benefit overall).

     

    Tursi, thank you! I knew you’d have the numbers worked out. 😉

    So that basically matches with most of what I had in mind, and it’s good to have it confirmed before starting implementation work.

    I’m going to experiment with different unrolls 4 and 8. But will have to come up with even larger files. I’m sure I’ll already notice a good difference with your nr80 file, but also want to try with a file of +10.000 lines.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...