TIPI - Geneve 9640 to Raspberry PI interface development

[+9640News]

Matt,

 

I tested the TIPI with an unmodified Geneve with a modified Myarc 512K card in the system. I've got some results that may be suggestive where the issue is. Any pages where the code is running on the Geneve card itself is fine. There is at least one page of external memory where there is an issue.

 

I have a table below where I have identified at least one memory page on the Myarc 512K card where my code does not receive a message back from the TIPI suggesting the TIPI can not write to it. I was able to move pages around a by adjusting the RAMDISK size. Same exact code, just different memory pages being written too. I included the calling program's workspace page, however, with the particular opcodes I am calling, everything is within the XOP Page for when/where the TIPI code is being run and where data should be returned too.

 

XOP Page Workspace Page Result

>98 >9A Good

>99 >9A Good

>9A >9B Bad

>9B >9C Good

>BD >BE Good

>EE >BE Good

Edited April 23, 2019 by BeeryMiller

[+9640News]

Another piece of information. The above example is tied to the following piece of code:

 

LI R12,>1EFE

SBO 0

 

The above code adds an extra wait state.

 

Time to dig into the GPL source code to see what the default states are and to determine if any of that translates into something useable within MDOS.

 

Beery

[+jedimatt42]

You keep saying thing like the "TIPI can not write to it", which confuses me.

 

The TIPI board does not do DMA... It can not write to any of the computer's memory... The CPU is the only thing that writes to memory...

 

The TIPI has 4 bytes of dual port memory in the form of memory mapped latches inside the CPLD. The TMS CPU can write to the 2 outbound bytes, and read from all 4. The PI can read the 2 outbound, and write to the 2 inbound.

 

So, if we can come up a level, what do you mean by the "TIPI can not write to it" ?

 

Do you mean that the CPU is not writing successfully to PEB addresses >5FFD and >5FFF when the PEB DSR bank is mapped in?

 

If the TIPI ROM sendmsg or recvmsg does not hang, then you are successfully exchanging bytes with the PI. You said you are getting garbage back... that's not the same as hanging.

 

If that is what is happening, then it seems to me the CPU when running the recvmsg routine is not correctly copying the byte from PEB address >5FFB to the passed in buffer address. Is it going somewhere else? Or is it reading the wrong byte?

 

Access to anything in the DSR ROM address range is still with a waitstate, correct?

 

-M@

[+9640News]

You keep saying thing like the "TIPI can not write to it", which confuses me.

 

The TIPI board does not do DMA... It can not write to any of the computer's memory... The CPU is the only thing that writes to memory...

 

The TIPI has 4 bytes of dual port memory in the form of memory mapped latches inside the CPLD. The TMS CPU can write to the 2 outbound bytes, and read from all 4. The PI can read the 2 outbound, and write to the 2 inbound.

 

So, if we can come up a level, what do you mean by the "TIPI can not write to it" ?

 

Do you mean that the CPU is not writing successfully to PEB addresses >5FFD and >5FFF when the PEB DSR bank is mapped in?

 

If the TIPI ROM sendmsg or recvmsg does not hang, then you are successfully exchanging bytes with the PI. You said you are getting garbage back... that's not the same as hanging.

 

If that is what is happening, then it seems to me the CPU when running the recvmsg routine is not correctly copying the byte from PEB address >5FFB to the passed in buffer address. Is it going somewhere else? Or is it reading the wrong byte?

 

Access to anything in the DSR ROM address range is still with a waitstate, correct?

 

-M@

 

Matt,

 

I am calling the routines for send/receive message in the TIPI DSR. When I say "TIPI can not write to it", I am getting bogus data back that the TIPI DSR writes to the specific memory page. Everything should still be with the wait state while in the DSR ROM.

 

I can see your logic if you are going where I think you are going. The DSR itself should not care what memory it is using to write to if data arrived at the port correctly. As far as the TIPI port(s) are concerned, I would not think it would care what type of memory is mapped elsewhere as it is the DSR itself that will move the data.

 

Hmmm. Yesterday was my day off, but I ran out of time to do any more testing. This evening I will dig more into the GPL code as obvious the "default" GPL settings for speed, etc. work for the GPL/Rompage mode. Maybe there is something there that is a clue........

 

Beery

[+9640News]

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

 

Michael, not sure who manages this website, but I saw a mistake under the GPL Interpreter section.

 

Page >53 for the E000-FFFF range is incorrect as it does not exist on a stock Geneve. I would have to actually go in and see what the actual page number is. I'm assuming it was not a base 10 number since everything else was hex.

Beery

