Jump to content

Photo

TIPI - TI-99/4A to Raspberry PI interface development


808 replies to this topic

#701 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 4,401 posts
  • Location:Portland, Oregon USA

Posted Tue Aug 28, 2018 2:12 AM

on that ti i am using the version that Tim made for F18a users. I dont have a hrd so you'll have to check with him here's the thread http://atariage.com/...-beta-releases/



#702 Ksarul OFFLINE  

Ksarul

    Quadrunner

  • 5,319 posts

Posted Sat Sep 1, 2018 5:56 PM

One thought on the DSK5-9 use cases. The various disk managers would all let you input numbers in that range BITD, and would work with any device that answered in that range. Some managers even let you input the letters A-Z as drive letters, but that particular flexibility was less common. For those with a Myarc HFDC card, if they put the HFDC into a system with a regular floppy controller installed (and used CRU >1000 for the HFDC), floppy drives attached to the HFDC would be numbered DSK5-8 and those connected to the original floppy controller (at >1100) would be DSK1-3(or 4). A lot of programs could address drives in the DSK1-9 range without modification, as the TI OS would automatically step forward until it found a device that answered to the DSK number utilized (or it would return with an error). Some RAMDISK-aware software would also step into the DSRs looking for the letters A-Z, but that was a somewhat uncommon answer, as most folks had more than enough device names available in the DSK1-9 range.

 

And no demands at all here--just providing data on the less-common hardware that was out there (and still is for those lucky enough to have it).

 

Thanks for doing the TIPI for the PEB. As soon as I can reach the sales page when one or more are still available, I plan to buy a pair of them. . .  :)



#703 jedimatt42 OFFLINE  

jedimatt42

    River Patroller

  • Topic Starter
  • 2,023 posts
  • Location:Beaverton, OR

Posted Sun Sep 2, 2018 1:44 PM

Thanks Jim... 

 

To all: 

 

If your system doesn't allow running TIPI at >1000 or >1100, then you should simply consider DSKx mapping a gracefully degrading feature, since you are choosing other hardware to have precedence over that feature. 

 
So far, most people don't seem to know enough about their TI systems to understand this. I still cannot test or support what I don't have. I can only try and fail to be flexible and compatible. I am declaring that I 'support' TI Floppy Controllers, TE RS232 cards, Flex cables, TI 32K ram, Jim's SAMS, and zero else. Use with anything else is welcome, but 'at your own risk' --- I will create a project wiki page for hardware compatibility, but it will require the community to support it. 

 

I am playing around with adding DSK5-9, and making DSK4 flexible. It is a trivial amount of code. (there is a branch on github named 'dsrChanges')  But before I release that I want to fix CALL TIPI to accept variables. And before that, I actually want to finish 1.0 of my own file manager. I don't believe there is any trickery I can do in the DSR to enable DM2K to fully work with a card it new nothing about. None of the other disk managers work with TIPI since there is no disk, and therefore no sector 0. I believe I need to provide a new file manager to realize the full feature set of TIPI anyway. So this is my current focus.

 

Too many people still don't have eprom erasers, so I want to prove the file manager before releasing an eprom so it doesn't turn into an thrashing situation. 

 

I will opportunistically resume therapeutic soldering when parts arrive. But I will most likely hold off sales until I know what the next step is with the eprom. 

 

-M@



#704 --- Ω --- OFFLINE  

--- Ω ---

    Hexacorerunner

  • 14,011 posts
  • Location:82.102.25.76

Posted Sun Sep 2, 2018 4:31 PM

You know, there is an easy way to go straight from power up directly to the 9640 Menu System.  Just buy an auto-booting 4A/DOS cartridge from arcadeshopper.

 

Even if you're not interested in 4A/DOS itself, the cartridge with one small batch file will instantly load BOOT or the 9640 Menu System whenever you power up, or exit a program.. all WITHOUT having to deal with the title screen or the consoles selection menu.



#705 RXB ONLINE  

RXB

    River Patroller

  • 3,601 posts
  • Location:Vancouver, Washington, USA

Posted Sun Sep 2, 2018 8:12 PM

Hmm just a note:

 

Any GROM Cartridge can do this.

The GPL power up will go that address and bypass the Title Screen.

This goes back to GRAM KRACKER by MIller Graphics doing that on MENU the forerunner of BOOT.

Also it worked for XB or EA or any Cartridge.



#706 --- Ω --- OFFLINE  

