TIPI - Geneve 9640 to Raspberry PI interface development

[+jedimatt42]

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@

[+9640News]

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 March 31, 2019 by BeeryMiller

[+jedimatt42]

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@

[+9640News]

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

[+jedimatt42]

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@

[+9640News]

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

[+jedimatt42]

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@

[+9640News]

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

[+9640News]

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

[+9640News]

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

[+jedimatt42]

Oh, I do use a ramdisk.

 

-M@

[+9640News]

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

[+9640News]

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

[+jedimatt42]

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@

[+9640News]

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

[+InsaneMultitasker]

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.

 

TIPI TEST DISK 720.dsk

[+9640News]

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

[+9640News]

About to post some messages been exchanging with Matt/Tim/Greg ................

 

 

Greg/Tim, looping the two of you in on what I saw with the Geneve and MEMEX combo testing I did today and have previously communicated to Matt.

OK Matt, from what you describe as far as what you tested, your testing and mine add up. What it looks like I am doing, and what neither of us would have seen to be an issue, is the MDOS testing side of things.

If TIPI code is returning data back to a page outside of the pages >00 to >3F range, then there is the problem. In TIMODE, the Memex memory is not used so the issue would not show up. On a stock Geneve, the issue would also not likely to show up. What I am uncertain until I swap Geneve's around, is what happens to the high speed ram on the Geneve with the stock 32K ram, and/or the other optional 32K ram. I will have to switch Geneve's to test that specific configuration.

In my case, anytime the program was running code talking to the TIPI in the >E0 to >EF pages, I got garbage back. When MDOS gave me a page on the Geneve (>18 in my tests), code was fine.

So, my guess there is still a timing issue with the Geneve when talking to a Memex memory page. I also have a Myarc 512K card I will also test to see if that creates trouble as well.

I believe the issue is not the sending of a message, rather just receiving a message back.

I'm going to loop Tim into this message/discussion as there may be some temporary workarounds with MDOS "crippling" the XOP driver requiring some modifications to MDOS that will need to be made.

Beery

[+9640News]

So... none of that makes any sense to me... mostly because I don't know anything about MDOS.

An MDOS process sets up a 64k memory map. Right?

XOPs get to run from some alternative 64k memory map. Right?

What is the significance of page numbers >E0 to >EF?

What is the significance of page numbers >00 to >3F?

The CPU can read and write to these memory spaces without special programming concerns beyond mapping them into their process space. Right?

The tipi message routines are given buffer addresses. I assume you are calling that while in the XOP's memory configuration.. so that address has to be the 16 bit address translated from the application memory map to the XOP memory map. Right?

I recall seeing flags to memory request xops around fast or slow memory... can you write your code in those terms to let the OS mask the problem for you?

Why isn't this a public thread so others can learn? I constantly get the impression that the Geneve and information about the Geneve is kept secret...

-M@

[+9640News]

From Tim:

 

 

• 
• 2,428 posts

Sent Today, 2:04 PM

Sharing a few random thoughts over lunch break:

Keep in mind that when using GPL, the assigned 32K and scratchpad memory pages are a combination of SRAM pages (EC,EE range) and on-board DRAM equivalent pages (>00->3F). Execution speed is controlled by paging fast or slow ram into these banks, and by enabling/disabling wait states. I don't know how you are testing in TI MODE but the memory mapping could make a difference. By enabling TI MODE, you can manually map these pages into memory space in your 9640 program, allowing you to do more testing against the page theory.

I would suggest that you confirm whether your 9640 mode read/write code works in a standalone program without the XOP framework. Sometimes the XOP memory mapper manipulation can mess things up, especially when transferring data between pages.

[+9640News]

From Beery to Matt:

 

 

Sent Today, 2:48 PM

jedimatt42, on 22 Apr 2019 - 1:46 PM, said:

So... none of that makes any sense to me... mostly because I don't know anything about MDOS.

1. An MDOS process sets up a 64k memory map. Right?

2. XOPs get to run from some alternative 64k memory map. Right?

3. What is the significance of page numbers >E0 to >EF?

4. What is the significance of page numbers >00 to >3F?

5. The CPU can read and write to these memory spaces without special programming concerns beyond mapping them into their process space. Right?

6. The tipi message routines are given buffer addresses. I assume you are calling that while in the XOP's memory configuration.. so that address has to be the 16 bit address translated from the application memory map to the XOP memory map. Right?

7. I recall seeing flags to memory request xops around fast or slow memory... can you write your code in those terms to let the OS mask the problem for you?