Edited April 23, 2019 by BeeryMiller

[+9640News]

Hmmm. Yesterday was my day off, but I ran out of time to do any more testing. This evening I will dig more into the GPL code as obvious the "default" GPL settings for speed, etc. work for the GPL/Rompage mode. Maybe there is something there that is a clue........

 

Beery

 

Well, the ninerpedia identified the differences in GPL speed on the GPL interpreter side of things. I will go in and make sure I have video wait states on but I do not see how this could be a factor.

 

Tim (or anyone else), if you are reading this, wasn't there an issue with some cards having a timing issue of some type and was part of the reason Myarc used a "Master" DSR? Seems like there was some kind of issue, and maybe something that was brought up in another thread in the past few weeks about why some card's DSR's weren't useable on the Geneve?????

If that is the case, I wonder if the DSR was copied into the XOP into Geneve memory so we were only accessing the ports of the TIPI, if this would overcome what I am seeing. Matt, if you are seeing this, how large is the DSR? If it is too big for the existing XOP code and the DSR to fit into a single 8K page, then if the DSR was AORG'd to load at >6000 to >7FFF instead of >4000 to >5FFF, but still point at the ports in the >5xxx ports, that could be one approach. I'm not sure without looking at the code to know how involved the send and receive message code is that resides in the DSR to know if can be extracted "as is" independent of the rest of the DSR. If it can, I would go that route instead.

I'm thinking out loud here and if someone has thoughts, please post. We know it works in the GPL interpreter/rompage environment. It's just the GPL environment and what it does with the gate arrray has some gaps in understanding..........

Beery

Edited April 23, 2019 by BeeryMiller

[+mizapf]

 

Michael, not sure who manages this website, but I saw a mistake under the GPL Interpreter section.

 

It is running on my webserver, but it is nonetheless a Wiki - typically meant to be a collaborative project. I can correct the information, but in general, if you have good reasons to change something, you need not wait for anyone; just boldly log in and go where no one has gone before.

 

(In fact, the digits were swapped, should have read >35)

[+9640News]

 

It is running on my webserver, but it is nonetheless a Wiki - typically meant to be a collaborative project. I can correct the information, but in general, if you have good reasons to change something, you need not wait for anyone; just boldly log in and go where no one has gone before.

 

(In fact, the digits were swapped, should have read >35)

 

Was not even aware I could change things myself.

 

Beery

[+mizapf]

I believe many people here are not aware of that. In fact, I planned the Ninerpedia to be a storage for all our TI knowledge, just like Wikipedia does for everything else.

[+InsaneMultitasker]

wasn't there an issue with some cards having a timing issue of some type and was part of the reason Myarc used a "Master" DSR? Seems like there was some kind of issue, and maybe something that was brought up in another thread in the past few weeks about why some card's DSR's weren't useable on the Geneve?????

One hypothesis is that onboard DSRs for the corcomp and TI FDC have timing-dependent code that runs to quickly on the Geneve, hence the need for low-level IO in the boot EPROM and similar low level IO in the master DSR. This has yet to be proved.

 

I find your test results suspicious as there should be little to no difference with pages 0x98, 0x99, 0x9A, 0x9B. Based solely on these results I would not expect a timing issue. Can you post your code?

 

XOP Page Workspace Page Result

>98 >9A Good

>99 >9A Good

>9A >9B Bad

[+mizapf]

I have some doubts about the timing issue. The point is that the controller has ultimate control about the execution speed of the low-level access. If the mere CPU speed had an influence, we would have something like an asynchronous access. Instead, the access is purely synchronous.

 

Actually, the TI disk controller locks the processor in a wait state loop until the full byte has been received. This happens when reading from an 5FFx address while the wait state logic is active (SBO 2), until an interrupt or a DRQ signal occurs, and the motor is turning. In the code, these lines look like

 

MOVB @>5FF6,R0

 

I know that the BwG controller had issues with the Geneve. It triggers wait states when 5FF7 is accessed, so that on the subsequent access to 5FF6, the byte is read normally. The TI console always accesses two bytes (5FF7, 5FF6), even for MOVB operations. But the Geneve actually only addresses a single byte at 5FF6, so no wait states are generated.

 

The TI FDC has a different wait state logic and actually waits on the 5FF6 access.

 

As I said, I'd really be interested to learn why the real TI FDC fails during boot time, since the currently emulated TI FDC does not encounter issues.

 

 

Edit: The safest way to find out is to compare the low-level access code of the FDC ROM with the corresponding code in the EPROM.

Edited April 23, 2019 by mizapf

[+InsaneMultitasker]