--- Ω ---

    Hexacorerunner

  • 14,011 posts
  • Location:82.102.25.76

Posted Mon Sep 3, 2018 6:16 AM

Hmm just a note:

 

Any GROM Cartridge can do this.

The GPL power up will go that address and bypass the Title Screen.

This goes back to GRAM KRACKER by MIller Graphics doing that on MENU the forerunner of BOOT.

Also it worked for XB or EA or any Cartridge.

 

Nice history lesson there, thanks Rich. 

 

Nice thing about the UberCART though, it's currently available to anyone who wants one and way cheaper than a Gram Kracker. :)  

 

Come to think of it, the scratch loader programmed in the 49F040 would do it faster from an UberCart, but still, 4A/DOS would give the user more utility.



#707 jedimatt42 OFFLINE  

jedimatt42

    River Patroller

  • Topic Starter
  • 2,023 posts
  • Location:Beaverton, OR

Posted Tue Sep 4, 2018 5:21 PM

Menu systems are orthogonal to TIPI, as you have all pointed out there are several great technical options.

-M@

#708 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • 953 posts
  • Location:Campbellsburg, KY

Posted Wed Sep 12, 2018 5:19 AM

Matt, 

 

Where/How does one turn on debugging for TIPI?  And, where might one find the output of the log?

Beery



#709 jedimatt42 OFFLINE  

jedimatt42

    River Patroller

  • Topic Starter
  • 2,023 posts
  • Location:Beaverton, OR

Posted Wed Sep 12, 2018 8:39 AM

Right now, turning on debugging, breaks the update feature unless you restore the file correctly first. I haven't taken the time to learn how moving that to a config file is usually done in python.

The tipi service log is available in the web-ui from the menus... also /var/log/tipi/tipi.log

/var/log is a tmpfs, so logs do not thrash your sdcard, consequently, there are no logs after a PI reboot.

Logging configuration for the tipi service is in the TipiService.py near the top. Google can describe python logging better than I.

I need to put this under control of PI.CONFIG so that it doesn't create problems with 'git pull', which is the primary mechanism in the update feature.

-M@

#710 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • 953 posts
  • Location:Campbellsburg, KY

Posted Wed Sep 12, 2018 7:02 PM

I did not write it down when I first set the TIPI up, and not able to find a link back to the page where the information was.

 

What is the username/password to connect to the PI/TIPI?  I rebooted my computer, and it did not save the password to the TIPI directory on the PI.

THanks.

 

Beery

 



#711 jedimatt42 OFFLINE  

jedimatt42

    River Patroller

  • Topic Starter
  • 2,023 posts
  • Location:Beaverton, OR

Posted Wed Sep 12, 2018 7:47 PM

I did not write it down when I first set the TIPI up, and not able to find a link back to the page where the information was.
 
What is the username/password to connect to the PI/TIPI?  I rebooted my computer, and it did not save the password to the TIPI directory on the PI.
THanks.
 
Beery


I try to capture this sort of thing so noone has to write it down: https://github.com/j...i-sd-card-image

-M@

#712 --- Ω --- OFFLINE  

--- Ω ---

    Hexacorerunner

  • 14,011 posts
  • Location:82.102.25.76

Posted Sat Sep 15, 2018 7:11 PM

I like the fact that we can upload stuff to the TIPI from the PC.  The current method works and I'm happy with it.  Now that being said, I sometimes wonder about the code used on some websites that lets you drag and drop an image or other files from your desktop into a web page for automatic uploading.  For example in Google Images there is a box where you can drag and drop an image.  Could that sort of code be added to the RPi's webpage/server?  Many people have wanted drag & drop capabilities, this would actually deliver.



#713 jedimatt42 OFFLINE  

jedimatt42

    River Patroller

  • Topic Starter
  • 2,023 posts
  • Location:Beaverton, OR

Posted Sun Sep 16, 2018 7:53 PM

I like the fact that we can upload stuff to the TIPI from the PC.  The current method works and I'm happy with it.  Now that being said, I sometimes wonder about the code used on some websites that lets you drag and drop an image or other files from your desktop into a web page for automatic uploading.  For example in Google Images there is a box where you can drag and drop an image.  Could that sort of code be added to the RPi's webpage/server?  Many people have wanted drag & drop capabilities, this would actually deliver.

 

 

That'd be awesome, except I'm not a web developer, so haven't put the time in to figure that out.  It would be a higher priority, if the Windows file share wasn't so easy to use, or linux command line scp...   

 

