Jump to content

Recommended Posts

TIPI does not have any on board ram. Those device names all have to be baked into the ROM header lists... The powerup routine could ask the PI what the saved state is, and restore the ROM selection.

 

---

 

TIPI does allow for longer filenames, with a munged up shortened alias for intolerant programs. There is a 10 character name alias for any long named file. And directory names of course are part of that path.

It is also a case sensitive file-system, like the TI FDC, even though a number of programs force the user to use only ALL CAPS in their filenames.

 

---

 

What TIPI really needs from TIMXT, is for you and I to work out a programming interface to TCP...

 

TIPI has 2 assembly language subroutine pointers in the ROM for general use. 'recvmsg' who's address is at 4010, and 'sendmsg' who's address is at 4012. The address to the routine is there.... So to call it, code like:

 

```

GPLWS EQU >83E0

SMSGPTR EQU >4012

RMSGPTR EQU >4010

...

LI R12,>1000 ; or use a CRUBASE you discover by level 3 IO checking status for file "PI.STATUS"

SBO 0 ; puts TIPI in memory map

MOV @SMSGPTR,R3 ; load the address of the sendmsg routine

MOV R0,@GPLWS ; Target WP R0 is length of message to send.

MOV R1,@GPLWS+2 ; Target WP R1 is address of data to send.

LWPI GPLWS
BL *R3 ; Call send msg - sends n bytes from cpu ram to TIPI's python code to handle.
LWPI MYWP

```

 

recvmsg works the same, but leaves the bytes received count in target WP R0. So after calling you can do:

 

```

MOV @GPLWS,R0 ; load the bytes received count into my R0.

```

 

