Jump to content

Photo

TIPI - Geneve 9640 to Raspberry PI interface development


41 replies to this topic

#26 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,964 posts
  • Location:Beaverton, OR

Posted Sat Mar 30, 2019 9:38 PM

I made no changes to your code, just ran your binary.

I'll try again later without turbo mode, and then without the latest CPLD change, to see if I can get it to fail.

-M@

#27 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 901 posts
  • Location:Campbellsburg, KY

Posted Sun Mar 31, 2019 11:29 AM

I made no changes to your code, just ran your binary.

I'll try again later without turbo mode, and then without the latest CPLD change, to see if I can get it to fail.

-M@

 

Since this was working on your system, I am not going to delve into setting up the TIPI log file at this point.  Waiting for confirmation, and if the old CPLD code does fail on your system, I will be sending my TIPI back ASAP for the update.

 

Beery


Edited by BeeryMiller, Sun Mar 31, 2019 11:29 AM.


#28 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,964 posts
  • Location:Beaverton, OR

Posted Sun Mar 31, 2019 4:17 PM

Beery,

 

Ok, I ran your terminal program from mdos in the following environments:

  1. My GenMod Geneve (Turbo Switch On, TIMODE Switch ON) + Fixed TIPI == PASSES
  2. My GenMod Geneve (Turbo Switch Off, TIMODE Switch ON) + Fixed TIPI == PASSES
  3. My GenMod Geneve (Turbo Switch On, TIMODE Switch ON) + old CPLD TIPI == PASSES
  4. My GenMod Geneve (Turbo Switch Off, TIMODE Switch ON) + old CPLD TIPI == PASSES
  5. Tim's Geneve with Swan Screen + old CPLD TIPI == FAILS (HANG after TIPI ROM discovery)
  6. Tim's Geneve with Swan Screen + Fixed TIPI == PASSES

My GenMod Geneve produces a NO CPU RAM error if I have the TIMODE switch off... I assume this means some of the RAM on the Memex card is bad, as it tries to skip onboard ram in that case (as I understand it)

 

My autoexec script on my boot disk, also runs the TIMODE command.

 

I don't really know what question this is answering...  I think you were after "why does Beery's code work on Matt's GenMod Geneve, and not Beery's?"  Is that correct?

 

-M@



#29 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 901 posts
  • Location:Campbellsburg, KY

Posted Sun Mar 31, 2019 5:26 PM

Yeah, the Geneve I have has the GenMod/Memex, but no turbo box switch.  Something is different which makes me question whether the CPLD update will have an impact on the Memex/Geneve in my possession.

 

What I do not have is the switchbox that plugs into the Geneve.  The one I got came without the box.  Not sure if there would be something in that box playing a role??? The documentation does say that the 0 wait state light has two brightness levels depending upon 0 or 1 wait state memory is used.  If anyone has a schematic for that box, I would appreciate it so I could build my own.

 

I do have the RPI 3B (no plus).  Not sure if that could have made any difference for something you are using?

 

As far as the no ram issue, sounds like with TIMODE OFF, you would be running all ram on the MEMEX.  Now, if you are getting that error, either you have some memory bad on the Memex in the memory pages >00 to >3F, or you have an original Eprom.  The Memex Eprom only tests memory from >00 to >39, as page >3A is not useable ram on the Memex because it overlays with the >7A and >BA pages.

 

If you run Memtest from MDOS (Ron Walters program), do you know what memory pages are marked in red (no Ram)?  This is only for information for you as it would have no bearing I am aware regarding TIPI.

 

Beery



#30 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,964 posts
  • Location:Beaverton, OR

Posted Sun Mar 31, 2019 6:03 PM

Without the box, the GENMOD Geneve should be in "TIMODE" and Turbo.

My red pages are 7A, BA, and F0-FF

I'll take that to a different thread.

---

Anyway, with no box attached I think you should be in the same mode as I am.

-M@

#31 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 901 posts
  • Location:Campbellsburg, KY

Posted Sun Mar 31, 2019 6:43 PM

OK, just wondering what the difference would be.....



#32 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,964 posts
  • Location:Beaverton, OR

Posted Sun Mar 31, 2019 7:04 PM

So, my fix enables the data signals to flow from the PEB bus into the CPLD as soon as the address lines indicate we are in DSR space, and the TIPI board is enabled. 

 

Without the fix, this also depended on MEMEN going low before that bus transceiver on TIPI is activated.  The bus transceiver does have a propagation delay. The tristate bus synthesized in the CPLD has a propagation delay, and the bits and bobs on the Geneve have them too... The WE signal goes through less delaying substances.. I don't have timing diagrams or measurements, but my theory is that I was just lucky that it works on my GenMod Geneve at all.  This is all that complex physics that matter, but we like to pretend don't exist when working with digital logic. 

 

-----

 

And I've posted it somewhere on Atariage before, but I have to give up on this being a repository of information... so here is the schematic for the GenMod Switchbox :  https://www.jedimatt42.com/geneve.html

 

-M@



#33 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 901 posts
  • Location:Campbellsburg, KY

Posted Sun Mar 31, 2019 7:08 PM