8. Why isn't this a public thread so others can learn? I constantly get the impression that the Geneve and information about the Geneve is kept secret...

-M@

OK, added some numbering here to answer questions.

1. Yes, 64K memory map though when memory is not specifically requested, it is assigned page >FF which is "empty" memory, and thus one of the reasons MEMTEST shows the physical pages >F0 to >FF as not being ram.

2. XOP's run from an alternative map that the operating systems managing during the paging scheme in the task header page from >0000 to >03FFF. MDOS programs start loading at >0400.

3. The Geneve has high speed ram at blocks of 32K at >E8 to >EB, and >EC to >EF when the optional 32K memory is installed. This is separate from the 512K that is also on the Geneve card.

4. The Geneve's onboard physical pages of ram are >00 to >3F. When TIMODE is OFF, this 512K bank is accessed on the Memex instead of the Geneve. The exception here is page >3A. Page >3A is only "good" when TIMODE is on due to the gate array hardware. If TIMODE is off, the Geneve can not access page >3A on the Memex and is why you get the memory error.

5. Yes, that is correct. Just keep in mind there is 1.5 MB of ram that is accessible on the MEMEX only due to the GenMod.

6. Yes, you are correct. Simplest test program was the one I sent you. I think it displays the memory page list being used.

7. MDOS is not as smart as we wish. In reality, it does not know if memory is 0 or 1 wait state, or on the Geneve or on a memory card. As such, it tries to guess if memory is fast or slow. One can request fast memory based upon its guesses, however, when you ask for "any" memory, you can get anything back. There is not a request for "slow" memory.

8. I was giving you a head's up. I will post on the group/appropriate topic. Information was not secret and I think pretty well known by anyone that has programmed back in the 90's. One has to dig a bit deeper or just ask and the few of those that are still here will gladly answer.

Beery

• Reply
• Report
• Edit

[+9640News]

 

From Tim:

 

Sharing a few random thoughts over lunch break:

Keep in mind that when using GPL, the assigned 32K and scratchpad memory pages are a combination of SRAM pages (EC,EE range) and on-board DRAM equivalent pages (>00->3F). Execution speed is controlled by paging fast or slow ram into these banks, and by enabling/disabling wait states. I don't know how you are testing in TI MODE but the memory mapping could make a difference. By enabling TI MODE, you can manually map these pages into memory space in your 9640 program, allowing you to do more testing against the page theory.

I would suggest that you confirm whether your 9640 mode read/write code works in a standalone program without the XOP framework. Sometimes the XOP memory mapper manipulation can mess things up, especially when transferring data between pages.

 

 

Tim,

 

I went digging into some GPL source code and will need to dig deeper to determine the wait state cru bit settings the GPL interpreter is using.

However, without changing any settings and with an XOP, I get the TIPI to talk to MDOS when I am using a memory page on the Geneve itself. I was able to set a 800K ramdisk and a 64K spooler to tie enough memory up. However, when the XOP code itself is installed on a page of memory not on the Geneve (at least on a GenMod system), then the receive message is getting back bogus information. Same program which is the XOP installer, but calling the XOP opcodes it installed. Basically, the installer had a few extra lines of code that turned it into a very basic telnet client itself.

 

I did try to play with some wait state CRU bits along with the "XMEMCY" (short external memory cycles) code that was in the boot eprom thinking it is a timing issue. I also set VDP slow as well. Not sure if this can be resolved with CRU bits, or if there is another issue.

 

I'm going to pull my stock Geneve and test it, and then add my Myarc 512K card to it as well to see if is GenMod related, or all external memory where the problem lies.

 

Beery

[+mizapf]

Concerning Geneve information, I hope everyone is aware about our texts on Ninerpedia: https://www.ninerpedia.org/wiki/Category:Geneve

 

(I mean, it's the reason why we're writing them.)

[+jedimatt42]

I have to admit I never tried searching in ninerpedia. So I had never seen most of that as I didn't run across it while navigating normally.

 

I am a failure at the internet. I generally have to know something is there to think of searching for it.

 

I was just looking this morning thinking how sad it is that there is so little info on ninerpedia.

 

I was wrong.

 

-M@

[+mizapf]

Yes, finding the information is typically the problem. I'm going to move MAME-specific stuff to my own website (setting appropriate forwarding links, of course), so Ninerpedia will concentrate on technical information about the TI family (and less about MAME specifics). Still, we should every now and then try to sort the stuff on Ninerpedia to make it better visible.