Anyone want to send a pull-request ? 

 

You can actually drag and drop to the the 'tipi' shared folder/directory/drawer from your mac, amiga, pc, etc...

 

-M@



#714 acadiel OFFLINE  

acadiel

    Stargunner

  • 1,514 posts
  • www.hexbus.com
  • Location:USA

Posted Mon Sep 17, 2018 9:25 AM

Been laying low... I need to catch up on this since I haven't touched it in months... we have a ROM upgrade, correct?  http://ti994a.cwfk.net/Downloads.html- I'll grab it and burn it.

 

Do I have to have certain software versions before I start down this path?  Or just upgrade it after?



#715 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 4,401 posts
  • Location:Portland, Oregon USA

Posted Mon Sep 17, 2018 9:26 AM

Been laying low... I need to catch up on this since I haven't touched it in months... we have a ROM upgrade, correct?  http://ti994a.cwfk.net/Downloads.html- I'll grab it and burn it.
 
Do I have to have certain software versions before I start down this path?  Or just upgrade it after?

Upgrade it after

Sent from my LG-H872 using Tapatalk

#716 acadiel OFFLINE  

acadiel

    Stargunner

  • 1,514 posts
  • www.hexbus.com
  • Location:USA

Posted Mon Sep 17, 2018 10:45 AM

Upgrade it after

Sent from my LG-H872 using Tapatalk

Thanks!  Updated EPROM And updated software.  I'm current again ;)



#717 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • 953 posts
  • Location:Campbellsburg, KY

Posted Thu Oct 11, 2018 7:51 AM

I'm copying some text over from ninerpedia regarding the Video operation of the Geneve and the Geneve's wait state generation.  I'm posting this because what we know is that the TIPI does not presently work on a stock Geneve, but there are indications it does work on a Memex (??) system.  Not knowing or understanding the internals of the TIPI, I am wondering if the issue could be tied to wait states and/or how the VDP is interfaced.  I am also a bit curious if we slowed down TIMODE in the GPL interpreter, if this would have any impact. 

 

Anyways, I was reading the information and thought it may be of interest and might trigger some thought if not previously considered, etc.

 

Source: https://www.ninerped...tate_generation

 

Video operation

 

As known from the TI-99/4A, accesses to the Video Display Processor must be properly timed, since the VDP does not catch up with the higher speed of the CPU. In fact, using a dedicated video processor turns the TI and Geneve into a multiprocessor machine, in contrast to other home computers of that time.

 

As we have independent processors, a synchronization line is usually required to avoid access operations at times when the other processor is not ready. However, there is no such line in the TI and Geneve. Texas Instruments recommends to insert commands to take some time before the next access, like NOPs or SWPB.

 

When bytes are written in a too fast succession, some of them may be lost; when reading, the value may not reflect the current video RAM contents. Setting the address may also fail when writing too quickly. The V9938 video processor of the Geneve offers its command completion status in a registered that can be queried from a program, but there is no synchronization by signal lines.

The problem has become worse with the higher performance of the Geneve. This may mean that programs that worked well with the TI may fail to run on the Geneve because of VDP overruns. For this reason, wait states may be inserted for video operations.

 

The Geneve generates two "kinds" of wait states when accessing the VDP. The first kind has been explained above; the VDP is an external device and therefore gets one wait state per default, and two when extra wait states are selected. After the access, however, the Gate Array pulls down the READY line for another 14 cycles when the CRU bit for video wait states is set (address 0x0032 or bit 25 when the base address is 0x0000).

 

There are some interesting points about video wait states, which we discuss in a separate section.


Edited by BeeryMiller, Thu Oct 11, 2018 7:51 AM.


#718 mizapf ONLINE  

mizapf

    River Patroller

  • 3,667 posts
  • Location:Germany

Posted Thu Oct 11, 2018 8:47 AM

BTW, it was me who added that text to ninerpedia, as a result of trying to improve the emulated timing in MAME. I used test programs to determine the delays, as we do not have a detailed description of the Gate array.



#719 --- Ω --- OFFLINE  

--- Ω ---

    Hexacorerunner

  • 14,011 posts
  • Location:82.102.25.76

Posted Thu Dec 27, 2018 10:36 AM

What are the odds of getting a small TI format compatible DV80 editor built into the TIPI interface program?

 

Attached Files



#720 mizapf ONLINE  

mizapf

    River Patroller

  • 3,667 posts
  • Location:Germany

