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

  2. Posted

    8 minutes ago, Keneg said:

    Ok, I have Turbo Pasc99 running now.  I created a small program to print “Hello World”.  It compiles fine so compiled to DSK1.TEST.  So how do I convert this to a program and run it?  I would prefer to create program files that can be used with just TIPI, I think that is an EA5 file?

     

    Please create a new topic for this. This sticky thread is dedicated to TI-99/4a development resources in general. Thanks.

  4. Posted

    2 hours ago, TheBF said:

    Could you write then read inside one loop.

    These new huge cards are getting pretty big for our old 9900.

    Even now erasing 1Mbyte takes significant time. :) 

    I didn’t even bother to try to erase SAMS before use. As long as your pointers and memory structures are ok, it doesn’t matter what is next to what you have in use. Don’t see a benefit in initializing memory up front or am I missing something?

    • Like 2

  6. Posted

    On 9/6/2020 at 8:36 AM, tmop69 said:

    Exactly, that was the idea! Probably most of us have received the TI99 for Christmas, so why not trying to recreate part of such magic feel with a new SSS game 40 years later? And the choice of an iconic game for another system, never released for the TI, was not casual. ;-)

     

    The package will have, in addition to the SSS, the manual ("classic" style) and two labels. We are investigating also for a box, however I suspect that the final price will be to high. In any case, let's see.

     

    Yeah, a box would be mighty cool!

     

    Guess that would make it the first new cartridge in a complete package.

    Unfortunately it makes things more expensive and probably not easy to design and source.

    • Like 2

  8. Posted

    Hi Matthew,

     

    yes, think it’s a great idea to get the mk2 out with VGA output for starting.

     

    I’m sure there are many people out there that already be very happy with just that.

    Activating features via later firmware upgrades is the new normal and nothing to be too worried about, if you ask me.

    You also get the joy of getting the product out in the wild and get a little return on your big invest (both on time and money).

     

    Filip

    • Like 2
    • Thanks 1

  10. Posted · Edited by retroclouds

    9 hours ago, DavidC said:

    First of all I would like to thank @senior_falcon for all your hard work.  This is truly incredible. I was able to get this up and running on Classic99 without issue.  Has anyone loaded onto their FinalGROM?  I tried, but all I get when I choose a option is a blank screen.  The original GEM from post #1 works fine on my FG, I simply cannot get 2.8 to work on my FinalGROM.  Any ideas?   

     

    I have the same issue with my FinalGROM, although I renamed the binary as suggested in the documentation.

    Could this have something to do with the firmware revision on the FinalGROM? Can that be updated (haven’t checked).

    Do know that my FinalGROM was in the first batch produced.

  11. Posted

    12 hours ago, Ksarul said:

    I still have plenty of bare boards available. I have an assembled board that I need to run through a shakedown test over the next day or two. I've been delayed over the last few weeks due to COVID-19 (it infected me and I avoided touching any of my hobby gear until I was sure I was fully clear)

     

    Jim, truly hope you are doing fine and that COVID-19 didn’t cause you too much troubles.

    • Like 3
    • Sad 1

  12. Posted

    3 hours ago, RXB said:

    Yea there was SCRATCH RECORD in the SCSI Card and I wrote a code to use it.

    It would find a record number and delete it but then it had to reorder the records to make up for blank spot left.

    Thus the routine was insanely slow even under Assembly speeds for large files.

     

    Mostly the reason for TI99/4A slow file speed is using VDP memory for Records and not RAM which would be much faster.

    ROS in the HDR ramdisk supports direct RAM transfer in addition to the classic VDP memory for records. Haven’t tried it yet but is interesting to see how much speedup it would make.

    • Like 1

  14. Posted

    8 hours ago, UrQuan3 said:

    Be nice guys.

     

    I have a very different reason to post.  I am very sorry this is proving to be a very time consuming project because I am very interested in one of the possibilities you mentioned after completing it.  The f18 is a cool tech demo, showing that an updated TI could have kept up with game machines that came out years later.  However, I would prefer not to cut up historical objects as such.

     

    However:

     

    I have been looking for several years for a video solution for Arduino type projects.  I can get an arduino with something like 300 TIMES the performance of an NES, but I can't touch it's video interface.  Raw video at 320x240 24-bit 60fps is already over 100mbit.  The SPI bus simply isn't going to support more.  Buy a sprite engine?  The TMS9918 (and it's Japanese derivatives) is recorded as the only commercially available sprite engine in history.  You may be sitting on the second.

     

    That, I am very interested in.

     

    That’s a fascinating idea! Always wanted to try an arduino project. Being able to use my VDP knowledge would be mighty cool.

    A while back I stumbled on a project where someone used a F18a MK1 in his propeller project (if I’m not mistaking).
    Unfortunately I can’t recall what it was otherwise I’d include the link here. 

  15. Posted · Edited by retroclouds

    ok, I solved this stupid, stupid bug that took me too much time 😁

     

    The problem was that R15 did not contain >8C02 at the time the TI-Disk Controller DSR was entered.  >8C02 is the VDP port address.

    Due to the fact that R15 was >0000 at the time the TI Disk Controller DSR was entered, obviously no byte was ever read from VDP memory and the DSR could not check if it owned the VDP file buffer itself and went into a loop between >4744 - and >4754

     

    Might be a check to add to classic99; verify that R15 contains value >8C02 when the TI Disk Controller is entered 

     

     

    • Like 4

  16. Posted

    10 hours ago, HOME AUTOMATION said:

    I think it's always there at >1100? just need to enable CRU bit 0.

     

    tidc0.thumb.JPG.623d005d88be8d08f1813c8b27646c73.JPG

     

    To get it to use your files... maybe you need to load thusly(Dunno)...

     

    tidc1.thumb.JPG.6c8786aa4d4d40ec442308ea0fdccae2.JPG

     

    tidc2.thumb.JPG.93f2fdaf3076f641aff739630c079367.JPG

    Thanks for pointing out where to select the TI Disk Controller! I knew I had seen it somewhere in classic99 but could not find it.

     

    The problem is not the CRU card itself, it’s there.

    Somehow the VDP byte read routine in the DSR code gets messed up and returns >00. 

    Yesteday evening I didn’t have time anymore to step through that part as well, so that’s something I like to try this evening.

     

     

     

  17. Posted

    On 8/19/2020 at 8:35 PM, retroclouds said:

    oh yes, I’ve been thinking about that. First have to bring back 24x80 mode though.

    The thing is that the file dialogs are on rows 26-30 so I’m kinda blind while loading/saving files.

    But bringing back 24x80 mode is well worth the effort if it allows me to run classic99 debugger.

     

    I've been able to nail down the problem in the Disk Controller DSR. Don't fully understand it yet, but the story goes like this:

     

    1. DSR takes over

    2. DSR calls preparation routine

    3. In the preparation routine, the DSR looks for a VDP file buffer that was created by itself by comparing CRU stored in VDP file buffer. (On startup of the TI-99/4a  with call files equivalent done by DSR power-up routine). 

    4. The preparation routine calls a VDP read routine that should bring back the CRU in the VDP file buffer. The problem is that it always brings back >00 instead of the CRU MSB >11
    5. As there is no match, it jumps to the next buffer in (3) and is in an infinite loop

     

    So I need to find out why the VDP byte read routine in the DSR brings back >00 instead of the CRU >11. That will have to wait for another day.

     

     

    Here's what I did to get there:

    1. I used mame and got a version of Stevie running there (no F18a support) so I'm a little bit blind, but works ok. Mame is setup with SAMS and TI Disk Controller

    2. I downloaded the commented disassembly of the TI Disk Controller DSR from Thierry's Site and used that to step through the DSR and set breakpoints.

     

    By the way, I really dig the mame debugger:

    • Multiple windows possible each with memory, disassembly, debugger, ...
    • Multiple breakpoints possible, trace to disk, etc.
    • Control the debugger via LUA scripts (sorta, not sure how well that works though)

     

    Don't think I would ever be able to find the bug without stepping through the DSR to actually see what is going on. 
    It works fine in all other emulators as there is no Disk Controller DSR there, so cannot reproduce.

     

    I thought there was an experimental feature in classic99 where you can enable the TI Disk Controller ROM, but could not find it anymore (checked multiple classic99 revisions).

  20. Posted

    Next to my multiple TI-99/4a home computers, I also own multiple Tomy tutors and even a Geneve.

     

    In The last 10 years or so Atariage has become the home of most of the TI-99/4a community.

    Unfortunately for the Tomy Tutor, the community is really scattered on the internet and it's hard to find technical details and programming details.

     

    Also have the feeling that most Tomy Tutor, 99/8 and Geneve owners are here on Atariage in the TI-99/4a section.

     

    To better focus the threads and gather additional interest I propose to create a subforum in the TI-99/4A Computers section right here on Atariage.

    Target group for the subforum are the close relatives of the TI-99/4a like Tomy Tutor, 99/8, DS990, ...

     

    Minimal requirement for that is that the heart of the computer, the CPU must be a Texas Instruments 16bit CPU like TMS9900 (or closely related like  TMS9995).

    The VDP chip alone does not count, machines with a Z80 CPU (Colecovision, MSX) have their own forums here on Atariage.

     

    I have opened up a poll that goes until end of september.  Depending on the poll results we can then discuss with Albert.

     

    What do you think? Please vote in the poll and comment here. 😀

     

     

    Retroclouds

    • Like 4
    • Thanks 2

  22. Posted · Edited by retroclouds

    8 hours ago, Lee Stewart said:

     

    Hooboy! It may be quite a while before I can make use of xas99.py. The proscription of ‘$’ from labels will break fbForth. They are scattered all through the code—many inherited from TI Forth. I was so looking forward to making the move, but this will take a lot of time to sort out.

     

    ...lee

     

    Lee, perhaps it’s easier to patch xas99.py so that it tollerates ‘$’ in labels. 

    Another possibility: for what it’s worth I’m using the dot “.” character as a delimiter in my labels and that works ok.

     

    • Thanks 1

  23. Posted

    For the sake of history I'm linking to the updated dsrlnk routine (V5B) written by the great late Paolo Bagnaresi. 

    As a matter of fact in this version you have the possibility to save the state in memory so that following calls in your program can jump right into it, without having to do the DSR scan again.

     

    http://www.whtech.com/ftp/YAHOO group backups/SWPB/FILES/Disk Access/DSRLNK DATA A - Corrected, CRU search start REV5B CPU PAB.txt

    • Like 1

  25. Posted

    4 hours ago, Ksarul said:

    I can answer some of the questions. On BASIC and the Pyuuta, it requires a BASIC-1 cartridge (used only with the Pyuuta MK-II) or a BASIC-1 Adapter (attaches to the back of the Pyuuta, using a variation of the same case as the Game Adapter for the 3D games).

     

    I have a set of the multicarts that I purchased for my systems a while back, but I haven't seen them available in a while. I don't think the schematics for them were ever openly available. I do have a few test boards I made to try making my own cartridges, but I haven't tested them yet.

     

    On general Tomy data, you can find a lot on this Tomy Tutor site. I think there is even a good bit of data on the cassette signalling there. Almost every other Tomy site in existence is only in Japanese, which may not help you much. You can find a lot of the Japanese data by searching on ぴゅう太 as opposed to Pyuuta.

     

    Next to the TI-99/4a development subforum I’d love to see a subforum for close TI-99/4a relatives such as Tomy Tutor and 99/8. Here’s the place where the folks hang out, so why not make it official as a subforum. 

     

    Quite sure that most Tomy Tutors out there belong to folks that also have one or muliple TI-99/4a’s and as such are on Atariage.

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...