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

[+arcadeshopper]

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/forums/topic/245321-9640-menu-system-timxt-beta-releases/

[+Ksarul]

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. . .

[+jedimatt42]

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@

[Omega-TI]

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.

[RXB]

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.

[Omega-TI]

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.

[+jedimatt42]

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

 

-M@

[+9640News]

Matt,

 

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

Beery

[+jedimatt42]

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@

[+9640News]

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

 

[+jedimatt42]

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/jedimatt42/tipi/wiki/FAQ#q-what-is-are-the-default-login-credentials-for-the-pi-sd-card-image

 

-M@

[Omega-TI]

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.

[+jedimatt42]

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@

[+acadiel]

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?

[+arcadeshopper]

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

[+acadiel]

Upgrade it after

 

Sent from my LG-H872 using Tapatalk

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

[+9640News]

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.ninerpedia.org/wiki/Geneve_wait_state_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 October 11, 2018 by BeeryMiller

[+mizapf]

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.

[Omega-TI]

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

 

[+mizapf]

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.

[Asmusr]

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.

[Tursi]

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.

[Tursi]

 

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.

[+arcadeshopper]

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

[+jedimatt42]

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.ninerpedia.org/wiki/Geneve_wait_state_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@