(You don't have to use GPLWS, or even change workspace, but sendmsg and receivemsg use R0-R4. And I've only tested these outside the DSR from gcc, where I don't know what the register usage is in the current workspace )

 

So, we can send and receive data as bytearray messages. I am thinking I'd like to wire up Stuart's UDS-10 emulator into the TIPI service, so that if while TIPI is waiting for DSR requests, you send a message starting with 0x23, then the rest of the message, and all subsequent messages are just bytes that go to the UDS emulator to process. TIPI would stay in UDS mode until an escape sequence was sent to it, telling it to pause the UDS connection, letting it return to DSR mode so you can save files and stuff... then send 0x23 again, and a resume command to get back to the business of data transfer.

 

The PI would buffer everything. It would be set up so that if there is no data ready to receive, the recvmsg simply sends a 0 byte message. This way you can poll for data in a 256 byte chunk, get what is available, and if there is too much it just waits on the PI side, until you are ready for it.

 

This is basically how I read mouse data on the TI as well. I send a msg with just the mouse code: 0x20, and it responds with a message of the mouse bytes: x,y,buttons, and then goes back into DSR mode.

 

This is how many kinds of extensions can be added to TIPI, without a DSR change, just registering a 'RawExtension' object to the python code, that can take over and return control when instructed.

If it is bad and doesn't return control, no big, because the process is killed when you take the TI back to the title screen.

 

Anyway, this will totally feel like cheating compared to what you've done to get fast transfer out of the RS232... It might not fit the IO model of TIMXT ... There are no interrupts to service. You can poll at your leisure and never miss a byte. I'm not sure if it will kill the experience of being able to hit space to pause the scroll on BBSs, or if the TCP push back is enough for that, as long as the receive buffer is small enough, then it might feel equally interactive.

 

-M@

 

  • Like 2

TIPI does not have any on board ram. Those device names all have to be baked into the ROM header lists... The powerup routine could ask the PI what the saved state is, and restore the ROM selection.

--

Anyway, this will totally feel like cheating compared to what you've done to get fast transfer out of the RS232... It might not fit the IO model of TIMXT ... There are no interrupts to service. You can poll at your leisure and never miss a byte. I'm not sure if it will kill the experience of being able to hit space to pause the scroll on BBSs, or if the TCP push back is enough for that, as long as the receive buffer is small enough, then it might feel equally interactive.

 

 

Ah, that clears up a misconception I had regarding where you were mapping and storing devices. Duh. I'll have to re-read the thread with that in mind.

 

As for polling - that's music to my ears ;) The ubergrom UART is a polled device and works just fine. I suppose the experience will depend on what you are connecting to -- a vintage machine won't dump data as fast as a PC-based BBS; then again, the target connection is meant to be the vintage machines.

  • Like 1

Oh, I'm a genius! icon_smile.gif LOL... ( I had to use auto-correction to spell one of those words write )

 

Swapping ROM banks, so I have WDS1. mode and DSK? mode is awesome!

 

I can copy files between TIFDC and TIPI, in DM2K if I use the WDS1. alias, and the >2x codes.

 

I just .ifeq'ed up some conditional code in my dsr lists, and build 2 versions. One with:

 

Lvl2 base = >10 and device names:

TIPI.

DSK0.

DSK1.

DSK2.

DSK3.

DSK4.

PI.

etc...

 

and another with lvl2 base = >20 and device names:

TIPI.

WDS1.

PI.

etc...

 

My last barrier (cause I'm also an idiot:) ) was shifting the error codes from the Level2 routines to the top 3 bits... which I knew I needed to do, but was surprised to find DM2K performing operations it expects to error in order to succeed.

 

Copying between directories on the Tipi in either mode as DSK4. or WDS1. works well too!

 

---

 

Now I just need to find a good way to control it... I have my config tool.. So I'll start there. I want it to persist, so the poweron routine will have to actually interact with TIPI besides just resetting the processes... This means I'll delay powerup until I can handshake with the PI. icon_smile.gif It'll be interesting how annoying or nice that is... Hopefully it will not take much longer than the little 3 note song I play in the power up routine.

 

-M@

To clarify one of our past exchanges: there is no DSR-specific reason that level2 base >10 and level2 base >20 routines and their device names cannot reside in the same DSR bank. The HFDC, for example, has DSK1-8 and WDS1-3 devices and all >1x and >2x routines in the same DSR, which it uses to co-exist with the floppy controller in the same PEB. It's really up to you and how you want the device configured.

 

The banking looks like a great way to get around device issues. Nice to see that even DM2K is working ;) Things are really taking shape.

  • Like 1

Did the HFDC work with a TIFDC in the same PEB? I think that is where my issue comes from... having two devices use the same set of routines... I wasn't getting good behavior...

 

It is possible I had another bug in the way... so I could re-test that. In which case though, I wouldn't need >20 at all... because acting like an HFDC's DSK? would be good enough.

 

-M@

Yes, the HFDC works fine with a TI (or Myarc or CorComp) FDC in the same system. The HFDC DSR responds to drives 1-4 or 5-8 depending on the configuration at powerup.

There are still issues with two cards using the same devices/routines depending on what order the cards are scanned.

 

The HFDC floppy level 2 routines don't support subdirectories in the same manner as the hard drive level 2 routines; and there is no >17 routine to mirror >27. Thus no program will know how to change directories for level 2 IO; you'll be stuck at the root. This is where the WDS-based level 2 may still be handy.

  • Like 1

Interesting.. when I was just using >1x routines DM2K let me create play in directories, and I could copy files from one dir on DSK4. to another.

 

I'm happy with the switching of ROMs.

 

Tonight I'll add a feature to switch in TIPICFG, and call it good.

 

-M@

  • Like 1

Good to know. Last time I checked, from a TI only Myarc's Disk Manager and the HFDC DSR could access the files in those subdirectories. I don't know of any way to use the direct input/output routines >14 and >15 to access files in those subdirectories, except for temporarily swapping sector 0 with the FDIR for the subdirectory. Seems to be a moot point as you have a solution in hand ;)

  • Like 1

In order to get things just right, I need to space the stackable header on the TIPI a bit... I could harvest insulator off of these:

 

post-42954-0-65165000-1515309107.gif

 

but I thought that would be wasteful, if I could get the insulator without the metal part somewhere... I'm just having trouble searching... anyone feel like googling that for me?

 

Or have a better idea of what they are called than 'header insulator' ?

 

-M@

In order to get things just right, I need to space the stackable header on the TIPI a bit... I could harvest insulator off of these:

 

attachicon.gifhdrbrk1x40318.gif

 

but I thought that would be wasteful, if I could get the insulator without the metal part somewhere... I'm just having trouble searching... anyone feel like googling that for me?

 

Or have a better idea of what they are called than 'header insulator' ?

 

-M@

 

If you just need a spacer, then presumably you would only need to fit it to a couple of pins (the pin at each end plus perhaps one in the middle)? So re-using bits from a pin strip would be quite economical?

 

Or could you cut a slice off a nylon hex spacer and secure in place with a dab of glue?

  • Like 1

Creative...

 

Yep, I'm just looking for even spacing on both ends while I hold and solder the stackable header in place. Maybe I'll find what I need between glue and weed-wacker 'string'

 

-M@

  • Like 3

Cool demonstration, Sinphaltimus! I wonder with all the checking you have going on in the XB code with the ON ERROR work, what if... DSK1 was mapped to a shared folder in Dropbox?

 

-M@

 

On another note... try going to TI BASIC (not XB) and running:

 

CALL TIPI
-M@
  • Like 2