when I poked around at the TI DSR on thierry's site I noticed at least one timing loop without any controller chip locking, though I may well have misunderstood the purpose of that code. A Myarc floppy controller used with ROMPAGE will fail at speed 5 but seems to work ok at speed 2. Is that a timing loop issue or a hardware-induced issue? I don't know that anyone has ever proved any of these cases. I don't have the time or resources for that right now. Wait states are just as likely an explanation. The proverbial 'someone' needs to get to the bottom of it

[+mizapf]

I just tried it on my DDCC-1 on the Geneve. A CALL DIR(1) succeeds with single density and rompage speed 5, but not with double density. However, the DIR subprogram even locks up with rompage at speed 1 with DD.

 

I should have a TI disk controller somewhere in my cardboard boxes to check this. It may be easier this way because we have schematics for the TI FDC, and its operation is well understood. (Does not help with DD, of course.)

 

Real hardware sucks. I'd like to simply glue in some log commands, as I do when debugging in MAME.

[+InsaneMultitasker]

With my standard Geneve (64K SRAM and 512K DRAM) and the Myarc FDC, I can load files and perform CALL DIR() at speeds 1,2,3. This is with a double density disk. Speeds 4 and 5 fail both operations. I did not try writing (grin). Maybe there is an element to disk skew and interleave in addition to some timing in the DSR. Isn't real hardware grand?

[+9640News]

Here is the source code and program image file to a TIPI terminal client for MDOS with source code. To exit the program, press F9.

 

When the program executes, it displays a series of 4 hex words waiting for a keypress. The LSB of the first word, represents the page where the XOP code has loaded. With my Myarc 512K card, if that page is either >9A, or now I have discovered page >92 as well, the program freezes. All other pages I have tested thus far have worked. I have not tested everything, just been adjusting the RAMDISK size to get various pages to load.

 

At present, the program once the enter key is pressed, connects with the 9640News.ddns.net:9640 BBS. I added the ANSI character definitions so the menus appear nicer with my BBS.

 

Beery

 

 

TIPI2.ARK

[+InsaneMultitasker]

Here is the source code and program image file to a TIPI terminal client for MDOS with source code. To exit the program, press F9.

 

When the program executes, it displays a series of 4 hex words waiting for a keypress. The LSB of the first word, represents the page where the XOP code has loaded. With my Myarc 512K card, if that page is either >9A, or now I have discovered page >92 as well, the program freezes. All other pages I have tested thus far have worked. I have not tested everything, just been adjusting the RAMDISK size to get various pages to load.

Umm, thought just occurred to me. When I ran memtest with genmod/memex system, all external ram pages in the >xA and >x2 range were blocked if I recall correctly. When you mention page >92 that rang a bell. Perhaps one of the cards is not properly decoded or there is something being stomped on when executing from those pages. Could be a timing or addressing issue when code executes within those specific pages. Maybe try pages A2, AA, etc for further testing.

[+9640News]

Definitely an idea. The above testing was done with a standard Geneve and modified Myarc 512K. It will be easy enough to throw the Memex and GenMod Geneve back into the system and flip the dipswitch to map out those external ram pages after I do some additional testing with the >A2 and or >AA pages.

 

The good news is that if it turns out to be something along those lines, then there is a software solution to block those pages from being accessible in an expanded memory system.

 

I should say MEMTEST has not reported any issues which I thought it would have had there been any decoding issue.

 

Beery

[+jedimatt42]

When building my 32k board, I found that memory tests for the 4A did not actually 'test' as much as 'detect'

 

In particular the corcomp memory test... worthless. The AMS/SAMS memory test, also very weak.

 

I don't know what technique is used in the MEMEX 'MEMTEST' but it doesn't have a burn in mode, and it completes rather quickly... so I would categorize it as memory detection, not testing.

 

-M@

[RXB]

I could make a RXB SAMS memory test most of the program would run from Scratch Pad as a 18 byte Assembly and GPL is how RXB SAMS Memory Access works.

Just add a 2 byte counter and single byte for page number and GPL would do the rest. So only 3 more bytes in Scratch pad would do the trick.

 

It would just start from Page 0 (4K) up to page 255 and move it to >2000, then >3000, then >A000, on up to >F000 and each time zero out that 4K memory and test each byte.

 

RXB 2000 to RXB 2012 had this feature built in to all pages except the PASS mode pages 0,1,2,3,A,B,C,D,E,F but only use >2000 for testing if AMS (SAMS) existed.

 

The update would work with all pages and all memory address.

Edited April 24, 2019 by RXB

[+9640News]