Posted Thu Dec 27, 2018 10:58 AM

What puzzles me sometimes is the usage of the name "v9t9 format". I thought this was a sector dump of the whole disk (as opposed to pc99). But TIFILES is one file only.



#721 Asmusr ONLINE  

Asmusr

    River Patroller

  • 3,145 posts
  • Location:Denmark

Posted Thu Dec 27, 2018 4:49 PM

What puzzles me sometimes is the usage of the name "v9t9 format". I thought this was a sector dump of the whole disk (as opposed to pc99). But TIFILES is one file only.

 

As I recall it, a v9t9 file is just a File Descriptor Record followed by the relevant sectors.



#722 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,664 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Dec 27, 2018 4:52 PM

What puzzles me sometimes is the usage of the name "v9t9 format". I thought this was a sector dump of the whole disk (as opposed to pc99). But TIFILES is one file only.

 

V9T9 had both individual files (with a custom header, not the same as TIFILES) and the sector dump disk format.



#723 Tursi OFFLINE  

Tursi

    Quadrunner

  • 5,664 posts
  • HarmlessLion
  • Location:BUR

Posted Thu Dec 27, 2018 4:52 PM

 

As I recall it, a v9t9 file is just a File Descriptor Record followed by the relevant sectors.

 

It's not quite the same as the FDR, that would have made too much sense. ;)



#724 arcadeshopper OFFLINE  

arcadeshopper

    River Patroller

  • 4,401 posts
  • Location:Portland, Oregon USA

Posted Sat Dec 29, 2018 1:51 PM

What are the odds of getting a small TI format compatible DV80 editor built into the TIPI interface program?

 

 

Pretty good, I'll add that to the feature requests.. will be post file manager if it's added though 



#725 jedimatt42 OFFLINE  

jedimatt42

    River Patroller

  • Topic Starter
  • 2,023 posts
  • Location:Beaverton, OR

Posted Sat Dec 29, 2018 8:41 PM

I'm copying some text over from ninerpedia regarding the Video operation of the Geneve and the Geneve's wait state generation.  I'm posting this because what we know is that the TIPI does not presently work on a stock Geneve, but there are indications it does work on a Memex (??) system.  Not knowing or understanding the internals of the TIPI, I am wondering if the issue could be tied to wait states and/or how the VDP is interfaced.  I am also a bit curious if we slowed down TIMODE in the GPL interpreter, if this would have any impact. 

 

Anyways, I was reading the information and thought it may be of interest and might trigger some thought if not previously considered, etc.

 

Source: https://www.ninerped...tate_generation

 

Video operation

 

As known from the TI-99/4A, accesses to the Video Display Processor must be properly timed, since the VDP does not catch up with the higher speed of the CPU. In fact, using a dedicated video processor turns the TI and Geneve into a multiprocessor machine, in contrast to other home computers of that time.

 

As we have independent processors, a synchronization line is usually required to avoid access operations at times when the other processor is not ready. However, there is no such line in the TI and Geneve. Texas Instruments recommends to insert commands to take some time before the next access, like NOPs or SWPB.

 

When bytes are written in a too fast succession, some of them may be lost; when reading, the value may not reflect the current video RAM contents. Setting the address may also fail when writing too quickly. The V9938 video processor of the Geneve offers its command completion status in a registered that can be queried from a program, but there is no synchronization by signal lines.

The problem has become worse with the higher performance of the Geneve. This may mean that programs that worked well with the TI may fail to run on the Geneve because of VDP overruns. For this reason, wait states may be inserted for video operations.

 

The Geneve generates two "kinds" of wait states when accessing the VDP. The first kind has been explained above; the VDP is an external device and therefore gets one wait state per default, and two when extra wait states are selected. After the access, however, the Gate Array pulls down the READY line for another 14 cycles when the CRU bit for video wait states is set (address 0x0032 or bit 25 when the base address is 0x0000).

 

There are some interesting points about video wait states, which we discuss in a separate section.

 

 

The foremost problem with the TIPI and the Geneve has nothing to do with VDP... it is simply an inability for the memory mapped IO at 0x5FFF and 0x5FFD to be written to when the DSR is enabled.  

The input ports at 0x5FF9 and 0x5FFB can be read just fine and the DSR rom can be read just fine. 

 

And yes, when using my GenMod Geneve with memex, it works fine. I can write to those addresses and the PI gets to see them just fine... The full DSR works in ROMPAGE mode even with GPL running at full speed. 

 

-M@






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users