Cool demonstration, Sinphaltimus! I wonder with all the checking you have going on in the XB code with the ON ERROR work, what if... DSK1 was mapped to a shared folder in Dropbox?

 

-M@

 

On another note... try going to TI BASIC (not XB) and running:

 

CALL TIPI
-M@

 

DROPBOX!!! That's Nuts! Adding that to my to test list! - Sounded crazy at first but now that I think about it.... I think it just might work......

 

CALL TIPI in TI BASIC - WHOA! Sweet!

 

EDIT: So I tested this locally, that is to say that I ran classic99 vs classic99 on the same computer with both computers pointing to a TIPI folder in my dropbox. Dropbox kept syncing up during gameplay every so often and gameplay continued like normal. I sent you and invite to my TIPI dropbox folder if you want to try it out over the internet....

Edited by Sinphaltimus
  • Like 3

M@! - Incredible - I can confirm that the number guessing game works via dropbox. So essentially the number guessing game can be played today by anyone using emulation. Just share your dropbox folder (with edit permissions ) with your opponent and both of you configure your DSK1 to point to your local dropbox share. What a great idea. Multiplayer TI-994/a games over the internet are (and have been) available now for anyone using emulation. :)

  • Like 1

Sounds great.

 

I would assume this would NOT work for something like MAME or MESS since I do not think two different emulators could access the same file at the same time???

 

Beery

Sounds great.

 

I would assume this would NOT work for something like MAME or MESS since I do not think two different emulators could access the same file at the same time???

 

Beery

 

Hey Beery - So as not to hijack the TiPi thread - I answered your question here as best I could - http://atariage.com/forums/topic/273950-classic99-versus-classic99-head-to-head-turn-based-game-demo/?p=3930397

 

As of now, To use DropBox with TiPi, a symbolic Link or mount point would need to be added to the TiPi share folder on the Pi that links directly to a DropBox folder on another computer. I don't know that there is a dropbox application for the Pi to do it directly.

So the emulation stuff isn't really TiPi related. Although we took a side step by bringing DropBox into the fray, I'd feel terrible derailing this topic over it.

Sounds great.

 

I would assume this would NOT work for something like MAME or MESS since I do not think two different emulators could access the same file at the same time???

 

Beery

MAME does not access files on the host, apart from the dsk image itself. Also, dsk images cannot be concurrently accessed because they are read into memory and written back on leaving the emulation.

  • Like 1

What we plan to implement, that also won't work in either emulation, is a more efficient server based shared variable system.

 

ElectricLab is working on that end of things... He has defined a protocol for sending commands to the variable storage, and retrieving from the storage. Declaring the variables as TCP shared or UDP shared. Some simple matchmaking, so the server can create the space for apps and 2 players to share.

 

We've talked briefly about an 'all'

 

He has been implementing this as one of TiPi's RawExtension objects that just uses the DSR for message passing. I believe I can refactor it a touch to be accessible from BASIC as well using a PI.VARS SpecialFile extension for TIPI, and make the same command interface available simple PRINT and INPUT of a DISPLAY/VARIABLE file.

 

This is an overly verbose, completely made up, semi-representative example, I believe Corey has codified this so it is much more compact, and working from gcc and TiPi messaging directly.

 

But the BASIC interface may look like:

 

OPEN #1:"PI.VARS",UPDATE,DISPLAY,VARIABLE 254
PRINT #1:"CREATE_APP:TICHAT,UDP"
PRINT #1:"CREATE_VAR:TICHAT:NAME=matt"
PRINT #1:"READ:TICHAT:MSGS"
INPUT #1:MSG$
...
Corey's working out the real details... I just mention this, as it is related to the BASIC gaming over the net turn we've taken. We'll see where it goes.

 

-M@

  • Like 4
  • 2 weeks later...

Loading my extended basic EA5 loader from ftp.whtech.com then catalog DSK1. being emulated from the TIPI storage and then loading Hitchhiker's guide from the TIPI

 

https://photos.app.goo.gl/kSkX9x21xQw3hDpu2

 

Sent from my LG-H830 using Tapatalk

  • Like 3

Really looking forward to buying one of these.

Loading my extended basic EA5 loader from ftp.whtech.com then catalog DSK1. being emulated from the TIPI storage and then loading Hitchhiker's guide from the TIPI

https://photos.app.goo.gl/kSkX9x21xQw3hDpu2

Sent from my LG-H830 using Tapatalk

 

I will give it a try probably need to find the manual as I've never used it :)

 

Greg

 

:grin: Here ya go!

 

P.S. - Just ignore the loading instruction if you are using the FlashROM version.

4A DOS - Instruction Manual Rev-02.pdf

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...