The Memex test program was a fairly good test program. I know it would write/read and was more than just a memory detect program. It would pick up memory issues such as on page >BC where the Rave Speech card could exist if it was not fully decoded properly. That is why MDOS excludes page >BC from useable memory.

 

There was also a version of Memtest that ran continuously in a loop. Ron modified it for the GenMod system to go through the system in a loop for hours/days for a burn-in to test for the very intermittent memory issue when a too slow chip was used on the GenMod/Memex combo.

 

I used to have the program, but have not found it yet in my archives.

 

Beery

[+9640News]

With the GenMod Geneve with a Memex in the system, any page I have tested that has loaded the XOP into memory on the Memex (pages >40 to >EF), has resulted in the program failing to display a received message properly.

 

With a stock Geneve and Myarc 512K, then the results are as previously reported. I have not tested additonal pages at this time.

 

For the interim until this issue is resolved, if it can be, then I am going to copy the code brute force into a page of memory the GPL interpreter would normally occupy. Need to figure out a page that is unlikely to be used except in rare circumstances.

 

Beery

[+jedimatt42]

I wonder if lifting the recvmsg ASM code into the XOP directly, and inserting an intermediate copy to a 9995 scratchpad register before copying out to the PEB ram would do the trick?

 

it performs a

MOVB @RDIN,*R1+   

on line 122 of tipi-io.a99 If that line was changed to

MOVB @RDIN, R3
MOVB R3,*R1+

It might be successful... assuming WP is somewhere in the on chip ram of the 9995, probably won't be too much slower.

 

There is evidence that copying bytes from TIPI registers to scratchpad (assumed scratchpad) is working when the sendmsg is looking at control data.

 

-M@

[+9640News]

Any way I can update my TIPI to test this out without everyone being flagged there is an update? I believe I can move things to being on the internal ram of the 9995 on the MDOS side of things without causing any other issues with the XOP's as MDOS is currently written. I'm not sure if that works, if there would be an issue with the Geneve Master DSR should anyone (not me!) ever attempt to add DSK access on the MDOS side of things. That would be a secondary issue in the future.

 

Beery

[+jedimatt42]

This is a ROM change, or you can move the ASM code directly into your XOP code... I can extract and unmacro that code for you if you like.

 

Later tonight...

 

-M@

[+jedimatt42]

Waiting for the oven to preheat, and realizing the assembly creates a listing for me... which de-macros the code pretty much...

 

TSRSET	EQU	>F100
TSRB	EQU	>0600

TCOUT	EQU	>5FFD
RDIN	EQU	>5FFB
RCIN	EQU	>5FF9



; Register usage:
;   R0 - receive buffer size. Result is number of bytes loaded into buffer.
;   R1 - cpu address of buffer
;   Destroys R0 - R8  ( Looks like I cleaned it up at some point to do less damage, R0 - R4 looks more accurate )
recvmsg
	LI	R2,TSRSET

	MOVB	R2,@TCOUT

RM1	CB	@RCIN,R2

	JNE	RM1
	LI	R2,TSRB		; set read mode

	MOVB	R2,@TCOUT

RM2	MOVB	@RCIN,R3

	CB	R2,R3
	JNE	RM2
	AI	R2,>0100

	ANDI	R2,>0100

	ORI	R2,TSRB

	MOVB	@RDIN,R4	; read MSB of data size

	SWPB	R4
	MOVB	R2,@TCOUT

RM3	MOVB	@RCIN,R3

	CB	R2,R3
	JNE	RM3
	AI	R2,>0100

	ANDI	R2,>0100

	ORI	R2,TSRB

	MOVB	@RDIN,R4	; read LSB of data size

	SWPB	R4
	CLR	R0		; reset byte counter
	CI	R4,>0000	; if size is 0, then be done

	JEQ	rrt

rnext
	MOVB	R2,@TCOUT

RM4	MOVB	@RCIN,R3

	CB	R2,R3
	JNE	RM4
	AI	R2,>0100

	ANDI	R2,>0100

	ORI	R2,TSRB

; Change to attempt avoidinga problem copying to fast mem on PEB bus
;	MOVB	@RDIN,*R1+	; copy byte from tipi to RAM
: replace above line that directly copies from TIPI register to external MEM
; with this that holds it in a scratchpad register first
	MOVB	@RDIN,R3	; assuming R3 is in TMS9995
	MOVB	R3,*R1+
; end of Geneve experiment

        INC     R0		; count the read ops
	C	R0,R4
	JNE	rnext		; if not done then go back and read next
rrt
	RT

also attached: plainasm.txt