OK Matt, found where the issue is as I now have mine working.

 

I flipped the dip switches #3 and #4 on the Memex to the ON position which locks out the onboard fast ram on the Geneve at pages >E8 to >EF.  My original code on my system was loading on fast memory on the Geneve in my configuration

 

Now, the code works on my end.

 

Beery



#34 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 901 posts
  • Location:Campbellsburg, KY

Posted Sun Mar 31, 2019 7:44 PM

Well, may need to scratch that.  It worked once after I flipped those switches.  Just tried running again, and now it does not work.

 

Beery



#35 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 901 posts
  • Location:Campbellsburg, KY

Posted Sun Mar 31, 2019 8:07 PM

Bit more information.  It's got something to do with what memory pages the program is loading.  I put a RAMDISK 800 in the AUTOEXEC file to block pages, and it is loading now consistently.

 

Beery



#36 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,964 posts
  • Location:Beaverton, OR

Posted Sun Mar 31, 2019 8:10 PM

Oh, I do use a ramdisk.

-M@

#37 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 901 posts
  • Location:Campbellsburg, KY

Posted Mon Apr 1, 2019 6:35 AM

Where it loads in memory appears to be an issue on a GenMod system whether the program is in memory on the Geneve or in memory on the Memex.

 

I'll be boxing my TIPI up in the next hour or so to send to Greg for hopefully a quick turn around as your time and his match up.

 

Beery



#38 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 901 posts
  • Location:Campbellsburg, KY

Posted Tue Apr 2, 2019 7:09 AM

Matt,

 

I was looking at the specs on the messaging system with the TCP access on the TIPI.  There are two bytes for the length of information that can be transferred.  How long can this string be?   Obviously, one could not request 64K as it would overwrite all memory space if it was writeable.   Can the DSR handle an 8K transfer if one had an 8K buffer?  I am assuming both a read and write have the same size limitations?

 

Right now, I am just trying to lay out in my mind what may be the simplest approach for a programmer wanting to capture a data block with the least amount of application program code with the XOP handling the bulk of knowing where to save the block and communicating how much data was transferred.

 

Here is what I am sorta thinking about:

 

                LI        R0,OpcodeForSetup

                LI        R1,Datablock (first word length, rest data)

                LI        R2,BlockLength

                XOP   @TIPI,0

 

                LI        R0,BlockRead

                XOP    @TIPI,0

 

So, with something like this, in two lines of code, one could read a block and subsequent code could do the processing once the OpcodeForSetup was initially called.  Minimal setup, and I think fairly easy to implement with the XOP and TIPI DSR doing the work and the programmer not worrying about the TIPI. He just uses two assembly instructions, and boom, he has the data.

 

I would have to experiment a bit to understand if someone would want to truly deal with an 8K block transfer, as right now, I am only aware of one unique case on my BBS where someone can select a menu item and get a dump of >16K data that has to be processed screen display. I do not know if an 8K transfer of data from the TIPI to the program has a visible delay. Outside of Heatwave or Fusion doing an ANSI display which is < 8K of a data block, I know of no other current things TI or Geneve users are doing where one would even have any interest in handling a significant length data stream for speed.

 

Anyways, any feedback is appreciated.

 

Beery



#39 jedimatt42 OFFLINE  

jedimatt42

    Stargunner

  • 1,964 posts
  • Location:Beaverton, OR

Posted Tue Apr 2, 2019 7:55 AM

The messaging limit is that unsigned 16 bit value for the length of your data buffer.  There is no intermediate buffer creating an artificial limit.

 

Of course if you claim your buffer is bigger than your address space, ... well this could be used for good or evil ... 

 

When the DSR performs a program image load, it transfers the entire file into VDP with one vrecvmsg call.  

The mouse interface transfers a 3 byte response.

 

And as you've seen the TCP read operation will fill the buffer you give it if the data is available from the socket (here the operating system on the PI is buffering). 

 

Client programmers have to take into consideration responsiveness when choosing how to use these things, but API authors should allow the full capability. 

 

For example, if you are writing a telnet program and handling a 16k buffer with a flood of data coming in, it'll take 2 seconds to complete the one read call, and your client will have a hard time being responsive to the keyboard to stop, or abort or pause... 

 

But if you are writing an online text adventure program that just loads menu images in bitmap mode direct from an amazon s3 bucket into the TI's VDP for display to illustrate the users current location, you'd want the big load. 

Or maybe you are using it as a virtual memory system, and want to page 8k of your code out to disk, and another 8k back in.

Or you have a virtual dungeon game that creates 24k procedural maps via a web service... and as you decend into the depths you want to load the new map in one shot. 

 

The sky is the limit. As long as it is only 16 bits up - minus size of reading code.

 

-M@



#40 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 901 posts
  • Location:Campbellsburg, KY

Posted Tue Apr 2, 2019 11:14 AM

The messaging limit is that unsigned 16 bit value for the length of your data buffer.  There is no intermediate buffer creating an artificial limit.

 

Of course if you claim your buffer is bigger than your address space, ... well this could be used for good or evil ... 

 

When the DSR performs a program image load, it transfers the entire file into VDP with one vrecvmsg call.  

The mouse interface transfers a 3 byte response.

 

And as you've seen the TCP read operation will fill the buffer you give it if the data is available from the socket (here the operating system on the PI is buffering). 

 

Client programmers have to take into consideration responsiveness when choosing how to use these things, but API authors should allow the full capability. 

 

For example, if you are writing a telnet program and handling a 16k buffer with a flood of data coming in, it'll take 2 seconds to complete the one read call, and your client will have a hard time being responsive to the keyboard to stop, or abort or pause... 

 

But if you are writing an online text adventure program that just loads menu images in bitmap mode direct from an amazon s3 bucket into the TI's VDP for display to illustrate the users current location, you'd want the big load. 

Or maybe you are using it as a virtual memory system, and want to page 8k of your code out to disk, and another 8k back in.

Or you have a virtual dungeon game that creates 24k procedural maps via a web service... and as you decend into the depths you want to load the new map in one shot. 

 

The sky is the limit. As long as it is only 16 bits up - minus size of reading code.

 

-M@

 

Just a FYI so others may understand.  During an XOP call, the existing program space moves around as it is manipulated by the operating system.

 

When one calls an XOP, the code in the current execution page range of >0000 to >03FF handles the call.  What happens here is the Geneve hardware page >00 is mapped into the address range of >0000 to >1FFF, with the potential of 3 additional pages being mapped at >2000 to >3FFF, >4000 to >5FFF, and >6000 to >7FFF.

 

I would have to double check code, as I am not sure whether the operating system maps it, or if I intentionally map it, but the original page 00 of one's task gets mapped at >8000 to >9FFF.  One needs this code to know what the list of the 8 memory pages were in the calling program.  There is an address there that points to what was originally mapped on mapper pages >F110 to >F117.

 

From a lookup based upon what information is being passed, one then maps two pages in at >A000 to BFFF and >C000 to >DFFF.  This is done because a pointer for a string could cross a memory boundary.

 

Thus, really at most, under the Geneve's operating system, all one could do is to pass 16K and perhaps up to 20K if you wanted to use memory at >E000 to >EFFF.  You would not page the range at >E000 to >FFFF as that is where the calling program's workspace needs to be to pass information back to the calling program's workspace registers.  There are other reasons as well due to the 9995 chip.

 

Now, the TIPI XOP using the TIPI DSR during an XOP call, actually pages in page >BA into the memory range of >4000 to >5FFF to use the DSR's subprograms. Memory range of >6000 to >7FFF is not used by the XOP, but it would not be contiguous with the original 16K block mentioned earlier for any block writes.

 

So, what we are left with is really a 16K block from >A000 to >DFFF that can be written to for the moment since the DSR does not know how to page Geneve memory.  In principle, I guess one could create a new / additional messaging system that would know how to page memory to another mappable memory device (Geneve, AMS, etc) to allow more memory to be written during a single call.

 

The only place I see that might be able at present to use such a paging system might be something like Stuart's web browser where a larger page file could be stored if a user was using an enhanced memory system.

 

Now, I will say that should ever a paging system be implemented, two paging systems would need to be implemented on the Geneve as the mapper registers are in different locations whether one is in GPL mode or MDOS mode.

 

Also as a note, the TIPI XOP can call some, but not all of the other XOP''s as well.  One can call the video, keyboard, memory and I believe the math XOP's.  What it can not call is the MDOS XOP for handling the DSR as the DSR is dependent upon the memory and is too many layers deep.  There are certain functions in the UTIL library that can probably be called like setting time, but loading a task or launching a mirror image of the existing program would have issues since it would call upon the memory XOP's and would be too many layers deep as well.

 

It's complicated to say the least.

 

 

Beery



#41 InsaneMultitasker OFFLINE  

InsaneMultitasker

    River Patroller

  • 2,427 posts

Posted Sun Apr 7, 2019 2:24 PM

Beery,

 

While searching for Tony's Boot EPROM source I came across some TIPI-related code that I wrote last year to test whether or not TIPI could load MDOS under GPL (99/4a) mode.  If I recall correctly, loading the OS takes 15-20 seconds.

There are a few things to watch out for when modifying the code, such as setting a level 2 device ID/number for TIPI (for other devices this is typically pulled from position 4 in the level 3 device name) and a modification to the included DSRLNK routine to account for some of the level 2 gymnastics.  Path.filename is hardcoded in the source.

 

I am posting the code here as opposed to one of the BOOT-related topics mainly because you might find the routines beneficial for MyTerm file transfers and because you are pursuing its active development.

 

Attached Files



#42 BeeryMiller ONLINE  

BeeryMiller

    Dragonstomper

  • Topic Starter
  • 901 posts
  • Location:Campbellsburg, KY

Posted Sun Apr 7, 2019 4:51 PM

Got the code Tim.  Will look it over.  Have not thought about file saving to the TIPI from MyTerm at this point in time.  Focus has been predominantly a Telnet client thus far.

I think I have the opcode for an 8K "message block"  coded, just need my TIPI back to test the code.

 

Beery






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users